Prompt Cache 盈亏平衡点：提供商端前缀缓存何时真正划算的精确数学计算

Prompt 缓存听起来是一个稳赢的方案：Anthropic 和 OpenAI 都宣传缓存命中可享受 90% 的折扣，且文档中展示了令人印象深刻的成本削减图表。团队实施了它，观察着缓存命中率计数器不断上升，并理所当然地认为自己在省钱。但实际上，有些团队支付的费用比完全不使用缓存时还要 多。

问题在于“写入溢价”（write premium）。每当你缓存一个前缀时，你都需要支付额外的费用——在 5 分钟的缓存窗口内是 1.25 倍，在 1 小时的窗口内是 2 倍。如果你的命中率太低，这些写入溢价的累积速度会超过读取折扣所节省的费用。缓存并不是免费的保险；它是你对自己流量模式下的一场赌注。

以下是这场赌注何时能获得回报的精确计算，以及决定你是获得了折扣还是在为浪费的缓存写入变相买单的架构决策。

收支平衡公式

对于 Anthropic Claude Sonnet 4.6，具体数值如下：

• 基础输入成本：$3.00/M tokens
• 5 分钟缓存写入：$3.75/M tokens（1.25 倍溢价）
• 缓存读取：$0.30/M tokens（90% 折扣）
• 每次缓存命中的净节省：$3.00 −$0.30 = $2.70/M

5 分钟缓存的收支平衡点是：

cache_write_cost = N × savings_per_read
$3.75 = N × $2.70
N = 1.39 次读取

你需要在 5 分钟窗口内进行大约 1.4 次缓存读取 才能收回写入成本。在实践中，2 次读取是你的最小可行阈值——低于这个数值就是稳赔不赚。

对于 1 小时的缓存窗口，写入成本翻倍至基础价格的 2 倍（$6.00/M），从而提高了收支平衡点：

$6.00 = N × $2.70
N = 2.22 次读取

你在一小时内需要 3 次读取。OpenAI 的计算方式相同（1.25 倍写入溢价，90% 读取折扣），因此各服务商的收支平衡点基本一致，约为 1.4 次读取。

这些数字意味着，对于具有中等重复使用率的工作负载，缓存很容易证明其价值——但对于任何流量稀疏、断断续续的工作负载，它反而是一种负担。一个每小时缓存一次的系统提示词，如果由缓慢流动的请求触发，且在过期前从未累积到 3 次命中，那么其总成本将高于不使用缓存。

前缀长度如何改变绝对利害关系

无论前缀长度如何，收支平衡的读取次数都保持不变，但金额大小呈线性增长。这改变了你应该追求缓存的积极程度。

对于 Sonnet 4.6，考虑在不同长度的缓存前缀上进行 10 次读取的情况：

前缀长度	写入成本	10 次读取成本	使用缓存的总成本	不使用缓存的总成本	节省比例
2,000 tokens	$0.0075	$0.006	$0.0135	$0.06	77%
50,000 tokens	$0.1875	$0.15	$0.3375	$1.50	77%
200,000 tokens	$0.75	$0.60	$1.35	$6.00	77%

百分比节省大致恒定。绝对节省额随前缀长度缩放——一个 200K token 的系统提示词如果正确缓存，每 10 次请求可为你节省 $4.65。在每天 10,000 次请求且命中率为 90$4,185。在每天 10 次请求且命中率为 90% 的情况下，每天仅节省 $4.18。投资回报率（ROI）的逻辑是一样的，改变的只是业务案例的规模。

最小 token 阈值在这里也很重要。Anthropic 和 OpenAI 都要求在缓存激活前，可缓存前缀至少包含 1,024 个 token。短于该长度的提示词无法从缓存基础设施中获益——每一次缓存写入都是浪费的开销。

生产环境中的真实命中率是怎样的

理论缓存命中率与实际命中率之间的差距是大多数实现失败的原因。以下是来自生产部署的两个具体数据点：

从 7% 到 84% 的提升：一家安全工具公司发现他们最初实现的缓存命中率仅为 7.4%。原因是：系统提示词中嵌入了动态内容。放置在稳定内容 之前 的时间戳、请求 ID 和会话令牌导致每个请求的哈希值都不同。将这些动态内容移动到稳定前缀 之后，即缓存块之外，在不触动底层逻辑的情况下，将命中率推高至 84%。这仅仅是一个结构性的改变。

多步任务 vs. 单步任务：同一家公司测量发现，多步智能体任务（其中相同的大上下文在各步之间重复出现）的命中率为 91.8%，而单步任务（每个请求基本上是唯一的）的命中率为 35.5%。决定可实现命中率的是任务的架构，而不仅仅是提示词设计。

这些案例说明了一个普遍规律：缓存命中率主要是一种架构属性，而不是提示词属性。它取决于你如何构建请求流、在哪里放置易变内容与稳定内容，以及你的流量模式是否在缓存 TTL 内产生重复的前缀匹配。

最大化命中率的会话架构模式

对于多轮对话，最有效的模式是将稳定的系统提示词放在首位，随后是将不断增长的对话历史作为二级缓存块：

[缓存块 1：系统提示词 —— 永不改变]
[缓存块 2：对话历史 —— 每轮增长]
[不缓存：当前用户消息]

每一轮都会为扩展的历史记录写入一个新的缓存条目，但从缓存中读取系统提示词。在第二轮之后，整个对话前缀都被缓存了。这种模式在客户支持或助手应用中的命中率通常落在 40–60% 的范围内，大部分节省来自于庞大且稳定的系统提示词。

对于文档问答（RAG），收益更大且更简单。如果你将一个 50K token 的文档作为缓存前缀加载，那么针对该文档的每个查询都会从缓存中读取。如果每天针对同一文档有 1,000 次查询且命中率为 90%，你的输入成本将从约 $150/天降至约$15/天。由于文档的 token 数量在输入中占主导地位，因此这种计算极具吸引力。

最糟糕的模式则相反：将任何易变元素——时间戳、用户特定 ID、动态指令——放置在提示词的 中间 或稳定内容之前。这会在易变元素处切断缓存前缀，并消除随后的所有缓存复用。每一个嵌入在系统提示词早期的指令（如 今天是 {date}）都会破坏其后所有内容的缓存。

并行请求的竞态条件

在高吞吐量的批处理工作负载中，存在一种特有的时序失效模式。当你同时发起 100 个并行请求时，第一个请求会触发一次缓存写入，这通常需要 2–4 秒才能完成。其余 99 个请求在写入窗口期间、即缓存条目可用之前到达。这 100 个请求都会支付写入开销；没有任何请求能从缓存中读取。

代价是：如果你在 Sonnet 上运行带有 1,000 个 token 前缀的 100 个并发请求，你本期望支付 30 美元的读取成本，结果却支付了 375 美元的写入成本——且完全没有实现缓存读取。你在没有获得任何收益的情况下，将成本增加了 25%。

解决方法是在发起并行批处理之前先发送一个预热请求，或者引入一个短队列以确保第一个请求的写入在其他同类请求到达之前完成。对于真正的批处理工作负载，顺序预热成本低廉且能消除竞态条件。

计算你的实际盈亏平衡命中率

与其根据所需的读取次数进行推算，你不如直接计算给定工作负载的盈亏平衡命中率。

对于一个请求，如果缓存前缀为 P 个 token，新鲜的非缓存输入为 F 个 token，且你预期在每个缓存 TTL 窗口内总共有 H 个请求：

Cost with caching = P × write_rate + (H-1) × P × read_rate + H × F × base_rate
Cost without caching = H × (P + F) × base_rate

将两者设为相等并求解命中率（即 H 中读取请求所占的比例），即可得出最小可行命中率。对于 Sonnet 上的 1,500 token 系统提示词：

• write_rate = $3.75/M, read_rate =$0.30/M, base_rate = $3.00/M
• 盈亏平衡点约为 H ≈ 1.4（如上所述推导）
• 随着 H 的增长，单个请求的分摊写入成本会降至接近于零

实际意义在于：盈亏平衡命中率随着流量的增加而降低。在每个缓存窗口有 10 个请求时，你需要除了第一个请求之外的每个请求都命中。在每个窗口有 100 个请求时，你只需要 1.4% 的命中率。对于高流量工作负载，使用缓存几乎总是正确的。对于低流量工作负载，则需要谨慎验证。

决策框架

在实施 Prompt 缓存之前，请验证以下各项条件：

在以下情况下实施：

• 可缓存前缀至少为 1,024 个 token
• 每个缓存窗口的预期请求数超过 3 个（针对 1 小时缓存的保守阈值）
• 提示词中的稳定部分占总输入 token 的 30% 以上
• 你已审计提示词中的嵌入式动态内容，并将其移至稳定块之后

在以下情况下不要实施：

• 请求到达的间隔时间长于你的目标缓存 TTL
• 提示词在每次请求中几乎都是唯一的（例如工具输出、每次调用都会更改的完整文档注入）
• 你的每日总请求量足够低，以至于写入溢价无法被摊销

上线前必做：

• 记录至少 100 个请求的提示词结构，以测量实际的前缀稳定性
• 在生产环境中监控缓存命中率，而不仅仅是缓存写入次数
• 根据观察到的命中率，计算使用和不使用缓存的预期月度成本

节省效果的真实表现

以下是运行 Sonnet 4.6 的团队的两个具体的月度成本计算：

客户支持（每日 1 万个工单，1,500 token 系统提示词，500 token 新鲜上下文）：

• 不使用缓存：$105/天，$3,150/月
• 使用缓存且命中率为 99.99%：$94.50/天，$2,835/月
• 节省：10% —— 节省较少，因为系统提示词仅占输入的 25%

文档问答（每日 1,000 个查询，5 万 token 文档，200 token 查询）：

• 不使用缓存：$155/天，$4,653/月
• 使用缓存且命中率为 90%：$34/天，$1,030/月
• 节省：78% —— 节省显著，因为文档占据了输入的大部分

差异归结为缓存 token 与总输入 token 的比例。巨大的、稳定的缓存前缀是产生经济杠杆的地方。如果只是在大量唯一的动态内容上方放一个很小的系统提示词，无论命中率如何，节省都微乎其微。

正确的思考方式

Prompt 缓存是对流量结构的一种押注，而不是一个简单的功能开关。API 为重复的前缀 token 提供了 90% 的折扣；该折扣是否能抵消写入溢价，完全取决于你的请求模式。

在实施之前算好这笔账：根据实际流量计算预期命中率，验证每个缓存窗口的命中次数是否超过盈亏平衡阈值，并在测量前剔除缓存前缀中的任何动态内容。跳过这些步骤的团队往往会低估缓存写入的成本，并高估缓存读取的收益。

当条件成熟时——前缀大且稳定、请求密度中等至偏高、前缀中没有不稳定的内容——节省将非常可观，且实施成本极低。如果不满足这些条件，你就是在为每一个触及缓存前缀的请求支付 25% 的额外费用。在上线前搞清楚你属于哪种情况。