缓存计费到底省了多少：一次可复现的实测对比

缓存在省什么钱

LLM 的计费按输入 + 输出。在一段长对话或一次文档问答里，输入往往远大于输出 —— 尤其是以下几种典型场景：

• 系统提示很长（几千 token 的角色设定 + 工具定义）；
• 多轮对话（每轮都要把历史再发一遍）；
• 文档问答（同一份文档被反复提问）；
• Agent 循环（每步都带着完整的上下文）。

这些场景里，输入有大比例是完全重复的内容。缓存就是把这部分内容在后端保留，下次直接复用，按更低的价格计费。

典型的计费结构（以 Claude 系为例）：

• 缓存写入：比普通输入略贵（约 1.25 倍）；
• 缓存读取：比普通输入便宜很多（约 0.1 倍）；
• 缓存有效期：通常 5 分钟，可配更长的档位。

所以对「反复使用同一段长前缀」的场景，省下的比例可以到 70%–90%。

缓存生效的前提

三个条件缺一不可：

1. 客户端确实发送了缓存标记（Anthropic 用 cache_control 块；OpenAI 系多为自动缓存，不需手动标记）；
2. 中转站把标记透传给了上游（这是最容易断掉的一环）；
3. 上游支持并且命中了缓存（前缀必须完全一致）。

中转站断在第 2 环的后果：请求正常返回，但按全价计费。你不会收到任何错误。

怎么判断缓存真的生效

唯一可靠的方法：看返回的 usage 字段。

开启缓存后，usage 里会多出与缓存相关的计数，例如：

"usage": {
  "input_tokens": 120,
  "cache_creation_input_tokens": 4200,
  "cache_read_input_tokens": 0,
  "output_tokens": 250
}

第二次发同样的请求，应当看到：

"usage": {
  "input_tokens": 120,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 4200,
  "output_tokens": 250
}

判据：

• 出现 cache_read_input_tokens > 0 → 缓存真的生效了；
• 字段整个不存在 → 中转站没有透传（它可能自己把 usage 重新算了一遍）；
• 字段存在但 cache_read 恒为 0、cache_creation 每次都很大 → 缓存写入成功但没命中（可能是前缀不一致，或站方每次都路由到不同后端）。

可复现的对比测试

准备：一段长度超过缓存最小阈值的固定前缀。注意各家的最小缓存长度不同（有的要求 1024 token 以上），太短不会缓存。

PREFIX="<重复的长文本，确保 > 1500 token>"

# 第一次：应看到 cache_creation
curl -s .../v1/messages -H "x-api-key: $KEY" -H "anthropic-version: 2023-06-01" \
 -d "{
   \"model\": \"<model>\",
   \"max_tokens\": 100,
   \"system\": [{\"type\":\"text\",\"text\":\"$PREFIX\",
                 \"cache_control\":{\"type\":\"ephemeral\"}}],
   \"messages\": [{\"role\":\"user\",\"content\":\"只回答 OK\"}]
 }" | grep -o '\"usage\".*'

# 立刻第二次（5 分钟内）：应看到 cache_read

关键：两次请求之间的时间要短于缓存有效期（默认 5 分钟）。

缓存不生效的三种原因

一、中转站没透传 cache_control

最直接的一种。判断方法：看返回的 usage 里有没有缓存相关字段。整个字段都没有，基本可以确定。

这一条的连带影响：你也会丢掉「缓存写入更贵、读取更便宜」这个定价结构 —— 也就是按全价计费，而且是在你并不知情的情况下。

二、你发送的前缀每次都不一样

缓存命中要求前缀完全一致（逐字节）。常见破坏因素：

• 系统提示里插入了当前时间或随机 ID；
• 历史消息被截断的长度每次都不同（比如按 token 数动态裁剪）；
• 序列化顺序不稳定（JSON key 顺序变了）。

检查方法：把同一段前缀连续发两次，如果第二次没命中，先确认前缀字节完全一致。

三、站方每次把请求路由到不同后端

这是中转站特有的问题。 如果站方有一个账号池 / 渠道池，而每次请求随机分配，那么缓存可能落在不同后端上 —— 你请求的缓存和上次写入的缓存不是同一个。

特征：cache_creation 每次都有，cache_read 偶尔有但不稳定。

这一条几乎无解，除非站方做了会话粘性（同一会话固定落在同一后端）。所以如果你重度依赖缓存，选站时应当把「是否支持会话粘性 / 渠道粘性」作为一个评估项。

折算成钱

保守估算（按 Claude 系的一贯比例）：

结论：缓存对「长固定前缀 + 重复调用」有效，对短对话无效。 如果你的用法不属于前者，不必花精力在这上面。

一个务实的建议

如果你重度依赖缓存，把它写进选型清单，并要求站方书面确认。 这不是能靠试出来的能力 —— 试出来的只是「这一次生效了」，不能保证长期稳定。

另外，无论缓存是否生效，都要在代码里记录 usage。不看 usage 就没有对账能力，而缓存恰恰是最容易在账单上被悄悄抹掉的一项。