先把当时的情况摆出来。客服系统接了 prompt 缓存，监控面板显示命中率 85%，月度账单只降了 4%，按 token 拆开看输入只占总量两成，输出长度最近涨了不少。
排查方向其实有限，先把可能性排一排。成本结构里输出单价是输入的几倍，输入占比却很低。另一种情况是命中率统计把 token 数当请求数算，口径不一致。
还有一种情况，输出没有长度上限，同一问题回答越来越长。另外，缓存只对输入打折，输出部分完全没变化。
动手时先按输入输出分别汇总 token 与费用
python -c "import json;r=[json.loads(l) for l in open('calls.jsonl')];print(sum(x['usage']['prompt_tokens'] for x in r),sum(x['usage']['completion_tokens'] for x in r))"算一下输出占总成本的比例
python -c "print(round(cost_out/(cost_in+cost_out),3))"给输出加 max_tokens 并统计截断率
python chat.py --max-tokens 300 --report truncation等前面都确认过，再按业务线拆分输出长度分布找异常场景
python usage_report.py --group scene --metric completion_tokens怎么算真的好了，看的是同一批现象。输出平均长度降到设定上限以内，总成本下降三成以上，截断率低于 2%，回答质量抽检没有明显退化。
补一句。命中率是过程指标不是成本指标，真正决定账单的是输入输出配比和输出单价，优化前先把 token 结构拆开看。这类问题最好一次改到位，反复小改反而容易把原因搅混。