团队可以自定义模型,在延迟、速度、内存和计算方面达到目标。借助开放式 NVIDIA Nemotron 系列模型,开发者可以找到适合其需求的模型。
例如,新的 Nemotron 3.5 Lightning NVFP4 Checkpoint 可在保持准确性的同时将吞吐量提升高达 4 倍。通过将多个权重量化为 4 位,将其从 66 GB 全精度检查点压缩到 22 GB。
为了将模型压缩到 NVFP4,训练后量化 (PTQ) 是一种可满足大多数需求的常用方法。但是,如果您想在更小的内存中实现高吞吐量,则需要更积极的量化。在这种情况下,量化感知型蒸馏 (QAD) 是最佳选择。使用 QAD 训练 Nemotron 3.5 Lightning 以适应量化噪声,产生了一个 NVFP4 检查点,该检查点占用更少的内存,可提供更高的吞吐量,同时保持准确性。
本文将介绍 QAD 如何使用 NVIDIA Model Optimizer 改进 Nemotron 3.5 Lightning 模型。我们将逐步完成整个训练流程,从最初的 PTQ 阶段到最后的蒸馏和评估。我们展示,QAD 通过积极的量化恢复了准确性下降。即使采用更保守的配置,QAD 在代理式基准测试中的表现也始终优于 PTQ,在确保高质量的同时减少内存占用。
什么是量化感知型蒸馏?
QAD 使用原始全精度模型 (教师) 来训练量化模型 (学生) 。首先,在全精度模型上运行 PTQ 来创建量化模型。然后,将冻结的 BF16 模型蒸馏输入量化模型,使用 KL 离散损失比较教师和学生的逻辑。
图 1 显示了用于构建 Nemotron 3.5 Lightning NVFP4 检查点的两阶段 QAD 过程。全精度 BF16 模型既是固定的教师,也是第 1 阶段 ( PTQ 通道,将权重量化为 W4A16 以生成量化学生) 的起点。在第 2 阶段,学生使用 QAD 进行训练,通过模拟量化运行其前向传递,而蒸馏损失使其与教师保持一致,从而生成最终的 NVFP4 检查点,准确性恢复接近基准。

量化感知型蒸馏过程
请按照以下步骤执行 QAD 流程。
第 1 步:训练后量化
QAD 的第一阶段是运行 PTQ 以生成量化的检查点 (学生) 。由于我们计划运行 QAD,因此可以执行更积极的量化。对于 Nemotron 3.5 Lightning,我们发现将 Mamba 线性层量化为更激进的 W4A16 (而不是 FP8) 可以实现更高的吞吐量,同时不会大幅降低准确性。
通常情况下,仅执行 PTQ 时,目标准确度中值恢复率超过 99%。与 QAD 结合使用时,由于 QAD 将恢复更高的准确性,因此可以将目标准确率中值恢复为95-99%。这证实了量化已经得到了足够大的推进,可以充分利用规模和延迟收益,同时为 QAD 留出了在下一阶段填补空白的空间。
我们预计 W4A16 的评估基准测试会出现小幅但有意义的下降,但计划使用 QAD 来弥补这一下降。这证实,量化已得到足够大的推进,足以保留规模和延迟收益,同时为 QAD 在下一阶段填补空白留出了空间。
第 2 步:量化感知型蒸馏
在 QAD 期间,学生模型的每个前向传递都会经过模拟量化,因此模型可以解释其在推理时遇到的量化噪声。同时,它经过训练,可通过蒸馏损失来匹配教师。通过教师信号,学生正在学习重现其来源模型的完整行为,而不仅仅是预测下一个令牌。结合使用这两种信号进行训练,使 QAD 能够通过积极的量化来保持高质量。
如需详细了解 QAD 流程,请参阅 NVIDIA Model Optimizer 上的 QAD 端到端示例。
如何使用 Model Optimizer 使用 QAD 开发 Nemotron 3.5 Lightning NVFP4
以下各节将介绍我们使用 QAD 和 NVIDIA Model Optimizer 开发 Nemotron 3.5 Lightning NVFP4 检查点的流程。
第 1 步:获取 PTQ 检查点
基础模型 NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16 就是导师。要创建学生,请在相同的基础上运行 PTQ,将其量化为 W4A16-NVFP4。由于这两种模型都来自同一模型,因此学生将拥有匹配良好的教师来学习。
我们为该学生试用了几种 PTQ 方法,这些方法在权重校准方式以及 Mamba 投影和 KV 缓存的量化方式方面有所不同。这种选择需要进行训练:最大校准的 recipe 输入动态比例的 QAD,而基于 MSE 的 recipe 输入冻结比例的 QAD (请参阅本节的第 2 步) 。
一些设置会在每个菜谱中共享。它们都将 lm_head 量化为 W4A16,我们称之为“忠实 lm_head”,而注意力投影层则保留在“BF16”中。校准使用 1000 个样本,并在单个 NVIDIA DGX B300 上运行。最后一种方法,即 four_over_six+ NVFP4 KV,是最具挑战性的方法。它只将 K 和 V 推送到 NVFP4 (W4A4) ,并在 BF16 中保留 \(QK^{\mathsf{T}}\) 和 \(\mathrm{attn} \cdot V\) 批量矩阵乘法,而 Q 未量化。
在 PTQ 阶段进行更积极的量化比在 PTQ 阶段进行最后一步更为有利,因为 QAD 之后会恢复准确性。这使您能够选择仅使用 PTQ 的 recipe 可以避免的设置,例如将 Mamba 线性层改为 W4A16 而不是更安全的 FP8。
事实上,我们希望 PTQ 检查点在评估基准测试中显示一个微小但有意义的下降,使中间精度恢复在 95% 到 99% 之间。这一下降证实了我们已经足够努力地扩大规模和提高延迟,同时为 QAD 留出了在下一阶段缩小差距的空间。
我们评估了许多 PTQ 方法,重点关注以下五个方法。对于每个配方,我们都进行了 PTQ 校准,序列长度从 8k 到 128k 不等。先前的实验表明,更长的序列长度会产生更好的 PTQ 结果。我们发现,长度为 32K 的序列在 4_ over_six 的情况下可提供最佳的 PTQ 结果,并且在 4_ over_six 的 32K 校准检查点上执行了所有 QAD 实验。在评估不同的 PTQ 方法后,我们发现采用 W4A16 Mamba 线性算法的 four_over_six 在准确性降级之间做出了最佳权衡,从而提高了推理性能。有关完整的准确性详细信息,请参阅“QAD 检查点评估”部分。
表 1 显示了用于构建 Nemotron 3.5 Lightning 学生检查点的五个 PTQ 方法。每个 recipe 都由 MoE 层、共享层和 lm_head 层的权重格式、校正方法、Mamba 输入/ 输出投影格式以及 KV 缓存格式定义。这 5 个库均使用 W4A16 NVFP4 权重,范围从经过最大校准的动态库到基于 MSE 的静态库,其中最激进的变体将 KV 缓存推送到 NVFP4。浅绿色行使用动态缩放,浅灰色行在训练步骤中使用静态缩放。
| 食谱 | MoE/shared/lm_head 权重 | 校准 | Mamba in/ out_proj | KV 缓存 |
|---|---|---|---|---|
| 最大值 | W4A16 动态 NVFP4 | 最大值 | W4A16 NVFP4 | FP8 |
| mamba_fp8_max | W4A16 动态 NVFP4 | 最大值 | FP8 (宽 × 宽 × 高) | FP8 |
| MSE | W4A16 静态 NVFP4 | MSE (均方误差) | W4A16 NVFP4 | FP8 |
| 4 次_ 6 次 | W4A16 静态 NVFP4 | 4/ 6 (在 M = 6 与 M = 4 之间的 MSE,arXiv:2512.02010) | W4A16 NVFP4 | FP8 |
| four_over_six = NVFP4 KV | W4A16 静态 NVFP4 | 4/6 | W4A16 NVFP4 | NVFP4 |
您可以使用 NVIDIA Model Optimizer 在自己的模型上重现此方法。 Hugging Face PTQ 示例 使用前面介绍的不同 PTQ 方法,将 Hugging Face 模型量化为 NVFP4。
import modelopt.torch.quantization as mtq
# define forward loop with dataset
def forward_loop(model):
for batch in calib_dataloader:
model(batch)
# Quantize base model to NVFP4 to create the PTQ student checkpoint
# Example uses W4A16_NVFP4_CFG for quantization
model = mtq.quantize(model, mtq.W4A16_NVFP4_CFG, forward_loop=forward_loop)
同一个 Hugging Face PTQ 示例 还涵盖了校准数据、支持的格式和导出选项。设置 PTQ 检查点后,您可以继续学习之前介绍的 QAD 训练配置和扩展策略。
第 2 步:QAD 训练
本节将介绍 QAD 训练,包括配置和量化规模处理。
设置训练配置
有了学生检查点,下一步就是决定如何训练它。在我们的消融过程中,有两个选择最为重要:用于训练的序列长度和蒸馏的数据。
序列长度:事实证明,序列长度对于某些基准测试至关重要,尤其是在上下文较长的基准测试中,训练时间过短会让准确性受到影响。后训练监督式微调 (SFT) 使用了大约 52.2 万个 token,我们的消融结果表明,要保留长上下文性能,需要 52.2 万个序列长度。为了平衡计算资源与序列长度,我们执行了序列长度为 256K 的初始消融,然后在最后一次 QAD 运行中扩展到 522K。
数据集:对于数据组合,我们在完成最终配方之前对一些内部混合进行了消融处理。对于希望重现这项工作的人,我们建议从 NVIDIA 发布的开放数据集开始,即 Nemotron-Post-Training v1 和 Nemotron-Post-Training v2,它们的分布与我们使用的类似。
蒸馏 recipe:学生从 PTQ 检查点开始:首先使用 Nemotron-3.5-Lightning-30B-A3B/ Lightning 量化 recipe 将 BF16 模型量化为 NVFP4。然后是蒸馏,而不是从头开始训练量化权重。在每个步骤中,相同的批量会同时通过 BF16 教师和 NVFP4 学生运行,学生经过训练,通过 logits 上的 KL 离散蒸馏损失来匹配教师,而教师作为参考信号保持冻结状态。蒸馏,恒定学习率为 5e-6,在 1.0 下无热身、丢弃禁用和梯度裁剪,两个节点乘以 8 个 GPU ( TP = 2,EP = 4) 。这与 NVIDIA Model Optimizer 随附的 QAD 工作流相同。
QAD 期间的量化规模处理
对于检查点和训练配置集,最后一个选择是如何在 QAD 期间处理量化规模。我们尝试了两种策略,具体应用取决于如何校准第 1 步中的 PTQ 检查点。
图 2 显示了动态和冻结刻度,其中两条车道共享相同的量化正向传递,包括激活、模拟量化、GEMM、梯度返回到 FP 权重的损失。顶部通道会重新计算当前张量中每个步骤的量化比例;底部通道会锁定经 PTQ 校准的比例,并仅更新权重。W (t) 是训练步骤 t 中的 BF16 权重,s (t) 是同一步骤中从这些权重重新计算的比例,s* 是捕获一次并在整个运行中保持的比例。

动态扩展 QAD:从最大校准 PTQ 检查点开始。这是表 1 中的 max 或 mamba_fp8_max 量化配置。两者都带有动态权重和激活,因此在训练期间会动态重新计算,并且权重和会随着模型的学习而调整。
冻结规模的 QAD:从基于 MSE 的 PTQ 检查点 (例如表 1 中的 MSE、four_over_six 或 four_over_six + NVFP4 KV) 开始。MSE 和 4 比 6 通过搜索达到其规模,以更大限度地减少量化误差,而在每个步骤中重复的成本太高。采用在 PTQ 期间找到的刻度,并在训练期间将其冻结,而不是重新计算刻度。只有权重会更新,而刻度则保持在其校准值不变。
先选择规模策略,然后再选择训练时间。它直接从第 1 步中选择的 PTQ recipe 开始。经过最大校准的检查点可实现动态扩展 QAD,而基于 MSE 的检查点可实现 QAD 冻结扩展。建议使用混合了动态片和冷冻片的多种 PTQ 方法,并对其进行评估,以评估哪种方法将受益于 QAD。
QAD 检查点评估
以下关于中间 Lightning 检查点的实验展示了 QAD 如何实现比单独使用 PTQ 更积极的量化。PTQ 和 QAD 检查点均使用相同的 W4A16 量化格式配方和相同的 21.19 GB 占用空间,而 BF16 基准使用 65.85 GB 占用空间,因此二者之间的任何差异都来自方法,而非额外的内存。QAD 在中间检查点 A 和 B 上运行,以 256K 序列长度进行快速实验,而最终的检查点 QAD 使用 524K 序列长度。
检查点 A
检查点 A (表 2) 是 SFT 中间检查点。检查点 B (表 3) 是中间 RL 检查点。我们评估了这些检查点后发现,QAD 仅在 PTQ 上就可以恢复激进量化带来的一些准确性损失。
| 基准测试 | BF1665.85 GB | 积极的 PTQ21.19 GB | QAD21.19 GB | QAD 增益 与 PTQ |
|---|---|---|---|---|
| MMLU-Pro | 81.27 | 80.10 | 81.04 | +0.94 |
| GPQA-D | 77.08 | 75.76 | 77.34 | +1.58 |
| AIME 2025 | 86.72 | 83.02 | 86.15 | +3.13 |
| AIME 2026 | 87.81 | 86.46 | 87.24 | +0.78 |
| SciCode Subtask | 35.21 | 32.36 | 35.72 | +3.37 |
| SciCode Problem | 13.28 | 10.63 | 12.19 | +1.57 |
| AA-LCR | 54.00 | 52.38 | 53.37 | +0.99 |
| AA-Omni Acc。 | 14.05 | 13.62 | 14.57 | +0.95 |
| IFBench | 74.00 | 73.00 | 72.96 | -0.04 |
| HLE | 12.14 | 9.78 | 12.33 | +2.55 |
| LM Arena Proxy | 10.05 | 8.81 | 10.05 | +1.23 |
| 分数恢复中值 | 100.00% | 96.33% | 99.72% | +3.39 |
我们首先在早期发布的预发布检查点 A 上试用了 QAD,该检查点的量化效果比最终发布的结果更为积极:W4A16 完全推动了 Mamba 线性投影。仅后训练量化的准确度中值恢复率为 96.33%,其中最大的回归出现在推理和编码基准测试中,其中 AIME 2025 下降了 3.70 个点,SciCode 子任务 2.85 和 HLE 2.36 下降了。来自同一检查点的 200 次 QAD 迭代使恢复率达到 99.72%,将 AIME 2025 恢复到 BF16 的 0.57 点以内,并将 SciCode 子任务和 HLE 略高于该值。
检查点 B
表 3 显示检查点 B,在更新的评估套件上进行评分,结果相同。PTQ 的中值分数恢复率为 95.84%,QAD 的中值分数恢复率为 98.53%,与 21.19 GB 相同。AA v4.1 指数是最明确的单一指标,从 20.03 上升到 23.48,上升了 3.45 点,而 BF16 基准为 24.81。QAD 改进了 9 项基准测试中的 5 项,因此结果是中值而不是任何单个分数。
| 基准测试 | BF1665.85 GB | Aggressive PTQ21.19 GB | QAD21.19 GB | QAD 增益 与 PTQ |
|---|---|---|---|---|
| AA v4.1 Index | 24.81 | 20.03 | 23.48 | +3.45 |
| GPQA-D | 77.37 | 75.19 | 77.46 | +2.27 |
| HLE | 10.84 | 10.89 | 11.35 | +0.46 |
| AA-LCR | 51.00 | 47.38 | 50.25 | +2.88 |
| AA-Omni Acc。 | 17.58 | 16.78 | 16.60 | -0.18 |
| AA-Omni Non-Halluci。 | 62.24 | 69.02 | 64.67 | -4.35 |
| SciCode Subtask | 41.12 | 39.57 | 38.98 | -0.59 |
| Tau3 Banking | 8.04 | 5.77 | 8.25 | +2.48 |
| GDPval Norm. Elo | 18.60 | 16.46 | 12.90 | -3.56 |
| 分数恢复中值 | 100.00% | 95.84% | 98.53% | +2.69 |
我们在稍后的检查点 B 上重复了这一实验,并观察到相同的模式:中值恢复率为 95.84% 到 98.53%。我们还测量了 AA 指数,该指数从 20.03 上升到 23.48,上涨了 3.4 个点,而 BF16 基准是 24.81。启动 NVFP4 的方法有意地更加保守,因此 PTQ 已经接近基准,而 QAD 的恢复速度要小得多,剩下的收益仅限于代理式基准的子集。总体而言,QAD 弥补了激进量化带来的准确性损失。PTQ 将权重修复到低精度网格,并接受产生的任何错误,而 QAD 允许模型继续针对该错误进行训练并做出调整,因此大部分性能下降都得到了恢复,而不是被吸收。
这种差异决定了一个菜谱可以推进的程度。在 QAD 下,PTQ 使若干点低于基准的配置变得可行,这意味着内存和吞吐量预算现在触手可及,否则会迫使更保守的精度。
最终 NVFP4 检查点
表 4 显示了最终 NVFP4 Checkpoint BF16 与 PTQ 与 QAD 的准确度评估。为了优化准确性,对最后一个检查点进行了保守量化,因此 PTQ 已接近 BF16,QAD 需要恢复的损失微乎其微。PTQ 和 QAD 的平均分分别为 99.24% 和 98.97%。在代理式和编码基准测试中,QAD 在 Terminal-Bench v2.1、SWE-Bench Multilingual 1.07、HLE 0.65 和 BrowseComp、SWE-Bench Verified 和 PinchBench 上比 PTQ 提高了 3.79 分。
| 基准测试 | BF16 | PTQ | QAD |
|---|---|---|---|
| 聚合 | |||
| 分数恢复 (中值) | 100.00 | 99.24 | 98.97 |
| AA v4.1 Index | 24.51 | 24.05 | 23.94 |
| 代理和编码 | |||
| 终端工作台 v2.1 | 24.44 | 22.05 | 25.84 |
| SWE-Bench Multilingual | 37.13 | 37.00 | 38.07 |
| 浏览压缩 | 39.50 | 39.50 | 40.00 |
| SWE-Bench Verified | 52.20 | 52.20 | 52.60 |
| PinchBench | 83.86 | 84.78 | 85.15 |
| τ²-bench Telecom | 59.65 | 60.96 | 59.87 |
| τ³-bench Banking | 9.90 | 9.48 | 7.84 |
| 知识、推理和后续说明 | |||
| LM Arena 代理 | 12.06 | 11.10 | 11.91 |
| HLE (不支持工具) | 10.80 | 10.70 | 11.35 |
| AA-Omniscience, accuracy | 17.47 | 16.35 | 16.80 |
| AA-Omniscience, non-halluc. | 68.88 | 69.20 | 69.03 |
| SciCode (子任务) | 32.51 | 31.21 | 30.73 |
| GPQA Diamond (不含工具) | 76.45 | 75.38 | 74.43 |
| GDPval (norm. Elo) | 17.19 | 19.09 | 17.02 |
| IFBench (loose) | 72.00 | 74.04 | 71.21 |
| 长上下文 | |||
| AA-LCR | 52.38 | 50.00 | 48.50 |
对于最后一个检查点,我们优化了准确性,这意味着使用 Nemotron-3.5-Lightning-30B-A3B/lightning_w4a16_nvfp4_4o6 进行更保守的量化。因此,PTQ 接近 BF16 基准,QAD 需要恢复的损失更少,中值分数恢复率分别为 99.24% 和 98.97%。
与激进的 PTQ 相比,QAD 带来的收益更小,但它们在重要的地方有所体现:QAD 在多个关键代理式基准测试中恢复了准确性,包括 Terminal-Bench v2.1、SWE-Bench Multilingual、BrowseComp、PinchBench、HLE 和 AA-Omniscience 准确性。
如何使用 Model Optimizer 运行 QAD recipe
完整的 QAD recipe 在 NVIDIA Model Optimizer 中作为单个启动程序 megatron_lm_qad.yaml 提供,端到端运行整个工作流。该文件适用于 Nemotron 3 Nano 和 Nemotron 3.5 Lightning。将其指向您想要的模型,然后启动。最终的 NVFP4 检查点 发布在 Hugging Face 上。
# from tools/launcher
source .env-slurm
uv run launch.py --yaml examples/nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16/megatron_lm_qad.yaml --yes
第 1 步:创建 PTQ 学员
第一步是使用 PTQ 将 BF16 教师量化为 NVFP4 学员。Nemotron 3.5 Lightning 不使用 RoPE,因此 --max-position-embeddings 对此处的位置编码没有影响。此处,我们将其保持为与其最大上下文长度 (1M) 相同,以确保一致性。对于确实使用 RoPE 的模型,请将其保留为 config.json 值。
task_1: # quantize the BF16 teacher into the NVFP4 student
script: common/megatron_lm/quantize/quantize.sh
args:
- --seq-length 32768 --max-position-embeddings 1048576
- --calib-size 32
environment:
- QUANT_CFG: MAMBA_MOE_NVFP4_CONSERVATIVE_CFG
- TP: "1"
- EP: "4"
第 2 步:来自冻结教师的学员蒸馏
通过添加 --modelopt-enabled 的 --export-kd-teacher-load 设置教师,即可启用 QAD。在引擎盖下,启动器调用 Megatron-LM 训练切入点 finetune.sh,该切入点会针对冻结的教师运行实际的蒸馏循环。
要重现我们的设置,请将启动器指向您的 PTQ 学员检查点和教师,调整序列长度和数据混合以匹配您的目标,然后启动。在单个 Nemotron-Post-Training v2 聊天分片上,蒸馏以恒定的 5e-6 学习率运行,其中 dropout 和梯度裁剪为 1.0:
task_2: # distill the NVFP4 student against the BF16 teacher
script: common/megatron_lm/train/sft.sh
args:
- --seq-length 32768 --max-position-embeddings 1048576
- --micro-batch-size 1 --global-batch-size 16
- --train-samples 6400 # -> 400 iterations
- --modelopt-enabled
- --export-kd-teacher-load /cicd/megatron-lm-bf16/.../BF16-MCore
- --lr 5.0e-6 --lr-decay-style constant --lr-warmup-samples 0
- --clip-grad 1.0 --weight-decay 0.0
- --attention-dropout 0.0 --hidden-dropout 0.0
environment:
- DATASET: nvidia/Nemotron-Post-Training-Dataset-v2
- TP: "1"
- EP: "4"
最后一项导出任务是将经过训练的学员转换为可部署的 Hugging Face NVFP4 检查点。
如要在您自己的模型上进行复制,请交换模型路径并选择 QUANT_CFG (用于设置步骤 3 中的匹配比例策略) ;如要以更高的序列长度进行训练,请将 –seq-length 和 –max-position-embeddings 设置为更高的值,例如 524288 (524k) 。有关完整的启动程序,请参阅 megatron_lm_qad.yaml。
如何使用 Megatron-Bridge 运行 QAD recipe
Megatron-Bridge 是 NeMo 框架中的一个 PyTorch 原生库,可提供预训练、SFT 和 LoRA,以支持热门语言、视觉语言、音频和多模态模型。它充当 Hugging Face 和 Megatron Core 之间的桥梁,在两种格式之间提供双向检查点转换。项目可以利用 Megatron Core 并行功能,或通过内置验证为各种推理引擎导出模型。
The mbridge_qad.yaml 启动器以端到端方式运行整个流程,执行以下四项任务:对训练数据进行标记化,将 BF16 模型量化为 NVFP4 学生模型,将学生模型与冻结的教师模型进行对比,以及导出可部署的 Hugging Face 检查点。在这里,我们使用预标记化数据,Nemotron-Post-Training-Dataset-v2 聊天分割使用 megatron_preprocess_data 预先进行标记化,并通过 --data_paths 传递给蒸馏。
# from tools/launcher
source .env-slurm
uv run launch.py --yaml examples/nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-BF16/mbridge_qad.yaml --yes
这在具有四个 GPU ( TP = 1、PP = 1、CP = 4、EP = 16) 的八个节点上运行,DP = 8,微批量大小 = 1,全局批量大小 = 64;200 次迭代大约覆盖 4.19 亿个训练令牌。
工作流包含本文详述的三个步骤,包含四个任务:
- 将 BF16 模型导入为 Megatron-Core 教师
- 量化单独的学员
- 学员蒸馏对抗冻结的教师
- 导出结果
这在具有 8 个 GPU ( TP = 2、PP = 1、EP = 4) 的两个节点上运行,得到的 DP = 8,微批量大小 = 1,全局批量大小 = 16;训练样本 = 6400,得到 400 次迭代。
了解详情
QAD 可以进行积极的量化,并且准确性仍然接近原始模型。在紧凑、稀疏激活的模型 (例如 Nemotron 3.5 Lightning) 上,这正是在保持准确性的同时解锁强大 NVFP4 检查点的原因。
NVIDIA Model Optimizer 中提供了 Nemotron 3.5 Lightning 的完整 QAD recipe。我们希望您可以在自己的模型上试用,并在我们分享的内容的基础上进行构建。
如需了解详情,请查看以下资源:
- Nemotron 3.5 Lightning Model Optimizer 4o6 yaml recipe
- Nemotron 3.5 Lightning Megatron LM QAD
- Nemotron 3.5 Lightning Megatron Bridge QAD yaml
- NVIDIA Model Optimizer Github 资料库
- NVIDIA Model Optimizer QAD 文档
- NVIDIA Model Optimizer LLM PTQ 文档
致谢
我们在此感谢 Nemotron 团队构建和开源 Nemotron 3.5 Lightning,并感谢 NVIDIA Model Optimizer 团队提供量化和蒸馏工具来助力实现这项工作。
我们感谢 Asma Kuriparambil Thekkumpate、Carlo del Mundo、Chenjie Luo、Daniel Lo、Daria Levy、Frank Sun、Hung-Yueh Chiang、James Shen、Jinhang Choi、Sweta Priyadarshi、Konstantinos Krommydas、Meng Xin、Rohan Joshi、Wei-Ming Chen、Victor Cui、Trenton Starkey 和 Yaniv Galron 对这项工作的贡献,包括配方开发、消融、评估和审查