中转站缓存命中却没省钱？用请求明细核对缓存读写与实际扣费

看到“缓存命中”却没有明显省钱，不一定是扣费错误。缓存通常影响特定输入部分的费用；输出、缓存写入和额外功能可能仍收费，中转站是否传递优惠也取决于它的计费说明。

本篇给出自己可执行的账单核对方法，不提供任何服务商的测试结论。所有数字均为演示数据。

先区分三类输入

不同模型与 API 可能使用不同字段、最低缓存长度、有效期和控制方式。不要把某个模型的规则直接套给另一个，也不要假设缓存读取永远是普通输入的固定折扣。

准备能定位到请求的记录

在固定模型、分组、Key 和接口协议下，保存每次请求的时间、请求 ID、总输入量、缓存读取量、缓存写入量、输出量和账单扣费。

一些兼容接口会在 usage 里显示 cached_tokens 等字段；字段名称与嵌套位置要看所用接口说明。有的接口把缓存 Token 包含在总输入量中，有的统计方式不同，必须先核对定义，避免重复加总。

中转站返回字段与自己的后台账单都要保存。缺少写入量或读取明细时，只能记录“当前证据不足”，不能直接推断全部命中或完全没有缓存。

一个有预算上限的对照方法

1. 选择无敏感数据、足以满足该模型缓存条件的固定材料，设定少量测试预算。
2. 按模型文档配置缓存，固定可复用前缀或断点；如果不支持对应参数，不要强行套用。
3. 连续运行少量请求，只改变后面的简短问题，保存每次完整用量。
4. 增设一组改变前缀的对照请求，检查用量字段是否出现预期差异。
5. 测试结束后核对分项费用；如果要判断不同时段表现，再另设预算复测。

单次未命中可能与长度、路由、有效期或断点有关。多轮结果也只是这组配置、时间与样本的表现，不能推广为平台永久命中率。

命中次数与 Token 命中率不同

假设三轮总输入分别为 10,000、10,000、80,000 Token，其中缓存读取分别为 9,000、9,000、0。

按轮次看，3 轮中 2 轮命中，比例约 66.7%；按 Token 看，总读取 18,000 ÷ 总输入 100,000 = 18%。只看“2/3 命中”会高估对这组输入费用的影响。

如果你只关心可复用前缀，也可以单独计算前缀命中比例，但应明确分母，不能与总输入命中率混称同一个指标。

分项计算，避免把缓存重复计入

假设总输入 10,000 Token，其中普通输入 1,000、缓存读取 8,000、缓存写入 1,000，三者互不重叠。演示单价分别为 10、1、12.5 元/百万 Token；输出 1,000 Token，30 元/百万。

应计费用 = 0.01 + 0.008 + 0.0125 + 0.03 = 0.0605 元。

这个示例没有额外工具费用、余额换算或其他倍率。如果接口定义不同，应先把各字段转换为不重叠的计费项；价格已含倍率时不要重复乘。

有偏差时先排查这些项目

确认同一请求、同一时区、同一渠道；检查余额单位与人民币换算、价格是否变化、日志是否延迟、显示小数位是否四舍五入，以及失败重试是否生成额外账单。

输出很长时，即使输入缓存效果好，总费用也未必显著下降。缓存写入成本还可能抵消前几轮节省，应该把首轮和后续复用一起计算。

回答一模一样，说明缓存命中了吗？ 不说明。提示缓存复用输入处理，不等于复用完整回答，文本结果不能替代用量证据。

命中率高能证明模型是真的吗？ 不能。返回字段和模型来源是不同的证据问题。

参考：OpenAI 提示缓存文档（本稿核对日期：2026-09-08；该文档只说明对应官方 API，中转实现仍需单独核验）。

继续使用账单追踪指南保存记录，或在模型价格查看具体报价。