context caching可以降低成本

上下文缓存（Context Caching） 能降低成本，核心原因是它避免了重复计算。

---

先理解大模型 API 的计费逻辑

调用大模型 API 时，费用通常按 token 数量 计算：

> 总费用 = 输入 token 费用 + 输出 token 费用

其中输入 token 就是你所发送的 prompt，包括：
系统提示词（System Prompt）
知识库/文档内容
历史对话记录
用户当前问题

输出 token 就是模型生成的回答。

---

痛点：长上下文的"重复税"

想象这样一个场景：你开发了一个法律合同审查助手，每次请求都附带一本 5 万字的《合同法》作为参考文档：

第 1 次请求：
[5万字合同法] + [用户问题：租房押金怎么退？]
→ 模型要先把 5 万字全部"读一遍"（Prefill），再回答问题

第 2 次请求：
[5万字合同法] + [用户问题：违约金上限是多少？]
→ 模型又要重新把同样的 5 万字"读一遍"

第 100 次请求：
[5万字合同法] + [用户问题：...]
→ 还是重新读一遍！

问题在于：这 5 万字的《合同法》每次都是一模一样的，但模型每次都要重新做 Prefill 计算、重新生成 KV Cache。你在为同一份内容反复付费。

---

上下文缓存如何解决？

上下文缓存的本质是：把长上下文的 KV Cache 存起来，下次直接复用。

第 1 次请求：
[5万字合同法] + [用户问题1]
→ 模型读完 5 万字，生成 KV Cache → 系统把这份 KV Cache 存进缓存池

第 2 次请求：
[用户问题2] ← 只发送新问题！
→ 系统从缓存池取出上次存的 KV Cache
→ 模型只需处理"用户问题2"这几个新 token
→ 输出回答

成本降低来自两个层面：

1. 减少计算量
没有缓存时：每次请求都要对 5 万字做 Prefill 计算
有缓存时：只需对新追加的几个字做 Prefill，95% 的计算被跳过

2. API 定价更低
各大厂商（OpenAI、Anthropic、Google、阿里等）对缓存命中的 token 收取远低于普通输入的费用
例如：普通输入 10 元/百万 token，缓存命中可能只要 1-2 元/百万 token

---

典型应用场景

| 场景 | 重复部分 | 每次新增部分 | 节省效果 |
|------|---------|------------|---------|
| 代码助手 | 整个代码仓库（几万行） | 用户的新需求/修改 | 90%+ |
| 客服机器人 | 系统提示 + 产品知识库 | 用户当前问题 | 80%+ |
| 法律/医疗咨询 | 法典/医学指南 | 个案描述 | 85%+ |
| 多轮长对话 | 前 20 轮对话历史 | 用户最新一句话 | 70%+ |
| 小说续写 | 前 10 章内容 | 续写指令 | 90%+ |

---

一句话总结

> 上下文缓存 = "把模型已经读过并记住的内容存起来"，下次问相关问题时不用再读一遍。你省了重复计算的钱，API 厂商省了重复计算的算力，双赢。

这也是为什么 Kimi 论文里提到的"前缀缓存池"（Prefix Cache）在大规模推理系统中如此重要——它不仅提速，更是直接省钱。