Prompt缓存：RAG场景实测可降成本10倍

你的 Agent RAG 上了生产，流量翻三倍，API 账单也翻三倍。你开始砍 context、换更便宜的模型、压缩 system prompt——回答质量下降了，成本却没按预期降下来。

大多数 LLM 定价表里都有第三行价格——cached input 的价格，但几乎没人把它放进对比 spreadsheet 里。本文展示如何开启它、三个让它悄无声息返回 0 的陷阱，以及如何在几分钟内自行在你的 stack 上验证。

你的账单大部分是重复 token

Dev.to 上一位作者实测了 prompt caching 的真实成本，并公布了全部数据。文章拆解了一个典型的客服 RAG prompt——据作者称是真实测量值，非估算：

组件	Token	占比	性质
System prompt	96	32%	每个 request 都相同
Retrieved context	1434	48%	在一个 session 内通常稳定
Conversation history	551	18%	头部稳定
User message	62	2%	唯一真正新的部分

测量结论：其中 98% 是重复内容，正在被全额计费。对于 Agent 和 RAG 工作负载，这才是钱真正花在哪里——不在于 prompt 长短。

Anthropic 的缓存需要你主动请求

这是最值得注意的发现。作者把同一个约 2600 token 的 system prompt 两次发送给 Claude Sonnet，间隔十分钟，经由一个 API gateway。在没有配置缓存的情况下：

cold: input=2253 cached=0 cost=$0.00470600
warm: input=2251 cached=0 cost=$0.00464200

文章写道："Nothing cached. Full price both times. No error, no warning, no hint that a 90% discount was available." response 里没有任何信号告诉你正在全额付款。

还是那个 prompt，给 system message 加上 cache_control marker（示例说明，非生产代码）：

"messages": [
  {"role": "system", "content": [
     {"type": "text", "text": PREFIX,
      "cache_control": {"type": "ephemeral"}}]},
  {"role": "user", "content": question}
]

cold: input=2628 cached=0    written=2614 cost=$0.00676300
warm: input=2626 cached=2614 written=0    cost=$0.00068680

作者结论：从第二个 request 起便宜了 90%。但注意 cold 的数字：$0.00676 对比不缓存时的 $0.00464——贵了约 46%。这是缓存写入溢价。第二个 request 开始你才获利；如果 prompt 只发送一次，缓存反而让你亏钱。

OpenAI 默认缓存，但有阈值

同样的测试，换成 GPT-4o-mini，不做任何配置：

cold: input=1355 cached=0    cost=$0.00021525  1737ms
warm: input=1355 cached=1280 cost=$0.00011145  1223ms

1355 个 input token 中有 1280 个来自缓存——文章记录便宜了 48%、快了 30%，且没有改一行代码。如果你的团队假设所有 provider 的 caching 都是自动的，Anthropic 那部分流量可能正在多花冤枉钱，而且没有任何信号提示你。

三个让缓存命中归零的陷阱

缓存按 prefix 匹配，且是精确匹配。作者把 prompt 开头只改了一个字符：cached 从 1280 变成 0，后面所有 token 都要重新按原价处理。这直接关系到 prompt 的构建方式：

System prompt 开头放 timestamp、user ID、session ID——文章明确指出这些会让每个 request 的缓存全部失效。原则：稳定内容放前面，动态内容放后面。

Prefix 太短——据文章，OpenAI 对 1024 token 以下（更老的 model 是 2048）不做缓存。低于阈值时全额付款且不会收到任何错误；cached_tokens 只返回 0。作者本人差点公布了一个 317 token prompt 的节省数据——它根本没法缓存。

TTL 太短——缓存条目在约五分钟后不活跃就过期（Anthropic 有一小时付费窗口）。陷阱很微妙：文章称 Anthropic 从 request 开始时计算缓存寿命，生成时间也会从中扣除。一个四分钟的响应 stream 只剩约一分钟给下一个 request 来得及命中。

还有一个不受控制的因素：据文章，OpenAI 的缓存状态在每台具体机器上，在约 15 请求/分钟的量级上，overflow routing 可能把 request 打到没有匹配条目的机器上——prompt_cache_key 参数存在就是为了改善这个问题。因此 hit rate 部分是基础设施属性，不只是 prompt 的问题。

缓存支持是选模型的标准，不只是 config

作者拉取了他所用平台上全部 393 个 model 的价格：248 个（63%）有缓存价格，145 个没有。最低降幅 1.0 倍，中位数恰好 10 倍，最高 120.8 倍。

两个含义：约三分之一 model 不支持 caching，所以它必须从一开始就被纳入选模型标准；以及 1.0 倍的条目——据文章是 Granite 8B 或 gpt-oss-20b 这类小型 open-weight model——不是陷阱，只是缓存对它们没有经济意义，因为 input 本身就几乎免费。

相比其他降本手段

作者在同一 workload 上测量了三个手段：

手段	效果	质量代价
换成更便宜的 model	最高 26 倍	回答改变
缓存稳定 prefix	39–90%	无
裁剪 retrieved context	约 60%	约 10%，回答改变

作者的评价：caching 是不需要牺牲质量就能降本的唯一手段——同样的 token，更低的价格。这就是为什么应该先处理 caching，再优化 prompt 或降级 model：后两个手段影响输出，这个不影响。

本周检查你的 stack

根据这些测量数据暴露的问题，做事的顺序应该是：

用相同 prefix 调用 API 两次，间隔几秒，读取 usage 中的 cached_tokens。返回 0 意味着你还没有缓存任何东西。

统计你的稳定 prefix 的 token 数。低于 1024 token 就不要对 OpenAI 抱期望——把更多稳定内容合并到前面。

用 grep 搜索 prompt 模板，找到 timestamp、user ID、session ID 放在静态内容之前的位置。全部移到末尾。

对于 Anthropic，给 system message 加上 cache_control，接受第一个 request 更贵。

检查你正在使用的 model 是否公布了 cached input 价格。

需要跟踪的说明：文章明确指出这是 2026 年 8 月 25 日通过单一 gateway 跑的测量值，这个领域的价格每周都在变，而且全量目录数字是公布价格而非真实流量——只有 cold/warm 两次测试是直接测量的。Bedrock 和 Vertex 有各自的 caching 实现，尚未被测量。如果你的生产环境跑在这两个平台上，在相信上面任何数字之前先自己测。