这个坑值得记一笔。批量评测 500 条，其中 90 条请求超时被脚本记为 0 分，均分从 84 掉到 69，实际上这批题在另一次运行里大多能答对。
刚开始盯着「单条超时设得比模型 P99 还短」，折腾了半个多小时，排掉了。
这类报错背后常见的原因有几处，逐个排除就行。超时被当成错误答案参与平均；并发过高触发限流，大量请求排队超时；失败样本没有重跑机制。
第一件事是把失败原因分类统计出来
python -c "import json,collections;rs=[json.loads(l) for l in open('res.jsonl')];print(collections.Counter(r['status'] for r in rs))"然后把超时样本单独挑出而不是记零分
python -c "import json;print([r['id'] for r in map(json.loads,open('res.jsonl')) if r['status']=='timeout'][:5])"降低并发并放开单条超时后重跑
python run_eval.py --concurrency 4 --timeout 120 --retry-failed均分只统计成功样本并单独报告失败率
python report.py --in res.jsonl --exclude-failed --report-failrate改完先别撤，确认这几项。均分回到 84 附近，失败率单独列在报表里，超时样本重跑后成功率超过 95%。
把超时算成 0 分等于把基础设施问题记到模型头上，指标要分开报，否则整个评测结论都会被带偏。报错文案容易误导，真正的原因往往在相邻那一层的日志里。