开头先说结论：大模型缓存命中，就是模型服务发现你这次请求里有一大段内容，和之前已经处理过的内容完全相同，于是不用重新“读一遍”，直接复用上次算好的中间结果。
这件事听起来像浏览器缓存，但本质更接近“把模型读过的前缀笔记保存下来”。它之所以能让计费便宜很多，是因为大模型最贵的一部分工作，往往不是吐出那几百个字，而是先把你塞进去的长上下文全部看懂。
一、一次大模型请求到底在花什么钱
我们平时说调用大模型，通常会分成两类 token：
- 输入 token：你发给模型的内容，比如系统提示词、工具说明、历史对话、文档、代码、知识库片段。
- 输出 token：模型生成给你的内容，也就是回答本身。
很多人直觉上以为“输出才是计算”，因为我们看到的是模型一个字一个字往外吐。但在真实服务里，输入同样要消耗大量计算：模型需要把每个输入 token 逐层处理，建立它们之间的注意力关系，形成后续生成时可复用的内部状态。
如果你的请求只有一句话，输入成本不明显；但如果你每次都带上几万字的系统提示、长文档、完整代码仓库片段，输入处理就会成为主要成本。
二、什么是缓存命中
大模型里的缓存，通常指的是 prefix cache，也就是“前缀缓存”。
如果两次请求的开头部分完全一样，比如：
- 相同的系统提示词
- 相同的角色设定
- 相同的工具说明
- 相同的长文档背景
- 相同的历史对话前半段
服务端就可以把第一次处理这些内容时产生的中间结果保存下来。第二次请求到来时，只要前缀一致，就不必重新计算这部分内容，而是直接复用。
这就叫缓存命中。
你可以把它想象成：第一次让模型读一本 200 页的产品手册，它需要从头读；第二次你还是拿同一本手册来问不同问题，模型服务发现“这本手册我刚读过”，于是直接翻到已经做好的读书笔记上，再处理你新问的那几句话。
三、为什么必须是“前缀”相同
这里有一个关键点：缓存命中通常要求相同内容出现在请求开头，并且 token 序列完全一致。
原因是 Transformer 模型处理文本时，后面的 token 会依赖前面的 token。服务端缓存的是“读到某个位置时的内部状态”。如果前面任何一个 token 变了，后面的状态都可能变，缓存就很难直接复用。
所以，下面这种组织方式更容易命中缓存：
- 固定系统提示词
- 固定工具说明
- 固定项目背景或文档
- 变化的用户问题放在最后
而下面这种方式就不友好：
- 每次在最前面插入当前时间、随机 ID、临时说明
- 把用户问题放在最前面
- 后面再拼接固定文档
哪怕固定文档本身没变，只要它前面多了不同内容，它就不再处于相同前缀位置，缓存命中率就会下降。
四、为什么缓存命中会便宜很多
便宜的核心原因很简单：已经算过的输入，不必完整再算一次。
大模型服务商的计费通常会把 token 分成几种价格：
- 普通输入 token：需要完整计算，价格较高。
- 缓存命中的输入 token：复用已有中间结果，价格显著更低。
- 输出 token：需要逐步生成，通常仍按正常输出价格计费。
以一些主流 API 的定价方式看，缓存命中的输入 token 可能只有普通输入价格的十分之一、二十分之一，甚至更低。不同厂商比例不一样，但方向一致：只要能复用，成本就会大幅下降。
这不是平台“打折促销”，而是计算成本真的低了。服务商少做了大量矩阵计算，自然可以把这部分价格压低。
五、一个直观例子
假设你做了一个代码助手，每次请求都带上：
- 2 万 token 的项目规范
- 5 万 token 的代码上下文
- 500 token 的用户问题
- 1000 token 的模型回答
如果没有缓存，每次都要重新处理前面 7 万多 token 的输入。
如果项目规范和代码上下文稳定，且都放在请求前缀里，那么第一次请求会正常计费；第二次、第三次、第四次，只要前缀命中，大部分输入就可以按缓存命中价格计算。你问的问题和模型回答仍然要正常算，但那 7 万 token 的“大头”会便宜很多。
这就是为什么在长上下文应用里，缓存命中能让账单差出一个数量级。
六、哪些场景最适合缓存
缓存命中最适合“固定大背景 + 多轮变化问题”的场景：
- 代码助手：固定仓库上下文，用户不断问不同问题。
- 文档问答：固定产品手册、合同、论文，用户连续追问。
- Agent 系统：固定系统提示词、工具说明、策略约束，每次只改变任务目标。
- 客服机器人：固定品牌话术、知识库片段、合规说明，多次服务不同问题。
- 内容生产：固定风格指南、栏目定位、选题背景，每次生成不同文章。
这些场景的共同点是：有一大段内容经常重复，而且可以稳定地放在请求开头。
七、怎样提高缓存命中率
想让缓存真正省钱，关键不是“打开某个开关”，而是调整请求结构。
- 把稳定内容放前面
系统提示词、工具定义、长文档、固定规则，尽量放在请求最前面。变化内容，比如当前问题、临时参数、用户输入，放在最后。
- 不要在前缀里塞随机变化
当前时间、请求 ID、用户昵称、动态标签、AB 实验参数，如果每次都不同，就不要放在最前面。它们会破坏后面整段前缀的复用。
- 保持文本序列完全一致
缓存按 token 序列匹配。多一个空格、换一种换行、JSON 字段顺序变化，都可能影响命中。工程上最好用稳定模板生成 prompt。
- 复用同一份上下文
如果文档内容没变，不要每次重新切分、重新排序、重新改写。固定顺序、固定格式，更容易命中。
- 注意缓存有生命周期
缓存不是永久保存。很多平台会设置时间窗口，比如几分钟到数小时不等。越密集的连续请求，越容易吃到缓存红利。
八、缓存命中不等于模型“记住了你”
这里也要澄清一个常见误解：缓存命中不是长期记忆。
它不代表模型真的把你的资料永久学会了，也不代表以后不用再传上下文。缓存只是服务端为了节省重复计算，在一段时间内保存了部分中间状态。
换句话说：缓存是计算优化，不是知识写入；是省钱提速，不是训练模型。
九、开发者应该关注什么指标
如果你在做 LLM 应用，建议至少关注这几个指标：
- cache hit tokens：命中的缓存输入 token 数。
- cache miss tokens：没有命中的普通输入 token 数。
- input/output token 成本占比：到底钱花在读上下文，还是花在生成回答。
- prompt 模板稳定性：同一个任务的固定前缀是否真的保持一致。
- 首次请求和后续请求的延迟差异：缓存命中通常也会让响应更快。
这些指标能帮助你判断：账单贵，到底是模型选太大了，输出太长了，还是上下文组织方式太浪费。
十、总结
大模型缓存命中，本质上是复用已经计算过的输入前缀。
它便宜很多，是因为模型不用反复处理同一大段上下文；服务商节省了真实计算量，所以缓存命中的输入 token 可以按更低价格计费。
对开发者来说，最重要的实践是：把不变的内容放在前面，把变化的内容放在后面，并尽量让固定前缀保持字面一致。
如果你的应用经常携带长提示词、长文档、长代码上下文，那么缓存命中不是一个小优化，而是决定成本结构的关键设计。
更多内容欢迎关注公众号：
