提示缓存（二）：五家厂商三家云的账单差异

先说结论。

同一个模型换个平台，缓存倍率可能一模一样，行为一定不一样，而文档本身还可能是错的。

Claude Sonnet 4.5 在 Bedrock 上的缓存倍率与 Anthropic 一方 API 一字不差——5 分钟写入 1.25×、1 小时写入 2×、读取 0.1×。真正的差异在三处：最小可缓存前缀、1 小时档的覆盖模型、以及有没有诊断工具。而这三处的失败全部是静默的。

关于最小前缀，我原本按官方文档写了「一方 API 1,024、Azure 2,048、Bedrock 4,096，差 4 倍」。后来我在 Bedrock 上做了二十多次夹逼调用，实测门槛是 1,024，和一方 API 一样——文档那一行错了 4 倍。完整数据在实测篇。

所以本文的对照表里，凡是我实测过的都标了实测值，没测过的标明是文档值。这两类要分开看，因为它们的可信度不一样。

如果你在做跨云选型或迁移，这篇给你四张对照表和一份逐平台的配置清单。如果你只用一家，直接跳到对应那一节，看你手上那个旋钮存不存在。

数据全部来自 2026 年 8 月中旬的当期官方文档与我自己的实测，来源附在文末。这个领域的定价半衰期短得惊人——就在我整理这批数据的当天，DeepSeek 改了计价方式，Azure 也在改。抄结论之前请自己核一遍。

上一篇讲了提示缓存（一）——省的是 prefill 算力、前缀必须逐 token 一致、TTL 是滑动窗口。这篇假设你已经知道这些。

一、当期倍率总表#

先把五家模型厂商的三个关键数字摊开。倍率是相对基准输入价的倍数：

	读取	写入	TTL	可调？
Anthropic 5 分钟档	0.1×	1.25×	5 分钟	选档
Anthropic 1 小时档	0.1×	2.0×	1 小时	选档
OpenAI GPT-5.6+	0.1×	1.25×	固定 30 分钟	否
OpenAI ≤5.5	0.1×	免费	5–10 分钟 或 24 小时	是，且两档同价
Gemini 隐式	0.1×	免费	不承诺，上限 24 小时	否
Gemini 显式	0.1×	免费	默认 1 小时，无上限	是，但按 token-hour 付租
DeepSeek V4 Pro	≈0.033×	1.0×	未公开承诺	否

一眼能看出两件事。

第一，OpenAI 在代际之间断裂了。 GPT-5.6 之前缓存写入免费、驻留时长可以用一个参数拉到 24 小时；从 5.6 起写入开始收 1.25×，TTL 锁死 30 分钟不可调（prompt_cache_options.ttl 唯一合法值就是 30m）。同一家厂商，两代模型的成本模型完全不同。

第二，DeepSeek 的读写比值是所有厂商里最极端的。 它的命中价约是未命中价的 1/30——而其他家普遍是 1/10。这个比值直接决定了「缓存能撑多久还划算」，后面第四节会算。

顺带说一个流传很广的错误推论#

Maxim Khailo 那篇跨厂商保温实测里给了一个很有用的公式：

盈亏平衡空闲时长  T ≈ τ · (w/r − 1)
   τ = 保温间隔，w = 重算倍率，r = 读取倍率

这个公式本身是对的，但它推 DeepSeek 的那步不成立。原文说 DeepSeek「冷启重算只要两分钱，所以不管怎么调间隔，ping 的成本都超过它防住的淘汰」。

问题在于：w 和 r 都是同一个基准价的倍数，所以绝对便宜在比值里约掉了。 重算便宜，ping 也按同一个比例一起便宜。平衡点在时间轴上的位置只由 w/r 决定，绝对价格只决定这笔账有多大。

而 DeepSeek 的 w/r 是四家里最大的。按它自己的公式，DeepSeek 应该拥有最宽的盈利区间，而不是「永不划算」。

这不是抓错，是个值得记住的思维习惯：看到「因为便宜所以不值得优化」这种推论，先检查便宜的那一项是不是两边都便宜。

二、最小前缀：实测值和文档值要分开看#

这一节我原本写的是「同一个模型三个平台三个门槛」，全部引自官方文档。后来去实测了，结果需要修正。

Bedrock 上的实测结果（每个模型两次夹逼调用，判定标准是 usage 里 cacheWrite/cacheRead 任一非零）：

模型	AWS 文档	实测下界（不缓存）	实测上界（缓存）	判定
Claude Sonnet 4.5	4,096	999	1,054	❌ 文档偏高 4 倍
Claude Sonnet 4.6	1,024	1,000	1,055	✅ 吻合
Claude Sonnet 5	表中未列	983	1,055	实测 1,024
GPT-5.6 Terra	1,024	817	1,504	✅ 吻合

四个模型的真实门槛全部是 1,024。文档里唯一与实测不符的是 Sonnet 4.5 那一行。 三个对照模型都吻合，说明不是测法有问题，也不是 Bedrock 文档整体不可信——就是具体那一行数据不对。详细的二分过程和成本在实测篇。

其余平台的门槛我没有实测，以下是文档值，按上面的经历，用之前请自己验一次：

一方 API 按模型（文档值）：

模型	最小前缀
Opus 5 / Fable 5 / Mythos 5	512
Sonnet 5 / 4.6 / 4.5、Opus 4.8	1,024
Mythos Preview、Opus 4.7	2,048
Opus 4.6 / 4.5、Haiku 4.5	4,096

注意 Haiku 4.5 文档标的是 4,096，比 Opus 5 的 512 高 8 倍——最便宜的模型反而门槛最高。不过鉴于 Sonnet 4.5 那一行的前例，这个数字也值得自己验。

Azure AI Foundry 上的 Claude 文档值是 2,048。Gemini 侧按代际递增：

Gemini 2 系（2.5 Pro / Flash / Flash-Lite）        2,048
Gemini 3 系（3.5 / 3.6 / 3.7 Flash）              4,096
Gemini 3.0 Flash Preview / 3.1 Pro Preview        6,144

验一次只要两个请求#

这是实测那篇最实用的产出：拿一个刚好在你怀疑的门槛附近的前缀，用相同内容发两次，读 usage。第一次应该有 write，第二次应该有 read；两个都是 0 就说明没达门槛。

两个请求、几分钱、一分钟。 相对于「门槛记错 4 倍导致缓存整年没生效」的代价，这个投入不值得省。

想知道自己 system prompt 加工具定义有多少 token，用 token 计数器 量一下再决定测哪个区间。

静默失败是这里最大的坑#

无论门槛是多少，不达标时的行为都一样：推理照常成功、前缀不缓存、不返回错误。

唯一的检测方式是读响应里的 usage。三家字段名还都不一样：

Anthropic   usage.cache_creation_input_tokens
            usage.cache_read_input_tokens

Bedrock     usage.cacheWriteInputTokens
            usage.cacheReadInputTokens
            总输入 = inputTokens + cacheRead + cacheWrite

OpenAI      usage.input_tokens_details.{cached_tokens, cache_write_tokens}
Azure       usage.prompt_tokens_details.{cached_tokens, cache_write_tokens}
Gemini      usage.total_cached_tokens / cachedContentTokenCount

三家的 inputTokens / input_tokens 都只表示「未命中也未写入」的那部分，不是总输入。这是最容易把成本算错的地方——你以为在看总量，其实在看余量。实测时我那个 4,401 token 的前缀，命中后 inputTokens 只显示 15。

而诊断工具只有一方 API 有#

Anthropic 提供了 Cache Diagnostics（beta，header cache-diagnosis-2026-04-07）：让 API 比较相邻两次请求，直接告诉你前缀在哪一块分岔，还带类型化的失效原因——model_changed、system_changed、tools_changed、messages_changed 等等。

限制写在文档里：Claude API only，Bedrock 与 Google Cloud 都不支持。

把这两条放一起看，结论有点讽刺：门槛数字最不可靠、失败又最静默的平台，恰好也是拿不到诊断工具的平台。

三、驻留控制有四种形态，而 ping 是最差的那种#

这是我认为最值得写下来的一节。

关于缓存保温，社区的默认动作是「定时发 ping 刷新 TTL」。但把五家的文档摊开会发现，「让缓存活下去」这件事有四种完全不同的实现路径，而发 ping 只是其中最笨的一种：

Anthropic       驻留是「买」的     5m(1.25×) 或 1h(2.0×) → 先算该买哪档
OpenAI ≤5.5     驻留是「免费开关」  prompt_cache_retention: "24h" → 根本不用 ping
Azure（12 个模型）同上             同一个参数，官方列出支持清单
OpenAI 5.6+     驻留不可选         固定 30m，且写入开始收费 → ping 变危险
Gemini 显式     驻留是「租」的     按 token-hour 付存储费，TTL 无上限
Bedrock         继承模型，但会少档  4.6 系没有 1h 档 → 可能只剩 ping 这条路

所以正确的问法不是「该多久 ping 一次」，而是：这个平台给了我驻留旋钮吗？给了就拧旋钮，没给才发 ping。

具体到每一家：

Anthropic —— 买哪档有个明确的切换点。 用官方倍率能直接算。设停顿 T 分钟，单位是基准输入价的倍数：

5 分钟档 + 4 分钟 ping       0.025 × T
1 小时档（60 分钟内零 ping）  额外 0.75×（2.0 减 1.25）

相等于 T ≈ 30 分钟。所以：

停顿 < 30 分钟    5 分钟档 + 约 4 分钟 ping
停顿 30–60 分钟   1 小时档，一次写入，不用 ping
停顿 > 60 分钟    1 小时档 + 约 50 分钟 ping

OpenAI ≤5.5 和 Azure 的那批模型 —— 一个免费参数就够了。 设 prompt_cache_retention: "24h"，驻留从「不活动 5–10 分钟就清、最多 1 小时」拉到最长 24 小时。文档明确写了同时支持两种策略的模型两档同价。Azure 侧列了 12 个支持的模型，gpt-5.5 默认就是扩展档。

在这批模型上，整个「保温该多久 ping 一次」的问题根本不存在。

Azure 上还有一个几乎没人提的杠杆： 预置吞吐（PTU-M）部署的 cached input 最高 100% 折扣，也就是免费。代价是不支持缓存断点、不报 cache_write_tokens。如果你已经买了 PTU，这笔便宜是白给的。

四、Vertex 显式缓存：一个原文框架套不上去的情况#

Gemini 的显式缓存是唯一按持有时间收费的：CachedContent 对象按 token-hour 计存储费，默认 TTL 60 分钟，最短 1 分钟，没有上限（文档原话 “There isn’t a maximum cache duration”），还能用 patch 续期。

当期存储单价（定价页表头是 Price Tok/hr，即每 token 每小时）：

Gemini 2.5 Pro / 3.1 Pro          $0.0000045 /token/hr  =  $4.50 / 1M token·hr
Gemini 2.5 / 3.5 / 3.6 / 3.7 Flash $0.000001  /token/hr  =  $1.00 / 1M token·hr

拿 10 万 token 前缀算一笔，结果是反直觉的：

Gemini 2.5 Pro
  存储 1 小时      100,000 × $0.0000045          = $0.45
  一次冷启重算      100,000 / 1M × $1.25         = $0.125

存一小时比直接重算贵 3.6 倍。

这说明 Vertex 的显式缓存不是「停顿保险」，而是「高频复用工具」。它的经济学和 ping 完全不同：

显式缓存总成本 = 存储单价 × token 数 × 持有时长 + N × 命中价
不缓存总成本   = N × 标准 input 价

解回本命中次数 N：

Gemini 2.5 Pro    $4.50 / ($1.25 − $0.125)  = 4.0
Gemini 2.5 Flash  $1.00 / ($0.30 − $0.03)   = 3.7

结论很整齐：按当期定价，Vertex 显式缓存需要「每小时命中 4 次左右」才回本，Pro 和 Flash 几乎一样。持有两小时就要 8 次。

注意这个公式里没有 τ——因为它不发 ping。上一节引的 T ≈ τ(w/r − 1) 假设「持有成本 = ping 成本」，在这里结构就不对。这是原文那个框架的边界，它测的四家里没有按 token-hour 计费的，所以没碰到。

Gemini 隐式缓存则是另一回事： 官方给了上界（博客里写「隐式缓存在 24 小时或更短时间内被清除」）但不承诺任何下界，只给启发式建议——大而通用的内容放前面、短时间内发相似前缀。所以你测不出一条可依赖的保留曲线。这一点和 Khailo 实测出的「Gemini 的命中率是路由抽奖，不是保留曲线」正好互相印证：一边是黑盒实测，一边是官方的沉默。

五、跨区域推理：四家里三家在关键问题上沉默#

跨区域路由为了可用性和吞吐，把请求调度到最优区域。而缓存绑定在具体机器或区域上。这两件事在架构上就是冲突的。

OpenAI 把机制讲得最透，而它讲透的内容就是答案：

• 缓存绑在单台机器的 GPU-local storage 上。文档原话是缓存只在两个请求共享同一前缀且落到同一台机器时才生效
• 路由按 prompt 前约 256 个 token 的哈希决定；prompt_cache_key 与该哈希组合，提高落到同一引擎的概率，但官方明说是 best-effort，不保证
• 每个 prefix + key 组合约 15 请求/分钟的软上限。 超了不报错、不拒绝，系统把多余请求摊到更多机器，每台新机器都是一次一次性 miss

最后一条对 agent 集群是个真实的坑：如果你所有实例共用一个 cache key，命中率会随规模反向下滑，而且没有任何报错提示你。高并发要按 key 分片，同时保持 key 与前缀的稳定映射。

Bedrock 官方承认跨区域会增加缓存写入。 文档在功能列表里把「Prompt Caching with Cross-region Inference」列为支持的组合，同时写明高需求时段这些优化可能导致 cache writes 增加。

这句话的确切含义，核心文档没有展开。AWS re:Post 上一篇 Sr TAM 署名文章补了一句解释：缓存是 per-Region 的，路由到某区域的请求不会命中另一区域建立的缓存——所以每个区域各写一份。

但要说清来源层级：这句话在 re:Post，不在核心文档。 我让两个独立的调研线分别查了 AWS 文档，都没在核心文档里找到「缓存作用域是区域级还是机器级」的明确表述。所以准确的说法是：官方承认跨区域会增加缓存写入，但从未公开缓存的作用域。 re:Post 那篇给的解释合理且来自 AWS 员工，可以当作强线索，不宜当作契约。

官方也没有建议为命中率改用单区域端点，只建议同时监控区域内和跨区域指标。

Azure 和 Vertex 则在关键问题上完全没写。

Azure 明确的只有一句：缓存不跨 Azure subscription 共享。同一 subscription 内 Global 部署是否跨区共享缓存、是否该为命中率选 Regional 而非 Global——文档里找不到。

Vertex 更矛盾：文档说 context caching 支持 global endpoint，但 CachedContent 是 region-scoped 资源（路径里带 location），且缓存存储在创建请求所在区域。用 global endpoint 时请求被路由到别的区域能否命中——也没写。

所以这一节能交付的不是配置清单，而是一个判断：跨区域路由和缓存命中在架构上冲突，而四家里三家没有承诺任何行为。你只能自己用 usage 字段测出有效命中率。 给一份假装确定的最佳实践反而更危险。

数据驻留会让缓存也一起变贵#

两条容易漏掉的加价：

• Anthropic：Claude 4.6 及以后，用 inference_geo 指定 US-only 推理，对所有 token 计费类别施加 1.1× 倍率，明确包含 cache writes 和 cache reads
• OpenAI：区域处理端点对 2026-03-05 之后发布的模型加价 10%

也就是说，开了数据驻留之后，你的每一次保温 ping 也贵了 10%。做合规约束下的成本估算时别忘了这一项。

六、逐平台配置清单#

把上面所有东西压成可执行的动作。

Anthropic 一方 API 按停顿长度选档：30 分钟以内用 5 分钟档配约 4 分钟 ping；30–60 分钟直接买 1 小时档、不 ping；超过 1 小时用 1 小时档配约 50 分钟 ping。ping 用 max_tokens: 0（官方预热形式，输出不计费，取代旧的 max_tokens: 1 土办法）。开 Cache Diagnostics 排查。注意 TTL 从请求开始计时、流式输出时间计入，所以真实间隔要比理论值更短。

AWS Bedrock 先自己验一次最小前缀，别照抄文档——我实测 Sonnet 4.5 是 1,024 而文档写 4,096。再确认要用的模型有没有 1 小时档：Opus 4.6、Sonnet 4.6 在 Bedrock 上只有 5 分钟。缓存按 tools → system → messages 三段累加计算最小 token 数，不是每段单独算。跑缓存实验时把 CRIS 作为受控变量。缓存不支持批量推理 API。Bedrock 上的 GPT-5.6 不走 Converse API——发 cachePoint 会报 AccessDeniedException，要用 invoke-model 配 prompt_cache_breakpoint。

Azure OpenAI / AI Foundry 先查你的模型属于哪一代：GPT-5.5 及更早，一个 prompt_cache_retention: "24h" 就够了，两档同价；GPT-5.6+ 则 TTL 锁死 30 分钟，且写入开始收费，要在稳定内容后放显式断点并用 explicit 模式避免把易变后缀也写进缓存。已经买了 PTU-M 的话，cached input 最高 100% 折扣，白捡。Claude 在 Foundry 上走 Anthropic 原生 cache_control，最小前缀 2,048，且缓存读取不计入 ITPM。

Google Vertex AI 先判断你是「高频复用」还是「长停顿」。高频复用（每小时命中 4 次以上）用显式缓存，TTL 按需设、没有上限；长停顿或低频访问就别用显式缓存，存储费会吃掉收益。隐式缓存不用配也不保证，把大而通用的内容放最前面就是你能做的全部。注意 Gemini 3 系门槛已升到 4,096、预览版 6,144。

OpenAI 一方 API 必须设 prompt_cache_key（GPT-5.6 上是启用可靠匹配的必需项），并按每个 key 约 15 请求/分钟分片。≤5.5 的模型直接开 24 小时驻留。5.6+ 用 explicit 模式把易变后缀挡在断点外，避免反复付写入费。盯 cache_write_tokens 持续高而 cached_tokens 持续低——那是断点位置错了的信号。

DeepSeek 读写比值约 1/30，是主流厂商里最有利的，缓存值得用。但它不公开承诺保留时长，只能自己测。另外 2026-08-16 起改成峰谷分时计价，谷时价是峰时一半，而峰时窗口（01:00–04:00 与 06:00–10:00 UTC）换成北京时间正好是 09:00–12:00 与 14:00–18:00，精准覆盖国内工作时间。批处理、CI、回归测试挪到夜间直接省一半。

小结#

上面所有数字都是拿 10 万 token 前缀举例的，而你的前缀长度、命中频率、停顿分布都跟我不一样。把自己的量代进 LLM 成本计算器 算一遍，比抄任何人的结论都靠谱——尤其是 Vertex 那个「每小时命中 4 次」的门槛，换个模型换个前缀长度就会变。

同一个模型换平台，价格可能一样，行为一定不一样——而文档本身也可能是错的。 Claude Sonnet 4.5 的缓存倍率在 Bedrock 和一方 API 完全一致，最小前缀我实测两边都是 1,024，但 AWS 文档写的是 4,096。差异真正落在 1 小时档的覆盖模型、诊断工具的有无，以及失败时一律静默。

先找旋钮，再考虑 ping。 驻留控制有四种形态——买档位、免费开关、锁死不可调、按 token-hour 付租。发 ping 是没有旋钮时的补偿动作，不是默认动作。

按 token-hour 计费会改变整个模型。 Vertex 显式缓存需要每小时命中 4 次左右才回本，它衡量的是复用频率而不是停顿长度。

跨区域路由与缓存命中天然冲突，而多数厂商没有承诺。 自己测有效命中率，别信推断。

实测篇是这篇的经验补充：我在 Bedrock 上把四个模型的门槛逐个夹逼出来，其中一个和文档不符。排查篇则讲工程上真正会把缓存打穿的那些坑：序列化顺序不确定性、工具顺序、代理层静默删掉缓存标记，以及怎么用 usage 字段做一个自查脚本。