LLM 推理成本降了 59%：缓存命中率从 7% 到 74%的实践

提示缓存的运作机制，加上在 DigitalOcean 无服务器推理（Serverless Inference）上的第一手实测数据（Anthropic 风格的显式 cache_control）。这套机制在各大供应商之间是通用的；DigitalOcean 的数据来自有文档记录的基准测试，而非市场营销数据。

提示缓存是大多数生产级 LLM 团队已经配置好、却没能真正从中受益的、杠杆效应最强的成本优化手段。ProjectDiscovery 公开的一个生产案例同时展示了失败模式和修复方法：一个安全情报智能体在每次请求时，都会发送相同的 4,000 个 token 的系统指令、工具定义和分析框架，后面再跟上具体的威胁数据以供评估——而缓存命中率却只有 7%。仅仅做了一处结构性的调整——把单个动态标识符从提示词中间移到末尾——命中率就飙到了 74%，每月推理账单也砍掉了 59%。

这个情况很常见：原则上缓存是配对了的，但一个放错位置的动态字段，就把整个前缀给毁了。这篇文章会讲清楚提示缓存到底是怎么工作的、为什么大部分实现都搞错了，以及从个位数命中率一步步走到生产环境中可达 60% 到 80% 命中率的具体做法。

先说一些结论

对于智能体和多轮工作负载来说，提示缓存是杠杆效应最强的单一成本优化手段——前提是前缀结构要正确。 一个生产案例（ProjectDiscovery）仅靠一次重新排序，就把缓存命中率从 7% 提升到 74%，推理成本直降 59%。
三种不同的缓存解决的是三个不同的问题： KV 缓存（自动的，在单次请求内部）、前缀缓存（跨请求的，也就是本文要讨论的重点）和语义缓存（应用层的，用于语义相近的重复查询，而非精确匹配）。
缓存是按完全、逐字节相同的前缀内容来匹配的。 只要有一个动态字段——比如时间戳、会话 ID、某个用户专属的数据——放到了缓存边界前面，它就会把后面的整个前缀全部弄失效，而不仅仅只是那个字段本身。
Anthropic 风格的显式缓存，大约 1 次缓存命中就能回本（按标准费率，写入 1.25 倍，读取 0.10 倍）；此后的每一次命中都是纯省下来的钱。OpenAI 的缓存读取折扣因模型代次而异——历史上是打五折，在其最新模型上正朝着打一折演进——所以你应该去查你所用那个具体模型的费率，而不是假设所有情况下数字都一样。
最小可缓存前缀长度因模型和代次而异。 较老的 Claude 3.x 模型可以缓存短至 1,024 到 2,048 个 token 的前缀；像 Claude Haiku 4.5 这样的新模型则要求至少 4,096 个 token。别假定同一个阈值在所有模型版本上都适用。
DigitalOcean 无服务器推理（Serverless Inference）上的第一手实测**（Claude Haiku 4.5，约 6,000 个 token 的前缀）：把单个动态字段从缓存前缀中移出后，命中率从 0% 提升到 99.3%，输入成本大约降低了 90%。
Google 的 Vertex AI 团队通过缓存感知路由，把前缀缓存命中率从 35% 翻番到 70%——在上下文很重的编码智能体工作负载上，TTFT 降低了 35%；在突发式聊天工作负载上，P95 尾延迟降低了 52%（这是两种截然不同的流量画像，不是把同一个指标量了两次）。

KV、前缀和语义缓存解决的是三个不同的问题

在 LLM 推理上下文中，“缓存”意味着三件完全不同的事，把它们搞混了就会导致优化精力投错了地方：

1. KV 缓存——自动的，在单次请求内部。 当模型生成响应时，它会为每个输入 token 计算键值注意力状态。如果没有 KV 缓存，每一步解码都需要重新计算所有先前 token 的注意力。KV 缓存会把这些状态存下来，这样解码过程就是增量的。它始终处于开启状态，不需要任何配置，并且能加速单次请求内的生成过程。你控制不了它；你只是自动从中受益。

2. 提示缓存（前缀缓存）——跨请求的，由你来控制。 前缀缓存把 KV 缓存的概念扩展到多个独立请求之间。当请求共享相同的开头 token——相同的系统提示词、相同的少样本示例、相同的参考文档——模型就会复用首次请求计算出的 KV 状态，而不是每次调用都重新算一遍。这就是本文余下部分要讨论的缓存。那些稳定不变的开头 token 就是可缓存前缀；每次请求不同的内容则是动态尾部。

3. 语义缓存——应用层的，一个独立的系统。 语义缓存存储完整的输入输出对，并在新查询与之前某个查询语义相近时，基于嵌入相似度把它们取出来。这不是模型层面的功能——而是你在应用层利用向量存储去实现的一种模式。它是提示缓存的补充，而非替代。

缓存读取成本仅占输入成本的 10%；写入溢价大约 1 次命中就能回本

经济账是前缀缓存成为主导性成本优化手段的原因。

在 Anthropic (Claude) 上，一次缓存写入的成本是基础输入费率的 1.25 倍（5 分钟 TTL）或基础输入费率的 2 倍（1 小时 TTL）；一次缓存读取的成本是基础输入费率的 0.10 倍——也就是打一折。以 Claude Sonnet 4.6 每百万输入 token $3.00 为例，你要为一个 5 分钟窗口的缓存条目支付 $3.75/M 来做写入，而每次读取只需支付 $0.30/M。如果一个缓存前缀在过期前被读了 10 次，你一共付出了一次 $3.75 的写入成本，以及 $0.30 × 10 = $3.00 的读取成本——相比之下，不用缓存就要 $3.00 × 11 = $33.00。对于这点命中次数来说，这个前缀的成本就降了 80%。

OpenAI 的缓存输入折扣在其整个模型目录中并不是一个固定数字——它随模型代次而变化。历史上 GPT-4o 家族是打五折；在 OpenAI 的最新模型上，这个折扣已经向打一折靠拢，也就是和 Anthropic 收取的 0.10 倍读取费率一样。你应该去查你所调用那个具体模型的当前费率，而不是假定同一个数字在所有 OpenAI 模型上都适用。DigitalOcean 的配套文章《提示缓存到底什么时候才能省下真金白银》中，有一份完整的、按模型细分的费率表，覆盖了 Anthropic、OpenAI 以及 DigitalOcean 自有定价页面上的开源模型，很值得和本文一起阅读。

写入成本是需要理解清楚的变量。缓存并不是免费的——你在填充缓存的第一个请求上支付了溢价，只有当后续请求足够频繁地命中时这笔账才算得过来。大致的盈亏平衡点是 h* = (w − 1) / (1 − r)，其中 w 是写入乘数，r 是读取乘数。按 Anthropic 5 分钟档位的费率（w = 1.25，r = 0.10），得出 h* = 0.25 / 0.90 ≈ 0.28，向上取整后就是仅仅 1 次缓存命中——在那一次命中之后，每一次额外命中都是纯省下来的钱。你可以拿上面那些具体数字直接验证一下：在恰好 1 次命中（总共 2 次请求）时，缓存的总成本是 $3.75 + $0.30 = $4.05，对比不用缓存的 $3.00 × 2 = $6.00——这已经更便宜了。对于每次请求都要发送的系统提示词来说，回本几乎是瞬间完成的。对于一份只被引用了几次的大文档来说，你就要算一下读取省下的钱值不值得那个写入成本。关于完整的推导过程以及 DigitalOcean 支持的每种费率档位下的计算示例，请参见上面链接的那篇配套文章。

前缀缓存在什么时候帮得上忙——什么时候帮不上：

帮得上忙： 一个庞大的稳定前缀（系统提示词 + 工具定义 + 少样本示例 + RAG 模板），在 TTL 窗口内被大量请求复用。前缀越大、复用次数越多，收益就越大。
帮不上忙： 前缀长度低于供应商的最短可缓存下限。在 DigitalOcean 无服务器推理（Serverless Inference）上，对我们来说大约 4,000 个 token 以下的前缀就不会被缓存——这与 Anthropic 对 Claude Haiku 4.5 等新模型当前 4,096 个 token 的最低下限一致。不过这个下限并非在所有 Claude 代次上都是统一的：较老的 Claude 3.x 模型可以缓存短至 1,024 到 2,048 个 token 的前缀。针对你用的那个具体模型版本去查最下限——不要假定一个阈值在所有地方都适用——并参见上面那篇配套文章里的按模型参考表。缓存对于那些复用率很低、1.25 到 2 倍的写入溢价永远摊不回来的前缀也帮不上忙，对于那些请求间隔时间超过 TTL 的低流量端点同样无效。

前缀中一个动态字段就能把命中率干到个位数

这就是上面 ProjectDiscovery 团队犯过的错误，也是绝大多数初次实现缓存的团队会踩的坑。

前缀缓存要求从提示词的开头起，内容完全逐位相同。 缓存是基于从第一个 token 开始的精确 token 序列来匹配的。任何改动——任何字符、任何在请求之间变化的字段——都会把缓存边界重置在那个位置。

来看一个模版，它的第一部分是静态的（系统指令、工具定义），而中间某处有一个 session_id、一个 timestamp，或者某个每次请求都不同的用户配置字段。尽管 90% 的提示词都是相同的，缓存却只覆盖到首个差异点之前的那些 token。那个点之后的所有内容，每次请求都要从头重新计算。

这就是那个安全团队的命中率只有 7% 的原因：一个动态的威胁标识符坐在了原本稳定的模板中间，于是系统提示词、分析指令和工具定义每次都被重新计算。把标识符挪到末尾——在所有稳定内容之后——就把完整前缀还给了缓存，仅一次部署就让命中率从 7% 提升到了 74%。

从个位数到 60–80% 命中率的四个步骤

第 1 步：找出你的稳定前缀。 梳理你的提示词结构，给每个组件分好类：

组件	稳定？	示例
系统提示词 / 人设	是	"你是一个乐于助人的助手……"
工具 / 函数定义	是	完整的工具 schema
少样本示例	是	静态示例
RAG 上下文模板	基本是	文档格式、章节标题
检索到的文档	不一定	相同文档 = 可缓存；每个查询不同 = 不可缓存
用户查询	否	每次请求都变化
会话变量	否	用户 ID、对话 ID、时间戳
每次请求的元数据	否	请求专属的上下文

你的可缓存前缀，就是在绝大多数请求中都保持相同的最长开头序列——通常是系统提示词、工具定义和固定的少样本示例，大概 1,000 到 8,000 个 token 的稳定内容。

第 2 步：把所有动态内容挪到末尾。 重新组织，让稳定前缀先出来，不被打断，所有动态内容跟在最后面。生产环境的提示词会自然地积累各种动态字段——这里塞一个会话 ID，那里插入一个用户偏好——而每次插入都在不知不觉中杀掉了缓存。目标结构如下：

[系统指令——完全静态]
[工具定义——完全静态]
[少样本示例——完全静态]
[检索到的上下文——模板稳定，内容可变]
[用户查询——动态]
[会话元数据——动态，放在最末尾]

具体到 DigitalOcean 无服务器推理（Serverless Inference）所暴露的 Anthropic 风格 cache_control API，这个陷阱就是一个每次请求都会变化的值（会话 ID、时间戳）坐在了标记好的前缀里面，而修复办法就是把它从 system 移到用户轮次里：

// 会话 ID 在每次请求时都不一样——注意它放在哪里。

// 坏掉的 —— ID 放在缓存好的 system 块里面：
{
  "system": [{
    "type": "text",
    "text": "Session 4f9a-2c1e。你是一个支持客服。[……600 行稳定的政策……]",
    "cache_control": {"type": "ephemeral"}
  }],
  "messages": [{"role": "user", "content": "我该怎么重置密码？"}]
}
// 下一次请求带着 "Session 7b3d-9f02……"，所以 system 文本永远不会
// 两次逐字节相同——整个前缀每次都被重新计算。实测：0% 命中。

// 修好的 —— ID 挪到了用户轮次；system 保持逐字节相同：
{
  "system": [{
    "type": "text",
    "text": "你是一个支持客服。[……600 行稳定的政策……]",
    "cache_control": {"type": "ephemeral"}
  }],
  "messages": [{"role": "user", "content": "Session 4f9a-2c1e。我该怎么重置密码？"}]
}
// 那个变化的 ID 现在跑到了断点之后，所以这 600 行前缀
// 在之后的每次请求上都能缓存。实测：~99% 命中。

第 3 步：把缓存命中率当作一等指标来监控。 缓存命中率应该和延迟、成本一起，出现在你的 LLM 运维仪表盘上。它是一个先行指标：命中率下降往往预示着一波成本飙升的到来，而且它能在提示词结构退化变成账单惊悚之前就暴露出来。大多数供应商的 API 都会在响应元数据中返回缓存使用情况——把它记下来，并针对它做告警。

第 4 步：让缓存 TTL 匹配你的流量间隔。 Anthropic 的 TTL 选项（5 分钟或 1 小时）是运维约束，而不只是定价档位。一个每隔 10 分钟才来一次请求的部署，永远也命中不了 5 分钟那档——要基于你 P50 上的预期请求间隔来选 TTL，而不是突发峰值。对于突发式工作负载（比如每天跑一批，一小时内处理几千个请求，然后安静下来），1 小时 TTL 即便写入要付 2 倍成本也值：写入成本每小时才付一次，而读取节省下来的量会在整个突发期内叠加。

缓存感知路由在两种不同的 Vertex AI 工作负载上，分别把 TTFT 降了 35%，P95 延迟降了 52%

提示缓存在成本上的节省已经被充分讨论过了。但它在延迟上的影响讨论得相对较少，而这同样可以非常显著。

Google 的 Vertex AI 团队公开记录了这样一个案例：通过智能路由——把共享相同前缀的请求发到那个已经缓存了该前缀的推理服务器——他们让前缀缓存命中率从 35% 翻番到了 70%。Google 的报告称，这在上下文很重的编码智能体工作负载（Qwen3-Coder）上把 TTFT 降低了 35%，并且在突发式聊天工作负载（DeepSeek V3.1）上把 P95 尾延迟改善了 52%。这是两种截然不同的流量画像，瓶颈也各不相同——重上下文工作负载的瓶颈在于重新计算的 overhead，突发式工作负载的瓶颈在于队列拥塞——并非对同一个工作负载用两种不同方式的测量。

其机制是：缓存命中直接免去了对提示词中稳定部分的 prefill 计算。对于一个 4,500 个 token 中 4,000 个都被缓存的提示词来说，模型只需要对新增的 500 个 token 执行 prefill——prefill 的工作量大约减少了 89%。Prefill 是计算密集型的；把它跳过去所带来的延迟收益是实打实的，而不仅仅是省了点钱。

DigitalOcean 无服务器推理上的第一手实测：命中率从 0% 到 99.3%，输入成本降低约 90%

为了拿出实际数字而不是只引述供应商的数据，我们直接对 DigitalOcean 无服务器推理（Serverless Inference）做了基准测试（Claude Haiku 4.5，每百万输入 $1.00，每百万输出 $5.00，约 6,000 个 token 的共享前缀，每种布局 1,500 个请求，共跑 3 轮）。有两个发现值得内化：

第一，这里的缓存是显式的，不是自动的。 DigitalOcean 无服务器推理使用的是 Anthropic 风格的模型：你需要用一个 ephemeral cache_control 断点把稳定前缀标记出来。没有这个标记，无论提示词结构有多干净，命中率都是 0%——而且还有一个最小可缓存长度（约 2,300 个 token 的前缀没有被缓存；约 6,000 个的被缓存了，这符合上面提到的该模型 4,096 个 token 的最低下限）。这就是前面描述过的 5 分钟 / 1 小时 TTL 机制，不是 vLLM 的那种自动前缀缓存。

第二，当前缀被正确标记后，布局的效果非常显著。 在保持模型和 token 数量不变、只把每次请求的动态字段从前缀内部移到尾部的情况下，实测缓存命中率从 0% 跳到了 99.3%，预估输入成本从每 1,000 个请求 $6.72 降到了 $0.57——大约降低了 90%。这正好落在打一折的缓存读取经济账所预测的区间内：当几乎所有输入都以 0.1 倍费率从缓存中提供时，输入账单大约会下降一个数量级。（我们实测的降低幅度，比仅靠命中率和折扣率拍脑袋算出的数字多了几个百分点；如果你要复现这个基准测试，请把精确百分比当作方向性参考，而非用来规划预算的具体数字，并根据你自己真实的流量形状去测量。）

DigitalOcean Serverless 提示缓存基准测试：当动态字段从缓存前缀中移出时，缓存命中率从 0% 到 99.3%，输入成本从每 1,000 个请求 $6.72 降到 $0.57

DigitalOcean Serverless 上的第一手实测（Claude Haiku 4.5，约 6,000 个 token 的前缀，每种布局 1,500 个请求）：用 cache_control 标记前缀并把动态字段移到尾部后，命中率从 0% 升到 99.3%，输入成本大约降低 90%（每 1,000 个请求 $6.72 → $0.57）。

一个诚实的数据说明：在共享的 Serverless 上，可以稳稳复现的收益是成本，而不是吞吐量。在各轮运行中，TTFT 和吞吐量会随着队列状况波动，而成本下降是持续保持住的。由缓存带来的客户端可观测吞吐量提升——也就是“释放出更多 GPU 周期给 decode”那部分收益——会体现在专用端点上，也就是你自己独占 GPU 的时候。DigitalOcean 面向 GPU Droplet 云服务器的推理优化镜像，正是为了这种情况，把自动前缀缓存融入了 vLLM 服务栈里；在专用 Droplet 上去测它的吞吐量 delta，是顺理成章的后续基准测试。关于一个完全可复现的、引擎级别的基准测试框架（包括原始的命中率和 TTFT 日志），请参见配套文章《提示缓存到底什么时候才能省下真金白银》。

语义缓存对重复查询可以彻底省掉推理

对于那些查询重复度很高的工作负载——比如客户支持、FAQ 机器人、知识库搜索——语义缓存可以作为前缀缓存的补充，把常见查询的完整推理过程直接省掉。模式如下：

每次请求到来时，计算这条查询的嵌入向量。
在向量存储中检查是否有语义相近的历史查询（通常要求余弦相似度 ≥95%）。
如果找到了匹配，直接返回缓存的响应——完全不用调模型。
如果没找到，执行推理并把结果存下来。

经济账相当诱人：一次缓存命中的边际成本几乎为零（一次嵌入调用 + 一次向量检索）。对于一个 40% 的问题都是“我怎么重置密码”变体的支持机器人来说，语义缓存可以消灭掉将近一半的推理调用。

什么时候用它，以及要管理什么：

时效性问题： 缓存的响应需要 TTL 或失效机制。上个月准确的回答，在产品更新后可能就是错的。
阈值调优： 相似度阈值太高命中的太少；太低会把不该匹配的不同问题也给匹配上，返回错误的响应。95% 的余弦相似度是一个合理的起点——要根据你自己的查询分布去调。
安全性： 在多租户部署中，如果查询相近但上下文不同，一个用户的查询可能会拿到另一个用户的缓存响应。需要按租户给缓存做命名空间隔离。

上线前的避坑检查清单

稳定前缀内部没有嵌入任何动态字段（时间戳、会话 ID、用户 ID、每次请求的元数据）。
检索到的文档跟在稳定提示模板后面，但出现在固定前缀之后。
每次部署的缓存命中率都被记录，并做了监控告警。
缓存 TTL 与你的流量间隔相匹配——对于一个间隔 10 分钟的工作负载，别把 TTL 设成 5 分钟。
对于多租户部署，语义缓存的条目按租户做了命名空间隔离。
缓存写入成本被单独追踪——它们会部分抵消掉读取带来的节省。
你的前缀满足你所用的那个具体模型版本的最小可缓存长度，而不是一个泛泛的“1,024 个 token”假设——新模型的要求可能会更高。
提示词结构有版本控制——不小心的提示词变更会悄无声息地让缓存全部失效。

做得对的话，三层缓存加在一起，能让 60–80% 的推理成本和延迟都从缓存里走掉。只有前缀缓存依赖于提示词结构，这就是为什么大部分收益——以及大部分错误——都出在这里。

关于这个话题的常见问题

1. 什么是提示缓存，它和 KV 缓存有什么不同？

KV 缓存是自动的，范围仅限于单次请求内部——它让模型能够增量式地生成 token，而无需在每一步解码时都从头重新计算整个序列的注意力。提示（前缀）缓存是这个想法在跨请求上的延伸：当后续请求与先前请求共享相同的开头 token 时，平台会直接复用已经计算好的 KV 状态，而不是重新处理。你不需要配置 KV 缓存；但你需要配置前缀缓存，做法就是把你的提示词组织成稳定内容在最前面的结构。

2. 为什么我明明已经正确启用了缓存，命中率还是那么低？

最常见的罪魁祸首，遥遥领先的就是一个动态字段——时间戳、会话 ID 或某个每次请求都不同的标识符——蹲在了可缓存前缀的末尾之前。缓存是按从第一个 token 开始、完全逐字节相同的内容来匹配的，所以在缓存边界之前的任何位置，哪怕只有一个字符变了，也会让边界之后的所有内容全部失效。把所有每次请求都不一样的内容挪到提示词的最末尾，放到标记好的缓存边界之后。

3. 提示缓存会改变模型的输出吗？

不会。缓存只影响输入前缀在内部如何处理——平台是复用先前计算好的注意力状态，还是重新计算它们。无论哪种情况，响应的生成方式是相同的，而且供应商都声明输出不会因为是否发生缓存命中而受影响。

4. 实际能被缓存的最短提示词长度是多少？

这取决于供应商，而在 Anthropic 上还取决于具体的模型代次——并没有一个放之四海皆准的数字。较老的 Claude 3.x 模型可以缓存短至 1,024 到 2,048 个 token 的前缀；像 Claude Haiku 4.5 这样的新模型要求至少 4,096 个 token。低于这个底限，提示词就根本不会被缓存，无论它被重复了多少次，或者 cache_control 标记放在了哪里。在把你从另一个模型或更老 Claude 代次那里拿来的数字当作前提之前，先去查一下你所用那个具体模型的当前最下限。

5. 缓存真正开始省钱之前，需要多少次缓存命中？

在 Anthropic 标准 5 分钟档位的费率下（写入 1.25 倍，读取 0.10 倍），盈亏平衡点大约是 1 次缓存命中——在那一次命中之后，每一次额外命中都是纯省下来的钱。通用公式是 h* = (w − 1) / (1 − r)，其中 w 和 r 分别是你的供应商相对于标准输入价格的写入和读取乘数；代入你自己供应商的费率就能算出你自己的盈亏平衡点。

6. OpenAI 的缓存输入折扣和 Anthropic 一样吗？

并不统一。Anthropic 的读取折扣在整个 Claude 家族中是一贯的打一折（0.10 倍），写入溢价根据 TTL 在 1.25 倍到 2 倍之间。OpenAI 的缓存读取折扣则随模型代次而变化——历史上 GPT-4o 家族是打五折，在新模型上正朝着打一折靠拢。你应该去查你那个具体模型的当前费率，而不是假定同一个数字适用于 OpenAI 的所有模型。

7. 提示缓存和语义缓存可以一起用吗？

可以，而且它们解决的是不同的问题，所以是互补叠加而非竞争。前缀缓存能降低每次请求时重复处理共享提示词结构的成本。语义缓存则是在进来的查询与之前回答过的问题语义足够相近时，直接跳过推理这一步。举个例子，一个支持机器人可以在每次请求上用前缀缓存来搞定它的系统提示词和工具定义，同时用语义缓存来在那些与历史问题几乎重复的那部分查询上，完全省掉推理。

8. 把动态字段移到提示词末尾，就一定能解决低命中率的问题吗？

这是杠杆效应最强的单一修复手段，并且能搞定绝大部分场景，包括本文开头提到的 ProjectDiscovery 案例。不过，如果你的前缀低于供应商的最小可缓存长度，如果你的流量太稀疏以至于在 TTL 窗口内产不出重复命中，或者如果那个“稳定”内容因为其他原因在请求之间实际上并不一致（比如一个你还没注意到的、藏了微妙变化字段的模板），那这一招就帮不上忙。重新排序解决的是布局问题；它解决不了流量形状或前缀长度的问题。