Prompt Cache 实测：同样的调用量，账单降了 62%

背景

Anthropic 和 OpenAI 都在 2024 下半年陆续推出了 prompt cache：首次请求按缓存写入价计费（通常是输入价的 1.25x），后续命中缓存的请求按缓存读取价计费（通常是输入价的 10%）。

理论上降本显著。但 理论和实际之间隔着一个”缓存命中率”。我们用 ZetaAPI 自身的客服 agent 和 codegen pipeline 跑了一个月实测。

测试场景

• 场景 A：客服 agent — 系统 prompt 固定（约 3200 tokens），用户问题变化，对话累积。日均调用 18k 次。
• 场景 B：codegen pipeline — 项目上下文前缀（约 12k tokens）按仓库变动刷新，同仓库的连续调用可复用前缀。日均调用 4k 次。

两个场景都启用 cache_control: { type: 'ephemeral' } 标记系统 prompt。

结果

场景	缓存命中率	原始输入成本	启用 cache 后	节省
客服 agent	88%	$300/日	$103/日	66%
codegen pipeline	71%	$643/日	$279/日	57%
综合	82%	$943/日	$382/日	59.5%

加上月初账单对账，全月整体节省 62%。

什么样的请求缓存命中率高？

从数据看，命中率的决定因素按权重排序：

1. 前缀稳定性 — 系统 prompt 长期不变的场景，命中率直接 80%+
2. 调用密度 — Anthropic 的 ephemeral cache 有 5 分钟 TTL，调用越密集，越可能落在同一 TTL 窗口里
3. 前缀长度 — 短于 1024 tokens 的前缀连缓存阈值都进不了

反直觉的发现

我们一开始以为 codegen 场景命中率会比客服高——项目上下文更”稳定”。但实际上 codegen 场景每次提交代码都会打断缓存，真实命中率反而低 17 个百分点。

缓存是时间维度的优化，不是语义维度的优化。 一个 prompt 只要被修改一个 token，它就是一个全新的 prompt，与上一次毫无关系。

给接入方的建议

• 系统 prompt 尽量做成不变的模板，把动态部分放到用户消息里
• 批量任务优先同批提交，别拆成几波跨 TTL 的调用
• 使用 ephemeral 标签的位置要放在最长的不变前缀末尾，而不是整个系统 prompt 末尾

后续我们会在控制台增加每个 API Key 的缓存命中率统计，方便接入方自己判断是否启用了 cache。