论文速读 | Beyond Accuracy: How Quantization Affects Coding Agents（arXiv:2611.02368，2026-11-02，Traversaal AI 与 Kansas State University，SLMs for Agentic Systems 2026 Workshop）
一个被默认但没被验证的假设
「4-bit 量化几乎无损」大概是过去两年被重复最多的工程信条之一。AWQ、GPTQ 这类 weight-only 方案把模型体积压到约 3.4 倍小，各大评测榜单上 perplexity 和单轮问答精度的损失通常在小数点后两位。于是本地部署 Coding Agent 的标准姿势变成了：Qwen2.5-Coder-32B 拉一个 4-bit 量化版塞进消费级显卡，跑 agent 循环，效果「基本一样」。
问题在于，这些结论全部来自单轮生成的评测。而 Coding Agent 不是单轮生成：它要调用执行器、读报错、改代码、再跑一遍。量化扰动作用在这样一个多轮反馈系统上，完全可能出现「最终分数没变，但中间行为面目全非」的情况。这篇论文就是第一个系统验证这件事的实证研究，结论比想象中更有冲击力。
实验设计：小而干净，统计上相当严谨
论文比较了四个模型——Qwen2.5-Coder-Instruct 的 7B、14B、32B，以及面向 Agent 场景的 Devstral-Small-2507（24B）——每个都跑 BF16、4-bit AWQ、4-bit GPTQ 三种精度。量化用 llmcompressor 生成（256 条校准样本，校准序列长度 1024），推理统一用 vLLM，OpenAI 兼容的工具协议。
Agent 本身是最小化设计：只有一个 python_executor(code, stdin) 工具，写代码、跑样例、看反馈、修改，每题最多 5 轮工具调用，采样参数温度 0.6、top-p 0.9，上下文 32k。评测集用 OJBench 的 NOI 与 ICPC 竞赛题，只取 Easy 和 Medium 共 115 题（Hard 集所有配置全部 0 分，直接弃用），Python 一种语言，每个配置跑 3 个种子，得到 345 个配对观测。
值得专门表扬的是统计功课。这不是「跑一遍看平均分」的野路子评测：作者用了配对 McNemar 检验加 Holm 多重比较校正、按题目聚类的 bootstrap 置信区间（20000 次重采样，保持同一题的三个种子在一起）、以及题目内置换检验。在这个基数很低（整体通过率 5% 到 14%）的评测上，这种严谨度让后面「无显著损失」的结论有了可信度，也让「行为漂移」的发现没法用「方差太大」搪塞过去。
发现一：最终精度确实没掉
整体精度（Easy 加 Medium 加权）上，五种配置的量化损失全部不显著：
| 模型 | BF16 | AWQ | GPTQ |
|---|---|---|---|
| Qwen-7B | 7.83% | 7.25% | 6.67% |
| Qwen-14B | 11.30% | 9.28% | 9.86% |
| Qwen-32B | 13.91% | 10.72% | 11.01% |
| Devstral-24B | 4.64% | 6.09% | 5.51% |
Qwen-32B 降幅最大（约 3 个点），但 Holm 校正后 p 值 0.21，按题目聚合分析 p 值 0.051，都过不了显著性门槛。Devstral 量化后精度甚至名义上略升。如果评测到这一步为止，结论就是广告词级别的「4-bit 无损」，量化部署安心用。
但作者没有停在这里。
发现二：一次通过率崩塌，循环解题暴增
这是全文最有力的一张牌。Qwen-7B 的解题轨迹在量化前后完全变了形：
- BF16 下有 17 题一次写对、全程不碰执行器；AWQ 量化后这个数字是 0，GPTQ 也只剩 3；
- 循环式解题（至少跑一轮执行反馈）从 10 题涨到 AWQ 的 25 题、GPTQ 的 20 题；
- 这个漂移在按题目聚合的分析下依然显著，甚至在两种精度都解出的题目子集上也成立——也就是说不是「难题掉出去、剩题变简单」的构成效应，而是同一批题的解法路径真的变了。
Devstral 则朝反方向漂：有效工具调用率从 BF16 的 8.7% 跌到 GPTQ 的 1.2%，GPTQ 下它仅有的 19 个成功全部是一次通过；它发起工具调用的频率本身也从 42% 掉到 AWQ 的 27%、GPTQ 的 21.4%。一句话总结：量化把 Qwen-7B 推向「更依赖工具」，把 Devstral 推向「不敢用工具」。
另一组背景数据也值得记住：Qwen-32B 在 BF16 下 71.3% 的题都用工具、一次通过为零，Qwen-14B 则是 31.6% 的工具使用率、一次通过和循环解题几乎对半。「会不会用执行器」在模型家族内部差异巨大，量化对这种模式的改变是模型特异的，不存在统一规律。
发现三：失败的方式变了
把每道失败题归到终止类别（运行时异常 IR / 答案错误 WA / 超时 TLE / 编译错误 CE / 内存超限 MLE），量化前后的分布同样在移动：
- Qwen-7B 在 AWQ 下 WA 占比从 65 降到 59.7，IR 从 21.7 涨到 29——错答案变成运行崩溃；
- Qwen-32B 的编译错误明显高于小模型（BF16 每种子 13.3 次），量化后继续上涨到 17.7 与 20.7；
- Devstral 的变化最剧烈且统计显著：IR 从 53.3 大幅降到 37.3 至 39.3，WA 和 TLE 随之上升，TLE 从 7 涨到 14.3。
失败模式的迁移对工程实践有直接影响：如果你的自动化流水线按失败类型做了差异化处理——比如编译错误触发重试、超时触发降级——量化前后这套策略的有效率是会变的。
我的工程判断
第一，「无显著损失」有相当成分是统计功效问题。 基础通过率只有 7% 到 14%，115 题乘 3 种子的样本量下，McNemar 检验对 2 到 3 个点的真实损失缺乏检出力——Qwen-32B 问题级 p 值 0.051 已经贴着门槛。正确解读不是「量化免费」，而是「这个实验规模下检测不出 3 个点以内的损失」。对精度预算以百分点计的生产系统，这个区别不是小事。
第二，成本账要按轮次算，不能按显存算。 量化的直接收益是权重体积缩小 3.4 倍、吞吐提升 2 到 3 倍；但 Qwen-7B 的循环解题从 10 涨到 25，意味着每题平均工具轮次上升，每轮都是一次完整的前向推理加上不断变长的上下文。假设平均轮次从 1.5 涨到 2.5，token 开销涨约七成，量化的吞吐收益大概率被吃掉一截。真正的总成本等式是：显存节省加单 token 提速，减去轮次膨胀乘上下文增长。这篇论文没算这笔账，但它的数据恰好提供了算账的原料——这是我认为每个本地部署者都该拿自己的任务复测的量。
第三，校准配置有个值得警惕的失配。 校准序列长度 1024，而服务上下文 32768。weight-only 量化本身不量化 KV Cache，激活也是 16-bit，所以这个失配不像 KV 量化那么致命，但权重缩放因子是基于短序列分布校准的，长上下文下的注意力模式分布外，这可能正是工具调用格式这类「长程格式记忆」率先劣化的诱因之一。这是我基于数据的推测而非论文结论，但校准长度对齐真实服务长度是零成本动作，建议照做。
第四，「Agent 专用模型」的标签在这套最小 harness 下没兑现。 Devstral-Small-2507 是以 Agent 能力为卖点的模型，整体精度却是四个模型里最低的（BF16 仅 4.64%），而且大多数工具调用不符合工具 schema——问题出在 harness 与提示词的匹配上，不在模型不会写代码。这再次验证了一个反复出现的教训：工具调用的可靠性是「模型乘 harness」的乘积，跨 harness 评测一次再下选型结论，比看任何宣传页都管用。
第五，OJBench 是个放大镜，不是镜子。 竞赛题是高推理强度、弱基础能力的极端场景（Hard 全军覆没就是证据），Agent 只有一个工具、最多 5 轮。真实的 SWE 场景里模型基础能力更强、工具面更宽、轮次几十起步，量化的轨迹扰动在更长循环里可能复利放大，也可能被更强的底座吸收。方向上「看轨迹不只看分数」的结论我认为可以外推，具体幅度必须实测。
选型建议：本地跑 Coding Agent，32B 级别优先 GPTQ（论文中精度和行为都更稳）；7B 小模型对量化最敏感，若任务允许尽量留 BF16 或上 FP8；无论选哪个，把「一次通过率、工具调用率、失败类型分布」加进你的回归评测集——只盯 pass@1，你会在不知不觉中为一个行为完全不同的模型买单。
一句话收束
这篇论文最大的贡献不是某个数字，而是把「量化评测」的定义往前推了一步：对 Agent 系统，精度是必要统计量，但轨迹、工具使用和失败模式才是行为的全貌。任何在本地跑 Agent 循环的人，都值得花二十分钟把这篇读一遍，然后回头看看自己上次的量化评测少测了什么。