AutoCompress 把部署约束写进剪枝搜索：三种硬件上平均准确率高出 Minitron++ 最多 6.57 个百分点
核心概要
大模型剪枝通常按参数量定目标，但参数量并不能预测延迟、吞吐和显存，这些指标取决于架构、负载、硬件与服务引擎。AutoCompress 把延迟、吞吐、参数和显存约束直接放进可微架构搜索，同时搜索全局维度与逐层结构，并用目标服务引擎中实测校准的代价模型引导搜索。在与 Minitron++ 相同的部署预算和恢复训练下，它在 RTX 5070、RTX 5080 和 H100 上把八项基准的平均准确率分别提高 6.57、2.35 和 0.57 个百分点，架构选择所用 token 约为后者的二分之一到三分之一。
深度剖析
剪枝目标从参数量预算换成部署约束：给定硬件、服务配置、精度和负载，AutoCompress 直接搜索满足延迟、吞吐或显存上限的压缩架构，并输出可独立部署的模型。 此前的 Minitron 类流程在用户给定的搜索空间和参数预算内做架构搜索，把部署要求翻译成剪枝目标仍要人工完成；而参数量本身并不反映模型在目标硬件和服务引擎上的执行代价。 在长上下文本地编程、批量数据中心服务和延迟敏感的游戏中交互三个场景中，与同样使用这些代价模型、同样预算的 Minitron++ 相比，AutoCompress 在 RTX 5070、RTX 5080 和 H100 上的八项基准平均准确率分别高出 6.57、2.35 和 0.57 个百分点。
搜索同时决定全局维度和逐层结构，因此不同层可以保留不同宽度，层也可以被整体移除。 Minitron 的搜索把各层限制为统一维度，排除了按层分配容量的架构；AutoCompress 把隐藏维度、Mamba 头数以及逐层的专家数和前馈宽度放在同一搜索空间里。 在 H100 上，两种方法选出相同的隐藏维度和 Mamba 头数，差别在于 Minitron++ 使用统一的专家数和中间维度，而 AutoCompress 逐层变化，结果蒸馏损失低 0.6%、平均准确率高 0.57 个百分点，架构选择 token 少 3.3 倍。
代价模型在目标服务引擎内测量单层运行时间并按层相加，显存则按权重、请求缓存、预填充工作区和运行时缓冲逐项估算。 仅按权重和 KV 缓存估算显存会漏掉执行工作区和运行时缓冲，在六个实际服务的 RTX 模型上这类估算低估显存 31% 到 43%。 显式计入这些分配后，测量误差约降低一个数量级；RTX 5080 上 60 次运行、468 条计时表项约耗 3.5 GPU 小时，H100 上 180 次运行耗 24.8 GPU 小时，RTX 5070 上 96 次运行耗 4.5 GPU 小时。
启示与展望
演示范围是三个具体部署目标：RTX 5070 上 4 GiB 显存与 750 ms 延迟的游戏 NPC、RTX 5080 上 13.96 GiB 与 11.5 s 的本地编程智能体、8 张 H100 上每卡 7,330 tok/s 的数据中心吞吐；另有一个把 Nemotron 3.5 Super 从 120B 压到 74B、在单张 B200 上以 BF16 服务 128K 上下文的案例。适合关注大模型部署与剪枝的工程师阅读。
大规模案例中，压缩模型的九项基准非加权均值为 54.74，父模型为 57.58，下降 2.85 分；由于训练成本，该案例没有运行 Minitron++ 基线。按层相加的延迟估计可能受架构变化引起的核选择、缓存行为和开销影响，其准确性只在未参与计时表构建的完整架构上验证。