先看现象。提示词从 v3 灰度到 v4，按 user_id 取模放 50% 流量，上线两小时后监控显示 prompt cache 命中率从 62% 掉到 3%，账单里缓存读这一项几乎消失。回滚到 v3 后命中率立刻回到 60%，试过把灰度比例降到 10%，命中率还是低。
把日志和配置对完，能解释这个现象的基本就这几处。两个版本的 system 前缀不同，缓存键按前缀哈希分成了两份。另一种情况是灰度用户在同一会话里来回切版本，每次都重建缓存。
还有一种情况，缓存 TTL 只有 5 分钟，灰度期间的请求被打散。
另外，监控按请求数算命中率，灰度组样本少把整体拉低。
上来先确认两个版本的前 400 个字符是否一致
python -c "a=open('v3.txt').read();b=open('v4.txt').read();print(a[:400]==b[:400])"接着把变更挪到 system 末尾再灰度
python -c "print('keep prefix stable, append diff')"从账单拉出缓存读的 token 数
curl -s https://api.openai.com/v1/organization/usage/completions -H "Authorization: Bearer $KEY" | head -c 400末了按灰度组分别统计命中率
python -c "import json;rows=[json.loads(l) for l in open('usage.jsonl')];print(sum(r['cached'] for r in rows)/max(1,len(rows)))"改完先别撤，确认这几项。灰度组与对照组的缓存命中率都在 58% 以上，账单里缓存读的 token 数恢复，v4 的评测分数不低于 v3。
补一句。提示词缓存认的是前缀，改动只要落在 system 开头就会让整段前缀失效，灰度期间两组各建一份缓存，成本按版本数翻。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。