Synthorai
🎁 新人 免费注册，送 10 次调用，最高 $1，免绑卡。
LLM 提示词缓存：2026 完整指南（输入成本降低 50-90%）

LLM 提示词缓存：2026 完整指南（输入成本降低 50-90%）

2026年5月26日 · 更新于 2026年7月15日 · prompt-cache · series-overview · llm-architecture
目录
  1. 从哪里开始
  2. 第 1 部分——LLM 提示词缓存如何工作
  3. 第 2 部分——对比各提供商的 LLM 提示词缓存
  4. 第 3 部分——可运行的 Python 教程
  5. 第 4 部分——按使用场景选择最佳模型
  6. 第 5 部分——LangChain 集成
  7. 如何阅读本系列
  8. 本系列的数据说明

如果你的聊天机器人、RAG 应用或 AI Agent 调用大语言模型，那么提示词缓存是最有效的一项优化：输入成本可降低 50–90%，首 token 延迟可缩短 3–10×，同时不影响输出质量。它不是额外叠加的技巧，而是由 Transformer attention 的定义直接决定的。理解这一点后，TTL、提供商差异和提示词结构等问题也就很容易理清了。

TL;DR

  • 提示词缓存可将输入成本降低 50-90%，首 token 延迟缩短 3-10x，同时不影响输出质量。
  • 2026-05-25 实测：Claude 的 cache_control 标记可将输入成本降低 88-89%；GPT-5.4-mini 的自动缓存将 TTFT 从 3.6s 降至 0.73s；DeepSeek-v4-flash 借助磁盘缓存提供 74% 的折扣。
  • TTL 较短，是因为 KV 状态占用的空间非常大：对于 70B 级模型，32K-token 上下文约需 10 GB。
  • DeepSeek 的缓存粒度为 64-token，而常见的最低粒度是 1,024-token，因此部分前缀匹配也能享受折扣。

本文是五篇系列文章的索引。内容从底层原理讲到生产环境中的选型矩阵，再深入到实际组装提示词的框架层。你可以根据已有知识选择起点。

从哪里开始

如果你想……从这里开始
理解缓存为何存在，以及 KV cache 到底是什么第 1 部分——KV Cache 与 TTL 的工作原理
选择提供商，并了解各家的差异第 2 部分——对比 Claude、GPT、Gemini、DeepSeek
直接复制可运行的 Python 代码并测出自己的数据第 3 部分——可运行的 Python 教程
为聊天机器人、RAG 或 Agent 负载选择合适的模型第 4 部分——适合聊天、RAG 与 Agent 的模型
通过 LangChain 正确命中缓存（模板、工具、Agent）第 5 部分——真正能命中缓存的 LangChain 配置

每篇文章都可以独立阅读，但按顺序阅读能够逐步建立完整认知，而且不会重复。

第 1 部分——LLM 提示词缓存如何工作

LLM 提示词缓存如何工作：详解 KV Cache 与 TTL →

这篇文章讲架构。它用一个公式解释 self-attention，说明稳定前缀的 K 和 V 向量为什么能在数学上复用，并展示内存与算力之间的权衡如何形成每个开发者都必须考虑的 TTL 机制。

核心结论：

  • 提示词缓存不是叠加在模型之上的优化，而是 causal-masked attention 的直接结果。位置 i 的 K/V 是 token 1…i 的确定性函数，因此相同前缀会产生逐 bit 相同的 K/V。
  • 缓存节省的是 prefill 阶段的计算（受算力限制，O(N²)）；decode 阶段受内存带宽限制，每个 token 的复杂度为 O(N)，所有推理引擎都会对其进行优化。
  • TTL 的存在是因为 KV cache 非常庞大（70B 模型的 32K 上下文约需 10 GB）。5 分钟是 GPU 内存压力下通常能维持的时间；只有磁盘缓存才能将 TTL 延长到数小时甚至数天，例如 DeepSeek 的 MLA 架构。
  • 缓存可以同时降低成本（命中时输入成本降低 50–90%）和延迟（对于 5–10K-token 的提示词，TTFT 可缩短 3–10×；超过 100K 时提升更明显）。

第 2 部分——对比各提供商的 LLM 提示词缓存

提示词缓存对比：Claude、GPT-5、Gemini、DeepSeek、Qwen（2026）→

这是一篇选型指南。五家提供商采用了五种截然不同的提示词缓存方案：Claude 使用显式标记，GPT-5 和 DeepSeek-v4 完全自动处理，Gemini 和 Qwen 采用隐式与显式混合模式，而 DeepSeek 的 MLA 则在架构层支持磁盘缓存。文章逐项对比各项能力，并提供一个包含 5 个维度的评估框架，用于针对具体负载进行评分。

核心结论：

  • 不要只比较基础价格，应根据实际命中率计算加权后的有效成本（公式见 §4.1）；实时 LLM 价格对比和成本计算器可以针对你的负载给出具体结果。
  • Claude 单次调用的折扣最高（约 90%），但需要显式添加 cache_control 标记。
  • DeepSeek-v4 是唯一大规模使用磁盘缓存的提供商；它的粒度是 64-token，而不是 1,024-token，因此部分前缀匹配也能享受折扣。
  • Gemini 的显式缓存按小时收取存储费用，是否能达到盈亏平衡取决于调用频率。
  • 在命中率相同的前提下，真正拉开提供商差距的五个维度是 API 易用性、命中率可预测性、TTL 匹配度、未命中时的延迟，以及迁移成本。

第 3 部分——可运行的 Python 教程

用 Python 实现 LLM 提示词缓存：可运行的代码教程 →

这是一篇实战文章。通过一个统一网关，分别使用一个 OpenAI SDK 和一个 Anthropic SDK，并给出 2026-05-25 的实测数据。测试覆盖完整的 Claude 系列（haiku-4-5 至 opus-4-7）、GPT-5.x、Gemini 2.5、DeepSeek-v4 和 Qwen3。

核心结论：

  • 带 cache_control 标记的 Claude：haiku/sonnet/opus 4-x 全系列的实测成本均降低 88–89%。使用 Anthropic SDK，并设置 base_url="https://synthorai.io/"。
  • GPT-5.4-mini 自动缓存：TTFT 提升 5×（7K-token 提示词从 3.6 s 降至 0.73 s），system token 的缓存命中率为 93%。
  • Gemini 2.5-flash 隐式缓存：在正确获取 streaming usage 的情况下，缓存命中时成本降低 88%。
  • DeepSeek-v4-flash：成本降低 74%，使用磁盘缓存，空闲数小时后缓存仍然有效。
  • 针对 TTL 的设计模式：cron 任务的保活心跳、前缀稳定性规则，以及每次调用应该记录哪些数据。

第 4 部分——按使用场景选择最佳模型

聊天、RAG 与 Agent 的最佳 LLM：2026 模型与成本决策矩阵 →

这是一篇决策指南。不同负载对成本和延迟的影响不同：聊天天然适合缓存，RAG 很难维持前缀稳定，而 Agent 则依赖严格的累积前缀管理。文章按负载类型给出模型建议和成本估算。

核心结论：

  • 聊天机器人：任何支持自动缓存的模型都适用，会话通常会自然命中缓存。根据成本和质量选择即可。gpt-5.4-nano 最便宜，gpt-5.4-mini 的缓存 TTFT 最短，claude-haiku-4-5 的指令遵循能力最好，价格只略高一些。
  • RAG：检索文档顺序发生变化，会导致提示词中部的缓存失效。有三种解决方案：将参考资料放到末尾、确定性地排列 chunk，或者使用 Claude 的多个 cache_control 断点。
  • Agent：工具调用和结果必须只追加，并且每一步的字节都要完全一致。claude-sonnet-4-5 配合 4 个 cache_control 标记，累积前缀的折扣最高；gpt-5.4-mini 无需改动代码即可节省 50%。
  • TTL 匹配：聊天使用 5 min；包含 human-in-the-loop 步骤的 Agent 使用 1 hour；调用零散的批处理任务使用磁盘缓存。

第 5 部分——LangChain 集成

LangChain 提示词缓存：真正能够命中缓存的配置 →

这篇文章讲框架集成。前四部分都假设你可以控制提示词的具体字节，但 LangChain 会代你组装提示词，而且它最方便的语法会在不报错的情况下让 Claude 缓存失效。测试基于 langchain-core 1.4.8，并使用带标记的 system 前缀。

核心结论：

  • ("system", "...") 这种字符串元组模板无法携带 cache_control：相同调用的实测缓存活动为零。解决方案是使用包含内容块的 SystemMessage。
  • 提示词顺序决定命中率：如果把检索到的 RAG 上下文放在静态规则之前，每次调用都会冷写缓存。由于 Claude 写入缓存需要额外付费，这样做的成本甚至高于完全不使用缓存。
  • system 块上的标记也会覆盖绑定的工具；bind_tools 能保持序列化字节稳定，而 Anthropic 格式工具字典中的标记会原样透传。
  • 多轮 Agent：将标记移动到最新消息，每一轮都会重新读取此前的完整前缀，只写入新增部分（实测：读取 1,864，写入 15）。
  • 对于自动缓存模型（GPT、GLM、DeepSeek），顺序错误不会产生明显信号：没有额外费用，也不会报错，只是永远拿不到折扣。需要监控 usage 字段。

如何阅读本系列

  • 刚接触这一主题的工程师：按顺序阅读。理解第 1 部分的架构后，第 2–4 部分就很容易串联起来。
  • 正在选择供应商的 PM 或架构师：直接阅读第 2 部分和第 4 部分。如果团队成员问“为什么存在 TTL”，再参考第 1 部分。
  • 今天就要上线具体负载的工程师：先读第 4 部分，在矩阵中找到对应场景，再到第 3 部分获取准确代码。
  • 已经在使用 LangChain：直接阅读第 5 部分。第 3 部分基于原生 SDK 的模式仍然适用，但字符串模板、变量位置和 usage 字段名等问题是框架特有的。
  • 正在优化现有应用的任何人：参考第 3 部分 §6 的跨提供商 benchmark，用自己的提示词复现测试。这只需要一天，不必进行数周的迁移。

本系列的数据说明

第 1–4 部分的数据测于 2026-05-25，第 5 部分的 LangChain 数据测于 2026-07-04。测试使用 Synthorai 网关（兼容 OpenAI 的接口为 https://synthorai.io/v1，Anthropic 原生接口为 https://synthorai.io/），采用单租户、单次串行运行，不施加并发负载。区域、时段和其他租户的竞争负载都会影响结果。请将这些数据作为起点；在对外引用前，先用自己的实际流量复现测试。

价格表和 TTL 行为基于截至 2026-05 的供应商公开文档。提供商通常每隔几个月就会更新这些内容；第 1 部分的架构原理不会变化，但第 2 和第 3 部分的对比数据会随时间变化。

← 返回博客