NVIDIA Model Optimizer 0.45.0：可堆叠的压缩技术栈

NVIDIA Model Optimizer 0.45.0: The Compression Stack That Stacks

问题
NVIDIA Model Optimizer (ModelOpt) 是一个工具包，它将训练好的检查点转化为可部署、硬件加速的产物——量化、剪枝、蒸馏，并导出用于TensorRT-LLM、vLLM或SGLang。0.45.0版本带来的功能集改变了我们对优化管线的认知：它不再是单次传递，而是一组可组合的变换堆叠，每个阶段都在放大上一阶段的收益。

本文是基于NVIDIA/Model-Optimizer仓库tag 0.45.0（commit ec87a82）克隆版的技术深度分析。文中引用的每个数字、命令和配置值均来源于该版本中的发布说明、示例README、YAML预设和基准测试表。没有估算，没有外推。

该版本的核心主张（值得详细了解的事情）是：剪枝和量化以乘法方式组合。Nemotron-3-Nano-30B教程展示了将Minitron结构化剪枝与FP8训练后量化叠加后，可实现2.6倍的吞吐量提升和2.6倍的内存减少——比单独使用任何一种技术都要好。这是立竿见影的好处。长期意义在于，优化管线本身成为一个可组合的、由配方驱动的系统，新的数值格式和剪枝策略可以作为YAML预设直接插入。

版本一览
ModelOpt 0.45.0基于Apache 2.0协议发布。核心包是modelopt/torch/，包含17个子包，涵盖量化、剪枝、蒸馏、稀疏性、导出和内核集成。examples/目录包含26个工作流示例，modelopt_recipes/定义了YAML预设系统，现在驱动着CLI词汇发现。

0.45.0的新功能
发布说明（/tmp/modelopt_045_release.md，78行）将变更组织为六个类别。以下是推理部署中重要的功能：

W4A16 NVFP4：无需校准前向传播的仅权重量化
最引人注目的量化特性是w4a16_nvfp4——FP4权重，group_size=16，BF16激活。发布说明明确写道：“无需校准前向传播”。这意义重大，因为标准PTQ流程的大部分时间都花在校准前向传播上，即通过模型运行代表性数据以收集激活统计信息。W4A16 NVFP4完全跳过了这一步——它是一种仅权重格式，数值转换是封闭形式的。

配置
来自modelopt_recipes/configs/ptq/presets/model/w4a16_nvfp4.yaml：
`yaml
# W4A16 NVFP4: FP4 weights, BF16 activations, no calibration
weight_quantizer:
num_bits: 4
group_size: 16
# ... NVFP4 E2M1 nibbles + per-block FP8 scales
`
group_size=16意味着每16个权重的块共享一个FP8尺度因子。这是NVFP4微缩放格式：4位E2M1权重元素与每个块的8位尺度因子配对。激活路径保持BF16——因此称为“W4A16”（4位权重，16位激活）。

如何使用
`bash
python examples/llm_ptq/hf_ptq.py \
--model_dir Qwen/Qwen3-8B \
--qformat w4a16_nvfp4 \
--output_dir /tmp/Qwen3-8B-W4A16-NVFP4
`
--qformat标志现在通过扫描modelopt_recipes/configs/ptq/presets/{model,kv}/下的YAML预设来发现可用格式。添加新的预设YAML即可使其在CLI上可用，无需修改脚本。发布说明指出，vLLM对W4A16 NVFP4的部署支持“正在进行中”。

MXFP4 → NVFP4转换
相关功能是--cast_mxfp4_to_nvfp4，它执行MXFP4权重到NVFP4的封闭形式、比特精确的转换。这针对两个模型系列：
- GPT-OSS（openai/gpt-oss-20b, openai/gpt-oss-120b）——通过examples/llm_ptq/hf_ptq.py
- DeepSeek V4——通过examples/deepseek/deepseek_v4/quantize_to_nvfp4.py，其中路由专家权重被转换（对于融合GEMM1，w1/w3共享一个per-tensor scale_2）。激活input_scale仍然来自--amax_path校准。

DeepSeek PTQ路径（examples/deepseek/ptq.py）现在默认使用原生top-k校准，并采用逐层后验统一专家input_quantizer.amax的peer-max同步。

为什么这立即重要
对于任何部署GPT-OSS或DeepSeek V4的人来说，转换路径意味着无需重新训练或重新校准权重即可从MXFP4迁移到NVFP4——转换是比特精确的。DeepSeek所需的唯一校准是激活input_scale。这将优化时间从数小时（完整PTQ校准）减少到数分钟（封闭形式权重转换 + 可选激活校准）。

长期影响
W4A16 NVFP4建立了一个模式：不需要校准的仅权重格式将量化步骤与数据管线解耦。这有两个重要意义。首先，它消除了在优化期间将校准数据（可能涉及敏感或特定领域数据）保存在内存中的需求。其次，它使量化步骤具有确定性和可重复性——相同的检查点总是产生相同的量化输出，因为没有随机校准采样。随着预设YAML系统的成熟，预计会有更多的数值格式作为“仅转换”预设发布，完全绕过校准。

Puzzletron：通过MIP实现的异构结构化剪枝
Puzzletron是此版本中架构上最有趣的功能。它不是一种统一的剪枝算法。它是一种异构结构化剪枝方法，找到逐层修改的最佳组合——不同的FFN中间大小和完整的注意力层移除——受限于目标参数数量或内存预算。

算法
来自examples/puzzletron/README.md，支持的修改包括：
- ffn_intermediate_size：每层不同的FFN中间大小
- attention op/noop：完全移除注意力层

最后阶段使用混合整数规划（MIP）找到满足目标约束的逐层修改的最佳组合。这源于Puzzle论文（arXiv:2411.19146）。

8阶段管线
该管线分8个阶段运行，每个阶段记录为“Puzzletron Progress N/8”：
1. 启动puzzletron管线
2. 将模型从HF转换为DeciLM（单GPU）
3. 评分剪枝激活（多GPU）
4. 剪枝模型并保存剪枝检查点（单GPU）
5. 构建替换库和子块统计信息（单GPU）
6. 计算一个块分数（多GPU）
7. 运行MIP并实现模型（多GPU）
8. 管线完成

第7阶段是MIP求解器搜索候选空间，以找到满足目标约束（内存、参数数量）同时最大化精度保留的架构。

支持的模型
examples/puzzletron/configs/目录包含以下配置：

展示的结果
该教程将Llama-3.1-8B-Instruct从113 GiB压缩到96 GiB（减少15%），token_accuracy_top_10退化小于1%。输出架构是异构的——例如，块17–28的注意力设置为no_op（注意力已移除），而块0–16和29–31保留gqa_4注意力，所有层保留intermediate_14336：
`
block_0: attention gqa_4 ffn intermediate_14336
...
block_16: attention gqa_4 ffn intermediate_14336
block_17: attention no_op ffn intermediate_14336 ← attention removed
...
block_28: attention no_op ffn intermediate_14336 ← attention removed
block_29: attention gqa_4 ffn intermediate_14336
...
block_31: attention gqa_4 ffn intermediate_14336
`
在更激进的30%内存减少（target_memory = 78_000 MiB）下，token精度退化约5%（0.898 vs 0.942 top-10）。--mip-only标志允许你在不重复昂贵的剪枝和评分阶段的情况下，用不同约束重新运行MIP搜索。

为什么这立即重要
Puzzletron提供了一种原则性的方法来压缩对于你的硬件来说过大的模型——不是统一缩小每一层，而是移除贡献最小的层的注意力，并逐层调整FFN宽度。MIP求解器在你的特定内存或参数预算下找到全局最优。对于在受限硬件（单个H100、DGX Spark、边缘设备）上运行模型的团队来说，这相当于“装不下”与“装下且精度可接受”的区别。

长期影响
异构剪枝产生了统一剪枝无法实现的架构——深度-宽度权衡在层间非均匀的模型。这与手动架构搜索背后的洞察相同，但实现了自动化且受约束驱动。随着支持模型列表的增长（Qwen3-8B和Nemotron-Nano-12B-v2已在其中），MIP方法成为标准的部署前步骤：指定内存预算，让求解器找到架构，然后量化。可组合管线（剪枝→量化）是长期方向。

Nemotron-3-Nano-30B-A3B教程：实际堆叠
examples/megatron_bridge/tutorials/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16/目录是此版本中理解ModelOpt重要性的最关键产物。这是一个完整的端到端教程：剪枝→蒸馏→量化→部署，每个阶段都有基准测试数据。

模型
NVIDIA-Nemotron-3-Nano-30B-A3B-BF16是一个MoE + Mamba-Transformer混合模型。官方模型有31.6B总参数/3.6B活跃参数。教程将其剪枝到22B总参数/3.0B活跃参数，蒸馏以恢复精度，然后量化为FP8。

堆叠结果
来自教程README的vLLM吞吐量表（单H100，ISL=32768，OSL=1024）：

叠加效应清晰可见：
- 仅剪枝（BF16 → 剪枝BF16）：2.0×吞吐量，内存减少30%（58.9 → 41.5 GiB）
- 仅FP8（BF16 → FP8）：2.2×吞吐量，内存减少47%（58.9 → 31.4 GiB）
- 叠加两者（BF16 → 剪枝+FP8）：2.6×吞吐量，2.6×内存减少（58.9 → 22.8 GiB）

吞吐量增益可以组合（2.0× × 1.1× ≈ 2.2×，来自剪枝模型上的FP8步骤），内存减少以乘法方式组合。

精度保留
教程在MMLU Pro、GPQA Diamond、GPQA Diamond (w. tools)、LiveCodeBench v6、AIME 2025、AIME 2025 (w. tools)、IFBench和SciCode (Subtask)上评估。平均分数：

剪枝+蒸馏+FP8模型保留了70.2的平均精度，而原始模型为72.1——下降了1.9个百分点——同时实现了2.6倍吞吐量和2.6倍内存减少。蒸馏轨迹显示稳定恢复：在2.5B token时，剪枝模型平均精度为63.3；在40B token时达到67.5；在100B token时（80B @ 8K + 20B @ 32K）达到70.5。教程指出该模型“在100B token时仍在学习”。

蒸馏混合
数据混合为30%预训练（Code 5, General 20, MATH 5）+ 70%后训练v1/v3（Math 27, Coding 20, Science 13, IF 5, Tool calling 5），在100B token上训练，采用80B @ 8K + 20B @ 32K的计划。这是两阶段长上下文蒸馏。

为什么这立即重要
如果你在单个H100上部署30B类MoE模型，这个教程就是一份配方。剪枝+FP8模型仅占用22.8 GiB——在80 GiB的H100上为KV缓存留下了57+ GiB。以1,576 tokens/s的吞吐量配合3K输入上下文，对于最初只有598 tokens/s的模型来说，这是生产级别的吞吐量。精度代价（平均1.9分）在教程本身指出的AIME（30个问题）和SciCode等小基准测试的噪声范围内。

长期影响
本教程验证了ModelOpt 0.45.0的核心论点：优化技术可以堆叠。剪枝和量化不是替代性的压缩策略——它们可以组合。长期方向是一条管线，其中每个阶段（剪枝→蒸馏→量化→导出）都是一个可组合的、由配方驱动的步骤，最终的部署产物是所有阶段的乘积。教程中关于“模型在100B token时仍在学习”的说明表明，通过更多蒸馏或更高质量的数据混合，精度差距可以进一步缩小——这意味着70.2这个数字是一个下限，而不是上限。

Megatron-Bridge：在一个框架内量化、导出和蒸馏
examples/megatron_bridge/目录是Megatron-Core集成层。三个脚本构成了工作流：

0.45.0的关键新增
- Qwen3-VL导出/导入映射，用于Qwen3VLForConditionalGeneration视觉-语言模型，处理model.language_model.权重前缀。
- 共享校准前向循环——modelopt.torch.utils.plugins.megatron_calibration.get_megatron_calibration_forward_loop取代了Megatron-LM和Megatron-Bridge中定制的校准循环，采用一个规范实现。
- MSE NVFP4StaticQuantizer检查点恢复和导出支持。
- 混合精度FP8 + NVFP4导出——逐层quant_algo记录在hf_quant_config.json中，PP感知的kv_cache_dtype收集。
- Minitron剪枝约束——active_params（用于MoE）和memory_mb，在现有params约束之上。可以同时提供多个约束。
- 添加了Gemma3 Minitron剪枝支持。

Megatron-Bridge量化命令
`bash
torchrun --nproc_per_node 2 examples/megatron_bridge/quantize.py \
--hf_model_name_or_path Qwen/Qwen3-8B \
--quant_cfg nvfp4 \
--tp_size 2
`

Mamba + MoE保守配置
对于Nemotron-3-Nano（Mamba-Transformer混合模型带MoE），发布说明中提到了保守配置，将注意力和Mamba Conv1d保持在BF16。这些配置在配方中以MAMBA_MOE前缀命名。对于量化Mamba Conv1d或注意力路径会降低质量的混合架构，推荐使用这些配置。

具有活跃MoE成本核算的AutoQuantize
AutoQuantize是ModelOpt的逐层混合精度搜索。给定比特预算，它会在预算内为每一层选择最便宜的量化格式。0.45.0版本增加了活跃MoE成本核算：
`python
constraints = {
"effective_bits": ...,
"cost_model": "active_moe",
"cost": {"active_moe_expert_ratio": ...}
}
`
这会按每个token的活跃专家加权路由专家成本，同时将共享专家完全计入。在CLI中：
`bash
python examples/llm_ptq/hf_ptq.py \
--auto_quantize_cost_model active_moe \
--auto_quantize_active_moe_expert_ratio 0.05
`

为什么这重要
对于像Qwen3-30B-A3B（256个专家，8个活跃）这样的MoE模型，活跃专家比例为8/256 ≈ 3.1%。如果没有活跃MoE成本核算，AutoQuantize会将比特过多分配给很少活跃的专家层，浪费比特预算。有了活跃MoE核算，搜索会按每层专家实际触发的频率成比例地分配比特——给共享专家和热专家更多比特，给冷专家更少比特。

Alpamayo：量化视觉-语言-动作模型
examples/alpamayo/示例量化了Alpamayo 1（原名Alpamayo-R1），一个约10B参数的视觉-语言-动作模型，用于自动驾驶。它输入多摄像头视频和自车运动历史，输出因果推理链及未来驾驶轨迹。

该示例支持三种量化模式：

AutoQuantize路径使用基于梯度的敏感性分数：它反向传播流匹配目标（动作专家预测的速度场v_pred与目标v_target = x_1 - x_0之间的MSE，来自教师强制前向传播），并估计每个候选格式对该损失的扰动程度。损失敏感的层保持FP8；其余层转为NVFP4。

视觉塔始终保持高精度，维度不是16倍数的小型动作投影头保持未量化（它们会破坏real-quant GEMM后端）。

为什么这重要
Alpamayo证明了ModelOpt的量化管线可以推广到文本LLM之外的多模态动作模型。校准循环是联合的——VLM +扩散——而AutoQuantize的敏感性指标是任务特定的流匹配损失，而不是通用的困惑度代理。这是量化任何具有非标准目标的模型的模板：定义损失，让AutoQuantize搜索，导出混合精度检查点。

可组合的配方系统：$import和预设发现
0.45.0中的两个架构变更使配方系统具有可扩展性：

1. 可组合的$import系统
配方YAML配置现在可以通过{$import: name}标记引用可重用的配置片段。所有内置PTQ配方都已转换为使用导入，共享片段位于modelopt_recipes/configs/下（数值格式、quant_cfg构建块、预设）。

2. CLI预设发现
三个PTQ示例脚本（hf_ptq.py, multinode_ptq.py, megatron_bridge/quantize.py）现在通过发现modelopt_recipes/configs/ptq/presets/{model,kv}/下的YAML预设来派生它们的--qformat / --kv_cache_qformat词汇，而不是携带硬编码的QUANT_CFG_CHOICES表。发现辅助函数、别名表和映射位于modelopt.recipe.presets中。

添加一个新的预设YAML即可使其在所有三个脚本的CLI上可用，无需代码更改。

之前支持的短名称（int8_sq, nvfp4_awq, fp8_pb_wo, nvfp4_mse, w4a8_awq, nvfp4_local_hessian, fp8_pc_pt, int8_wo）通过弃用别名表继续工作。

新的KV缓存转换预设
configs/ptq/presets/kv/fp8_cast.yaml和configs/ptq/presets/kv/nvfp4_cast.yaml将fp8_cast / nvfp4_cast提升为一等KV预设。use_constant_amax: true设置现在位于YAML中（权威来源），并且之前hf_ptq.py中的运行时后编辑已被移除。针对转换KV格式的自定义外部配方必须在[kv]_bmm_quantizer配置上自行设置use_constant_amax: true。

还为部分NVFP4和仅权重配方添加了FP8 KV缓存转换变体：nvfp4_mlp_only-kv_fp8_cast, nvfp4_experts_only-kv_fp8_cast, nvfp4_omlp_only-kv_fp8_cast和nvfp4_weight_only-kv_fp8_cast。

Nemotron-3-Super-120B-A12B配方
针对Nemotron-3-Super-120B-A12B的两个PTQ配方：
- super-nvfp4.yaml (MSE混合)：NVFP4 W4A4路由专家 + FP8 per-tensor共享专家 / Mamba in/out_proj + FP8 KV缓存
- super-nvfp4-max-calib.yaml (max-calib混合)

长期影响
预设发现系统意味着量化格式空间现在由数据驱动，而不是代码驱动。一个新的数值格式（比如未来的MXFP6或自定义块稀疏格式）以YAML文件形式发布，而不是Python PR。这降低了尝试新格式的门槛，并使CLI自文档化——--qformat help通过扫描预设目录列出每个可用格式。

量化嵌入
现在nn.Embedding注册在QuantModuleRegistry中，并暴露：
- weight_quantizer（嵌入表）
- output_quantizer（查找激活）
- input_quantizer占位符（永久禁用——嵌入输入是整数索引，无法进行fake-quantization）
- export_hf_checkpoint将量化嵌入权重与Linear层打包在一起。嵌入量化器是选择加入的（parent_class: nn.Embedding默认禁用）。

这对于嵌入表占总参数显著比例的模型（常见于大词汇量模型或多语言模型）相关。将嵌入表与Linear层一起量化进一步减小了总的量化检查点大小。

破坏性变更与迁移
内核重组
modelopt.torch.kernels下的自定义CUDA/Triton内核重组为common/attention, quantization/{conv,gemm}和sparsity/attention。高级API（mtq.quantize, mtsa.sparsify）保持不变，但任何直接从内核子包导入的代码必须更新——没有向后兼容性垫片。迁移示例：
`python
# 旧 → 新
from modelopt.torch.kernels import attention
# → from modelopt.torch.kernels.common.attention import attention

from modelopt.torch.quantization.triton import ...
# → from modelopt.torch.kernels.quantization.gemm import ...

from modelopt.torch.sparsity.attention_sparsity.kernels import ...
# → from modelopt.torch.kernels.sparsity.attention import ...
`

模型特定配方已移出--qformat
之前硬编码在examples/llm_ptq/中的gemma、mpt、phi4mm和Nemotron VL的模型特定PTQ quant_cfg调整，现在是modelopt_recipes/huggingface/<model_type>/ptq/下的选择加入模型特定配方。传递--recipe huggingface/<model_type>/ptq/<recipe>以应用。仅使用--qformat路径会产生通用数值。

其他破坏性变更
- KDTrainer / QADTrainer评估现在报告KD为主要eval_loss，CE为eval_ce_loss；之前的eval_kd_loss指标已被移除。
- GradNAS剪枝算法已弃用（改用Minitron或Puzzletron）。
- examples/chained_optimizations目录已弃用。
- Step3.5-Flash配方已移至modelopt_recipes/huggingface/step3p5/Step3.5-Flash/ptq/nvfp4-mlp-only.yaml。

值得注意的Bug修复
- MoE路由器导出修复（NVBug 5718750）：未量化的MoE路由器/门现在始终列在exclude_modules中。在transformers>=5.0上，MoE路由器不再是nn.Linear（例如TopKRouter），并且从未接收量化器，因此BF16路由器权重被写入检查点但未包含在exclude_modules中。vLLM/SGLang随后将其视为量化并加载失败（例如Qwen3-30B-A3B NVFP4：AssertionError: Tried to load weights of size [128, 2048] to a parameter of size [128, 1024]）。
- GPT-OSS MXFP4→NVFP4路径：get_model现在通过Mxfp4Config(dequantize=True)在顺序设备映射上加载本地MXFP4检查点（反量化为BF16），修复了CUDA非法内存访问和导出NotImplementedError。
- FP8原生权重修复：校准具有原生FP8权重（DeepSeek-V3）的模型时出现NotImplementedError: "max_all_cuda" not implemented for 'Float8_e4m3fn'——reduce_amax现在在归约前将FP8输入上转换为默认float数据类型。
- Megatron-Core HF导入器：为GPT系列模型（Qwen3等）从HF加载融合的TELayerNormColumnParallelLinear.layer_norm_weight——没有此修复，剪枝后的MMLU保持在随机水平。

模型支持矩阵
来自examples/llm_ptq/README.md支持矩阵（第96-125行），确认的量化格式支持：

对于Mamba+MoE混合模型（Nemotron-3-Nano），推荐使用保守配置（MAMBA_MOE_FP8_CONSERVATIVE_CFG, MAMBA_MOE_NVFP4_CONSERVATIVE_CFG）——它们将注意力和Mamba Conv1d保持在BF16。

立即收益：本周你能做什么
1. 将Qwen3或Llama模型量化为W4A16 NVFP4，无需校准前向传播：
`bash
python examples/llm_ptq/hf_ptq.py \
--model_dir Qwen/Qwen3-8B \
--qformat w4a16_nvfp4 \
--output_dir /tmp/Qwen3-8B-W4A16-NVFP4
`
这只需数分钟，而非数小时，因为没有校准前向传播。

2. 将GPT-OSS或DeepSeek V4模型从MXFP4比特精确地转换为NVFP4：
`bash
python examples/llm_ptq/hf_ptq.py \
--model_dir openai/gpt-oss-20b \
--cast_mxfp4_to_nvfp4 \
--output_dir /tmp/gpt-oss-20b-nvfp4
`

3. 使用Puzzletron和MIP求解器，将Llama-3.1-8B剪枝以适应内存预算，然后使用--mip-only重新运行MIP搜索以探索不同内存目标，无需重新评分。

4. 端到端运行Nemotron-3-Nano-30B教程，复现2.6倍吞吐量/2.6倍内存结果。教程指定容器nvcr.io/nvidia/nemo:26.04和ModelOpt 0.45.0。

5. 使用流匹配目标作为敏感性指标，通过AutoQuantize量化Alpamayo检查点——这是量化任何具有非标准损失函数的模型的模板。

长期影响：未来的方向
1. 管线正变得可组合
0.45.0版本将ModelOpt从独立工具的集合推向可组合的管线，其中每个阶段都是配方驱动的步骤。$import系统、预设发现和Megatron-Bridge栈（量化→导出→蒸馏）都指向这个方向。Nemotron-3-Nano教程是证明点：剪枝→蒸馏→量化→部署，每个阶段的输出馈入下一个，最终产物是所有阶段的乘积。

2. 量化格式变得数据驱动
预设发现系统意味着新的数值格式以YAML文件形式发布，而不是代码变更。CLI从预设目录自文档化。这降低了尝试新块大小、尺度格式和混合精度策略的门槛。随着NVIDIA和社区添加预设，格式空间预计将快速增长。

3. 免校准量化成为一个类别
W4A16 NVFP4和MXFP4→NVFP4转换都绕过了校准前向传播。这不是一个小优化——它从根本上改变了部署工作流。免校准量化是确定性的、可重复的且数据无关的。它消除了PTQ管线中最大的变异来源。

4. 异构剪枝是压缩的未来
统一剪枝（每层相同比例）是一种粗鲁的工具。Puzzletron基于MIP的异构剪枝——每层不同的FFN大小、选择性注意力移除——产生了统一方法无法实现的架构。随着支持模型列表的增长，这成为将大模型适配到受限硬件上的标准方法。

5. 精度下限在上升
Nemotron-3-Nano教程中的剪枝+蒸馏+FP8模型保留了70.2的平均精度，而原始模型为72.1——并且教程指出该模型“在100B token时仍在学习”。这意味着70.2这个数字是一个下限，将随着更多蒸馏、更好的数据混合或更长的训练而上升。“优化后”与“原始”之间的差距正在缩小，而优化收益（2.6倍吞吐量，2.6倍内存）正在增长。

6. 导出是统一的
Megatron-Bridge的export.py产生一个单一的HuggingFace统一检查点，TensorRT-LLM、vLLM和SGLang都可以消费。vLLM从hf_quant_config.json自动检测ModelOpt量化。这意味着部署目标与优化管线解耦——优化一次，随处部署。

复现本文分析
本文中每个事实的来源是标签为0.45.0的NVIDIA/Model-Optimizer仓库：
`bash
git clone --depth 1 --branch 0.45.0 \
https://github.com/NVIDIA/Model-Optimizer.git Model-Optimizer-0.45
cd Model-Optimizer-0.45
`

引用的关键文件：

发布说明可在 github.com/NVIDIA/Model-Optimizer/releases/tag/0.45.0 获取。
ModelOpt 0.45.0采用Apache 2.0许可。Nemotron-3-Nano-30B-A3B-BF16模型可在HuggingFace上获取。Puzzle论文见arXiv:2411.19146。