提示缓存（一）：到底缓存了什么

有个说法流传很广：提示缓存省的是重复传输的 token。

这个说法是错的，而且错得有后果——它会让你以为缓存是个网络层优化，于是把注意力放错地方。

prompt 每次都要完整发给服务端，一个字都不会少传。省下的是服务端算它的那一遍。

搞清楚这件事之后，后面所有反直觉的现象都能解释：为什么改一个空格就全盘失效、为什么开启缓存可能比不开更贵、为什么同一个模型换个云跑成本模型就变了。

这是系列第一篇，只讲原理。第二篇比五家模型厂商和三家云的当期账单差异，第三篇讲工程上真正会把缓存打穿的那些坑，第四篇是在 Bedrock 上的实测——顺手测出了官方文档的一处错误。

一、缓存的是 prefill，不是流量#

先看一次请求在服务端被拆成什么。

Transformer 生成时，每个 token 都要对它之前的所有 token 做注意力。前面那些 token 的 K/V 投影算过一次就没必要再算，于是被缓存下来——这就是 KV cache。

一次请求分两段，特性完全不同：

Prefill 把整个 prompt 并行算完，一次前向传播搞定，算力密集。10 万 token 的上下文，这一段就是实打实的一大坨浮点运算。

Decode 逐 token 生成，每生成一个都要读一遍上面那份 KV，显存带宽密集。

prompt caching 干的事就是：把 prefill 算出来的那份 KV state 跨请求留下来。下次发来同样的前缀，服务端认出来，跳过 prefill 直接进 decode。

所以它的收益是两重的——省钱（读取价约是输入价的 10%）和省首 token 延迟（prefill 那一大坨算力不用再花）。后者在 agent 场景里常常比省钱更值钱。

顺带一个推论：缓存对输出不产生任何影响。 官方文档明确写了，模型基于缓存的前缀重新生成，采样过程不变，所以两次相同请求该不一样还是不一样。它纯粹是省了重复计算，不是把答案存下来了。这和很多人第一反应的「结果缓存」是两码事。

二、为什么必须逐 token 一致#

既然缓存的是 KV state，那能不能只改一个词、复用剩下的？

不能。而理由就藏在注意力的定义里。

注意力是因果的——第 k 个 token 的 K/V 依赖它前面所有 token。你把第 5 个 token 改了，第 5 个之后每一个 token 的 KV 都算错了。

所以缓存只能按前缀匹配，而且是逐 token 完全一致的前缀。服务端通常按块（常见 64 token 一块）对前缀做哈希，命中就跳过那一段。

由此得出这个领域唯一一条铁律：

静态内容放前面，易变内容放后面。

system prompt、工具定义、参考文档放前面；时间戳、session ID、用户本轮输入放后面。

一个动态时间戳插在 prompt 开头，整条缓存归零。而且它不会报错——推理照常成功，回答照常正确，只有账单变贵。这是这类 bug 最难受的地方，后面第三篇会专门讲。

三家厂商都在文档里点名了这个场景。OpenAI 给了一条很实用的建议：只用于日志或调试的动态值，塞进 request metadata，别塞进 prompt。

层级顺序也是前缀的一部分#

Anthropic 把前缀的层级定得很明确：tools → system → messages。改动前面一层，后面所有层的缓存一起失效。

改工具定义的名称、描述或参数，三层全部作废。

OpenAI 的表述更直白：工具定义、工具顺序、结构化输出的 schema 都参与构成前缀。

「工具顺序也算」这一条，是实际工程里最容易踩的——你的工具列表如果是从一个 map 里收集出来的，或者由插件动态注册，顺序可能每次进程重启都不一样。第三篇会给出可复现的例子。

三、TTL 为什么必须存在，以及它是滑动的#

KV state 很大。10 万 token 在大模型上是几十 GB 量级，占着 HBM 或 SSD。厂商不可能永久替你存着，所以必须淘汰。

于是有了 TTL。而这里有两个细节决定了实际怎么调参。

第一，TTL 在读取时刷新，而且刷新不额外收费。

Anthropic 文档明写：缓存每次被使用时都会刷新，不额外计费。这是滑动窗口，不是从写入起固定计时。

整个「保温」（keepalive）思路就立在这条上面——停顿期间定时重发同一个前缀，把窗口一直续下去。而这不是社区野路子：Anthropic 官方文档直接建议，5 分钟档要保温就至少每 5 分钟发一次预热请求，并为此提供了专门的 max_tokens: 0 请求形式，读入 prompt、写缓存、立刻返回，输出 token 不计费。

第二，间隔一旦超过 TTL，这个优化会反转符号。

这是我认为最值得记住的一点。假设 TTL 是 5 分钟而你每 8 分钟 ping 一次，那么每一次 ping 都落在一个已经死掉的缓存上。于是它不再是一次便宜的读取，而是一次全价 prefill，外加一次写入费。

本该花 0.1× 的动作变成花 1.25×，单次贵 12.5 倍，而且你在反复做。Maxim Khailo 在他的跨厂商保温实测里测过这一格：Anthropic 上用 8 分钟间隔，账单是完全不 ping 的 4 倍。

绝大多数调参调错了只是效果变差。这个参数有一道悬崖——过了线，优化本身变成病灶。

一个容易忽略的时序陷阱#

Anthropic 文档里还有一句，我第一次读漏了：

生命周期从写入或读取缓存的那个请求「开始」时刻计算，不是从响应结束。生成响应花的时间要算进 TTL。

举个例子就明白严重性：一个流式输出跑了 4 分钟的响应，那么复用同一前缀的后续请求，必须在它完成后约 1 分钟内发出。

这意味着社区流传的「4 分钟最优间隔」是空转条件下的结论。真实 agent 负载里，一次带扩展思考的长回复流两三分钟很常见，而这段时间全部计入那 5 分钟。你的安全间隔要比 4 分钟更短，短多少取决于你自己响应时长的分布。

顺便说一句，Aider 是最早公开实现缓存保温的工具（v0.53.0 起有 --cache-keepalive-pings），它用的间隔是 5 分钟——正好踩在 Anthropic 的 TTL 边缘上。按上面这条规则，在流式长响应的场景下这个间隔有越界风险。这是个可以自己测出来的点。

四、写入不是免费的，所以缓存可能让你更贵#

最后一块拼图：缓存写入本身要花钱。

• Anthropic：5 分钟档写入 1.25× 基准输入价，1 小时档 2×，读取 0.1×
• OpenAI：GPT-5.6 之前写入免费；从 GPT-5.6 起写入收 1.25×
• Bedrock 上的 Claude：与 Anthropic 一方 API 完全一致的 1.25× / 2× / 0.1×
• Gemini：读取统一 90% off（即 0.1×），但显式缓存另外按 token-hour 收存储费

把这几个数字放一起，一个结论浮出来：

如果你的前缀每次都在变，开启缓存比不开更贵。

因为你每次都付了写入溢价，却永远读不到。这不是假想——第三篇里那些「代理层静默删掉缓存标记」的案例，最终账单长的就是这个样子：功能正常、日志干净、成本上升。

还有一个更隐蔽的门槛：前缀太短会静默不缓存。

各家都有最小可缓存 token 数，不达标时的行为是——推理成功、不缓存、不报错。Anthropic 文档标的门槛按模型从 512 到 4096 不等。

而这些数字本身也未必可靠：我在 Bedrock 上实测过 Claude Sonnet 4.5，真实门槛是 1,024，而 AWS 文档写的是 4,096，差 4 倍。同一套方法测的另外三个模型倒是都和文档吻合。所以门槛这种数字，用之前值得自己验一次——两个请求就够，方法在实测篇。

小结#

四条，按重要性排：

缓存的是服务端的 prefill 算力，不是网络流量。 收益是省钱加省首 token 延迟，且不改变输出内容。

前缀必须逐 token 一致，改动点之后全部连带作废。 由此只有一条铁律：静态在前，易变在后。工具定义和工具顺序都算前缀。

TTL 是滑动窗口，读取免费刷新——但它从请求开始计时，流式输出的时间也算。 间隔超过 TTL 会让优化反转成 4 倍成本。

写入要付溢价，前缀不稳就是净亏。 而前缀太短会静默不缓存——门槛因模型而异，且文档给的数字未必准。

下一篇把五家模型厂商和三家云的当期倍率、TTL 档位、最小门槛、跨区域路由摊开来比，算清楚在哪家、什么停顿长度下该拧哪个旋钮。

写作时点是 2026 年 8 月中旬，文中所有价格与倍率都来自当期官方文档并附在文末参考文献里。这个领域的定价半衰期短得惊人——就在我整理这批数据的当天，其中一家刚改了计价方式。抄结论之前请自己核一遍。