同一个问题问两遍，第二遍明显更快，背后是推理缓存。它省掉的是重复计算，不是重复思考：大模型没有记住你的问题，只是把算过的中间结果留着复用。弄清它存什么、什么时候命中、什么时候失效，你就知道为什么有些应用越用越顺，也知道调整提示词顺序为什么会改变账单。
缓存存的到底是什么
大模型每生成一个 token，都要在每一层算一遍注意力。为了不重复算，推理框架会把已处理 token 的键值向量留在显存里，这就是常说的 KV 缓存。它原本只服务一次请求内部，逐字往外吐的时候反复使用。
前缀缓存把这个机制跨请求延长了：新请求的开头和上次完全一致时，框架直接复用那段键值，跳过前向计算。存的是张量而不是文字，所以它对"意思相同但措辞不同"完全不认。
另一种是结果缓存，存的是一整条问答。键通常是请求的哈希，包含模型名、提示词、采样参数。命中就直接返回，连推理都不跑。两者常被混为一谈，收益和风险差得很远。
命中的三个条件
前缀要逐 token 一致。注意是逐字，多一个空格、换一个标点，从差异那一处往后全部失效。命中率上不去时，先查这里。
要从开头算起。缓存的是前 N 个 token，不能只缓存中间一段。把变化的内容放前面，等于每次都在制造新前缀，后面的复用全部作废。
还要同模型、同版本、同参数。模型更新后旧缓存不再可用；温度、top_p 一变，结果缓存的键就变了。部分服务还限定同一账号或同一会话，具体规则以产品文档为准。
前缀缓存为什么更值钱
算一笔结构账。一段两千字的产品手册放在提示词开头，每来一个新问题都要重读一遍。没有缓存，这两千字的计算每次都要付；有缓存，只在首个请求付一次，后面都是读取。
省的不只是钱，还有首字延迟。长提示词场景下，等待时间里很大一部分花在读入阶段，命中后这段几乎消失；输出阶段快不快是另一回事，可以对照每秒输出多少 token来判断。
客服机器人、固定知识库问答、代码助手，都是系统提示很长、用户问题很短的结构，收益集中在这里。多轮对话则是另一种情况：每轮追加内容，前缀持续延长，只要开头不动，前几轮的部分仍可复用，这就是长对话越到后面越顺的原因。
什么情况下不生效
| 场景 | 现象 | 原因 |
|---|---|---|
| 提示词开头带时间戳或随机单号 | 每次都算满，命中率接近零 | 前缀从首个 token 就不同 |
| 每次按相关度重排参考资料 | 时快时慢，账单波动 | 内容相同但顺序变了，前缀不匹配 |
| 更换模型版本或精度 | 旧缓存全部作废 | 权重变了，键值不再对应 |
| 请求间隔超过保留时间 | 命中率随空闲时长下降 | 缓存有存活期，到期回收 |
| 只改结尾的追问 | 仍能命中 | 前缀未变，只有新增部分要算 |
表里最后一行常被误解：改结尾不影响命中，改开头影响全部。由此得到一条反直觉的写法——稳定的内容放前面，变量放后面。
把提示词写规范为什么省钱
三条做法。系统指令、角色设定、输出格式固定在开头，一字不改；参考资料按固定顺序拼接，别每次按相关度重排；用户的具体问题放最后。
必须带时间戳就放末尾，或者塞进用户消息里。这类细节看着琐碎，日调用量上万次时会直接体现在账单上。自己部署还要在框架里设缓存显存占比和淘汰策略，默认值通常按通用流量调，不一定适合你的场景；可部署的模型范围见开源权重模型。
它做不到什么
缓存不让答案变准。命中只代表跳过计算，输出质量和首次计算一致，错了还是错，缓存只是让错误答案返回得更快。
结果缓存有语义风险。问题字面相同、语境不同，"现在什么价""今天有货吗"这类带时效的提问，返回旧答案就是错的。带时间、库存、价格的内容不适合做结果缓存，或者必须设很短的有效期。
缓存还占显存。留得多，能给批处理的空间就少，吞吐反而下降。这个权衡在托管服务上你调不了，只能换规格。
三个容易混淆的问题
问：命中缓存能便宜多少？ 取决于服务方定价，有的对命中部分打折，有的把写入和读取分开计价，以官方计费说明为准。别按全部免费做预算。
问：自己部署需要单独开缓存吗？ 主流推理框架自带前缀复用，但要配显存比例和淘汰策略。流量以短请求为主时，给缓存留太多反而拖低并发。
问：缓存和量化能一起用吗？ 能，两者作用在不同环节：量化压缩权重，缓存复用中间结果，原理见模型量化。但量化会改变数值，切换精度后旧缓存不能混用。
缓存速查
- 前缀缓存存键值张量，结果缓存存整条问答
- 命中要求逐字一致、从开头算起、同模型同参数
- 稳定内容放前面，变量放最后
- 带时效的内容别做结果缓存
- 缓存占显存，留多留少都要试
