先看现象。把超过 2 万 token 的文档统一路由到支持 128k 的模型做摘要，一周后账单显示摘要任务占了总成本 61%，人工抽查发现 3000 字的分段摘要质量差不多。
排查方向其实有限，先把可能性排一排。按文档总长度路由，没有看真正需要摘要的正文长度。也可能是128k 档位单价是普通档四倍，长上下文还按全量输入计费。
另外，摘要结果没有缓存，同一份文档被不同入口重复提交。
少数情况下是分块摘要与整篇摘要没做对比，默认就选了贵的那个。
动手时先按文档长度分桶统计调用量与成本
python cost_report.py --group-by len_bucket --since 7d接着对 4 万 token 以上的文档试用分块摘要
python summarize.py --mode chunk --chunk 6000 --file docs/同一批 50 篇文档双跑对比质量与单价
python ab_summary.py --docs 50 --modes chunk,long末了把路由条件从总长度改成有效正文字数
python -c "import json;print(json.load(open('route.json'))['summary'])"怎么算真的好了，看的是同一批现象。摘要成本占比从 61% 降到 24%，50 篇双跑样本的人工评分差在 0.2 分以内，长文档的要点覆盖没有下降。
长上下文模型贵的不只是是倍数，输入按整篇计费时，把附录和页眉页脚先剔掉，比分块更省钱也更稳。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。