一条流水线吃下量化+剪枝+蒸馏：拆解 Model-Optimizer 三大压缩引擎如何协同

一条流水线吃下量化剪枝蒸馏拆解 Model-Optimizer 三大压缩引擎如何协同【免费下载链接】Model-OptimizerA unified library of SOTA model optimization techniques like quantization, distillation, pruning, neural architecture search, speculative decoding, etc. It compresses deep learning models for downstream deployment frameworks like TensorRT-LLM, TensorRT, vLLM, etc. to optimize inference speed.项目地址: https://gitcode.com/GitHub_Trending/te/Model-Optimizer大模型部署正在经历一场压缩军备竞赛FP8 已成标配NVFP4 冲进 4-bit剪枝从学术论文走进生产流水线蒸馏则从教学技巧变成精度恢复的兜底方案。但对绝大多数团队而言这三件事至今仍是三条独立工具链——量化工具管量化、剪枝脚本管剪枝、蒸馏框架管蒸馏各自的 checkpoint 格式互不认账拼装成本远高于单点收益。NVIDIA Model OptimizerModelOpt给出的答案是把量化、剪枝、蒸馏、NAS、投机解码、稀疏化全部收进同一个 Python 库让它们以模式mode的形式可叠加地施加到同一个模型对象上最后统一导出为 TensorRT-LLM、vLLM、SGLang 都能直接加载的 checkpoint。社区对其的关注也从又一款量化工具升级为统一压缩流水线——本文将基于仓库源码与其端到端教程拆解这条流水线究竟是如何把三大引擎串起来的。一、为什么要一条流水线压缩技术之间的耦合关系单点压缩的收益是有上限的。剪枝能砍掉冗余结构但砍完精度必然掉量化能 2~4 倍压缩体积但精度损失视格式激进程度而定蒸馏能让学生逼近教师但需要消耗训练算力。真正的问题是三者互为因果剪枝制造精度缺口需要蒸馏来补Minitron 论文的标准实践就是剪枝后跑一段短蒸馏再交付量化制造精度缺口同样需要蒸馏来补当格式激进到 W4A4 时PTQ 已经扛不住必须做量化感知蒸馏QAD蒸馏产出的学生模型仍然值得再量化一次精度恢复后FP8/NVFP4 的低精度收益才能放心兑现。于是最优解天然是一条链式流水线剪枝 → 蒸馏 → 量化 → 导出。这也是仓库端到端教程反复验证的顺序README 中 2026 年 5 月的更新直白地写道Nemotron-3-Nano-30B-A3B 经Pruning two-phase distillation FP8 quantization后获得 2.6× vLLM 吞吐与 2.6× 内存缩减且各基准精度基本保持。二、三大引擎的架构定位一切皆模式mode流水线能串联的前提是三大引擎共享同一套模型改写与状态管理机制。核心设计位于 modelopt/torch/opt/mode.py每种优化技术都是一个ModeDescriptor通过apply_mode施加到模型上施加过程被记录进模型的 modelopt state dict。ModeloptStateManagermodelopt/torch/opt/conversion.py负责状态与元数据的保存、恢复这让先量化、再蒸馏这类叠加操作有了统一契约——蒸馏完的 checkpoint 仍保留量化状态可以直接导出部署。量化引擎mtq.quantize 校准 格式矩阵量化入口是 modelopt/torch/quantization/model_quant.py 的mtq.quantize(model, config, forward_loop)先按quant_cfg将原模块替换为带TensorQuantizer的量化版本再用forward_loop灌入少量校准数据完成校准。配置采用先全禁、再按通配符逐层启用的条目式语法例如MY_QUANT_CFG { quant_cfg: [ {quantizer_name: *, enable: False}, # deny-all {quantizer_name: *weight_quantizer, cfg: {num_bits: 8, axis: 0}}, {quantizer_name: *input_quantizer, cfg: {num_bits: 8, axis: -1}}, ], algorithm: max, }这套机制支撑了 FP8、NVFP4、INT8、INT4 等格式与 SmoothQuant、AWQ、SVDQuant 等算法的自由组合格式清单见 modelopt/torch/quantization/config.py并进一步演化出auto_quantize自动混合精度搜索与 KV cache 量化。此外modelopt/torch/quantization/compress.py 的compress_convert会把伪量化权重真正打包成低精度张量Real Quant把压缩从仿真变成落地。剪枝引擎约束驱动的架构搜索剪枝入口是 modelopt/torch/prune/pruning.py 的mtp.prune(model, mode, constraints, dummy_input)。它不做逐权重置零而是把模型转成搜索空间在约束下寻找最优子网络Minitronmcore_minitron同构剪枝按激活幅度重要性评分统一裁剪层数、隐藏维度、FFN 宽度、注意力头、MoE 专家数等维度FastNAS面向 CV 模型的异构搜索Puzzletron基于混合整数规划MIP的 NAS 算法可跨异构架构搜索。约束可以是参数量、FLOPs甚至显存足迹{params: 60%}或{flops: 4.5e6}也可以直接给export_config指定目标架构。搜索过程支持自定义评分函数如 10% 采样的 MMLU输出 top-K 候选架构供进一步蒸馏验证。蒸馏引擎teacherstudent 元模型蒸馏核心在 modelopt/torch/distill/mtd.convert(model, mode)把学生模型包装成同时封装 teacher 与 student 的DistillationModel训练完成后mtd.export()还原出纯学生。配套的 loss 体系LogitsDistillationLoss、MGDLoss、MFTLoss与StaticLossBalancer等损失均衡器见 modelopt/torch/distill/losses.py。对 Hugging Face 用户仓库还提供KDTrainer——直接替换 HF Trainer内部处理 teacher 前向与 KD 损失计算学生保持普通 HF 模型结构用法见 examples/llm_distill/README.md。三、协同的关键checkpoint 贯穿 量化感知蒸馏三大引擎真正协同的机制是量化 checkpoint 可以直接作为蒸馏的学生模型。在 Megatron-Bridge 工作流中examples/megatron_bridge/README.md每个脚本的输出都是下一个脚本的输入prune_minitron.py从 HF checkpoint 出发产出剪枝后的 HF checkpointdistill.py以原始模型为 teacher、剪枝/量化模型为 student产出蒸馏后的 Megatron checkpointquantize.pyPTQ 校准产出带 ModelOpt 状态的量化 checkpoint可继续训练export_quantized_megatron_to_hf.py导出统一 HF checkpoint直接部署。其中 QADQuantization-Aware Distillation是最能体现协同的环节量化 checkpoint 通过--student_megatron_path直接载入 distill.pyModelOpt 量化器自动恢复蒸馏过程让模型学习能扛住 4-bit 取整的权重。仓库甚至为此专门调低了学习率--lr 1e-5因为任务是让权重适配量化而不是从头学任务。四、案例一剪枝 蒸馏 FP8 量化30B 模型压缩出 2.6× 吞吐examples/megatron_bridge/tutorials/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16/README.md 展示了完整的四步流水线Minitron 剪枝把 31.6B/A3.6B 的 MoE 模型剪到 22.28B/A3.0Bactive 参数为主约束两阶段蒸馏80B tokens 8K 序列 20B tokens 32K 长上下文把精度拉回最后 FP8 PTQMamba 与 MoE 层量化、注意力保持 BF16收尾。实测数据显示了压缩收益的叠加效应单 H100ISL32768/OSL1024Checkpoint加载内存输出吞吐相对原始 BF16原始 31.6B/A3.6B BF1658.9 GiB598 tok/s1.0×原始 FP831.4 GiB1,323 tok/s2.2×剪枝 22B/A3.0B BF1641.5 GiB1,190 tok/s2.0×剪枝 22B/A3.0B FP822.8 GiB1,576 tok/s2.6×剪枝单独带来 2.0×、FP8 单独带来 2.2×两者叠加却不止112而是 2.6× 吞吐与 2.6× 内存缩减——这正是流水线而非单点工具的收益所在。蒸馏后的模型在 MMLU Pro、GPQA Diamond、AIME 2025 等 8 项基准上平均 70.5与官方 72.1 差距极小。五、案例二W4A4 NVFP4 走不通QAD 把它拉回 BF16 精度第二个案例更极端examples/megatron_bridge/tutorials/Qwen3.6-35B-A3B/README.md 直接挑战 W4A4权重激活全 4-bit。仓库给出一个反直觉的结论权重-only 的 NVFP4 在 12 种测速 shape 中有 10 种比 BF16 更慢——BF16 激活迫使 vLLM 回退到 Marlin 反量化路径永远摸不到 Blackwell 的 FP4 张量核心。只有把激活也量化W4A4 才真正解锁硬件收益。于是流水线变成W4A4 NVFP4 PTQ → QAD 500 步蒸馏 → 导出部署。QAD 的作用被严格量化评估W4A4 只在 IFBench−2.6pp和 MMMU-Pro−1.2pp上造成真实损失QAD 恰好把这两处分别恢复到 −0.3pp 与 −0.7pp其余四个基准本就无损失可恢复。最终收益checkpoint 从 67 GiB 压到 22 GiB3.1×prefill 32000/400 shape 下吞吐达 BF16 的 1.30×12 种测速 shape 中 9 种超过 BF16、全部超过 W4A16。值得注意的是99.2% 的量化张量集中在 MoE 专家层——量化格式选择本身就是一种架构级的工程决策。六、衔接推理引擎统一导出与格式契约流水线最后一公里是格式不打架。ModelOpt 用统一的 Hugging Face checkpoint 作为部署契约export_hf_checkpointmodelopt/torch/export/unified_export_hf.py把量化模型导出为一组 safetensors 权重、一个hf_quant_config.json量化配置及模型结构信息。所有后端共享同一套格式名定义在 modelopt/torch/export/quant_format.pyfp8、nvfp4、int8_sq、int4_awq、w4a8_nvfp4_fp8等导出与推理端对格式的理解天然一致。导出后的 checkpoint 可直接被三条路径消费TensorRT-LLM其 PyTorch backend 直接加载统一 HF checkpoint无需构建 TensorRT engine见 docs/source/deployment/1_tensorrt_llm.rstvLLM / SGLangvLLM 从 checkpoint 自带的quantization_config读取精度与 KV cache 设置如教程中 FP8 部署需--kv-cache-dtype fp8、NVFP4 需 FlashInfer MoE 相关环境变量仓库还维护了 vLLM fake-quant 相关插件modelopt/torch/export/plugins/覆盖只导出配置、运行时假量化的轻量路径。从 README.md 的路线图看这条衔接链仍在扩张统一导出 API 已同时覆盖 transformers 与 diffusersSGLang 与 vLLM 的官方 checkpoint 集合持续上新。对部署团队而言ModelOpt 的价值不止于单点技术领先更在于把选型、压缩、恢复、导出压缩成一条可复现的流水线——剪枝的缺口由蒸馏补量化的成本由 QAD 摊最后统一落到推理引擎的格式契约上。这正是社区把目光从TensorRT 加速转向Model-Optimizer 统一流水线的原因当 4-bit 都开始不够用能叠加才是真本事。【免费下载链接】Model-OptimizerA unified library of SOTA model optimization techniques like quantization, distillation, pruning, neural architecture search, speculative decoding, etc. It compresses deep learning models for downstream deployment frameworks like TensorRT-LLM, TensorRT, vLLM, etc. to optimize inference speed.项目地址: https://gitcode.com/GitHub_Trending/te/Model-Optimizer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考