自建网关统计 prompt cache，把 cache_creation_input_tokens 和 cache_read_input_tokens 加在一起做分子，面板显示命中率 92%，按账单反推实际只有四成左右。
一开始怀疑是「usage 缺失时按 0 处理，分母被压小」，查了一圈，方向不对。
排查方向其实有限，先把可能性排一排。写入缓存的 token 成本更高，不能算作命中。另一种情况是正则同时匹配了两个字段名，统计时一起累加。
另外，多轮请求里同一段缓存被重复计数。
上来先把两类 token 分开拉出来看
python -c "import json;u=json.load(open('usage.json'));print(u.get('cache_creation_input_tokens'), u.get('cache_read_input_tokens'))"然后按请求 id 去重后再算比例
python -c "import pandas as pd;d=pd.read_csv('usage.csv').drop_duplicates('request_id');print(d[['read','write','prompt']].sum())"命中率只算 read 除以总输入
python -c "print(round(412000/(412000+610000),3))"等前面都确认过，再用账单金额反推一次做交叉验证
python -c "print(round(412000*1.0/ (412000*1.0 + 610000*1.0),3))"恢复的判定其实很直接。面板命中率回落到 0.4 左右，与账单反推的值一致，缓存写入那部分单独有一栏成本。
这里还有个坑。缓存写入是花钱买未来的折扣，把它算成命中等于自己骗自己，统计口径要按计费语义拆开，read 和 write 是两笔完全不同的账。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。