事情本身不复杂，线索都在日志里。同一段 3000 token 的 system 前缀连续调用 200 次，控制台账单里 cached tokens 显示 0，但响应 usage 里有 cached_tokens 字段，怀疑计费与统计用了两套口径。
第一反应是「统计看的是组织维度，缓存按项目维度计」，验证下来不成立。
原因不止一个，得分开看。缓存只在请求间隔小于 5 分钟时生效。还有一种是前缀里有时间戳，每次请求都算新前缀。
不容易想到的是，SDK 版本旧，usage 里的缓存字段没被上报。
先确认两次请求的间隔是否在有效期内
python -c "import time;print('gap seconds', 300)"再往下把时间戳挪到 user 消息末尾再压测
python bench.py --prefix system_long.txt --repeat 200 --interval 60从响应里逐条累计缓存 token
python -c "import json;d=json.load(open('resp.json'));print(d['usage'].get('prompt_tokens_details'))"剩下的就是对比账单明细与本地累计值
python reconcile.py --local cache_stat.csv --bill usage_export.csv怎么算真的好了，看的是同一批现象。第二次之后的请求 usage 里 cached_tokens 稳定在 2900 以上，账单的缓存单价那一栏出现金额，本地累计与账单差额小于 1%。
容易忽略的是，缓存命中率和前缀稳定性强相关，前缀里只要有一个会变的字段，整个缓存就作废，计费口径不一致往往只是缓存压根没命中。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。