CMU 发布 CompressionBench：让六个编程智能体各用 8 小时压缩大模型，36 份成品 29 份通过验收，困惑度看不出的生成故障要靠答题测试才暴露

把压缩做成一道终端任务

卡内基梅隆大学 Infini-AI-Lab 的 9 位作者（含 Beidi Chen）11 月 4 日在 arXiv 提交论文 CompressionBench，并公开代码与任务。问题很直接：编程智能体能不能自己把一个大模型压到指定体积，同时让它还能用？每个任务给智能体一份原始权重、一个存储上限、一张 H200 NVL、固定版本的 vLLM 和 8 小时预算，量化、混合精度、剪枝、低秩、蒸馏怎么组合由它自己定，最后要交出压缩权重和对应的推理代码。上限同时约束保存的模型包和推理时驻留在显存里的权重，防止「小文件、运行时还原成全精度」的取巧。

参赛的是 Claude Sonnet 5.5、Claude Opus 5.5、GLM 5.3、Kimi K3.1 Pro、MiniMax M3.1 Flash 和 DeepSeek V4.1 Flash 1017，统一通过 Claude Code、最高推理强度运行。源模型是 Nemotron-3.5 Super VL 120B-A12B、Qwen3.5 122B-A10B 两个 MoE 模型（上限 32 GiB 与 48 GiB）和稠密的 Qwen3.8 27B（8 GiB 与 12 GiB）。

结果：宽松上限全过，严格上限掉队

搜索阶段智能体只能看到困惑度反馈；截止后由独立环境验收，要求 GSM8K、HumanEval、TriviaQA（各 50 题）的平均准确率保留 BF16 的 80%。36 份成品中 29 份通过，宽松上限下 18 份全部通过；严格上限下 6 份因准确率不达标被拒、1 份在答题时超时。每个任务取困惑度最低的成品，平均困惑度比 BF16 高 3.4%，平均准确率 77.33%，BF16 为 79.56%。按困惑度，各任务最好的智能体成品都优于五个已发布的量化版本；统一位宽的 GPTQ 基线只在宽松的 MoE 任务上过关。平均困惑度排名 Sonnet 第一、Opus 第二，花 API 费用最多的并不是排名最好的。

只看困惑度会漏掉什么

论文更有价值的部分是对搜索记录的分析。在包体积几乎不变的 24 次修改里，有 21 次通过改进量化器或重新分配精度降低了困惑度；整模型反馈推翻了 79 次局部排序中的 17 次。但困惑度也会骗人：Opus 在一次稠密模型任务中，困惑度持续改善，GSM8K 却从 88% 跌到 72%；GLM 和 MiniMax 剪枝后的模型在 HumanEval 上出现重复或截断输出。反过来，MiniMax 通过对比批量和逐专家推理的 token 概率，查出一个专家索引 bug，修复后困惑度增幅从约 11% 降到 4.5%。

作者把表示设计、实验判断和能力验证列为智能体自主压缩的三个关键。每组智能体与任务只跑了一次，结论仍需更多重复实验支撑；对用智能体做模型优化的团队，论文的提醒是验收必须包含真实生成测试，而不只是困惑度。