一把 key 上六个后端的缓存命中怎么查：哪些前缀真的省下了 USDC
讲清楚如何用一把聚合 key 分辨不同后端的缓存命中，判断哪些重复前缀真的省了钱、哪些在重复计费。
为什么一只 key 后面的缓存要单独看
聚合站把一次请求路由到 Claude、GPT、DeepSeek、Qwen、GLM、Kimi 等不同后端，各家的上下文缓存机制并不相同：有的自动命中、有的需要显式声明、有的按前缀长度门槛收费或打折。所以你看到的“总 token 数”无法直接说明省钱与否，必须按后端拆开看。
先分清三种“缓存”
- 服务端上下文缓存：命中后输入 token 按折扣价或缓存价计费，未命中按全价。
- 网络/网关缓存：只影响延迟，不影响计费。
- 客户端复用：你自己在本地拼 prompt，本质上仍然是新请求。
只有第一种会改变 USDC 扣费。判断省钱，只看第一种。
从响应里找哪些字段
不同后端返回的字段名不一样，但通常有这几类信息可看：
- 输入 token 中命中的部分与未命中的部分（有的拆成 cached / uncached，有的只给一个 cache_read 数）。
- 是否有“创建缓存”的额外计费（部分后端写入缓存本身收费）。
- 请求是否被标记为缓存未命中（例如返回结构与预期不符）。
聚合站在转发时一般保留上游原始 usage 字段，建议直接读原始部分，而不是只看聚合后的总数。
用前缀分组做对照实验
单次请求的数字噪声大，可靠做法是按前缀分组统计：
- 固定一段系统提示词或长文档作为“前缀”，放在请求最前面。
- 同一前缀连续发多次，记录每次的命中 token 数。
- 换一个前缀再发一组，作为对照。
- 比较两组“命中 token ÷ 总输入 token”的比值。
如果某后端第一发未命中、后续命中，说明缓存生效；如果每次都接近零命中，说明该前缀没有被复用，或者该后端不支持你这种调用方式。
判断“真省”还是“被重新计费”
可用一个粗略的口径：
- 命中部分按折扣价、未命中按全价，再乘聚合站的 ×1.3 系数，得到实际扣费。
- 与“全部未命中”的基线相比，差额就是省下的部分。
- 若某后端对缓存写入单独收费，要把这笔费用也计入，否则会把“看起来命中”误判成省钱。
常见误区：前缀太短、被中间插入的动态内容打断、或者每次请求在开头放了时间戳/用户 ID，都会让缓存永远不命中——这时你以为在复用，其实每次都在全价重算。
跨后端对比时注意口径一致
六个后端的 token 计数方式和缓存门槛不同，直接比命中率会失真。建议：
- 用同一段前缀文本、同一顺序、同一长度做测试。
- 分别记录各后端的命中 token、未命中 token、以及是否有写入费用。
- 只比“同后端内部命中 vs 未命中”的差额，再横向比较差额大小，而不是比命中率绝对值。
把结论落到成本上
- 高频复用、前缀稳定的任务（长系统提示、固定知识库、固定格式模板），在多后端上都值得做缓存验证。
- 前缀经常变化、或动态内容靠前的任务，缓存收益通常有限。
- 贡献 key 的一方按官方价 ×1.1（优质 ×1.2）返 USDC，用户按 ×1.3 扣费；缓存节省发生在输入侧，理解这一点有助于判断哪些调用模式更划算。
一个可复用的检查清单
- 请求前缀是否稳定且足够长？
- 动态内容是否被放在前缀之前？
- 响应里的命中字段是否逐次上升？
- 是否存在缓存写入费用？
- 换算成 USDC 后，是否真的低于全未命中基线？
按这套方法逐后端核对，你就能知道一把 key 背后，哪些前缀真的省下了钱。