LLM 提示缓存 #2：对比 Claude、GPT、Gemini、DeepSeek

太长不看 —— 五家主流 LLM 提供商以五种截然不同的形态暴露提示缓存：显式标记（Claude）、全自动（GPT-5、DeepSeek-v4）、隐式+显式混合（Gemini、Qwen），或架构层面的磁盘落地（DeepSeek 的 MLA）。本文给你逐项功能对比，以及一套五维评估框架，帮你针对自己的工作负载给它们打分——成本、命中率可预测性、延迟、TTL 契合度和 API 易用性。架构背景见第 1 篇：缓存原理；实测数字与可运行的 Python 见第 3 篇：教程。

系列：全 4 篇之第 2 篇 · 上一篇：第 1 篇 —— 缓存原理 · 下一篇：第 3 篇 —— 可运行代码教程 · 第 4 篇 —— 按用例选最佳 LLM

1. LLM 缓存类型分类法

在逐家提供商展开之前，有四个设计维度值得先厘清：

1.1 控制方式：显式 vs 隐式 vs 混合

• 显式 —— 开发者标记提示中哪些部分要缓存（Anthropic Claude cache_control）。控制力最强；需要改代码。
• 隐式 / 自动 —— 提供商自动检测匹配的前缀（OpenAI GPT-5、DeepSeek-v4）。零代码改动；无法强制命中。
• 混合 —— 两种模式都可用；按调用逐次选择（Gemini、Qwen）。

1.2 持久化：内存 vs 磁盘落地

由提供商的 KV 缓存架构决定，而非 API 表层决定。

• 内存（HBM） —— 缓存存活于 GPU 内存，存活时间短（分钟级），最小分块大（1,024 个 token）。大多数提供商的默认方式。
• 磁盘落地 —— 缓存持久化到 SSD/NVMe，TTL 长得多、粒度更细。DeepSeek 已大规模上线此能力，得益于其多头潜在注意力（MLA）压缩，将 KV 缓存缩小约 4 倍（DeepSeek-AI，2024）。

1.3 粒度：匹配分辨率

多小的前缀就能拿到折扣？

• 64 个 token —— DeepSeek（业界最细）
• 128 个 token —— OpenAI（匹配增量）
• 1,024 个 token —— Claude、OpenAI、Gemini、Qwen 的最小可缓存分块

更细的粒度意味着部分前缀重叠也能算数——对小幅提示变动宽容得多。

1.4 对象模型：逐调用标记 vs 命名缓存对象

• 逐调用标记 —— 每个请求内联要缓存的内容，由提供商做哈希（Claude、OpenAI、DeepSeek、Qwen 隐式）。
• 命名缓存对象 —— 开发者通过单独的 API 调用创建缓存，拿到 cache_id，后续引用它（Gemini 显式、Qwen 显式）。以额外的仪式感换取显式的生命周期控制。

这四个维度相互交织。一家提供商的方案，就是由它在每个维度上的位置来描述的。下一节会逐家展开。

2. 逐家提供商深度剖析

2.1 Anthropic Claude —— 显式、内存、1,024-token 粒度

主力模型（2026-05）： claude-haiku-4-5、claude-sonnet-4-5 / 4-6、claude-opus-4-5 / 4-6 / 4-7。

缓存 API。 在你的 system 或 messages 数组中任意位置最多标记四个 cache_control 断点。缓存命中花费约为基础输入费率的 10%；缓存写入花费 125%（25% 的溢价）。默认 TTL 为 5 分钟滑动（每次命中都重置），另有 1 小时选项。

定价形态。 Anthropic 在其定价页按模型公布每百万 token 费率；缓存折扣在整个系列中保持一致。对于 claude-sonnet-4-5 上一个 8,000-token 的 system 提示、每天 10 万次调用，一旦前缀变热，每次调用成本大约下降 8–10 倍——单次命中即可回本。

TTL 行为。 默认 5 分钟滑动——每次命中都把过期时间往后推 5 分钟。1 小时 TTL 让写入成本翻倍，但对任何空闲间隔 > 5 分钟的工作负载都是必需的。

粒度。 1,024-token 最小值。哈希基于精确的 token 序列；最前面改一个字符就会让整个前缀失效。

API 易用性。 最高。多断点设计让你能独立缓存”永不变”+“很少变”+“逐任务变”——对于提示各段以不同节奏变化的 agent 与 RAG 工作负载，这是同类最佳。

坑点。

• 忘了加 cache_control 就意味着完全没有缓存——不像 GPT 或 DeepSeek，这里没有隐式兜底。
• 缓存哈希即便在 tool/function 数组内部也对顺序敏感——要确定性地排序它们。
• 5 分钟默认值让 Claude 不适合没有显式保活的零散批处理任务。
• 如果你通过网关调用 Claude，请确认网关支持 Anthropic 原生的 /v1/messages 路径并带 cache_control 标记（OpenAI 兼容的 /chat/completions 路径通常不会传递这些标记——用指向网关 base URL 的 Anthropic SDK）。

最适合。 长上下文 agent、带稳定 system 提示的多轮对话、带分层缓存的结构化 RAG。

2.2 OpenAI GPT-5.x —— 自动、内存、1,024-token 粒度

主力模型（2026-05）： gpt-5.4-nano、gpt-5.4-mini、gpt-5.2、gpt-5.4-pro、gpt-5.5-pro。代码用的 Codex 变体：gpt-5.2-codex、gpt-5.3-codex。

缓存 API。 无需操作——对每个 ≥1,024 token 的请求自动生效。缓存命中按输入费率的 50% 计费；无写入溢价。匹配增量：128 个 token。

定价形态。 OpenAI 在其定价页公布每百万 token 费率。缓存输入打 5 折；输出不变。

实测（2026-05-25，约 6,900-token system 提示）：

* gpt-5.4-mini 命中那一轮的补全远短于未命中那一轮；此处的成本差混入了缓存折扣与补全长度的变化。5 倍的延迟下降（3.63 → 0.73 s）才是更干净的信号。

TTL 行为。 确切数值未公布；现场报告显示 5–60 分钟不等，取决于负载和前缀热度。热门的共享前缀存活更久（LRU 偏向它们）。

API 易用性。 微不足道——现有代码照常运行。记录 prompt_tokens_details.cached_tokens 来度量命中率。

坑点。

• 无法强制命中。如果你的流量产生唯一前缀，你什么都拿不到。
• 5 折的折扣比 Claude/DeepSeek 的 90%/75% 浅（与 Gemini 隐式的约 25% 相当）。
• 流式有时只在最后一个 chunk 报告缓存命中——要仔细埋点并传 stream_options={"include_usage": True}。

最适合。 已有的用 GPT 的代码库，改造成本超过边际节省。前缀重复天然较高的突发流量。

2.3 Google Gemini —— 混合、内存、命名缓存对象

主力模型（2026-05）： gemini-2.5-flash、gemini-2.5-pro、gemini-3-flash-preview、gemini-3.1-pro-preview、gemini-3.1-flash-lite-preview。

缓存 API。 两种模式：

• 隐式：自动，像 GPT 一样。缓存 token 按输入费率的约 25% 计费。无存储费、无需设置。
• 显式：通过单独的 API 调用创建一个 cachedContent 对象。在后续请求中按名称引用它。缓存 token 按约 10%（更低）计费，但你要按每百万 token 支付一笔每小时的存储费。

定价形态。 长上下文是 Gemini 的强项；定价按上下文长度档位递增（低于 20 万 vs 高于 20 万的阈值，对应更高的每 token 费率）。

实测（2026-05-25）：

TTL 行为。 隐式：分钟级，未披露。显式：开发者设置，默认 1 小时，最高 24 小时。

API 易用性。 显式缓存需要两步流程（创建 → 引用）。cachedContent 的生命周期（创建、更新 TTL、删除）由你负责。

坑点。

• 存储费是低用量显式缓存的致命伤。 始终按你的调用频率计算回本点。
• 隐式缓存命中率波动大；不要依赖它做成本建模。
• 缓存对象绑定区域——多区域应用需要复制缓存。
• gemini-*-pro 是推理模型：max_tokens 太小时，补全会被隐藏的思考消耗掉，你会看到 completion_tokens=0。在任何面向用户的路径上把 max_tokens 提到 ≥256。

最适合。 一份大文档（>2 万 token）每小时被查询 10+ 次。视频问答。对企业 PDF 的多模态 RAG。

2.4 DeepSeek-v4 —— 自动、磁盘落地、64-token 粒度

主力模型（2026-05）： deepseek-v4-flash（通用），deepseek-v4-flash（本代也覆盖 coder 类工作负载）。

缓存 API。 自动，像 GPT 一样——但由 MLA 压缩驱动，使缓存紧凑到足以持久化到磁盘。缓存命中按输入费率的约 25% 计费；无写入溢价。最小匹配：64 个 token。

定价形态。 DeepSeek 定价页以人民币计价。命中率大致折算为 75% 的输入成本削减。

实测（2026-05-25）：

TTL 行为。 小时级，对高流量前缀有时更久。磁盘落地存储意味着缓存能挺过会让其他厂商内存缓存被驱逐的 GPU 内存压力。

粒度。 64-token 最小值是业界最小的。小幅提示编辑会让大部分前缀仍然匹配，而不是像 1,024-token 提供商那样完全失效。

API 易用性。 OpenAI 形态的 API；换 base URL 即可。标准的 prompt_tokens_details.cached_tokens 字段。

坑点。

• 仅限 DeepSeek 系列模型。无法将此缓存用于其他模型家族。
• 英文上质量优异，但在最难的推理基准上落后于 Claude/GPT-5。

最适合。 中文工作负载（成本）。粒度重要的高频前缀工作负载（检索顺序不稳定的 RAG）。成本敏感的批处理任务。

2.5 阿里 Qwen3 —— 混合、内存、命名缓存对象 + 隐式

主力模型（2026-05）： qwen3-max、qwen3.5-plus、qwen3.5-flash。视觉变体：qwen3-vl-plus、qwen3-vl-flash。

缓存 API。 两种模式：

• 隐式：常开，像 GPT 一样。缓存部分按输入费率的约 20% 计费。
• 显式：通过 API 创建带自定义 TTL 的缓存。命中约 10%，写入 125%。

实测（2026-05-25）：

TTL 行为。 默认 5 分钟，可按缓存对象配置。显式为滑动窗口；隐式为短的固定 TTL。

API 易用性。 隐式是 GPT 形态（零工作量）。显式是带缓存生命周期的两步流程。

坑点。

• 目前只有 qwen3-max 和 qwen3.5-plus 支持显式缓存。
• 多区域（新加坡、美国）可用性正在逐步推出——在依赖它处理非中国数据前请确认区域。
• 相对 Anthropic/OpenAI 的文档存在缺口——建议做经验性测试。

最适合。 需要严格缓存控制的中国企业工作负载。已在阿里云上的客户。

3. 并排对比

3.1 折扣结构（厂商文档，2026-05）

3.2 TTL、粒度与持久化

3.3 在 7K-token 前缀上的实测延迟（2026-05-25）

† Claude 各行是通过 Anthropic 原生 /v1/messages 端点带 cache_control 标记测得的（见第 3 篇 §2）。Claude 最大的收益在成本上（输入约省 88–89%——完整成本表见第 3 篇 §2）；按 Anthropic 公布的数字，对于 10 万+ token 的提示，TTFT 改善会急剧放大。

单次顺序运行，无并发负载。你的数字会随区域、时段和竞争租户负载而变动。

4. 五维评估框架

像”Claude 省 90%“这样的标题很有意思，但很少能告诉你该选什么。针对你自己的工作负载，给每家提供商在这五个维度上打分，然后按你在意的程度加权。

4.1 每百万 token 的有效成本（按命中率加权）

不要比基础价——要比你真实命中率下的期望成本：

effective_cost = base × (1 - hit_rate × (1 - discount)) + write_premium × write_rate

70% 前缀重复（典型聊天机器人）的算例：

• Claude：约 90% 折扣 × 0.7 命中 + 25% 写入 × 0.3 → 有效 ≈ base × 0.45
• GPT-5：约 50% × 0.7 + 0 → 有效 ≈ base × 0.65
• Gemini 隐式：约 75% × 0.7 + 0 → 有效 ≈ base × 0.48
• DeepSeek-v4：约 75% × 0.7 + 0 → 有效 ≈ base × 0.48

乘以每家厂商各自的实际基础费率（各家不同）才能得到可比的美元数字。打分：为你的工作负载计算 effective_cost；越低越好。

4.2 命中率可预测性

• 显式缓存者（Claude、Qwen 显式、Gemini 显式）—— 可预测性高。你标了它，它就会命中（TTL 内）。
• 自动缓存者（GPT-5、DeepSeek-v4、Gemini 隐式、Qwen 隐式）—— 取决于前缀相似度以及提供商负载（LRU 驱逐）。

对于与成本挂钩的 SLA，优先选显式。对于尽力而为的优化，自动也行。

4.3 TTL ↔ 流量节奏契合度

4.4 缓存未命中下的延迟

一家命中快但未命中慢的提供商，如果你的命中率不高，仍然有问题。比较 §3.3 里的两个数字，并按期望命中率加权。

4.5 API 易用性与迁移成本

• 迁移成本最低：GPT-5 ↔ DeepSeek-v4（都是 OpenAI 形态，都是自动缓存）。
• 中等：GPT-5 → Gemini 隐式（不同 SDK，无缓存代码要重写）。
• 高：GPT-5 → Claude（必须加 cache_control，重构提示分层）。
• 最高：在没有网关的情况下从任意单家迁到多提供商（多套缓存 API）。

5. 按工作负载形态的快速结论

6. 迁移考量

如果你的打分说该换，有三件事要规划：

数据迁移。 缓存前缀不会在提供商之间转移——每次切换都是冷启动。为预热期预留几个小时高于平常的成本。

提示重新架构。 Anthropic 的多断点设计鼓励一种分层提示结构，它对任何提供商其实都更好——重构一次也惠及非 Claude 路径。

通过网关对冲。 如果你拿不准，就通过一个 Token Gateway 路由。你保留了可选性而不必押注单一厂商，代价是多一跳，以及（取决于网关）可能失去对厂商专属缓存控制的访问。关于 Synthorai 网关实际做了什么、以及哪些说法你该持怀疑态度，见第 3 篇 §9。

7. 随时间变化的内容

关于这些对比的持久性提个醒：本文中的数字会变动。缓存已成为价格竞争性的特性，提供商每隔几个月就更新其方案。有两件事值得关注：

• TTL 延长。 Anthropic 的 1 小时选项已正式可用；Gemini 可能延伸到多天。预期 TTL 焦虑会缓解。
• 粒度。 OpenAI 和 Anthropic 最终很可能放弃其 1,024-token 最小值；DeepSeek 的 64-token 门槛已设立了新的预期。

当折扣趋同时，差异化因素将变成 API 易用性和延迟——而非标题上的节省。

下篇预告：第 3 篇 —— 提示缓存教程：可运行的 Python 把上面的架构图景变成可运行的代码，并把 §3.3 的延迟表复现为一个你可以自己跑的基准测试。

常见问题

综合各方面考虑，哪家 LLM 提供商的提示缓存最便宜？ 在同等命中率（约 75%）下，按我们 2026-05 的实测，中文工作负载选 deepseek-v4-flash、英文选 gemini-2.5-flash 隐式，是每百万 token 有效成本最便宜的。claude-sonnet-4-5 拥有最深的单次调用折扣（约 90%）但基础价更高——当命中率 >85% 时它胜出。把你自己的命中率代入 §4.1 的公式。

为什么 Gemini 在低用量工作负载上更贵？ 显式缓存的每小时存储费会吃掉折扣，除非你频繁查询缓存。对于低用量工作负载，用 Gemini 隐式缓存（无存储费，约 25% 折扣）。

我能把 Claude 的 cache_control 用在 OpenAI 上吗？ 不能直接用——它们是各自独立的缓存实现。在 OpenAI 兼容的 /chat/completions 端点上，该字段对非 Anthropic 模型通常是个空操作（那些模型本来就自动缓存）。对于 Claude 具体而言，请用 Anthropic 原生的 /v1/messages 端点并带上标记。

DeepSeek 的 MLA 架构是专有的吗？ 论文（DeepSeek-AI 2024）是公开的。其他提供商可以采用 MLA 式的 KV 压缩，但这需要重新训练基础模型——不是一个运行时开关。截至 2026-05，DeepSeek 仍是唯一在生产中上线它的主流提供商。

开源自托管模型怎么样？ vLLM、SGLang 和其他推理引擎原生支持前缀缓存（PagedAttention 论文是其基础）。如果你在 H100/H200 上自托管，可以用 LMCache 或类似方案实现磁盘落地缓存。这里的定价分析只适用于托管服务——自托管的经济账完全不同。

为什么这个对比里没有 Mistral、Cohere 或 Llama API 提供商？ 截至 2026-05，它们的缓存方案不够成熟。Mistral 的缓存在早期试用阶段；Cohere 不暴露显式缓存；Llama API 提供商（Groq、Together、Replicate）差异很大。等它们的特性集稳定后再回头看。

来源：Anthropic Prompt Caching · OpenAI Prompt Caching · Google Gemini Context Caching · DeepSeek KV Cache · Alibaba Bailian Context Cache · DeepSeek-V2 / MLA paper · PagedAttention / vLLM (Kwon et al. 2023)。实测数字来自 https://synthorai.io/v1，于 2026-05-25 测得。

← 返回博客