AutoCompress：让大模型压缩直接对齐真实硬件约束

大模型压缩的难点，已经不只是“删掉多少参数”。同样的参数规模，换一套层宽、注意力结构、上下文长度或服务引擎，最终得到的延迟、吞吐和显存占用都可能不同。NVIDIA 研究团队提出的 AutoCompress，试图把模型压缩从依赖人工试错的参数规划，转变为面向真实部署条件的自动化搜索。

从参数量转向硬件目标

传统剪枝流程往往先设定一个模型大小，再观察它能否满足部署要求。但参数量只是粗略指标，无法直接代表目标 GPU 上的端到端表现。AutoCompress 的核心思路，是把硬件、工作负载和服务引擎共同纳入优化过程：

• 先建立成本模型：针对目标 GPU 对模型进行高效分析，估算不同架构选择对延迟、吞吐和显存的影响。
• 进行可微架构搜索：在约束条件下，同时优化全局结构和逐层结构，而不是让每一层采用相同的压缩比例。
• 生成异构模型：不同层可以保留不同规模，使有限的计算和存储预算优先分配给更重要的结构。
• 剪枝并蒸馏：确定架构后执行实际剪枝，再通过知识蒸馏尽量弥补压缩带来的质量损失。

这种流程的关键并非单纯追求更小的模型，而是让搜索目标与具体部署环境保持一致。研究中，成本模型还通过端到端的延迟、吞吐和显存测量进行验证，降低了“预测达标、实际超限”的风险。

三类场景中的结果

AutoCompress 在三种差异明显的使用场景中进行了评估：长上下文本地编码、批量数据中心服务，以及对响应速度敏感的游戏内交互。相较于 Minitron 剪枝框架，在八项基准上的平均准确率提升分别为：RTX 5070 上 6.57 个百分点、RTX 5080 上 2.35 个百分点、H100 上 0.57 个百分点。研究材料还指出，架构搜索所需的 token 数减少了约 2 至 3.3 倍。

在更大规模的案例中，团队将 Nemotron 3.5 Super 从 120B 参数压缩到 74B，用于单张 B200、BF16、128K 上下文的服务，同时保留约 95% 的平均基准得分。

意义与边界

AutoCompress 的价值在于，它把“模型质量”和“部署可行性”放到了同一个优化问题中。对于长上下文应用、批量推理和端侧交互等场景，开发者不必只根据参数量反复猜测模型是否能跑满约束，而可以直接以目标硬件和服务条件定义压缩结果。

不过，现有结果仍应结合具体硬件、工作负载和服务引擎理解。该方法强调的正是部署环境的差异，因此某一 GPU 或场景中的收益，并不意味着所有平台都能获得相同提升。更现实的影响是：模型压缩可能从一次性的人工架构设计，逐渐变成由性能测量驱动的自动化工程流程。

来源：Hugging Face Daily Papers