# 提示缓存（二）：五家厂商三家云的账单差异 > AWS 文档说 Claude Sonnet 4.5 在 Bedrock 上要 4096 token 才能缓存，我实测是 1024——和一方 API 一样。本文对照五家模型厂商与三家云的当期倍率、TTL 档位、跨区域行为，并区分哪些数字是实测的、哪些只是文档值。 - 作者: zhuermu - 发布: 2026-08-17 - 网页版: https://zhuermu.com/blog/prompt-cache-2-platform-comparison/ --- **先说结论。** 同一个模型换个平台，**缓存倍率可能一模一样，行为一定不一样，而文档本身还可能是错的。** 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 倍。完整数据在[实测篇](/blog/prompt-cache-4-bedrock-threshold-test/)。 所以本文的对照表里，凡是我实测过的都标了实测值，没测过的标明是文档值。**这两类要分开看**，因为它们的可信度不一样。 如果你在做跨云选型或迁移，这篇给你四张对照表和一份逐平台的配置清单。如果你只用一家，直接跳到对应那一节，看你手上那个旋钮存不存在。 数据全部来自 2026 年 8 月中旬的当期官方文档与我自己的实测，来源附在文末。**这个领域的定价半衰期短得惊人**——就在我整理这批数据的当天，DeepSeek 改了计价方式，Azure 也在改。抄结论之前请自己核一遍。 上一篇讲了[提示缓存（一）](/blog/prompt-cache-1-how-it-works/)——省的是 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 那篇[跨厂商保温实测](https://blog.mempko.com/your-agentic-workflows-cache-keepalive-costs-8x-too-much-v2-the-interval-frontier/)里给了一个很有用的公式： ``` 盈亏平衡空闲时长 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 文档整体不可信——就是具体那一行数据不对。详细的二分过程和成本在[实测篇](/blog/prompt-cache-4-bedrock-threshold-test/)。 **其余平台的门槛我没有实测，以下是文档值**，按上面的经历，用之前请自己验一次： 一方 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 计数器](/tools/token-counter/) 量一下再决定测哪个区间。 ### 静默失败是这里最大的坑 无论门槛是多少，不达标时的行为都一样：**推理照常成功、前缀不缓存、不返回错误。** 唯一的检测方式是读响应里的 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 成本计算器](/tools/llm-cost-calculator/) 算一遍，比抄任何人的结论都靠谱——尤其是 Vertex 那个「每小时命中 4 次」的门槛，换个模型换个前缀长度就会变。 **同一个模型换平台，价格可能一样，行为一定不一样——而文档本身也可能是错的。** Claude Sonnet 4.5 的缓存倍率在 Bedrock 和一方 API 完全一致，最小前缀我实测两边都是 1,024，但 AWS 文档写的是 4,096。差异真正落在 1 小时档的覆盖模型、诊断工具的有无，以及失败时一律静默。 **先找旋钮，再考虑 ping。** 驻留控制有四种形态——买档位、免费开关、锁死不可调、按 token-hour 付租。发 ping 是没有旋钮时的补偿动作，不是默认动作。 **按 token-hour 计费会改变整个模型。** Vertex 显式缓存需要每小时命中 4 次左右才回本，它衡量的是复用频率而不是停顿长度。 **跨区域路由与缓存命中天然冲突，而多数厂商没有承诺。** 自己测有效命中率，别信推断。 [实测篇](/blog/prompt-cache-4-bedrock-threshold-test/)是这篇的经验补充：我在 Bedrock 上把四个模型的门槛逐个夹逼出来，其中一个和文档不符。[排查篇](/blog/prompt-cache-3-debugging-cache-misses/)则讲工程上真正会把缓存打穿的那些坑：序列化顺序不确定性、工具顺序、代理层静默删掉缓存标记，以及怎么用 usage 字段做一个自查脚本。 --- ## 常见问题 ### 同一个模型在不同云上，缓存价格一样吗？ Claude Sonnet 4.5 在 AWS Bedrock 上的缓存倍率与 Anthropic 一方 API 完全一致——5 分钟写入 1.25×、1 小时写入 2×、读取 0.1×。最小可缓存前缀我实测两边都是 1024（AWS 文档标的 4096 与实测不符）。真正的差异在 1 小时档的覆盖模型和有没有诊断工具。 ### 前缀不够最小 token 数会怎样？ 推理正常成功、正常返回，但不缓存，也不报错。唯一的发现途径是检查响应 usage 里的缓存读写计数，两个都是 0 说明压根没缓存。 ### Vertex 的显式缓存划算吗？ 取决于命中频率而不是停顿长度。它按 token-hour 收存储费，10 万 token 存一小时在 Gemini 2.5 Pro 上要 $0.45，而一次冷启重算只要 $0.125。按当期定价，一小时内需要命中 4 次左右才回本。 --- ## 参考资料 - [Prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) — Anthropic 官方文档 - [Prompt caching](https://platform.openai.com/docs/guides/prompt-caching) — OpenAI 官方文档 - [Pricing](https://platform.openai.com/docs/pricing) — OpenAI 官方定价页 - [Prompt caching for faster model inference](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html) — AWS Bedrock 官方文档 - [Amazon Bedrock pricing](https://aws.amazon.com/bedrock/pricing/) — AWS 官方定价页 - [Prompt caching in Azure AI Foundry Models](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching) — Microsoft 官方文档 - [Context caching](https://cloud.google.com/vertex-ai/generative-ai/docs/context-cache/context-cache-overview) — Google Cloud 官方文档 - [Models & Pricing](https://api-docs.deepseek.com/quick_start/pricing/) — DeepSeek 官方文档 - [Your Agentic Workflow's Cache Keepalive Costs 8x Too Much (v2)](https://blog.mempko.com/your-agentic-workflows-cache-keepalive-costs-8x-too-much-v2-the-interval-frontier/) — Maxim Khailo，跨厂商保温实测