提示缓存命中怎么验证：从账单反推命中率

提示缓存（prompt caching）常被当成纯优化项，实际上它是账单里最容易被高估的一项能力。厂商宣称能省 50% 以上，但只有命中率足够高时才成立。

最直接的验证方法是三次请求法。第一次发送一段固定前缀加不同后缀，记录 usage 里的 cache 相关字段；第二次用完全相同的前缀，只改后缀；第三次把前缀改一个字。三次的输入计费如果有两次明显低于第一次，说明前缀缓存确实生效，且对前缀边界敏感。

要注意缓存的最小长度。多数实现要求前缀达到几百到一千 token 才进入缓存，短提示不会命中。把系统提示与长文档放在前面、变量放后面，是命中率最高的写法；反过来把用户问题放最前面，就等于每次都是新前缀。

第二个观察点是延迟。命中缓存的请求，首 token 时间通常明显下降，因为跳过了前缀计算。如果账单降了但延迟没变，要怀疑是不是计费侧做了折扣而实际并未缓存，这种情况在部分中转上出现过。

第三个观察点是跨请求一致性。缓存的生存期通常是几分钟到一小时，过期后重新计费。批量任务如果并发度很高，同一前缀会被多个请求同时读入，实际节省有限；串行或小并发反而更容易吃满缓存。

把命中率写进监控：每周抽样一批固定前缀请求，记录命中比例与单次成本，与未命中时对比。这个数字比宣传页上的折扣比例更能指导预算。

如果站点完全不返回缓存相关字段，就只能用延迟做间接判断：同一前缀连续两次请求，第二次首 token 时间显著下降且账单金额下降，可以认为命中；两者只降其一，就值得向客服确认计费口径。把这类观察写进周报，比事后对账更容易发现折扣是否真的生效。