什么是大模型的 Cache？
简单说：Cache 就是”记住算过的东西，下次不用重新算”。
当你给 AI（比如 ChatGPT、Claude）发消息时，AI 需要先”读懂”你发的所有文字，这个过程很耗计算资源。如果你下次发的消息前半段和上次一样，AI 可以直接用上次算好的结果，只处理新增的部分。
这就是 Cache——把计算结果存起来复用。
用一个生活比喻
想象你去一家餐厅，每次点餐都要把菜单从头看到尾：
- 没有 Cache：每次去都重新看完 200 页菜单，再告诉服务员你要什么
- 有 Cache：服务员记住了你上次看到第 180 页的进度，这次你只需要从第 180 页看起
AI 处理文字就像”看菜单”，Cache 就是”记住看到哪里了”。
Cache 的两种类型
1. Prompt Cache（提示词缓存）
最常见，也是最重要的。
当你每次调用 AI 时，发送的内容通常分两部分：
[系统提示词 - 固定不变] + [用户的具体问题 - 每次不同]
比如：
- 系统提示词（固定）：”你是一个客服助手，以下是我们的产品手册……（5000字）”
- 用户问题（变化）：”退货流程是什么？”
没有 Cache 时：每次用户提问，AI 都要重新处理那 5000 字的产品手册。
有 Cache 时：第一次处理完产品手册后，结果被缓存。后续用户提问时，AI 直接复用缓存，只处理新的问题。
效果：
- ⚡ 速度快 2-3 倍（跳过了重复处理）
- 💰 费用降低 50-90%（缓存命中的部分按折扣计费）
2. KV Cache（键值缓存）
这是 AI 内部的技术细节，非技术人员只需要知道：
KV Cache 是 AI “思考”过程中的临时记忆。它让 AI 在生成回答时不用每个字都从头想，而是基于之前想好的中间结果继续。
这个对用户是透明的，AI 框架自动处理。
Cache 命中率是什么？
Cache 命中率 = 复用了缓存的比例。
- 命中率 80% → 80% 的内容不用重新计算，只有 20% 是新的
- 命中率 0% → 完全没用上缓存，所有内容都重新计算了
命中率越高，速度越快、费用越低。
如何提高 Cache 命中率？
✅ 方法 1：保持提示词前缀一致
最重要的一条规则：Cache 从头开始匹配，遇到第一个不同的地方就停止。
好的例子 ✅
请求1: [系统提示A] + [问题1]
请求2: [系统提示A] + [问题2] ← 系统提示A 完全一样，命中缓存！
坏的例子 ❌
请求1: [系统提示A] + [问题1]
请求2: [系统提示B] + [问题2] ← 开头就不同，完全不命中
关键：不要在提示词开头放变化的内容（比如时间戳、随机 ID）。把变化的内容放在最后。
✅ 方法 2：固定内容放前面，变化内容放后面
推荐的消息结构：
┌─────────────────────────┐
│ 系统提示词（固定） │ ← 会被缓存
│ 参考文档/知识库（固定） │ ← 会被缓存
│ 对话历史（逐渐增长） │ ← 部分缓存
│ 用户当前问题（每次不同） │ ← 不缓存，但很短
└─────────────────────────┘
✅ 方法 3：提示词长度要够（不同厂商有最低门槛）
各厂商对缓存有最小长度要求：
| 厂商 | 最低缓存长度 | 备注 |
|---|---|---|
| Anthropic (Claude) | 1024 tokens (~800字) | 自动缓存，无需手动开启 |
| OpenAI (GPT) | 1024 tokens | 自动缓存 |
| Google (Gemini) | 32,768 tokens | 需要手动标记缓存区域 |
如果你的提示词太短（比如只有一句话），就达不到缓存门槛，不会生效。
✅ 方法 4：减少不必要的提示词变动
每次修改提示词模板都会让缓存失效。如果提示词稳定不变，缓存就能一直复用。
✅ 方法 5：使用对话历史
多轮对话天然适合缓存——每一轮新消息只在末尾追加，前面的历史消息保持不变，所以历史部分都能命中缓存。
费用影响
以 Anthropic Claude 为例：
| 场景 | 输入价格 | 说明 |
|---|---|---|
| 无缓存 | $3 / 百万 token | 完整价格 |
| 缓存命中 | $0.3 / 百万 token | 便宜 90% |
| 首次写入缓存 | $3.75 / 百万 token | 第一次贵 25%，但后续都便宜 |
举例：你有一个 5000 token 的系统提示词，每天调用 1000 次。
- 无缓存：5000 × 1000 × \(3/M = **\)15/天**
- 有缓存（假设 95% 命中）：首次 \(0.02 + 命中 \)1.43 = $1.45/天，节省 90%
常见误区
❌ “Cache 需要手动开启”
大多数厂商（Anthropic、OpenAI）的 Prompt Cache 是自动的，不需要任何代码修改。只要你的请求前缀相同，就会自动命中。
❌ “Cache 会让回答变得一样”
不会。Cache 只是跳过了”理解你的提示词”的步骤，AI 仍然会根据你的具体问题生成不同的回答。就像服务员记住了菜单不代表每次给你上一样的菜。
❌ “Cache 会泄露其他用户的数据”
不会。Cache 是按请求内容精确匹配的，而且同一账号内隔离。不同用户的缓存互不影响。
❌ “用了 Cache 回答质量会下降”
完全不会。Cache 复用的是中间计算结果，和从头计算是完全等价的，输出质量没有任何区别。
总结
| 项目 | 说明 |
|---|---|
| Cache 是什么 | 记住算过的东西，下次不重新算 |
| 核心好处 | 更快、更便宜 |
| 最重要的优化 | 保持提示词前缀不变 |
| 费用节省 | 最高可达 90% |
| 需要开发吗 | 大多数情况不需要，自动生效 |
一句话：让你发给 AI 的内容尽量”前面不变、后面变”，缓存就能自动帮你省钱加速。
补充：LiteLLM 代理的缓存层
如果你用 LiteLLM 做 API 代理（统一管理多家大模型），它有两层完全不同的缓存：
第一层：Provider Prompt Cache（透传，自动生效）
这就是前面讲的 Prompt Cache，由 OpenAI/Anthropic/Deepseek 等厂商自己实现。LiteLLM 只是透传，不需要额外配置。
各厂商支持情况：
| Provider | 触发条件 | 特殊参数 |
|---|---|---|
| OpenAI | 1024+ tokens，自动 | prompt_cache_key（路由提示，提高命中率）、prompt_cache_retention="24h"（延长缓存） |
| Anthropic | 1024+ tokens | 需要在 message 中标记 cache_control: {type: "ephemeral"}（Anthropic 对写入缓存额外收费） |
| Deepseek | 自动 | 同 OpenAI 方式 |
| Bedrock | 看具体模型 | 部分模型支持 |
LiteLLM 会统一返回缓存命中信息：
{
"usage": {
"prompt_tokens": 2006,
"prompt_tokens_details": {
"cached_tokens": 1920
}
}
}
cached_tokens 就是命中缓存的 token 数。
特点：每次回答仍然不同，只是省了”理解提示词”的计算。
第二层：LiteLLM 应用层缓存（需要主动开启）
这是 LiteLLM 自己实现的缓存，完全相同的请求直接返回之前的结果，不再调用 API。
支持多种后端：
| 后端 | 适合场景 |
|---|---|
| In-Memory | 单机、测试用 |
| Redis | 生产环境，多实例共享 |
| Redis Semantic | 语义相似的问题也能命中（用 embedding 匹配） |
| S3 / GCS | 持久化存储，适合离线分析 |
| Disk | 本地持久化 |
控制参数：
no-cache：强制调 API，不用缓存no-store：不把结果写入缓存ttl：缓存有效期（秒）s-maxage：只接受多少秒内的缓存
⚠️ 注意：这层缓存会返回完全一样的回答。适合确定性查询（比如”1+1等于几”），不适合需要多样性回答的场景。
两层缓存对比
| Provider Prompt Cache | LiteLLM 应用层缓存 | |
|---|---|---|
| 谁实现的 | OpenAI/Anthropic 等厂商 | LiteLLM 自己 |
| 是否调 API | 调（但更快更便宜） | 不调（直接返回旧结果） |
| 回答是否相同 | 不同（重新生成） | 相同（完全复用） |
| 是否自动 | 大多数厂商自动 | 需要主动配置 |
| 省钱幅度 | 50-90%（缓存 token 打折） | 100%（不产生 API 费用） |
| 风险 | 无 | 可能返回过时/不合适的回答 |
实际建议
- Provider Prompt Cache 不用管，自动生效，做好”前面不变后面变”就行
- LiteLLM 应用层缓存按需开启——高频重复查询可以省很多钱，但要注意回答可能过时
- Redis Semantic Cache 是个有趣的折中：语义相似的问题也能命中，但精确度不如精确匹配