报错是这么冒出来的。客服场景的 system 有 2400 token 的规则和话术，多轮对话每轮都整段重发，月账单从 1.4 万涨到 3.2 万，缓存命中率显示是 0。
中间走过弯路，把「历史消息拼接顺序每次不同，前缀不稳定」当成主因，改完现象没变。
把日志和配置对完，能解释这个现象的基本就这几处。system 里混了时间戳和用户昵称，前缀每次都变。另一种情况是请求里没有开缓存相关参数。
另外，换了模型但缓存是按下限较短的模型算的。
先确认前缀是否真的逐字节一致
python -c "import hashlib;print(hashlib.md5(open('sys.txt','rb').read()).hexdigest())"接着把变量部分从 system 挪到 user 末尾
python -c "print('system=static; vars=tail')"然后确认请求里带了缓存参数
python -c "print({'prompt_cache_key':'svc_v3'})"等前面都确认过，再对比改动前后缓存命中的比例
python cost_report.py --group-by cache_hit --since 7d怎么算真的好了，看的是同一批现象。缓存命中率从 0 到 71%，system 部分按缓存价计费，月账单回落到 1.6 万，回答质量没有变化。
提醒一点。缓存命中的前提是前缀完全一致，system 里放任何随请求变化的内容都会让命中率归零；变量统一挪到末尾是改动最小的做法。报错文案容易误导，真正的原因往往在相邻那一层的日志里。