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