prompt caching 在中转站上到底生效吗，以及它值多少钱

缓存解决的是什么问题

大模型 API 的计费是按输入 token 算的。但很多场景下，输入里绝大部分内容是重复的：

• RAG 系统：每次都带同一批知识片段
• 代码补全：每次都带整个文件的上下文
• 长文档问答：每次都带整份文档
• Agent 工具：每次都带同一套工具定义和系统提示

这些内容每次都重新计费，成本会高得离谱。prompt caching 就是让这部分重复内容只算一次的机制。

官方是怎么算的

以 Anthropic 的机制为例（各家大同小异）：

关键数字是 0.1 倍 —— 命中缓存的部分，费用降到原来的十分之一。

配合本项目里的倍率概念：假设某站倍率 0.5，官方输入价 $3/百万 token：

不用缓存：800万 × $3 × 0.5 = $12
用缓存：  600万 × $3 × 0.1 × 0.5  +  200万 × $3 × 0.5
        = $0.9 + $3 = $3.9

差了三倍。 而这两家的倍率可能是一样的 —— 差别只在是否透传缓存字段。

为什么中转站可能不支持

缓存依赖请求里的特殊字段（如 cache_control），以及响应里返回的缓存统计。中转站在中间做转发时：

• 如果它原样透传，缓存生效
• 如果它重建请求（比如为了改写参数），缓存字段可能被丢掉
• 如果它用的上游通道本身不支持，也生效不了

问题在于：这三种情况从外部看不出来。 站点的宣传页通常不会写这一点。

怎么验证一家站是否支持

方法一：看响应的 usage 字段

发一个带有缓存标记的请求，检查返回的 usage：

{
  "usage": {
    "input_tokens": 1000,
    "cache_creation_input_tokens": 800,
    "cache_read_input_tokens": 0
  }
}

如果完全没有 cache 相关字段，说明这个站的响应里不含缓存信息。这不绝对等于不支持，但说明它至少没有把它暴露出来。

方法二：连发两次同样的请求

# 第一次：写入缓存
# 第二次：应该命中缓存

对比两次返回的 cache_read_input_tokens。第二次应该是非零值。

方法三：直接对账（最可靠）

跑一天真实流量，然后：

理论消耗（不含缓存）= 总输入token × 输入单价
实际消耗 = 余额差额

若 实际 < 理论 × 0.7  → 缓存很可能生效了
若 实际 ≈ 理论        → 缓存未生效

它值不值得作为选型依据

值得，而且应该排在倍率之前。

理由：缓存影响的是你的 token 结构，而 token 结构是可以差出几倍的。倍率的差异通常不到两倍。

排序建议：

1. 是否支持缓存（影响可达 3-5 倍）
2. 稳定性（影响可用性）
3. 计费口径是否透明
4. 倍率（影响约 2 倍以内）
5. 支付便利性

这不意味着倍率不重要，而是说：先确认口径，再比价格。口径不清楚的情况下去比倍率，比出来的是假数字。

如果你的站点不支持缓存怎么办

三个可行的应对：

一、自己压缩上下文。 把重复的 system prompt 精简，只送必要的上下文。

二、改变请求结构。 尽量把可变内容集中在后部 —— 这样即使没有缓存，未来换成支持缓存的站时迁移成本也低。

三、换站。 如果你的应用天然是「大段重复上下文」型（RAG、代码补全），那缓存的价值很大，值得为此换一家支持的站。

相关阅读

• 从官方价到你的账单：一次完整的成本换算演练
• 从官方价到实际账单：一次完整的成本换算演练
• 推理模型的账单为什么比预期高