Synthorai

LLM 提示缓存：2026 完全指南

2026年5月26日 · prompt-cache · series-overview · llm-architecture
目录
  1. 从哪里开始
  2. 第 1 部分 —— LLM 提示缓存如何工作
  3. 第 2 部分 —— 跨服务商对比 LLM 提示缓存
  4. 第 3 部分 —— 可运行的 Python 教程
  5. 第 4 部分 —— 按使用场景选最佳模型
  6. 如何阅读本系列
  7. 本系列中的数据

如果你针对大语言模型构建聊天机器人、RAG 应用或 AI 智能体，提示缓存是唯一能在不损失质量的前提下，帮你拿回 50–90% 的输入成本和 3–10× 的首字延迟（TTFT） 的优化手段。它不是外挂的小技巧——它直接源自 Transformer 注意力机制的定义方式。一旦你理解了这一点，技术栈的其余部分（TTL、各服务商的差异、提示结构）就都顺理成章了。

本页是一个四部分系列的索引，带你从理论一路走到生产环境的决策矩阵。根据你已有的知识储备选择进入点。

从哪里开始

如果你想……从这里开始
理解缓存为什么存在，以及 KV 缓存到底是什么第 1 部分 —— KV 缓存与 TTL 如何工作
选择一个服务商，并了解每家的不同之处第 2 部分 —— 对比 Claude、GPT、Gemini、DeepSeek
复制粘贴可运行的 Python，测量你自己的数据第 3 部分 —— 可运行的 Python 教程
为聊天机器人 / RAG / 智能体工作负载匹配合适的模型第 4 部分 —— 聊天、RAG 与智能体的最佳模型

每一部分都可独立阅读，但它们的写法保证了按顺序阅读时层层递进、不重复。

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

LLM 提示缓存 #1：KV 缓存与 TTL 如何工作 →

这是架构篇。把自注意力当作一个单一公式来讲解，说明为什么稳定前缀的 K 和 V 向量在数学上可以复用，并展示内存与计算之间的权衡如何产生每个开发者都必须围绕其设计的 TTL 行为。

要点：

  • 提示缓存不是叠加在上层的优化——它是因果掩码注意力的直接结果。位置 i 处的 K/V 是 token 1…i 的确定性函数，因此相同的前缀会产生比特级完全一致的 K/V。
  • Prefill（计算受限，O(N²)）才是缓存所节省的部分；decode（内存带宽受限，每个 token O(N)）是每个推理引擎本来就已经优化好的。
  • TTL 存在是因为 KV 缓存非常庞大（在 70B 模型上，32K 上下文约需 ~10 GB）。5 分钟是 GPU 内存压力的临界点；只有借助磁盘支撑的缓存（DeepSeek 的 MLA 架构）才可能实现数小时到数天的缓存。
  • 缓存在成本（缓存命中时输入便宜 50–90%）和延迟（5–10K token 范围的提示 TTFT 下降 3–10×，100K+ 的提示降幅更大）两方面都获益。

第 2 部分 —— 跨服务商对比 LLM 提示缓存

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

这是选型指南。五家服务商以五种迥然不同的形态暴露提示缓存——显式标记（Claude）、全自动（GPT-5、DeepSeek-v4）、隐式+显式混合（Gemini、Qwen），或架构层面的磁盘支撑（DeepSeek 的 MLA）。本文给出逐项功能对比，外加一套 5 维评估框架，按你具体的工作负载为它们打分。

要点：

  • 不要对比基础价格——要对比按你的命中率加权后的有效成本（公式见 §4.1）。
  • Claude 拥有最深的单次调用折扣（~90%），但需要显式的 cache_control 标记。
  • DeepSeek-v4 是唯一在规模上提供磁盘支撑缓存的服务商；由于粒度是 64 个 token 而非 1,024 个，部分前缀匹配也能拿到折扣。
  • Gemini 的显式缓存需要按小时支付存储费——盈亏平衡点取决于调用频率。
  • 一旦你把命中率这一变量控制住，真正区分各服务商的就是这五个维度：API 易用性、命中率可预测性、TTL 适配度、未命中时的延迟，以及迁移成本。

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

LLM 提示缓存 #3：可运行的 Python 教程 →

这是动手实操篇。一个 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 秒降到 0.73 秒），系统 token 上的缓存命中率 93%。
  • Gemini 2.5-flash 隐式缓存：在捕获流式 usage 的前提下，缓存命中时成本下降 88%。
  • DeepSeek-v4-flash：便宜 74%，磁盘支撑（缓存可挺过小时级的空闲）。
  • TTL 感知模式：为 cron 设置保活心跳、前缀稳定性规则、每次调用应记录哪些内容。

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

LLM 提示缓存 #4：聊天、RAG 与智能体的最佳模型 →

这是决策篇。不同的工作负载以不同方式拉动成本/延迟杠杆——聊天天然对缓存友好，RAG 要对抗前缀稳定性问题，智能体则依赖累积前缀的纪律性。本文按工作负载形态给出模型推荐并附成本估算。

要点：

  • 聊天机器人：任何带自动缓存的模型都能用；会话天然会命中。按成本/质量挑选。gpt-5.4-nano 最便宜，gpt-5.4-mini 缓存后的 TTFT 最快，claude-haiku-4-5 在略高的溢价下指令遵循最佳。
  • RAG：检索文档的重排序会摧毁提示中段的缓存命中。三种修复办法——把引用推到末尾、确定性的分块排序，或使用 Claude 的多 cache_control 断点。
  • 智能体：工具调用与结果必须是仅追加的，且逐步之间比特级完全一致。带 4 个 cache_control 标记的 claude-sonnet-4-5 提供最强的累积前缀折扣；gpt-5.4-mini 无需改代码即可获得 50% 的节省。
  • TTL 匹配：聊天用 5 分钟，带人在环节步骤的智能体用 1 小时，零散的批处理用磁盘支撑缓存。

如何阅读本系列

  • 刚接触该主题的工程师：按顺序读。第 1 部分的架构会让第 2–4 部分瞬间通透。
  • 做供应商选型的 PM 或架构师：直接跳到第 2 部分 + 第 4 部分。如果队友问起“可 TTL 为什么存在”，再回看第 1 部分。
  • 今天就要上线某个特定工作负载的工程师：先看第 4 部分（在矩阵里找到你那一行），再看第 3 部分拿到确切代码。
  • 优化现有应用的任何人：第 3 部分 §6 的跨服务商基准——用你自己的提示复现它；这是一天的工作量，而不是数周的迁移工程。

本系列中的数据

所有实测数据均于 2026-05-25 针对 Synthorai 网关采集（OpenAI 兼容用 https://synthorai.io/v1，Anthropic 原生用 https://synthorai.io/），单租户、单次顺序运行、无并发负载。你的数据会随地域、时段和竞争租户负载而变化——请把它们当作起点，在引用之前先用你自己的流量复现。

定价表和 TTL 行为反映的是截至 2026-05 各供应商的公开文档。供应商每隔几个月就会更新这些内容；架构层面的推理（第 1 部分）是稳定的，而对比性的数据（第 2 与第 3 部分）会漂移。

← 返回博客