哪家 LLM 提示词缓存最便宜？5 家提供商横向对比（2026）

TL;DR — 五家主流 LLM 提供商采用了五种差异很大的提示词缓存方案：显式标记（Claude）、全自动（GPT-5.x、DeepSeek-v4）、隐式与显式混合（Gemini、Qwen），以及由底层架构支持的磁盘缓存（DeepSeek 的 MLA）。本文逐项对比这些方案，并提供一个适用于实际工作负载的 5 维评估框架，涵盖成本、命中率可预测性、延迟、TTL 匹配度和 API 易用性。架构原理见第 1 篇：缓存原理；实测数据和可运行的 Python 代码见第 3 篇：教程。

系列文章：第 2 篇，共 5 篇 · 上一篇：第 1 篇 — 缓存原理 · 下一篇：第 3 篇 — 可运行代码教程 · 第 4 篇 — 不同场景下的最佳 LLM · 第 5 篇 — LangChain 集成

1. LLM 缓存类型划分

在逐家分析之前，先明确四个设计维度：

1.1 控制方式：显式、隐式与混合

• 显式 — 开发者标记提示词中需要缓存的部分（Anthropic Claude 的 cache_control）。控制力最强，但需要修改代码。
• 隐式 / 自动 — 提供商自动检测相同前缀（OpenAI GPT-5.x、DeepSeek-v4）。无需修改代码，但无法强制命中。
• 混合 — 两种模式都支持，可按请求选择（Gemini、Qwen）。

1.2 持久化方式：内存与磁盘

持久化方式由提供商的 KV cache 架构决定，与 API 形式无关。

• 内存（HBM） — 缓存存放在 GPU 显存中，生命周期较短，通常只有几分钟；最小缓存块较大，为 1,024 个 token。大多数提供商默认采用这种方式。
• 磁盘 — 缓存持久化到 SSD/NVMe，TTL 更长，粒度也更细。DeepSeek 已大规模部署这种方案。其 Multi-head Latent Attention（MLA）压缩可将 KV cache 缩小约 4×（DeepSeek-AI，2024）。

1.3 粒度：匹配精度

前缀最短需要多少 token，才能获得缓存折扣？

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

粒度越细，部分前缀重合也越容易计入缓存。提示词出现小幅变化时，容错性会高得多。

1.4 对象模型：单次请求标记与具名缓存对象

• 单次请求标记 — 每次请求都内联需要缓存的内容，由提供商计算哈希（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。

GPT-5.6 更新（2026-06）： GPT-5.6 系列修改了以下规则。缓存写入现在按输入价格的 1.25x 计费；要稳定匹配，必须提供 prompt_cache_key；同时新增了显式的 30 分钟 TTL 断点。本文表格描述的是 GPT-5.5/5.4 的行为；5.6 参见 GPT-5.6 成本指南和我们的缓存最小值实测。

缓存 API。 可以在 system 或 messages 数组中的任意位置设置最多四个 cache_control 断点。缓存命中价格约为基础输入价格的 10%；缓存写入按 125% 计费，溢价 25%。默认 TTL 为滑动式 5 分钟，每次命中都会重新计时；也可选 1 小时。

价格结构。 Anthropic 在定价页公布各模型每百万 token 的价格，整个模型系列的缓存折扣比例一致。以 claude-sonnet-4-5 为例，如果 system prompt 为 8,000 个 token、每天调用 100K 次，前缀预热后，单次调用成本大约可降至原来的 1/8 至 1/10；只需命中一次即可回本。

TTL 行为。 默认采用滑动式 5 分钟 TTL，每次命中都会将过期时间再延后 5 分钟。1 小时 TTL 会让写入成本翻倍，但只要工作负载的空闲间隔超过 5 分钟，这个选项就很有必要。

粒度。 最小 1,024 个 token。哈希基于完全一致的 token 序列；前部改动一个字符，就会让整个前缀失效。

API 易用性。 最强。多断点设计可以分别缓存“永不变化”“偶尔变化”和“按任务变化”的内容。对于提示词各部分更新频率不同的 agent 和 RAG 工作负载，这是目前最成熟的方案。

注意事项。

• 如果忘记添加 cache_control，就完全不会缓存。它不像 GPT 或 DeepSeek 那样有隐式缓存兜底。
• 即使在 tool/function 数组内部，缓存哈希也对顺序敏感。必须使用确定性的排序。
• 对于没有显式保活机制、调用零散的批处理任务，默认 5 分钟 TTL 并不合适。
• 如果通过 gateway 调用 Claude，需要确认 gateway 支持 Anthropic 原生 /v1/messages 路径和 cache_control 标记。兼容 OpenAI 的 /chat/completions 路径通常不会透传这些标记，应将 Anthropic SDK 的 base URL 指向 gateway。

最适合。 长上下文 agent、system prompt 稳定的多轮对话、采用分层缓存的结构化 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。代码模型包括 gpt-5.2-codex、gpt-5.3-codex。

缓存 API。 无需任何操作。所有不少于 1,024 个 token 的请求都会自动缓存。缓存命中按输入价格的 50% 计费，没有写入溢价。匹配增量为 128 个 token。

价格结构。 OpenAI 在定价页公布每百万 token 的价格。缓存输入减免 50%，输出价格不变。

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

* gpt-5.4-mini 在命中轮次生成的 completion 比未命中轮次短很多，因此这里的成本差异同时受缓存折扣和 completion 长度变化影响。延迟下降 5×（3.63 → 0.73 s）是更可靠的信号。

TTL 行为。 OpenAI 没有公布确切值。根据实际使用反馈，TTL 会随负载和前缀热度变化，大约为 5–60 分钟。大量请求共享的热门前缀会保留更久，因为 LRU 会优先保留它们。

API 易用性。 几乎没有接入成本，现有代码可以直接使用。记录 prompt_tokens_details.cached_tokens 即可统计命中率。

注意事项。

• 无法强制命中。如果流量中的前缀几乎都不重复，就没有任何收益。
• 50% 的折扣低于 Claude/DeepSeek 的 90/75%，与 Gemini 隐式缓存约 25% 的输入价格相比也更浅。
• streaming 有时只在最后一个 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 的强项。价格按上下文长度分档；低于 200K 与超过 200K 的 token 采用不同费率，后者单 token 价格更高。

实测（2026-05-25）：

TTL 行为。 隐式缓存为数分钟，具体时长未公开。显式缓存由开发者设置，默认 1 小时，最长 24 小时。

API 易用性。 显式缓存需要两步：创建 → 引用。cachedContent 的创建、TTL 更新和删除都由调用方负责。

注意事项。

• 对低调用量的显式缓存来说，存储费会抵消大部分收益。 一定要按实际调用频率计算盈亏平衡点。
• 隐式缓存的命中率不稳定，不要直接用它做确定性的成本建模。
• 缓存对象绑定地域。多地域应用需要分别创建缓存。
• gemini-*-pro 是 reasoning 模型。如果 max_tokens 太小，completion 预算会被隐藏的思考过程消耗，最终会看到 completion_tokens=0。所有面向用户的调用都应将 max_tokens 提高到至少 256。

最适合。 对同一份大型文档（超过 20K 个 token）每小时查询 10 次以上的场景、视频问答、基于企业 PDF 的多模态 RAG。

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

主力模型（2026-05）： deepseek-v4-flash（通用；这一代也用它处理 coder 工作负载）。

缓存 API。 与 GPT 一样全自动，但底层采用 MLA 压缩，使缓存足够紧凑，可以持久化到磁盘。缓存命中按输入价格的约 25% 计费，没有写入溢价。最小匹配长度为 64 个 token。

价格结构。 DeepSeek 定价页以人民币标价。缓存命中大约可让输入成本降低 75%。

实测（2026-05-25）：

TTL 行为。 TTL 可达数小时，高流量前缀有时会保留更久。由于使用磁盘存储，其他提供商的内存缓存可能因 GPU 显存压力被淘汰时，DeepSeek 的缓存仍能保留。

粒度。 64 个 token 是目前业界最小值。提示词有少量修改时，大部分前缀仍可匹配；不像最小粒度为 1,024 个 token 的提供商那样容易整块失效。

API 易用性。 API 形状与 OpenAI 一致，只需替换 base URL。使用标准的 prompt_tokens_details.cached_tokens 字段。

注意事项。

• 只支持 DeepSeek 系列模型，无法将这套缓存用于其他模型系列。
• 英文能力很强，但在难度最高的 reasoning benchmark 上仍落后于 Claude/GPT-5.x。

最适合。 注重成本的中文工作负载；粒度很重要的高频前缀场景，例如检索结果顺序不稳定的 RAG；成本敏感的批处理任务。

2.5 Alibaba 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，建议通过实测验证。

最适合。 需要精细控制缓存的中国企业工作负载，以及已经使用 Alibaba Cloud 的客户。

3. 横向对比

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

3.2 TTL、粒度与持久化

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

† Claude 的数据通过 Anthropic 原生 /v1/messages endpoint，配合 cache_control 标记测得，参见第 3 篇 §2。Claude 最大的收益来自成本，输入价格约降低 88–89%；完整成本表见第 3 篇 §2。根据 Anthropic 公布的数据，当提示词达到 100K 以上 token 时，TTFT 改善会显著放大。

测试为单次串行运行，没有并发负载。实际数据会随地域、时段和其他租户负载而变化。

4. 5 维评估框架

“Claude 节省 90%”这类结论很醒目，但通常不足以决定选型。应该根据实际工作负载，从以下五个维度为每家提供商打分，再按业务优先级加权。

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

不要比较基础价格，要比较实际命中率下的期望成本。可以将自己的数据代入 LLM 成本计算器，或浏览各提供商的实时 LLM 价格对比：

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.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.x、DeepSeek-v4、Gemini 隐式缓存、Qwen 隐式缓存）— 取决于前缀相似度和提供商负载，包括 LRU 淘汰。

如果 SLA 与成本挂钩，优先选择显式缓存。仅做尽力而为的优化时，自动缓存就足够。

4.3 TTL 与流量节奏的匹配度

4.4 缓存未命中时的延迟

如果命中很快、未命中却很慢，而实际命中率又不高，这个提供商仍然会带来问题。需要同时比较 §3.3 中的两组数据，并按预期命中率加权。

4.5 API 易用性与迁移成本

• 迁移成本最低：GPT-5.x ↔ DeepSeek-v4，两者都兼容 OpenAI API 形状，也都采用自动缓存。
• 中等：GPT-5.x → Gemini 隐式缓存。SDK 不同，但无需重写缓存逻辑。
• 较高：GPT-5.x → Claude。必须添加 cache_control，并重构提示词分层。
• 最高：不使用 gateway，从单一提供商迁移到多提供商。需要对接多套缓存 API。

5. 按工作负载快速选型

6. 迁移注意事项

如果评估结果指向更换提供商，需要提前处理三件事：

数据迁移。 缓存前缀无法在提供商之间迁移。每次切换都会冷启动。预热期间的成本会高于正常水平，通常要持续数小时，需要提前预留预算。

提示词架构调整。 Anthropic 的多断点设计鼓励将提示词拆成不同层级。这种结构本身也更适合其他提供商。一次重构，同样能改善非 Claude 路径。

通过 gateway 做冗余路由。 如果还无法确定，可以经由 Token Gateway 路由。这样可以保留切换提供商的能力，而不用绑定单一厂商。代价是增加一次网络跳转，而且某些 gateway 可能无法透传提供商特有的缓存控制。Synthorai gateway 实际支持什么、哪些宣传需要谨慎验证，参见第 3 篇 §9。

7. 这些结论会如何变化

这些对比并非长期不变：本文中的数字会变化。缓存已经成为价格竞争的重要功能，提供商每隔几个月就会更新方案。需要关注两点：

• TTL 延长。 Anthropic 的 1 小时选项已经 GA；Gemini 未来可能延长到数天。TTL 很快不会再是主要顾虑。
• 粒度。 OpenAI 和 Anthropic 最终很可能降低 1,024-token 的最小值。DeepSeek 的 64-token 粒度已经建立了新的行业预期。

当各家折扣趋于一致后，真正的差异会落在 API 易用性和延迟上，而不是宣传中的最高节省比例。

下一篇：第 3 篇 — 提示词缓存教程：可运行的 Python会把上面的架构分析变成可直接运行的代码，并将 §3.3 的延迟表整理成可以自行执行的 benchmark。

常见问题

综合考虑后，哪家 LLM 提供商的提示词缓存最便宜？ 在命中率相同、约为 75% 时，根据我们在 2026-05 的测量，中文工作负载使用 deepseek-v4-flash，英文工作负载使用 gemini-2.5-flash 隐式缓存，每百万 token 的有效成本最低。claude-sonnet-4-5 的单次调用折扣最高，约为 90%，但基础价格也更高；当命中率超过 85% 时，它更有优势。请将实际命中率代入 §4.1 的公式。

为什么 Gemini 在低调用量工作负载中更贵？ 如果查询频率不高，显式缓存的按小时存储费会抵消折扣。低调用量场景应使用 Gemini 的隐式缓存，无存储费，折扣约为 25%。

OpenAI 能使用 Claude 的 cache_control 吗？ 不能直接使用。两者是独立的缓存实现。在兼容 OpenAI 的 /chat/completions endpoint 上，该字段对非 Anthropic 模型通常不起作用，这些模型本身会自动缓存。对于 Claude，应通过 Anthropic 原生 /v1/messages endpoint 发送这些标记。

DeepSeek 的 MLA 架构是专有的吗？ 相关论文（DeepSeek-AI 2024）已经公开。其他提供商也可以采用类似 MLA 的 KV 压缩，但这需要重新训练基础模型，无法在运行时直接开启。截至 2026-05，DeepSeek 仍是唯一将其投入生产的主流提供商。

开源自托管模型呢？ vLLM、SGLang 等推理引擎原生支持前缀缓存，其基础来自 PagedAttention 论文。如果在 H100s/H200s 上自托管，可以使用 LMCache 或类似方案实现磁盘缓存。本文的价格分析仅适用于托管服务，自托管的成本结构完全不同。如果希望进行多提供商路由，又不想自行运维路由器，托管式 LiteLLM 替代方案可以在保留缓存能力的同时，用一套 API 接入这些提供商。哪些开放权重模型支持缓存、由哪些托管平台提供该功能，详见开放权重 LLM 的提示词缓存。

为什么对比中没有 Mistral、Cohere 或 Llama API 提供商？ 截至 2026-05，它们的缓存方案还不够成熟。Mistral 的缓存仍处于 early access；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。

← 返回博客