Nemotron 3 Super：LatentMoE、NVFP4 预训练与 agentic 后训练

本文译自 NVIDIA 的技术报告 Nemotron 3 Super: Open, Efficient Mixture-of-Experts Hybrid Mamba-Transformer Model for Agentic Reasoning¹，2026 年 4 月 14 日提交于 arXiv，署名 544 位贡献者。这里是全文翻译，覆盖摘要、§1 引言、§2 预训练、§3 后训练、§4 面向推理的量化、§5 结论、Contributors，以及附录 A 逐 benchmark 的 merge 评测和附录 B FP4 训练后量化算法细节。参考文献一节不译，正文里的外部链接走脚注。

这篇是 Nemotron 3 系列里的中档模型，三件事是它自己的首发：整个 25T token 预训练跑在 NVFP4 上、用 LatentMoE 替掉标准 MoE 层、带原生 MTP 头做 投机解码。训练栈是 Megatron-Core，那一侧的系统细节见 Megatron Core 的 MoE 训练：打破内存、通信与计算三堵墙；后训练的三个 RL 阶段全部跑在 异步 RL上，新增的 low-effort 模式属于 推理努力度那条线。

我们描述 Nemotron 3 Super 的预训练、后训练与量化——一个 1200 亿参数（激活 120 亿）的 Mamba-Attention 混合 Mixture-of-Experts 模型。Nemotron 3 Super 是 Nemotron 3 家族里第一个做到以下三点的模型：1）在 NVFP4 下预训练，2）采用 LatentMoE——一种同时优化每 FLOP 精度和每参数精度的新 Mixture-of-Experts 架构，3）包含 MTP 层，通过原生投机解码加速推理。我们在 25 万亿 token 上预训练 Nemotron 3 Super，随后用 supervised fine tuning（SFT）和 reinforcement learning（RL）做后训练。最终模型支持最长 1M 上下文，在常见 benchmark 上达到相当的精度，同时相对 GPT-OSS-120B 和 Qwen3.5-122B 分别取得最多 2.2 倍和 7.5 倍的推理吞吐。Nemotron 3 Super 的数据集，连同基座、后训练和量化后的 checkpoint，都已在 HuggingFace 上开源。

1 引言

过去几年，基于 Mixture-of-Experts（MoE）的大语言模型越来越流行。MoE 帮助 LLM 在比常规 dense 模型更低的激活参数量下达到更高精度。与 MoE 正交的另一条路是 Mamba-Attention 混合模型，它在显著提升推理吞吐上已经显出潜力。我们在 Nemotron 3 里把这两个改进方向合起来。作为 Nemotron 3 系列模型的一部分，我们提出 Nemotron 3 Super——一个激活 120 亿、总参数 1200 亿的 MoE Mamba-Attention 混合模型。Nemotron 3 Super 取得了优于或持平 GPT-OSS-120B 和 Qwen3.5-122B 的 benchmark 精度，同时在 8k token 输入 / 64k token 输出这一设置下分别取得最多 2.2 倍和 7.5 倍的推理吞吐。

Figure 1：Nemotron 3 Super 与 GPT-OSS-120B、Qwen3.5-122B 的精度与吞吐对比。Nemotron 3 Super 在流行 benchmark 上取得相当的精度，但提供了最高的推理吞吐；在 8k 输入序列长度、64k 输出序列长度下，Nemotron 3 Super 相对 GPT-OSS-120B 和 Qwen3.5-122B 分别提供最多 2.2 倍和 7.5 倍的吞吐。我们在 B200 GPU 上用 vLLM 和 TRT-LLM 测吞吐，每个模型取两个框架里更好的那个。GPT-OSS-120B 用 MXFP4 权重、MXFP8 激活和 FP8 KV-Cache；Qwen3.5-122B 用 BF16。SWE-Bench 用 OpenHands harness 评测。

Nemotron 3 Super 是我们第一个用 LatentMoE 的模型——一种在每参数和每 FLOP 精度上都优于常规 MoE 的新型 MoE 架构。Nemotron 3 Super 还引入了 Multi-Token-Prediction（MTP，多 token 预测），它通过投机解码加速推理，同时改进整体模型质量。我们在 NVFP4 下预训练 Nemotron 3 Super，证明了低精度下预训练可以既稳定又准确。和 Nemotron 3 Nano 类似，我们在 25 万亿文本 token 上预训练 Nemotron 3 Super，分成 2 个阶段。第一阶段占预训练的 80%（20 万亿 token），重点是多样性和覆盖面；第二阶段占预训练的 20%（5 万亿 token），重点是高质量数据和 benchmark 精度。我们的基座模型精度显著优于同等规模的 state-of-the-art 基座模型，比如 GLM-4.5-Air-Base 和 Ling-flash-Base-2.0。

我们训练 Nemotron 3 Super 时高度强调 agentic 能力。为了支撑这个目标，我们大幅扩展了 RL 环境的广度、agentic 训练数据的体量和质量，以及围绕多步工具使用行为的后训练总量。为了在这一批多样的长程任务上有效训练，我们对 RL 基础设施的韧性做了大量改进，使大规模异步训练成为可能。这套扩展后的 agentic 训练配方相对 Nemotron 3 Nano 在软件工程、终端使用和通用工具使用等 benchmark 上带来了实质提升。

我们在 Nemotron Developer Repository 上公开分享 Nemotron 3 Super 的训练配方²。我们还开放释出以下内容：

Checkpoints：

• Nemotron 3 Super 120B-A12B NVFP4³：后训练并做 NVFP4 量化的模型
• Nemotron 3 Super 120B-A12B FP8⁴：后训练并做 FP8 量化的模型
• Nemotron 3 Super 120B-A12B BF16⁵：后训练模型
• Nemotron 3 Super 120B-A12B Base BF16⁶：基座模型
• Qwen3-Nemotron-235B-A22B-GenRM-2603⁷：RLHF 用的 GenRM

数据：

• Nemotron-Pretraining-Specialized-v1.1⁸：一批合成数据集，目标是提升 LLM 在代码概念与算法、形式逻辑、经济学和选择题上的能力
• Nemotron-Super-Post-Training-Data⁹：一批 RL 环境和 SFT 数据集，覆盖广泛的 agentic 能力

报告分为三大部分：预训练（§2）、后训练（§3）和量化（§4），每部分详述我们的做法。

2 预训练

这一节我们介绍 Nemotron 3 Super 120B-A12B Base 的关键特性，详述它的 Mamba-Attention 混合 Mixture-of-Experts（MoE）架构、NVFP4 预训练、超参数配置、长上下文扩展，以及用于预训练的 25 万亿 token 语料。我们也会展示 Nemotron-3 Super 120B A12B Base 在一套完整的 benchmark 上取得了优于其他公开 state-of-the-art 模型（包括 Ling-flash-Base-2.0 和 GLM-4.5-Air-Base）的精度。

2.1 模型架构

Figure 2：Nemotron 3 Super 的层排布。和 Nemotron 3 Nano 类似，我们用 Mamba-Attention 混合架构，但 Nemotron 3 Super 是第一个用 LatentMoE 层而不是标准 MoE 层来做稀疏扩展的模型。

Table 1：Nemotron 3 Super 的架构维度。模型采用 Mamba-2 与 MoE 混合的设计，并策略性地插入全局 attention 层，以在序列建模性能和推理吞吐之间取得平衡。

配置项	Nemotron 3 Super 120B-A12B Base
总层数	88
模型维度	4096
Q 头数（$n_{q}$）	32
KV 头数（$n_{kv}$）	2
头维度	128
Mamba 状态维度	128
Mamba 分组数	8
Mamba 头数	128
Mamba 头维度	64
专家隐层维度	2688
共享专家中间层大小	5376
每层专家总数	512
Top-$k$（激活专家数）	22
MoE latent 维度	1024
MTP 层数（共享权重）	2

Nemotron 3 Super 120B-A12B Base 把 Nemotron-3 Nano 引入的 Mamba-Attention 混合 Mixture-of-Experts（MoE）架构放大。我们把这个基础扩展到 1206 亿总参数，同时把每次前向的激活预算约束在 127 亿参数（不含 embedding 时为 121 亿）。架构由三根支柱构成：稀疏的 LatentMoE 扩展（§2.1.1）、用于推理加速的 Multi-Token Prediction（MTP，§2.1.2），以及一个周期性的混合交错排布（§2.1.3）。

2.1.1 LatentMoE：面向硬件的专家设计，提升每字节精度

Mixture-of-Experts（MoE）架构已经成为在固定推理成本下最大化精度的一条有前景的路线，它让模型可以扩展参数量而保持每 token 的浮点运算量（FLOPs）不变。现有的 MoE 设计大体上是被高层的稀疏性论证驱动的，为离线、吞吐导向的场景做优化，很少考虑对延迟、内存带宽和通信施加严格约束的在线部署。每 FLOP 精度反映的是计算效率，而每参数精度捕捉的是内存占用、内存带宽、路由带来的通信以及分片开销。忽视这些因素，可能得到一个在聚合算力上看着高效、但实际运行中承受大量低效的架构。

出于这些观察，我们从硬件—软件协同设计的视角重新审视了 MoE 设计。通过在吞吐—延迟 Pareto 前沿上系统分析现有 MoE 系统，配合精度测量和理论分析，我们识别出了主流 MoE 设计中限制「单位推理成本换到的精度」的结构性低效。从这些分析里我们提炼出以下高效 MoE 扩展的设计原则：

1. 在低延迟服务中，MoE 推理往往被读取专家权重的内存带宽成本主导。每个专家矩阵的尺寸是 $d \times m$，其中 $d$ 是隐层维度、$m$ 是专家 FFN 的中间维度；因此降低这项成本需要减小 $d$ 或 $m$。
2. 在吞吐导向的服务中，分布式 MoE 推理被 all-to-all 路由主导。路由数据量按 $d \times K$ 缩放，其中 $K$ 是激活专家数；因此降低通信开销需要减小 $d$ 或 $K$。
3. 保住模型质量需要保住有效的非线性预算 $K \cdot m$。因此，要在不牺牲质量的前提下缓解内存和通信瓶颈，$K$ 和 $m$ 应当保持固定。
4. 任务相关的有效特征秩 $r_{\mathrm{eff}}$ 给 $d$ 能压到多小设了下限；把 $d$ 压到这个下限以下会导致模型质量崩塌。
5. 同时扩大专家总数 $N$ 和每 token 的 top-$K$ 专家数，会通过指数级扩大专家组合的空间来改进质量。

原则（1）—（3）意味着隐层维度 $d$ 是最有希望被压缩的那个轴，在吞吐导向和延迟导向两种场景下都能拿到收益而不显著损失精度。原则（4）给出了 $d$ 能压到多远而不崩塌的下界。原则（5）表明增大 $N$ 和 $K$ 会改进质量；由于内存带宽和通信随 $K$ 线性增长，我们可以把 $K$ 放大 $\alpha$ 倍、同时把 $d$ 缩小同样的 $\alpha$ 倍，从而在相近的推理成本下拿到更高精度。在这些洞察的指引下，我们开发了 LatentMoE，一种设计目标是在相近推理成本下取得比标准 MoE 更高精度的 MoE 架构。

Figure 3a：标准 MoE 架构。

Figure 3b：LatentMoE 架构。两张图合起来是原文的 Figure 3：在 LatentMoE 中，token 从隐层维度 $d$ 被投影到更小的 latent 维度 $\ell$ 上做路由和专家计算，把路由参数的加载量和 all-to-all 流量都降低了 $d/\ell$ 倍。这些节省被用来把专家总数和每 token 激活的 top-$K$ 专家数都放大同样的倍数，在推理成本大致不变的前提下提升模型精度。

LatentMoE 架构如 Figure 3b 所示。每个输入 token $x \in \mathbb{R}^d$ 先通过一个可学习的下投影矩阵 $W_{\downarrow} \in \mathbb{R}^{\ell \times d}$ 被投影到低维 latent 空间 $\mathbb{R}^{\ell}$。压缩后的表示随后被路由到一组扩大了的专家，这些专家完全在这个 latent 空间里运算。专家计算之后，输出被聚合，再通过一个可学习的上投影矩阵 $W_{\uparrow} \in \mathbb{R}^{d \times \ell}$ 投回维度 $d$。把路由专家的计算和 all-to-all 流量搬进 latent 空间，相对标准 MoE 把每专家的权重加载量和通信载荷都降低了 $d/\ell$ 倍。我们用这些节省把专家总数从 $N$ 提到 $N' = N \cdot d/\ell$，把每 token 的 top-$K$ 激活专家数从 $K$ 提到 $K' = K \cdot d/\ell$。维度的下降抵掉了专家数和 $K$ 的上升，于是在相近的计算与通信预算下得到更高的模型质量。为了保住质量，所有非路由的计算——包括路由 gate（gating network）、共享专家计算和非专家层——都保留在完整隐层维度 $d$ 上，因为它们对我们针对的那些瓶颈贡献不大。更多细节请读者参考 LatentMoE 技术报告。

2.1.2 Multi-Token Prediction

Nemotron-3 Super 引入 Multi-Token Prediction（MTP）目标，以同时改进建模质量和推理效率。与常规的 next-token 训练不同，MTP 让模型在每个位置上预测多个未来 token。这鼓励模型形成能捕捉多步依赖和更长程结构的表示，带来了 validation loss 和下游 benchmark 精度上一致的改进。

除了质量收益，MTP 还使原生投机解码成为可能。那些辅助预测头充当了一个内部的 draft model：推理时它们生成候选续写，由主模型在一次前向里验证。这大幅降低了解码延迟，同时只引入极少的额外 FLOPs——显著少于外部 draft model 所需的量。虽然投机解码在小 batch size 下尤其有效，但近期工作显示它在更大 batch 和稀疏 MoE 场景下也能提升吞吐。

为稳健的自回归 drafting 而设计

标准的 MTP 实现使用 $N$ 个独立的头，每个头被训练去预测一个固定的偏移（比如 $n+2, \dots, n+N+1$）。这在训练时有效，但把投机解码限制在最多 $N$ 个 draft token。更长的 draft 要么需要增大 $N$，要么需要把某个训练在固定偏移上的头反复自回归地复用。

复用一个固定偏移的头会引入训练—推理不匹配：这个头是在 ground-truth 隐状态下训练的，但推理时它要以自己生成的状态为条件。这种分布漂移常常导致接受率随 draft 长度增加而下降。

Nemotron-3 Super 通过在训练时让多个 MTP 头共享参数来解决这个限制，得到一个见过多种偏移的统一预测头。这种共享权重的表述在多个预测跨度上正则化了这个头，改进了它对自回归 drafting 时遇到的自生成隐状态的稳健性。结果是同一个头可以在推理时被递归应用，生成更长的 draft 而接受行为更稳定。虽然接受率随 draft 长度增加自然会下降，但退化程度比独立训练的偏移头温和得多。这使得更有效的投机解码成为可能，而不需要引入额外参数或单独的 draft model。

投机解码性能

我们用 SPEED-Bench 评测 MTP 质量，这是一个为投机解码定制的 benchmark。Table 2 报告了固定 draft 长度为 7 时的平均接受长度（每个验证步接受的 token 数）。Nemotron-3 Super 取得了最高的总体平均接受长度（3.45），在所有领域上都超过 DeepSeek-R1，并与 Qwen3-Next 保持竞争力。

Figure 4：SPEED-Bench 上按 draft 位次的 MTP 接受率，draft 长度为 7。

Table 2：SPEED-Bench 上的 MTP 平均接受长度，draft 长度为 7。

类别	DSR1	Qwen3 Next	Nemotron3 Super
Coding	2.99	4.32	3.78
Humanities	2.67	3.07	3.26
Math	2.98	3.89	3.73
Multilingual	2.83	3.97	4.05
QA	2.63	3.09	3.16
RAG	2.79	3.53	3.78
Reasoning	2.80	3.47	3.59
Roleplay	2.19	2.17	2.82
STEM	2.79	3.37	3.30
Summarization	2.59	3.06	3.48
Writing	2.41	2.69	2.99
平均	2.70	3.33	3.45

Figure 4 画的是接受率随 draft token 位次的变化。如预期，所有模型的接受率都随 draft 深度单调下降。但 Nemotron-3 Super 在每一个 draft 位置上都保持比 DeepSeek-R1 更高的接受率，并在大多数位次上紧跟或超过 Qwen3-Next。值得注意的是，在更大的 draft 位次（4–7）上差距更明显，而那里正是递归 drafting 最困难的地方。这个表现说明共享头的自回归设计在更长的投机 rollout 下稳定性更好。

总的来说，Nemotron-3 Super 里的 MTP 同时改进了表示学习和解码效率，让模型在更长 draft 长度下也能取得更高接受率，而不依赖外部 draft model。这些接受率上的收益转化成了 Blackwell 硬件上更好的服务效率。如 Figure 5 所示，通过 MTP 增加 draft 深度（从 $D=1$ 到 $D=3$）显著推移了吞吐—延迟的 Pareto 前沿，在任意给定的中位用户延迟下都比关掉 MTP 的基线交付更高的聚合输出 token 每秒（TPS）。

Figure 5：NVFP4 checkpoint 的总吞吐与单用户吞吐（TRT-LLM，TP=1，B300 GPU）。对比关掉 MTP 与 draft 长度为 1、3 的 MTP。测量于 SPEED-Bench 的 Throughput-1k split，输出 1k token。

2.1.3 混合交错 MoE 架构与全局锚点

Nemotron 3 Super 采用一种混合 Mixture-of-Experts（MoE）架构，设计目标是最大化推理吞吐——尤其是长上下文推理场景——同时保住大规模 dense Transformer 的建模容量。现代序列模型的主要系统瓶颈是 self-attention 层里 KV cache 的二次增长。为了解决这一点，我们主要使用 Mamba-2 块，它在生成时以一个常数大小的状态运行，大幅降低了内存开销和延迟。

这 88 层的栈遵循一个周期性交错排布，其中 MoE 层与 Mamba-2 块配对。Mamba 提供了高效的线性时间序列建模，同时少量 self-attention 层被策略性地插入，作为全局「锚点」，让全 token 交互和跨栈的长程信息路由成为可能。这种混合交错保住了全局依赖建模，同时把大部分计算卸载给更高效的 Mamba 和稀疏 MoE 组件。Table 1 和 Figure 2 给出了结构参数和混合栈具体交错排布的完整总结。

Attention 层采用 Grouped-Query Attention（GQA），32 个 query 头、2 个 KV 头（头维度 128）。与之前的 Nemotron 模型一致，我们不用位置编码、不用 dropout、线性层里不带 bias 项，用 RMSNorm 做归一化，并保持 embedding 和输出权重不共享。这个配置支持最长 1M token 的上下文。

稀疏扩展进一步改进效率。每个 MoE 层每 token 只激活一部分专家（top-22 路由），使模型能扩展到 1206 亿总参数，同时每次前向维持 127 亿的激活参数预算。

总体上，线性时间 Mamba 块、稀疏激活的 MoE 容量与位置经过设计的 attention 锚点之间的协同，让 Nemotron 3 Super 既能交付强的长上下文表现，又对现代硬件上的真实部署做了优化。

2.2 NVFP4 预训练

Table 3：按层类型的精度分配。

层类型	格式	理由
除下面另行说明外的所有线性层	NVFP4
网络最后 15%	BF16	在大规模下促进训练稳定
Latent 投影	BF16	策略性地留在 BF16，因为对 step time 的影响可以忽略
MTP 层	BF16	保住 multi-token prediction 的能力
QKV 与 attention 投影	BF16	维持那少数几个 attention 层的保真度
Mamba 输出投影	MXFP8	缓解在较小规模下把这一层量化到 NVFP4 时观察到的高频下溢
Embedding 层	BF16

Nemotron 3 Super 用 Nemotron 3 白皮书里详述的 NVFP4 预训练配方训练。除 Table 3 另行说明的以外，所有线性层的 fprop、dgrad 和 wgrad GEMM 都使用 Transformer Engine 提供的开源 NVFP4 GEMM kernel（cuBLAS 后端）训练。这套框架按我们此前工作首次引入的方案，把权重、激活和梯度量化到 NVFP4。权重用二维（2D）块缩放量化到 NVFP4，以保持前向和反向中量化权重的一致性。梯度和激活沿 GEMM 的 reduction 轴用一维（1D）块量化到 NVFP4。对 wgrad 的输入做 Random Hadamard Transform（RHT），对梯度张量施加随机取整（stochastic rounding）。NVFP4 格式使用 E2M1 元素格式、16 元素的微块、E4M3 的微块缩放因子，以及第二级的 FP32 全局 scale。Nemotron 3 Super 展示了 NVFP4 下最长到 25T token 的大规模稳定训练。

在 Nemotron 3 Super 的训练过程中，我们观察到权重梯度中零值元素的数量在增长，于是调查了根因以验证训练是否健康。某些专家层里浮现出了幅值模式，特征是 FC1 输出通道的范数和对应 FC2 输入通道的范数都趋向零（Figure 6）。到预训练结束时，零值权重梯度元素占到总参数量的 7%，看起来和这些幅值模式相关。我们认为 NVFP4 量化提高了权重梯度中真零的发生率，而这些值在 BF16 或 MXFP8 下本可以更容易地表示出来。低范数通道在这些层用 NVFP4 训练时，很可能衰减得更快。

Figure 6：Nemotron 3 Super 专家层权重中的通道幅值模式。模式随训练推进而浮现。上：早期层的路由专家 FC1 权重矩阵，分别在 0.5T token 和 23T token。下：早期层的路由专家 FC2 权重矩阵，分别在 500B token 和 23T token。FC1 的低范数输出通道与 FC2 的低范数输入通道对齐。

Figure 7：Nemotron 3 Nano 上零值权重梯度元素的数量。左：已发布的 Nemotron Nano 3 模型，用 BF16 训练到 25T token。右：训练到 1T token 的消融研究，分别用 BF16 和我们的 NVFP4 配方。NVFP4 模型在 1T token 处达到的零值权重梯度数量，与 BF16 模型在 25T token 处相当。在 0.5T token 处从 NVFP4 切回 BF16，会让零值权重梯度回到基线水平。BF16 里小幅值梯度（<1e-12）的高度普遍，说明 NVFP4 量化把这些本已很小的值下溢成了零。

我们对比了两个完全相同的 Nemotron 3 Nano 模型，分别用 BF16 和 NVFP4 训练 1T token，发现在同一个 token 视界上 NVFP4 预训练产生的零值权重梯度大约多 3 倍。当一个训练到一半的 NVFP4 模型被切回 BF16 时，零值权重梯度的数量回到基线水平。BF16 模型里仍然含有很多小幅值梯度（<1e-12），但 NVFP4 量化把这些值下溢成了零（Figure 7）。我们从路由专家层采样了权重、激活和梯度张量，观察到在 500B token 处 FC2 的 dgrad 有很高的下溢率，主要原因是二维权重量化块会同时跨越高幅值和低幅值通道。FC2 的 dgrad 下溢通过梯度反向传播在 FC1 的 wgrad 里造出零。在 750B token 处，我们观察到 FC1 的 fprop 有很高的下溢率，在 FC2 的 wgrad 里造出零（Figure 8）。1T token 的 NVFP4 模型表现得像一个训练时间长得多的 BF16 模型。在 10T token 之后，已发布的用 BF16 训练的 Nemotron 3 Nano 模型达到了与训练到 1T token 的 NVFP4 模型相当的零值权重梯度元素数量（Figure 7），而且检查早期专家层的权重矩阵发现了类似的通道幅值模式。这些在 Nemotron 3 Nano 架构上得到的结论，为理解 Nemotron 3 Super 中的通道幅值模式和零值权重梯度元素的增长提供了线索。

Figure 8：Nemotron 3 Nano 中零元素权重梯度的来源，按层深度递增展示路由专家层，在同一层索引下的所有路由专家上取平均。上：在 500B token 处采样的张量。FC1 的零值权重梯度占比高于 FC2，且几乎完全归因于 FC2 的 dgrad 下溢。下：在 750B token 处采样的张量。FC1 和 FC2 的零值权重梯度占比同样高。FC1 的零值权重梯度归因于 FC2 的 dgrad 下溢。FC2 的零元素权重梯度主要归因于 FC1 的 fprop 下溢，FC2 的 wgrad 下溢有少量贡献。

沿着我们此前 NVFP4 预训练的工作，我们评估了在学习率退火之前把所有张量切到更高精度是否对 Nemotron 3 Super 有益。我们在 19T token 处（退火前 1T token）把所有张量提升到 MXFP8，继续训练到 20.6T token。虽然这改进了 loss 轨迹，但在下游任务精度上没有带来收益（Figure 9）。因此最终的 Nemotron 3 Super 模型在整个 token 视界上都用我们的 NVFP4 配方预训练。

Figure 9：把网络精度切到 MXFP8 后下游任务评测精度的改进。大于零的值表示相对 NVFP4 模型精度有改进。在 MXFP8 下训练之后，没有任何一项下游任务评测指标显示出持续的改进。

2.3 预训练数据

2.3.1 数据

这里我们描述自 Nemotron 3 Nano 以来新加入预训练的几个数据集。我们把这些数据集以 Nemotron-Pretraining-Specialized-v1.1 的名字发布在 HuggingFace 上⁸。

2.3.2 合成代码概念

为了提升 Python 解题能力，我们合成生成了一个由 Python 问题和解答构成的数据集。我们用一份从 Nemotron-Pretraining-Code 数据集¹⁰中整理出的、包含数千个编程概念的分类体系，配合 GPT-OSS-120B，从 HumanEval benchmark 数据集里抽取高层编程概念。对抽取出的分类表示做去重后，我们总共收集到 91 个概念。

用抽取出的概念，我们用 GPT-OSS 20B 做开放式生成，产出测试这些概念的 Python 编程问题，并要求它生成带有描述性函数名、且问题描述写在函数 docstring 里的问题。为了把这些问题生成到预训练规模，我们每次生成组合最多四个概念，每组概念生成最多五道题。这产出了总计约 1400 万道题。

问题生成之后，我们用 GPT-OSS 120B 为每道生成的题产生五份自包含的解答。为了避免让在这些数据上训练的模型偏向生成啰嗦冗长的解答，我们要求 GPT-OSS 120B 把解答限制在最多 60 行。每道题我们生成五份解答，在拿到约 2300 万个「问题—解答」对之后停止生成。

作为生成这个数据集的最后一步，我们彻底清洗了生成的问题—解答对。清洗包含以下步骤：我们检查 GPT-OSS-120B 是否引入了原始问题（由 GPT-OSS-20B 生成）里未指定的额外 import。所有不满足这个条件的解答都被丢弃。我们只解析 GPT-OSS-120B 提供的解答部分，把它接到 GPT-OSS-20B 生成的问题后面，构成最终的问题—解答对。我们发现 GPT-OSS-120B 经常会修改原始问题，这一步确保了我们维持住原始问题构造 prompt 里规定的目标格式。我们通过生成抽象语法树（AST）来检查最终的问题—解答对是不是合法的 Python 代码。如果最终函数没通过 AST 检查，就被丢弃。经过上述清洗流程，我们得到了构成这个数据集的 1500 万道题。

2.3.3 合成无条件算法题

为了造出这个数据集，我们用 Qwen3-235B-A22B（基座模型）和 gpt-oss-120b 生成算法类 Python 题目。我们用极简的 prompt——比如「Write a function」「Write a Python function」或者「Write a coding problem and solution for a student to solve」——并可选地指定难度等级（easy、medium 或 hard）。为了确保多样性和质量，我们提示 gpt-oss-120b 重写这些样本，让它们处理边界情况、加上单元测试，并以多种方式重新格式化输出。

在另一个变体里，我们让 gpt-oss-120b 生成 LeetCode 风格的问答，同样带一个随机选取的难度等级。我们还用 gpt-oss-120b 给解答的正确性打分，若不正确则加以修正。总体上，这种近乎无条件的 prompting 确实导致了很高的重复率。为了对抗这一点，我们发现按 gpt-oss-120b 为每道题生成的 5–8 个词的短标题做去重是有效的。

所有样本都针对 HumanEval、MBPP、CRUXEval 和 LiveCodeBench 做了去污染，做法如下：首先，把与这些 benchmark 精确匹配的解答移除。其次，我们用 Qwen3-Embedding-0.6 编码问题和解答，过滤掉与任一 benchmark 相似度大于 0.8 的数据。

尽管以通常的预训练标准看这个数据集很小（0.2B token），我们相信它有助于教会像处理边界情况、推理程序执行这样的编码实践——证据是把这些数据集加进 25T token 预训练最后 100B token 的一次重跑里，相对 Nemotron 3 Nano 基座 checkpoint 在 HumanEval、MBPP 和 CRUXEval-O 上带来了 1–2 分的提升。

2.3.4 合成经济学

我们生成了一批形式多样的经济学选择题，包括完形填空、计算、句子补全和多选多，覆盖微观经济学、宏观经济学和计量经济学里的关键主题和术语（例如「Statistical Inference and Hypothesis Testing - Type I error」和「Inflation and the Price Level - Inflation rate」），主题来自一份人工整理的清单。对每个「主题—术语」对，我们用 Qwen3-235B-A22B-Thinking-2507 生成多道题，每道题都配一份详细的、分步骤的、格式良好的解答。为了增强多样性，我们进一步提示模型以最初的输出为参照，创作新的原创题目。每个「问题—解答」对都经过基于模型的验证，检查清晰度、是否有歧义、可解性和准确性。

2.3.5 合成形式逻辑

我们合成了一批形式逻辑的问题与解答，跨越若干任务，比如在自然语言和谓词逻辑或命题逻辑之间互译、推导条件命题的前件，以及用间接真值表或完整真值表求解逻辑问题。我们通过在 prompt 里注入随机的 persona¹¹、字母和/或逻辑连接词（即 $\land$、$\lor$、$\supset$、$\equiv$、$\sim$）来给生成的场景、前提和公式引入变化。我们用 Qwen3-235B-A22B-Thinking-2507 生成并评估这些问题与解答。

2.3.6 合成选择题

我们从 MMLU 的辅助训练集出发，自举构造了一个选择题（MCQ）数据集；那个辅助集本身汇聚了来自 ARC、MC_TEST、OpenBookQA、RACE 等来源的辅助 MCQ 数据。从每道种子题出发，我们提示 Qwen3-235B-A22B 生成多道遵循相同任务格式和难度画像的相似题目，以及对应的答案选项。第二阶段，我们提示 DeepSeek-V3 模型解每道生成的题，选出一个答案并给出支撑其选择的知识或上下文推理。为了提升答案可靠性，我们对每道题用不同随机种子采样多次独立生成的解答，然后在生成的答案上做多数投票以确定最一致的选项，只保留最终答案与多数一致的样本，丢弃不一致或错误的实例。

用这条流水线，我们生成了约 350 万条 MMLU 风格的 MCQ 样本（约 16 亿 token），并附有明确、相关的知识或推理轨迹。我们通过消融实验评估这批数据的效果：在 Nemotron-Nano-V3 的 24.9T token checkpoint 上继续训练额外 100B token，其中 1B token 来自生成的 MMLU-aux-train-SDG 数据。结果显示大多数 benchmark 上有一致的增益：MMLU 从 77.22 提升到 77.51，「MATH Level 5」从 78.55 到 79.05，AIME-2024 从 53.3 提升到 56.7，MBPP 从 74.8 到 75.2。其他 benchmark 上的表现基本稳定，只有小幅波动，说明合成的 MCQ 数据主要强化了数学与结构化推理能力，而没有在别处引入回退。

2.3.7 数据配比与顺序

我们采用 Nemotron 3 Nano 里描述的数据配比。我们的预训练语料跨 16 个高层类别。最大的组成部分是网页爬取数据，我们按 Nemotron-CC 的分类体系把它划成五个基于质量的分组：crawl-medium、crawl-medium-high 和 crawl-high，代表质量递增的爬取数据，加上它们的合成对应物 syn-crawl-medium-high 和 syn-crawl-high，由过滤后的网页文档生成。

除了网页爬取，配比里还包括数学、Wikipedia、代码、Nemotron-CC-Code、学术文本、Crawl++、多语言数据、finepdfs 和合成的 SFT 风格数据集。SFT 风格数据进一步分为 general-sft、stem-sft 和 code-sft。作为 SFT 风格组成的一部分，我们把以推理为重点的数据集也纳入预训练，动机来自此前证明这类数据有效的研究发现。Crawl++ 由 OpenWebText、BigScience 和 Reddit 数据集构成。

数据混合的设计目标是平衡多样性和质量：估计质量相当的来源被赋予相近的权重，而更高质量的数据集在混合里获得成比例更大的权重。关于数据集质量估计和混合构造的更多细节见我们此前的工作。我们采用那项工作提出的两阶段课程。在阶段 1，混合强调数据多样性，以促进广泛覆盖和泛化。在阶段 2，配比转向以高质量来源为主（比如 Wikipedia），以精细化模型表现。向阶段 2 的转换发生在总训练 token 的 80% 处。两个阶段各自使用的具体配比见 Figure 10。

Figure 10a：阶段 1 的数据配比。

Figure 10b：阶段 2 的数据配比。两张图合起来是原文的 Figure 10：预训练各阶段的数据配比。

2.4 超参数

Nemotron 3 Super 120B-A12B Base 的预训练使用 Warmup-Stable-Decay（WSD）学习率调度，总 token 视界为 25 万亿。学习率（LR）在最初的 2000 亿 token 上 warm up 到峰值 $4.5\times10^{-4}$。在一段持续的稳定平台期之后，我们在最后 5 万亿 token 上实施 minus-sqrt 衰减调度，把 LR 退火到最小值 $4.5\times10^{-6}$。

我们用 AdamW 优化器，weight decay 为 0.1，动量系数 $\beta_1=0.9$、$\beta_2=0.95$。模型以 8,192 的序列长度、3,072 条序列的 batch size 训练，约合每个 batch 2517 万 token。

架构采用 Mamba-MoE 混合设计，MoE 层含 512 个专家、top-22 路由机制（$k=22$）。我们用 sigmoid 的 router 打分函数，辅以专家偏置。为了确保这 1206 亿参数上专家利用的均衡，我们采用了无辅助损失的负载均衡策略，更新率为 $10^{-3}$，同时搭配系数为 $10^{-4}$ 的标准负载均衡损失。

此外，我们使用 MTP 目标，loss 缩放因子为 0.3。为了在大规模下最大化计算效率和训练稳定性，执行时采用 BF16 与 NVFP4 的混合精度方案。

2.5 Merge 评测追踪

在 §2.4 所述 WSD 学习率调度的稳定阶段，学习率保持恒定，单个训练 checkpoint 在 benchmark 上的表现在步与步之间是有噪的。沿着近期关于权重空间合并的工作，我们施加 checkpoint 合并（在最近若干 checkpoint 的滑动窗口上做加权平均），以在不需要专门的学习率衰减实验的前提下得到更可靠的模型质量读数。在常规的预训练工作流里，评估中间 checkpoint 的模型质量需要专门的衰减实验；checkpoint 合并消掉了这笔成本。对于一个和我们类似的调度，节省下来的算力可能达到约 4T token（比如省掉约 2 次 1.5T 的和约 2 次 0.5T 的实验），或者大约是总预训练 FLOP 预算的 16%。

沿用 WSM 的做法，我们用 minus-sqrt 衰减模拟来计算合并系数，每 1,000 次迭代保存一个 checkpoint（在我们 $3{,}072 \times 8{,}192$ token 的全局 batch size 下约合 25B token）。我们在预训练过程中评估了 125B、250B 和 500B token 三种滑动合并窗口。在一套 12 个 benchmark（MMLU-Pro、MMLU、HumanEval、HumanEval+、MBPP、MBPP+、GSM8K、MATH-500、RACE、ARC-Challenge、HellaSwag、WinoGrande）上平均，最好的合并结果在不加权平均上一致地超过对应的训练 checkpoint 2–4 分。由于合并相对训练来说计算上很便宜，我们可以在每个 checkpoint 上评估全部三个窗口并选最好的。Figure 11 在完整的 25T token 训练过程上报告了这个「三选一最优」的合并结果与训练 checkpoint 的对比。

Figure 11：预训练过程中训练 checkpoint 与最优离线 checkpoint 合并在 12 个 benchmark 上的平均精度。在稳定 LR 阶段，离线合并带来一致的 2–4 分改进。在 LR 衰减阶段（阴影区），差距收窄，因为训练 checkpoint 从真实的学习率退火里获益了。

在最后 5T token 的 LR 衰减阶段（从 20T 到 25T token），合并 checkpoint 与训练 checkpoint 之间的差距大幅收窄，到训练结束时两条评测轨迹基本重合。WSM 的作者报告过把合并与衰减结合相对只做合并没有增益，所以这种收敛是预期之中的。WSM 原本的结果走得更远，显示基于合并的读数能超过衰减训练出的 checkpoint。在 Nemotron 3 Nano 规模的架构（30B-A3B）上做实验时，我们在模拟较短（约 500B）的衰减窗口时能复现出这样的收益。但在 1T 和 1.5T 合并视界上的直接对比，没有显示出相对衰减训练 checkpoint 的改进。

我们的结论是，离线 checkpoint 合并似乎在较短的退火视界上最有效。这与 Ling 那边的发现一致——他们用的衰减调度相当短，也报告了合并带来的改进；对比之下我们这里用的是长得多的 5T 衰减，训练衰减能够追平或超过基于合并的读数。最终被选去做下游对齐的基座 checkpoint 本身就是一个 500B 的合并结果；即便在完整的衰减调度旁边，短视界合并在实践中仍然有用。话说回来，我们的实验只探索了单一的合并调度（minus-sqrt）和固定的 checkpoint 粒度；仍有可能存在别的系数方案、更细粒度的 checkpoint 窗口，或者为更长衰减视界定制的合并策略，能把在较短尺度上观察到的收益找回来。逐 benchmark 的拆解见附录 Figure 17。

2.6 长上下文扩展

和 Nemotron 3 Nano 类似，我们在预训练最后加了一个长上下文阶段（LC-Phase）。在 LC-Phase 里，我们做持续预训练（CPT），给基座模型装上长上下文能力。我们用恒定学习率 $4.5*10^{-6}$、全局 batch size 16。我们用 64 路 context parallelism、2 路 tensor parallelism 和 64 路 expert parallelism，在 GB200 GPU 上训练。我们复用了 Nemotron 2 与 3 Nano 的长上下文文档 QA 数据集。在 LC 阶段的数据配比里，我们给文档 QA 数据分配 20%，剩下 80% 是降采样后的阶段 2 数据。我们最初在 1,048,576（1m）上下文长度上做 CPT，这个阶段持续了 340 亿 token。之后我们又加了一个阶段，交替在 1m 和 4k 序列上训练，以缓解我们观察到的对数学相关 benchmark 的轻微影响。第二个阶段持续了 170 亿 token。

2.7 基座模型评测

Table 4：Ling-flash-base-2.0、GLM-4.5-Air-Base 与 Nemotron Super 120B-A12B Base 的对比。最好的结果加粗。

任务	指标	N-3-Super 120B-A12B-Base	Ling-flash base-2.0	GLM-4.5 Air-Base
通用知识
MMLU	5-shot, acc	86.01	81.00	81.00
MMLU-Pro	5-shot, CoT EM	75.65	62.10	58.20
AGIEval-En	3/5-shot, CoT EM	77.92	61.70	62.40
GPQA-Diamond	5-shot, CoT EM	60.00	36.00	23.20
数学
GSM8K	8-shot, EM	90.67	90.75	82.60
MATH	4-shot, EM	84.84	63.80	50.36
MATH Level 5	4-shot, EM	70.00	39.80	26.30
AIME 2024	pass@32	53.33	30.00	20.00
代码
HumanEval	0-shot, pass@1 n=32	79.40	70.10	76.30
MBPP-Sanitized	3-shot, pass@1 n=32	78.38	77.30	77.50
常识理解
ARC-Challenge	25-shot, acc_norm	96.08	94.80	93.90
HellaSwag	10-shot, acc_norm	88.97	84.69	87.70
OpenBookQA	0-shot, acc_norm	50.20	47.00	48.60
PIQA	0-shot, acc_norm	85.47	84.00	84.22
WinoGrande	5-shot, acc	78.93	78.37	83.82
阅读理解
RACE	0-shot, acc	91.00	90.10	89.50
多语言
MMLU Global Lite	5-shot, avg	85.72	74.94	79.25
MGSM	8-shot, avg	87.47	82.73	80.33
长上下文
RULER 64K	0-shot	92.26	72.12	80.26
RULER 128K	0-shot	88.26	52.03	61.70
RULER 256K	0-shot	84.56	-	-
RULER 512K	0-shot	82.49	-	-
RULER 1M	0-shot	71.00	-	-

除另有说明外，所有评测结果都通过 Nemo Evaluator SDK¹² 和 NVIDIA 的 LM Evaluation Harness 开源容器¹³收集。为了可复现，评测设置的更多细节可以在 Nemo Evaluator SDK 的 examples 目录里找到¹⁴。用于评测、经 NVIDIA 的 Nemo Evaluator SDK 打包的 LM Evaluation Harness 开源容器在这里¹⁵。这个容器构建在 LM Evaluation Harness 之上，为公平起见对所有模型施加了以下改动：

1. 对数学推理，我们用贪心解码评测 GSM8K 和 MATH benchmark。我们还单独标出 MATH benchmark 里竞赛难度的切片，记为「MATH Level 5」。此外，我们报告 AIME-2024 上的 $\text{pass}@32$ 表现。所有生成结果都用 Math-Verify 判分¹⁶。
2. 对代码任务（HumanEval、MBPP），我们在 0-shot 设置下评测 EvalPlus 变体，并对生成结果做 sanitization。我们从每个 prompt 的 32 次生成中估计 $\text{avg}@32$ 和 $\text{pass}@1$。
3. 通用推理 benchmark（OpenBookQA、PIQA、Hellaswag、Winogrande）保持不变，只有 ARC-Challenge 例外——我们把所有选项同时呈现，做法类似 MMLU。
4. 对多语言能力，我们评测 MGSM（8-shot，原生 CoT）和 Global MMLU-Lite。
5. 对长上下文能力，我们评测 RULER，每个任务用 100 个样本。

Nemotron 3 Super 120B-A12B Base 的精度结果以及与 Ling-flash-Base-2.0、GLM-4.5-Air-Base 的对比见 Table 4。

3 后训练

我们遵循与 Nemotron 3 Nano 相同的总体配方，但更强调 agentic 任务。Figure 12 给出流水线的概览。我们从 Supervised Fine-Tuning（SFT）阶段开始（§3.1），随后是三阶段的 Reinforcement Learning 阶段——RLVR、SWE-RL 和 RLHF（§3.2）。最后我们以一个 MTP healing 阶段收尾。

在 SFT 里，我们扩展了训练配比，以覆盖更广的 agentic harness 和交互场景。我们也显著改进了 RL 基础设施，使数千卡上可靠的大规模异步训练成为可能。这套基础设施让我们能够（1）在 21 个不同环境上训练，提升跨任务的稳健性，以及（2）在长程 SWE 任务上训练，强化真实 agentic 场景下的多步推理与问题求解。

Figure 12：Nemotron 3 Super 后训练流水线概览。Base（1M 上下文）先过 SFT（7M 样本、80B token），再进 RLVR 的三轮，环境类型分别为 25、30、26 种，后两轮引入 low effort、第三轮聚焦 agentic；总计 37 种环境类型，每个 batch 最多 4,000 个环境实例。之后依次是 SWE RL（20B token）、RLHF（18B token）和 MTP healing。

译注：图上标的是 37 种环境类型，而正文 §3.2.1 说的是「21 个环境」，RLVR 数据那一节说的是「21 个环境和 37 个不同的 RL 数据集」。按后者理解，图上的 37 更可能是数据集数而不是环境数。

3.1 Supervised Fine Tuning

对 Nemotron 3 Super 的 SFT，我们的重点是改进数据集的质量和多样性。特别地，我们放大了 agentic 数据集，并提高了它们在整体 SFT 配比中的占比。chat template 与 Nemotron 3 Nano 保持一致。此外我们加了 low effort 推理模式，给用户对推理长度更多的控制。我们发现单阶段 SFT 会导致「长输入短输出」场景上明显退化。因此我们采用两阶段 SFT 流程：阶段 1 强调从 token 级监督中学习并诱导出强的推理行为，阶段 2 则切换到按对话归一化，防止长输出主导 loss，从而在保留推理能力的同时恢复长输入短输出的表现。下面我们描述这套做法。

SFT 目标与两阶段损失

对一个包含多段对话 $c$ 的打包全局 batch $\mathcal{B}$，令 $\mathcal{O}_c$ 表示对话 $c$ 的输出 token 位置集合，$|\mathcal{O}_c|$ 表示其输出 token 数。用 token 级的负对数似然 $\ell_t = -\log p_\theta(y_t \mid x, y_{

阶段 1：token 级（全局）平均

我们最小化打包全局 batch 里所有输出 token 上的平均 loss：

$$ \mathcal{L}_{\text{tok}} = \frac{\sum\limits_{c \in \mathcal{B}} \sum\limits_{t \in \mathcal{O}_c} \ell_t} {\sum\limits_{c \in \mathcal{B}} |\mathcal{O}_c|}. $$

这相当于把所有对话的输出 token 对数概率加起来，再按输出 token 总数归一化。

阶段 2：样本级平均

接着我们切换到按对话归一化的 loss，并在各对话之间等权平均：

$$ \mathcal{L}_{\text{samp}} = \frac{1}{|\mathcal{B}|} \sum\limits_{c \in \mathcal{B}} \left( \frac{1}{|\mathcal{O}_c|} \sum\limits_{t \in \mathcal{O}_c} \ell_t \right). $$

这个阶段通过在跨 batch 平均之前先用每段对话自己的输出 token 数做归一化，削弱了长输出的主导地位。

阶段 1 我们用 256k 序列长度打包、全局 batch size 64、恒定学习率 $1e-5$、30k 个 warmup 样本跑 SFT。阶段 2 我们用 512k 序列长度打包并纳入长度最长 512K 的长上下文数据，全局 batch size 32、恒定学习率 $1e-5$。

SFT 期间的 MTP

我们继续用预训练时那个共享权重的 MTP 头训练 Nemotron 3 Super，以同时保住多步预测带来的精度收益和投机解码带来的推理期收益。具体地，我们训练两个共享参数的 MTP 层，用按 token 计算的 loss 和 0.3 的缩放因子构成一个带缩放的辅助损失，优化这个组合目标。

3.1.1 数据

我们从 Nemotron 3 Nano 的 SFT 数据集里复用以下几个：Chat、Infinibyte 和 Formal Proofs。我们用新的 teacher 模型（DeepSeek v3.2、Kimi K2）刷新了以下几个：Competition Math、Competition Code、Conversational Tool Use、Multilingual、Science。下面我们描述新增或大幅改动的 SFT 数据集。

软件工程。我们从真实的 GitHub issue 出发整理了一批编码任务数据集，用来训练 Nemotron 3 Super 的自主软件工程能力，包括代码探索、任务追踪、issue 复现和 bug 修复。我们使用 SWE-Gym、R2E-Gym 和 SWE-rebench 数据集里的 issue 与容器化执行环境。对 R2E-Gym，我们用 Qwen3-Coder-480B-A35B-Instruct 重新生成问题陈述。我们以 Qwen3-Coder-480B-A35B-Instruct 为 teacher 模型，从 OpenHands agent harness 蒸馏轨迹。

Agentic 编程。

Figure 13：Agentic 命令行界面（CLI）数据集构造与训练流水线。四层分别是：种子任务生成（用户 CLI 操作的种子集 → NeMo Data Designer 生成 20k query → GPT-OSS-120B 做 LLM Judge 任务过滤 → 15k 合成任务外加 AGENTS.md 规格）、任务整合（3k SWE 任务与 10k Web 开发任务并入统一任务池）、交互录制（用 Qwen 3 Coder 480B、Minimax M2.5 等 agentic LLM 执行，录制 Codex、OpenCode、Qwen Code CLI、Stirrup 上的 CLI 交互）、后处理（归一化为 OpenAI 格式并带上工具定义，供大规模 SFT 使用）。

随着 Agentic 命令行界面（CLI）工具的出现，软件开发的格局发生了实质转变，从 2021–2023 年的「自动补全」时代走进了自主执行的时代。伴随 Claude Code、OpenCode 和 OpenAI 的 Codex 等 harness 的大幅改进，模型现在有能力充当活跃的数字协作者，具备多步推理、长程执行和端到端任务编排的能力。

我们建立了一套基础的种子任务集，设计目标是复现 agentic CLI 里常见的、由用户发起的操作。完整流水线见 Figure 13。我们用 NeMo Data Designer 从一个含 24 种典型动作的分类体系出发，生成了约 2 万条 query。随后我们在 LLM-as-a-Judge 框架里用 GPT-OSS 120B 过滤掉那些引用已有代码库、或者要修改现存文件的任务。这一缓解措施确保模型不会试图在空目录里做修改操作——那种情形常常在失败的执行循环里导致重复且耗尽的工具调用。得到的数据集包含约 1.5 万个以直接合成解答为中心的任务。为了进一步增强生成输出的多样性，我们给每个任务配了一份补充的 markdown 规格，等价于一个 AGENTS.md 文件。这些文档施加了额外的约束和架构要求，有效地收窄了设计空间，逼 agent 给出更复杂、更多样的解法。

由于我们剔除了所有需要已有代码库的任务，我们又用约 3000 道来自 SWE 任务的题目来扩充这个任务集——这些题很难，并且自带已有仓库和特定的 git hash commit。我们在已有 issue 陈述之前加了一段简单的 prompt，说明执行环境里没有安装库，因此应当避免执行单元测试。这是一个有意识的决定，目的是大幅减少支持每个 SWE 任务基于容器的逐样本执行所需的工程量，减少工具调用次数，并避免多轮单元测试执行带来的巨大工具输出。这也进一步放松了对 agent 解决 issue 的约束，因为没有 SWE 专用的 prompt 引导 agent 去解题。最后，我们以一个含 100 个细粒度任务的分类体系为种子，合成了 1 万个 Web 开发任务，并施加 LLM-as-a-Judge 剔除需要已有仓库的任务。我们对这些任务不加限制，但只提供一个 Node.js 环境，期望 agent 自行搭好并安装所有依赖和插件。

把这些任务集应用起来，我们从 Qwen-3-Coder-480B 和 Minimax M2.5 这类高性能开源 agentic LLM 蒸馏——记录它们与各种 CLI 环境（比如 Codex、OpenCode、Qwen Code CLI 和 Stirrup）的交互。这些交互轨迹随后被过滤、归一化成带各种工具定义的标准 OpenAI message 格式，用于大规模 SFT，以有效地把 agentic 操作知识嵌进模型。对每一个 Agentic CLI，我们研究其存在且常被使用的各项能力。我们把同一批任务集应用到不同能力上，比如 Agent Skills、工具限制（只允许 bash 执行）、向用户提澄清问题、单步与多步规划、静态与动态多轮对话、以及并行工具调用——具体取决于那个 CLI 能否容纳这些能力。

长上下文。我们用一条更完整的合成数据流水线扩展了 Nemotron 3 Nano 的长上下文 SFT 数据集。为了改进长上下文的多文档推理，我们用预训练配比里的长序列（包含书籍、论文、财报、代码仓库等）构造了一个合成 SFT 数据集。我们先按主题/领域对这些文档聚类，再把相关文档拼接起来达到目标序列长度，比如 128K、256K 或 512K token。对每个长上下文样本，我们用一个 LLM 生成一个或多个 QA 对。prompt 要求问题必须涉及跨文档或跨小节的跳转，确保信息是分散的而不是局部的。它严格强制多跳推理，要求至少 4 到 7 个不同的检索或推理步骤。这些步骤要求做计算或逻辑处理，防止简单的复制粘贴，并且经常包含明确的格式化指令。接着，我们为每个「上下文—问题」对生成 8 条独立的推理轨迹。我们施加语义多数投票来给答案分组，或按精确匹配、或通过一个 LLM judge。从得到的多数组里，我们选出推理轨迹最短的那个答案。此外，我们还生成七种合成推理任务，以提升模型按顺序、从左到右处理上下文的能力。具体地，把合成的片段（用 Qwen3-235B-A22B-Thinking-2507 生成）拼接起来构成长输入上下文。thinking 轨迹则由基于规则的推理步骤串起来构造，每一步都包含输入上下文里的相关摘录和追踪用的元数据，比如与 query 相关的片段出现频次。我们还通过拼接 Nemotron-Personas-USA 的记录来构造长上下文样本以达到所需序列长度。问题被设计来强调跨记录的多跳推理和信息聚合。上下文、问题和答案用预定义模板格式化，ground-truth 答案由在底层记录上执行 SQL 查询得出。

金融推理。为了构造一个大规模的金融推理训练语料，我们采用基于模板的合成数据生成（SDG）流水线，把一个人工整理的种子集放大成数十万个有依据的问答对。流水线从 SecQue benchmark 取用 565 道专家撰写的种子题；SecQue 是一个锚定在 SEC 10-K 和 10-Q 文件上的金融分析问题数据集。这些种子在标普 500 公司¹⁷和财年（2019–2024）上做组合式扩展，其中对比类问题被限制在同一 GICS 子行业内的公司对之间，以保持语义连贯。GPT-OSS-120B 对每个模板实例做改写，每种组合产出最多三个不同的表述。得到的问题按 SecQue 原始元数据映射到相关的 SEC 文件小节，对应文档被转换成 markdown 并施加可配置的 token 上限。答案生成上我们采用 GenSelect 策略：用 GPT-OSS-120B 以不同随机种子为每题采样五个候选答案，再由一个更大的 judge 模型（Qwen3-235B-A22B）基于数值准确性、金融方法论和逻辑严谨性选出最好的回答。接着一个更小的模型（Qwen3-30B-A3B）把每一对分类为 ANSWERABLE 或 UNANSWERABLE，只保留那些包含完整、有实质内容的回答的样本。在做 supervised fine-tuning 之前，SDG 输出还要经过基于百分位的异常值移除和去重。最终数据集包含 366,243 个带推理轨迹的金融问答对。

CUDA。我们用一条基于 DeepSeek-R1 和 GPT-OSS-120B 的合成数据生成流水线，构造了一个包含 10 万个样本的大规模合成 CUDA 数据集，覆盖 kernel 生成、修复和优化。种子题目来自流行的开源库、NVIDIA 库的 API 接口，以及 BackendBench。这些种子被用来生成形如（PyTorch 参考实现，CUDA C++ kernel）和（自然语言规格，CUDA C++ kernel）的元组，每个都附带推理过程。对每个种子条目，会生成多个候选 kernel，并在一个内部的 CUDA 评测环境里严格验证正确性。通过验证的 kernel 再按性能排序，保留性能最高的那个。此外，我们从一个内部的 CUDA agent 收集轨迹，产出形如（PyTorch 参考实现，有缺陷的 CUDA C++ kernel，错误信息，修正后的 CUDA C++ kernel）和（PyTorch 参考实现，慢的 CUDA C++ kernel，Nsight Compute 日志，优化后的 CUDA C++ kernel）的样本。利用公开文档和官方代码示例，按与 CUDA-C 数据相同的表述方式，我们还生成了额外的 PyTorch 参考实现以及对应的 CUDA 库实现（带推理链），以及对齐的自然语言规格。这些库包括 Thrust、CUB、cuBLAS、cuDNN、cuSPARSE、cuRAND 和 cuSOLVER。

安全。相对 Nemotron 3 Nano，我们通过把一个稳健的 prompt 库和一套两阶段的合成回复生成策略结合起来，显著增强了安全框架。在保留 Nemotron Content Safety v2、Gretel Safety Alignment v1、Harmful Tasks 和 Red-Team-2K 的核心 prompt（覆盖内容安全与常见越狱手法）的同时，我们新增了针对过度拒答、人群偏见和版权复现的合成 prompt。我们也扩大了越狱策略的覆盖面，以更好地捕捉新兴的对抗手法，包括间接 prompt 注入攻击。

我们相对 Nemotron 3 Nano 的主要进步是一个明确的回复策略（response policy）框架。对每个 prompt，回复策略是从 prompt 元数据、其标注的安全类别，以及一组轻量辅助分类器的预测中推断出来的；这些分类器检测诸如自伤风险、人群针对性，或是否嵌入了对抗指令这类属性。我们把这个决策过程建模成一个多类分类问题，每个类别对应一种符合安全准则的回复模式。这些回复模式规定模型应该提供求助热线之类的支持资源、给出带简短解释的拒答，还是回答请求中善意的那部分而忽略恶意内容。这确保了回复在多样的安全敏感场景下都是安全的、合乎语境的、一致的。

沿着 deliberative alignment 框架，我们采用两阶段生成流程，其中推理轨迹和最终回复被分别整理，但都与我们的回复策略保持一致。第一阶段，我们构造一段简洁的推理轨迹，引导模型反思该 prompt 的安全属性，明确指出这个请求为什么可能不安全或与政策相关，以及回复应当受哪些约束。第二阶段，我们基于这段推理轨迹生成最终回复，确保它遵守预定义的回复策略和行为准则。这种结构上的分离鼓励模型对安全准则做审慎的反思，同时产出一致、合规、合乎语境的回复，让最终回复在遵守安全政策的同时尽量少地提及这些政策本身。最后，我们施加一个内容审核分类器，过滤掉任何被标记为不安全的回复，为对齐安全目标提供额外的保障。

搜索。为了改进搜索能力，我们用 NeMo Data Designer 生成了一个合成的搜索 agent SFT 数据集。流水线从构造锚定在 Wikidata 知识图谱上的种子 prompt 开始：我们用 SPARQL 在约 25 个已验证的实体类别（城市、大学、电影、化学元素等）里查询连接良好的枢纽实体，然后在图上做 4–8 跳的随机游走，并通过停止节点列表、反元关系排除和最小路径长度阈值过滤掉退化的路径。每条有效游走产出一个起始实体、一串事实关系和一个最终答案实体。

Data Designer 随后分三个阶段处理这些种子：（1）draft 阶段把结构化的知识图谱游走转成一个自然语言多跳问题，（2）混淆阶段重写问题以隐藏中间实体、消除面包屑式的链条——产出「搜索谜题」式的 query，求解者必须自己独立分解问题，（3）agent 阶段由 MiniMax-M2 通过 Tavily¹⁸ 的 MCP 搜索工具发起网络搜索来求解被混淆的问题，产出一条带支撑 URL 的、有依据的搜索轨迹。得到的每条 SFT 记录都是一段多轮对话，其中 assistant 轮把 chain-of-thought 推理与结构化工具调用交错，tool 响应轮以 JSON 返回搜索结果，在平均每条轨迹 12 次工具调用的过程里保住完整的 Thought–Action–Observation 循环。最后一个结构化输出阶段把 agent 的原始回复归一化成一个经过校验的 JSON schema。

终端使用。用于增强终端能力的数据集遵循 Nemotron-Terminal 中描述的双流 Terminal-Task-Gen 方法，总计 84,864 个样本。这条流水线把对已有高质量数据集的改造与锚定在一个完整终端技能分类体系上的合成任务生成结合起来。来源分布为 68,924 个合成样本、8,125 个来自 Nemotron-Cascade-Math 的样本和 7,815 个来自 Nemotron-Cascade-Code 的样本。轨迹构造上，我们用 DeepSeek-V3.2 作为主引擎，通过一个 agentic 的执行—反馈循环，在隔离的 Docker 化环境里生成分步的解题轨迹。所有样本都用 Terminus 2 agent 框架作为底层脚手架生成，它提供了一套统一的终端工具和结构化的交互协议，以在长程轨迹上维持一致性和质量。

多语言。我们的多语言数据把英文 SFT 样本的合成翻译与一个句级平行语料结合起来，以改进机器翻译。我们复用 Nemotron 3 Nano 的逐行翻译流水线，用 Qwen2.5-Instruct-14b 翻译成六种语言（德语、西班牙语、法语、意大利语、日语和中文）。翻译之后，我们施加过滤以移除语言错误的样本和其他常见失败模式。我们观察到一个反复出现的现象：翻译会破坏 prompt 规格与答案格式之间的对齐——这种一致性在英文数据里通常是保住的。这种不匹配在初步测试中导致了指令跟随失败。为了缓解，我们引入了一个用 Qwen3-4B-Thinking-2507 做的轻量后编辑步骤来自动恢复格式合规性。我们还用额外的中文 $\leftrightarrow$ 英文对扩充了平行语料，并排除了此前会拖累后训练表现的极短样本。

结构化查询语言（SQL）。为了改进 Nemotron 3 Super 在企业 SQL 工作负载上的表现，我们用 NeMo Data Designer 生成了一个合成的 text-to-SQL 数据集。数据集包含 96.5k 条记录，跨 MySQL、PostgreSQL 和 SQLite，覆盖 60 个行业门类、约 700 个领域主题和 90 个 SQL 概念分桶（从基础 SELECT 到递归 CTE、窗口函数和地理空间查询）。每个样本把一段自然语言 prompt 和一份完全合成的数据库 schema 上下文与一条目标 SQL 查询配对。为了提升稳健性并模拟生产数据库在现实中的杂乱，流水线会往数据库上下文里注入干扰表和干扰列。具体地，相关但无关紧要的表和列被加进数据库上下文，逼模型学会忽略无关的 schema 元素。prompt 的多样性沿三个轴控制——指令风格（命令式、陈述式、疑问式、语境式、缩略式）、语言语域（正式、口语、技术、学术、直接）和礼貌程度——从而产出自然而多样的用户请求。最终这 96.5k 条记录是 Data Designer 用逐方言的语法校验器和五个 LLM-as-a-critic judge 从一个更大的数据集里校验和过滤下来的。

对话式工具使用。大规模的专门化工具使用训练数据已被许多模型采用来提升 agentic 能力。对 Nemotron 3 Super，我们通过一条完全合成的六阶段生成流水线来放大对话式工具使用数据：

1. Domain Generation：用模型采样合成领域，迭代地把初始生成扩展成专门化的子领域。
2. Policy and Tool Generation：采样客服政策和相关工具，通过自我精炼迭代改进；用 few-shot prompting 和 LM-as-a-Judge 做质量过滤，以维持风格和格式。
3. Scenario Generation：为每个政策设定生成合理的用户 persona、背景信息和咨询问题。
4. Trajectory Collection：对每个「政策—场景」对，在一个模型扮演的 agent、用户和环境之间模拟 16 段客服交互。
5. Verification：用 LM-as-a-Judge 在结果层面和过程层面评估轨迹。
6. SFT Data Selection：为 SFT 选出成功的轨迹，并通过丢弃全成功或全失败的场景来做难度过滤。

Figure 14：Nemotron 3 Super 所用的专门化对话式工具使用 SFT 数据的合成数据生成流水线概览。六个阶段依次为：1. Domain Generation（渐进式子领域采样）、2. Policy and Tools（迭代自我精炼）、3. Scenario Generation（每个政策放大场景）、4. Trajectory Collection（每条轨迹多次 rollout）、5. Verification（结果与过程层面的判定）、6. SFT Selection（难度过滤）。

流水线的可视化见 Figure 14。我们在上述流水线的不同环节使用 Qwen3-235B-A22B-Thinking-2507、Qwen3-32B、Qwen3-235B-A22B-Instruct-2507、deepseek-r1-0528、DeepSeek-V3.2 和 gpt-oss-120b，产出了跨 838 个领域的 279,116 段对话。相比 Nemotron 3 Nano 用的 5 个领域、15,588 段对话，这是一次实质的放大。

通用工具使用。更宽泛的通用工具调用合成数据流水线从构造多样的工具集开始，来源包括 ToolEyes、API-Bank、UltraTools、AutoTools、xLAM、Glaive-Function-Calling-v2、Toucan-1.5M，以及自行编写的工具，它们构成下游合成任务生成的基础。一条工具调用轨迹通过锚定在这些工具集中的一个或多个上来模拟。轨迹模拟涉及一个 LLM 扮演三个角色——User（User-LLM）、Assistant（Assistant-LLM）和 Tool Environment（Tool-LLM）。User-LLM 被喂入选定的工具集、一个从 Nemotron-Personas-USA 采样的 persona，以及一个工具调用场景（单轮、多轮或多步）。User-LLM 先按工具调用场景的引导设计一个任务，这个任务要与选定的 persona 相关且能被选定的工具集解决。Assistant-LLM 通过产出工具调用并回应工具执行结果，在一轮或多轮里尝试解决这个任务。Tool-LLM 负责根据 Assistant-LLM 生成的工具调用和被调用的工具，产出一个模拟的工具执行结果。Tool-LLM 的 prompt 里带一份评分细则，帮它识别工具调用中的语法和语义错误，以及原始用户 query，这样在工具调用成功时工具结果能被放到语境里。为了保证准确性，我们采用了轮级和轨迹级的 judge，做法类似专门化工具调用数据的生成。轮级 judge 还搭配了基于规则的校验，以确保工具调用的正确性。我们用 DeepSeek-v3.2 和 GLM-4.7 放大这条流水线，造出了一个含 150 万条多样工具调用轨迹的数据集。

整体的通用合成工具调用数据流水线可视化见 Figure 15。

Figure 15：Nemotron 3 Super 所用通用工具调用数据的流水线概览。第一层是种子与采样（144 个工具集，Nemotron-Personas 的 100 万条 profile 做 persona 采样，对话类型分单轮/多步/多轮，主题采样以对话类型为条件，工具子集不超过 15 个）；第二层是 query 生成与门控检查（LLM 从 persona、工具和主题生成 query，再由 LLM judge 做通过/不通过的门控）；第三层是多 agent 模拟（User Agent、Assistant Agent、API Response Simulator 构成回路，Inline Judge 逐轮评估，Tool Verifier 对着 JSON schema 校验工具调用），最后由 Trajectory Judge 评估整段对话。

3.1.2 SFT 数据配比

我们通用的阶段 1 SFT 数据配比见 Figure 16（所有未列出的数据集合计占配比不到 1%）。我们在总计超过 700 万个样本上训练。阶段 2 我们取阶段 1 配比的 85%，并用 256K 和 512K token 的长上下文数据扩充。相比 Nemotron 3 Nano，我们显著提高了 agentic 任务的体量和多样性，并给了它在配比中大得多的占比。

Figure 16：Nemotron 3 Super 的 SFT 数据配比。

3.1.3 推理控制

Nemotron 3 Super 训练了三种推理模式：reasoning-off、regular 和 low-effort。low-effort 推理模式是新加的。regular 和 low-effort 推理模式都可以选择与推理期的预算控制配合使用。这些控制的组合提供的灵活性覆盖了精度—效率取舍的整个谱段，以满足客户在各种应用场景下的需求。

low-effort 推理模式是在 SFT 阶段通过加入由 GPT-OSS-120B 在其 low-effort 模式下生成的训练样本引入的。这些 low-effort 训练样本覆盖数学推理、STEM 问答和指令跟随任务，按样本数计占整体 SFT 数据的 2%。low-effort 模式随后在下一节将讨论的 RL 阶段被进一步优化。

reasoning-off 模式和推理期预算控制的 SFT 配方与 Nemotron 3 Nano 类似，有几处差别。我们为 reasoning-off 模式随机剥掉 3% 样本的推理轨迹。在主 SFT 阶段之后，我们为推理期预算控制额外加了一个 350 步的短半 on-policy SFT 阶段，在其中我们从模型收集 rollout，并把 12% 的推理轨迹截断到随机的推理预算上。

3.2 强化学习

Nemotron 3 Super 后训练的 RL 阶段由三个阶段构成，之后再跟一个 MTP healing 阶段，如 Figure 12 所示：

• 阶段 1：多环境 RLVR（RL from Verifiable Rewards）（§3.2.1）。这是主要的训练阶段，我们在完整的环境集合上联合优化 Nemotron 3 Super。在统一的混合里训练能让每次 RL 更新都被完整的环境分布告知，并有助于防止训练过程中单个任务上的回退。
• 阶段 2：面向端到端软件工程任务的 SWE-RL（§3.2.2）。我们把 SWE-RL 作为独立阶段来跑，因为 SWE 的 rollout 生成起来慢得多，而且通常需要更长的上下文，与短程环境共同训练时会造出吞吐瓶颈。把这个阶段隔离出来使我们能够为长程、长上下文的轨迹调 rollout 和 batching 设置。
• 阶段 3：RLHF（§3.2.3）。我们最后施加 RLHF 作为一个独立阶段，以改进指令跟随行为、稳健性和整体交互质量。
• 阶段 4：MTP Healing。在这个阶段我们只训练 MTP 头，其余权重全部冻结。我们复用 RLVR 的 prompt，用与 SFT 类似的负对数似然 loss 在生成的回复上训练 MTP 头。我们发现这个阶段显著改进了 MTP 的精度。

下面我们描述这些阶段，包括训练算法、数据和系统设置。

3.2.1 阶段 1：多环境 RLVR

我们采用与 Nemotron 3 Nano 类似的统一 RLVR 策略，但显著扩大了环境数量。我们发现同时在所有环境上训练能带来稳定的增益，而单环境训练会导致其他 benchmark 上严重的回退。

我们的 RLVR 设置包含 21 个环境，覆盖多样的领域，包括数学、代码、STEM、安全、chat、指令跟随、长上下文能力、谜题和各种 agentic 任务。数据配比和课程上我们采用与 Nemotron 3 Nano 类似的做法：先过滤掉 SFT 模型能一贯答对的 prompt，然后把剩下的样本按难度课程排序。这套方法的更多细节见 Nemotron 3 Nano。

低努力度推理（low-effort）

在多环境 RL 阶段中，我们把一部分 prompt 转成 low-effort 模式。对每个 low-effort prompt，一次 rollout 的 reward 会被调整为正确性和生成 token 数两者的函数。low-effort 的 prompt 混合起初由数学、STEM 问答和竞赛编程 prompt 的子集构成，合计占所有 RL prompt 的 2%，后来缩减为数学和 STEM 问答的子集，只占 RL prompt 的 1%。对数学和 STEM 问答，我们随机采样一个子集。对竞赛编程，我们有一批从 SFT 数据里留出的编程题，low-effort 编程 prompt 只从这个留出集里采样。经验结果表明这个数据策略提供了足够的泛化，且 low-effort 模式在多环境 RL 过程中在一大批 benchmark 上都得到了改进。

RLVR 数据

相比 Nemotron 3 Nano，我们显著放大了 RL 数据。下面我们描述多环境 RL 里用到的 RL 数据集。大部分 RL 训练环境已在 Nemo Gym 里开源。总计我们在 21 个环境和 37 个不同的 RL 数据集上训练。

• 数学。我们用与 Nemotron 3 Nano 相同的竞赛数学题。对这个数据集，我们既在带 Python 执行工具的条件下训练，也在不带的条件下训练。我们还引入了一个新的形式化证明验证环境。
• 代码。我们在来自 Nemotron 3 Nano 和 Nemotron-Cascade 的竞赛风格代码数据上训练。我们也在软件工程任务的单步补丁生成上训练，为下一阶段的端到端 RL 做准备。
• STEM。我们纳入 Nemotron 3 Nano 的 STEM 数据集，并新增了人工整理的更具挑战性的科学问题。
• 指令跟随。我们用一个新的 multi-challenge 数据集扩充 Nemotron 3 Nano 的指令跟随数据。在这个设置下，agent 必须遵循复杂的用户指令，reward 由一份预先确定的评分细则计算。
• 安全。我们加了两个环境：一个针对减少安全相关 prompt 上的过度拒答，一个针对提升对越狱的稳健性。对越狱，种子 prompt 来自我们的 SFT 数据；为了在 RL 中浮现出更难的攻击，我们按 PAIR 的做法施加一条迭代攻击流水线，去攻击一个只做过 SFT 的早期 checkpoint，收集攻击成功率高的改造后 prompt。
• 长上下文。我们用 Nemotron 3 Nano 引入的同一个长上下文环境。
• Agentic 工具使用。除了 Nemotron 3 Nano 的工具使用环境，我们新增了聚焦对话式工具使用和终端使用的环境。
• Reasoning Gym。我们用 Reasoning Gym 训练，使模型能在一套多样的推理任务上学习。

3.2.2 阶段 2：面向软件工程的端到端 RL

在 SWE-RL 阶段，我们改进模型在多样 harness 下自主解决 GitHub issue 的能力。每次 rollout 启动一个装有目标仓库的 Apptainer 容器，跑一个 OpenHands agent 循环产出代码补丁，再拿它对着 ground-truth 测试评估，得到一个二元 reward。为了工具多样性，我们在 OpenHands 内部实现了 OpenCode 和 Codex 的 agent 类，匹配 Claude Code 和 Codex CLI 的工具格式，从而复用同一个 harness 而在训练时变化工具和 prompt。这种多 harness 训练改进了模型在推理期跨所有目标 harness 的泛化和表现。

3.2.3 阶段 3：Reinforcement Learning from Human Feedback

RLHF 上我们采用与 Nemotron 3 Nano 类似的做法，训练一个大的 GenRM 模型在 RL 期间提供监督。我们训练的不是普通的 GenRM，而是一个遵循原则（principle following）的 GenRM。这些原则让我们能在身份认同和安全这类重要领域上引导 Nemotron 3 Super 的行为。和 Nemotron 3 Nano 一样，我们用 Qwen3-235B-A22B-Thinking-2507 作为训练 GenRM 的初始化。

训练 GenRM 我们用 Helpsteer 3 数据集、lmarena-140k 数据集里商用友好的子集，以及一些更近期收集的人类偏好数据。与 Nemotron 3 Nano 不同，我们在整个多环境 RL 阶段都用我们的 GenRM 训练，并且在后训练最后还单独跑了一个只做 RLHF 的阶段。

3.2.4 算法

我们用异步 GRPO 设置，其中训练和推理被解耦到不同的 GPU 设备上。推理 worker 持续生成轨迹，存进一个 rollout buffer。一旦收集到足够的轨迹凑成一个 batch，这个 batch 就被送给训练引擎做一次模型更新。只要有新的模型版本可用，我们就把更新后的权重推给推理 worker。由于权重更新可能发生在 rollout 中途，单条轨迹可能包含由不同模型版本产生的 token。我们在推理 worker 上更新模型权重后不重算 KV cache。为了避免过大的 policy lag（它可能导致精度退化），我们限制推理 worker 最多落后最新模型版本一步。

为了稳定训练并最小化训练—推理不匹配和 policy lag 带来的 off-policy 效应，我们对由训练侧和推理侧 logprob 计算出的 importance sampling ratio 做掩码。

在多环境 RLVR 里，我们每步采样 256 个 prompt，每个 prompt 生成 16 条回复。我们以 4096 的 batch size 训练，对应每次 rollout 一次梯度更新。我们从 49K token 的最大生成长度开始训练，后来提到 64K。

Agentic RL —— PivotRL：面向长程 agentic 能力的后训练在效率和精度之间存在张力。这里的长程指的是需要与环境多轮交互的任务，比如对话式工具使用、代码编辑、终端交互和网页搜索。SFT 对这类任务来说便宜又简单，但它常常损害目标领域之外（OOD）的表现。端到端 RL 在很大程度上避免了这个结果，但它昂贵，因为每次更新都要求在复杂环境里做在线交互式 rollout。为了解决这一点，在 Super 的后训练里我们采用了 PivotRL。

PivotRL 是一种 assistant 轮级别的 RL 方法，它通过在 RL 期间复用离线的 SFT 专家轨迹来处理这个取舍。它把训练聚焦在那些 SFT 轨迹里信息量大的轮次（称为「pivot」）上——也就是策略对下一个动作有不确定性的地方——并用一个领域适配的 reward 让策略的动作去匹配专家动作，这样模型做出相似动作也能拿到 credit，而不必和专家动作完全一致。我们注意到这个方法大幅提升了我们 agentic RL 的效率，而不会遇到 SFT 那样的 OOD 退化问题。

我们把 PivotRL 应用于所有 agentic 领域：包括 Agentic 编程、搜索、终端使用和对话式工具使用。我们很快会有一份更详细的手稿。

3.2.5 基础设施

当下模型后训练前沿的 RL，其特征就是把任务或环境的多样性扩大，让模型学到越来越通用的能力。把 RL 扩展到多环境要求一个高性能、可扩展、标准化的接口来协调 rollout 与训练。为了用一套标准框架同时应对扩展性能和可扩展性这两个挑战，我们采用 NeMo Gym 和 NeMo RL 来支持在许多不同环境/验证器上做大规模 RL。

NeMo Gym 基于「服务器」这个抽象。Gym 里有三类核心服务器：（1）agent、（2）model 和（3）resource。一个 agent 服务器实现某个 RL 环境的 rollout kernel。一个 model 服务器包装 vLLM 之类的推理引擎，提供 prompt-response API，同时仔细保留 RL 所需的 token、推理 log-prob 数据和元数据。一个 resource 服务器提供验证 API，从给定 rollout 计算 reward。

我们 Nemotron Super 3 的 RLVR 实验全部基于 NeMo RL 和 NeMo Gym 的集成基础设施：NeMo RL 充当 RL 训练循环的控制器，用 Megatron-Core 做大规模模型训练，并把所有 rollout 都路由经 NeMo Gym 和 vLLM。

NeMo RL 和 NeMo Gym 用 ray 做编排和资源管理，并把 ray cluster 部署在 SLURM 上。Megatron 训练 worker、vLLM 生成 worker、Gym 环境和 judge 模型全部被调度到同一个 ray cluster 上。

异步 RL 基础设施：所有 RL 阶段都用了异步 RL，其中生成可以独立于训练进行，通过牺牲 rollout 的 on-policy 程度来换取训练效率。这些训练用的是一步 off-policy，其中每个训练步都被预留给一个未来的训练步，因此没有浪费的 rollout。训练和生成不共置，这简化了部署，也避免了在异步训练与生成 worker 之间编排复杂的内存管理。

所有异步 RL 运行还用了 in-flight 权重更新，其中训练可以更新生成 worker 的权重，而不必等剩下正在进行的 rollout 完成。结果是单条 rollout 可以带有来自不同新旧程度策略的 token 和 log 概率。启用 in-flight 权重更新对加速异步 RL 训练至关重要。我们在 in-flight 权重更新之后不重算 KV cache。

韧性：当我们扩展到 1k GPU 时，遇到了若干在更小作业形态下没有观察到的、导致间歇性失败的问题。这些问题分两类：（1）硬件相关和（2）软件相关。

我们观察到若干硬件问题需要整个作业重启，因此也做了几项优化来改进启动时间：（1）把所有初始化并行化，（2）预取所有虚拟环境和二进制文件，（3）利用 vLLM 和 flashinfer 等上游仓库里的缓存。

并行初始化加剧了后训练软件栈里端口绑定上潜伏的竞态条件，这成了一个重要的失败点。后训练软件的若干组件需要端口：（1）Ray 控制平面、（2）vLLM worker 与 OpenAI 服务器、（3）TCP rendezvous、（4）NeMo Gym 服务器。由于一个节点上需要端口的进程数量很多，我们在 1K GPU 规模上频繁撞上端口冲突，而这些全都是 time-of-check to time-of-use（TOCTOU）竞态条件。我们观察到的模式是：某个组件检查一个端口是否可用但没有排他地占住它，等到它（或它通知的另一个进程）尝试绑定时，另一个进程已经把这个端口拿走了。

SWE-RL 基础设施：在软件工程任务上训练模型要求一个 gym 环境，它能执行数百个并发的 agent—代码库交互，每个都在隔离的沙箱里，并返回一个由真实测试执行导出的 reward 信号。在 Nemo-Gym 的 SWE-RL 环境里，每次 rollout 启动一个装有目标仓库的 Apptainer 容器，跑 OpenHands agent 循环产出代码补丁，再跑 ground-truth 测试算出一个二元 reward。Rollout 用 Ray 以 SPREAD 调度策略分布到各节点。下面我们描述这个环境的关键组件。

• 用 Apptainer 做容器执行。我们集群上没有 root 权限，这限制了用 Docker 做容器隔离。取而代之，我们用 Apptainer（前身是 Singularity）把每个 SWE 任务实例跑在一个预构建的容器镜像（.sif 文件）里，通过一个可写的 tmpfs overlay 提供文件系统隔离，同时共享宿主内核。
• OpenHands agent 循环。agent 循环由一个改造版的 OpenHands 执行，管理每次交互的完整生命周期：初始化运行时、呈现问题陈述、跑 agent 的 step 循环直到可配置的轮次上限、抽出 git 补丁，然后清理。agent 通过 bash 命令和文件操作，经一个基于 tmux 的 session 与仓库工作区交互。
• 内存管理。由于 Apptainer 容器共享宿主内存和进程（不像 Docker 有 cgroup 隔离），失控的 agent 进程会造成影响整个节点的 OOM。我们实现了一个内存看门狗守护进程，监控 tmux 进程树的聚合 RSS，在超过可配置上限时主动杀掉 pane 内的进程，同时保住 tmux server 存活以便优雅恢复。
• 命令黑名单。Apptainer 共享内核的特性意味着一个 agent 发出 killall 或 pkill 可能会终止同一节点上的训练进程或 vLLM 服务器。一个基于正则的命令黑名单在执行前截住并阻断危险命令，返回带更安全替代方案的有用错误信息。
• Harness 多样性。为了在训练时增加工具多样性而不必构建各自独立的 harness 集成，我们在 OpenHands 内部实现了 OpenCode 和 Codex 的 agent 类，匹配它们各自外部 harness（Claude Code 和 Codex CLI）的工具输入/输出格式。这两个 agent 都接进 OpenHands 已有的运行时和对话记忆，继承了容器管理和 observation 处理。
• 序列化。我们把 Python 标准的 json 换成 orjson 来序列化 gym 与 model server 之间的 HTTP 载荷，因为每一轮轨迹都携带 prompt token ID、生成的 token ID 和 log 概率，产生的载荷很大，能从 orjson 基于 Rust 的实现里获益。

3.3 后训练模型评测

Table 5：Nemotron 3 Super 的评测套件。我们与 Qwen-3.5-122B-A10B 和 GPT-OSS-120B 对比。

Benchmark	N-3-Super	Qwen3.5-122B-A10B	GPT-OSS-120B
通用知识
MMLU-Pro	83.73	86.70	81.00
推理
AIME25（无工具）	90.21	90.36	92.50
HMMT Feb25（无工具）	93.67	91.40	90.00
HMMT Feb25（带工具）	94.73	89.55	-
GPQA（无工具）	79.23	86.60	80.10
GPQA（带工具）	82.70	-	80.09
LiveCodeBench（v5 2024-07$\leftrightarrow$2024-12）	81.19	78.93	88.00
SciCode（subtask）	42.05	42.00	39.00
HLE（无工具）	18.26	25.30	14.90
HLE（带工具）	22.82	-	19.0
Agentic
Terminal Bench（hard subset）	25.78	26.80	24.00
Terminal Bench Core 2.0	31.00	37.50	18.70
SWE-Bench（OpenHands）	60.47	66.40	41.9
SWE-Bench（OpenCode）	59.20	67.40	-
SWE-Bench（Codex）	53.73	61.20	-
SWE-Bench Multilingual（OpenHands）	45.78	-	30.80
TauBench V2
Airline	56.25	66.0	49.2
Retail	62.83	62.6	67.80
Telecom	64.36	95.00	66.00
平均	61.15	74.53	61.0
BrowseComp with Search	31.28	-	33.89
BIRD Bench	41.80	-	38.25
Chat 与指令跟随
IFBench（prompt）	72.56	73.77	68.32
Scale AI Multi-Challenge	55.23	61.50	58.29
Arena-Hard-V2	73.88	75.15	90.26
长上下文
AA-LCR	58.31	66.90	51.00
RULER 256k	96.83	96.74	52.30
RULER 512k	95.22	95.95	46.70
RULER 1M	91.64	91.33	22.30
多语言
MMLU-ProX（跨语言平均）	79.36	85.06	76.59
WMT24++（en$\rightarrow$xx）	86.67	87.84	88.89

我们在与 Nemotron 3 Nano 相同的广泛 benchmark 套件和评测栈上评测 Nemotron 3 Super，覆盖通用知识、推理、agentic、指令跟随、长上下文和多语言能力。所有评测结果都通过 Nemo Evaluator SDK¹² 收集，大多数 benchmark 走 Nemo Skills Harness¹⁹。为了可复现，用于评测、经 NVIDIA 的 Nemo Evaluator SDK 打包的 Nemo Skills 开源容器在这里²⁰。除了 Nemo Skills，评测还使用了专用的开源打包容器：Tau-2 Bench（默认 prompt）、Terminal Bench Hard（48 个任务）、ScaleAI Multi Challenge 多轮指令跟随、Ruler。评测设置的更多细节可以在 Nemo Evaluator SDK 的 configs 目录里找到¹⁴。以下 benchmark 还没有接入我们的开源工具，对它们我们用了官方开源实现或内部脚手架（后者我们计划将来开源）：SWE Bench Verified（OpenHands）、SWE Bench Multilingual（OpenHands）、BrowseComp with Search（内部实现，配 Serp API）、Terminal Bench Core 2.0（Harbor）。

推理能力

我们报告 AIME 25、HMMT Feb 25、GPQA、LiveCodeBench v5、SciCode 和 HLE 上的结果。在所有 benchmark 上 Nemotron 3 Super 与 GPT-OSS-120B 具有竞争力，同时略微落后于 Qwen-3.5-122B。

Agentic 能力

我们报告 TerminalBench（hard 子集和 v2 集合）、SWE-Bench（OpenHands、OpenCode、Codex 和 Multilingual 集合）、TauBench V2（Airline、Retail、Telecom 及其平均）和 BrowseComp 上的结果。对 Browsecomp，我们的 harness 大量借鉴了 GPT OSS 一起放出的浏览器工具，并且我们不使用任何上下文管理策略。SQL 上我们评测 BIRD benchmark 的 dev 集（1,534 个样本，SQLite，执行准确率）。在所有 agentic benchmark 上，Nemotron 3 Super 优于或持平 GPT-OSS 120B，并在部分 harness 上与 Qwen 3.5 122B 有竞争力。

Chat 与指令跟随能力

我们报告 IFBench、Multi-Challenge、Arena-Hard V2 上的结果。在所有 benchmark 上 Nemotron 3 Super 与基线模型具有竞争力。

长上下文能力

我们报告 Ruler（每个任务 100 个样本）和 AALCR 上的结果。

多语言能力

我们在 MMLU-ProX 和 WMT24++ en$\rightarrow$xx 上测量多语言能力。Nemotron 3 Super 在两个 benchmark 上都追平或超过基线模型。

与 GPT-OSS-120B 和 Qwen-3.5-122B-A10B 对比时，只要有官方报告的数字我们就用官方数字；没有的时候，我们遵循 Nemotron 3 Nano 报告的做法，或者从可靠的公开汇总处取值（在与官方协议一致的前提下），或者由我们自己按官方评测设置算出分数。

4 面向推理的量化

我们用 Model-Optimizer²¹ 做训练后量化（PTQ），把权重和激活量化，产出两个高效的部署 checkpoint：给 Hopper 的 FP8（W8A8）和给 Blackwell 的 NVFP4（W4A4）。

4.1 Nemotron 3 Super FP8 checkpoint

FP8 PTQ 校准上，我们用了后训练 SFT 数据集里 256 个样本、65536 上下文长度的一个小子集。FP8 量化上，我们量化了 MoE GEMM（路由的和共享的都算）和 Mamba 线性层。我们也把 KV Cache 保持在 FP8，而 Mamba 状态 cache 为了加速被量化到 FP16。这个 checkpoint 中各算子的精度分配总结在 Table 6。

Table 6：FP8 checkpoint 与 BF16 基线的精度设置对比。

配置项	FP8 checkpoint	BF16 基线
Embedding	BF16	BF16
Attention GEMM（QKV 与输出投影）	BF16	BF16
KV Cache + Attention BMM1	FP8	FP8
Attention BMM2	BF16	BF16
MoE GEMM（稀疏专家与共享专家）	FP8	BF16
MoE Latent 投影 GEMM	BF16	BF16
Router	FP32	FP32
Mamba GEMM	FP8	BF16
Mamba SSM Cache	FP16	FP32
Mamba 1D Conv	BF16	BF16
输出层	BF16	BF16

4.2 Nemotron 3 Super FP4 checkpoint

FP4 是比 FP8 更激进的量化格式，对 prefill 重的推理负载（比如编码 agent 的部署）尤其有吸引力，因为那里线性层和 MoE GEMM 是主要的性能瓶颈。NVFP4 在 Blackwell GPU 上有原生加速，且精度优于 MXFP4 之类的其他 FP4 格式。推理用的 NVFP4 使用带符号的 E2M1 值，在最后一维上以大小为 16 的 1D 块做逐块缩放。这些逐块 scale 再用一个逐张量静态校准的 FP32 缩放因子量化成 FP8 E4M3。

在基线的 NVFP4 PTQ 配方里，每个逐块 scale 由块内绝对值的最大值决定。我们评估了一系列替代的 PTQ 方法，这些实验的结果见附录 B.1。最好的整体结果来自一个混合的 FP4 配方：权重的逐块 scale 通过最小化权重 MSE 来选取，而激活的逐块 scale 继续用基于 max 的缩放。这个选择既有效又实用。权重量化是离线校准的，所以可以做昂贵的 scale 搜索而不影响运行时性能。激活量化必须在运行时高效地算出来，这让 scale 搜索算法不切实际。基于 max 的激活缩放在运行时性能和量化精度之间提供了不错的折中。

此外，我们有选择地把一些层从 FP4（W4A4）提升到 FP8（W8A8）或 BF16（W16A16）以进一步改进精度。我们用了 Model-Optimizer AutoQuantize²²，一种受神经架构搜索（NAS）启发的方法来推导最优的混合精度分配。AutoQuantize 估计每个算子的敏感度、建模各量化选择的性能代价，然后用一个背包式的优化流程求解最优的逐层分配。它的敏感度指标遵循一个受 Optimal Brain Surgeon 启发的二阶 Taylor 近似，如 LLM-MQ 中所引入。AutoQuantize 把 LLM-MQ 推广到了 weight-only 量化之外。它支持算子级量化，包括对 GEMM 的权重与激活联合量化，并且考虑了算子融合这类推理部署约束。AutoQuantize 算法的细节见附录 B.2。

总的来说，我们最终的 NVFP4 PTQ 配方结合了：

• 最小化 MSE 的、经校准的逐块权重缩放，
• 动态的、基于逐块 max 的激活缩放，以及
• 通过 Model-Optimizer AutoQuantize 对敏感层的选择性提升。

这个组合解决了朴素 NVFP4 PTQ 的精度损失，同时保住了部署所需的运行时效率。最终 NVFP4 checkpoint 中各算子的精度分配总结在 Table 7。

Table 7：主干 NVFP4 checkpoint 与 BF16 基线的精度设置对比。

配置项	AutoQuantize 搜索？	NVFP4 checkpoint	BF16 基线
Embedding	否	BF16	BF16
Attention QKV 投影 GEMM	是	BF16	BF16
Attention 输出投影 GEMM	是	FP8 / BF16	BF16
KV Cache + Attention BMM1	否	FP8	FP8
Attention BMM2	否	BF16	BF16
稀疏专家（路由）GEMM	是	NVFP4	BF16
共享专家 GEMM	是	NVFP4 / FP8 / BF16	BF16
MoE Latent 投影 GEMM	是	FP8 / BF16	BF16
Router	否	FP32	FP32
Mamba 投影 GEMM	是	FP8 / BF16	BF16
Mamba 1D Conv	否	BF16	BF16
Mamba SSM Cache	否	FP16	FP32
输出层	否	BF16	BF16

表注：对所有被搜索的主干 GEMM，AutoQuantize 从 { NVFP4, FP8, BF16 } 里考虑候选精度，在一个有效精度预算为 4.75 bit 的量化敏感度目标下选出逐算子的分配。在搜索出的模型里，稀疏专家 GEMM 全程被分配 NVFP4，attention 和 Mamba 投影 GEMM 被分配 FP8 或 BF16，共享专家 GEMM 用 NVFP4、FP8 和 BF16 的混合。

把 AutoQuantize 与改进后的 NVFP4 PTQ 配方结合，产出了一个大部分是 FP4 的模型，只有一小部分层为了保精度留在 FP8 或 BF16。完整的混合精度 PTQ 流程在单个 8 卡 B200 节点上不到 2 小时完成，用了 Nemotron 3 Super SFT 数据集里 512 个序列长度 4096 的样本。得到的模型相对 BF16 基线达到 99.8% 的中位精度，同时保住接近 FP4 的性能。最终评测结果报告在 Table 8。

Table 8：Nemotron 3 Super 的评测套件。我们把 FP8 和 NVFP4 优化后的模型与 BF16 模型对比。

Benchmark	N-3-Super	N-3-Super FP8	N-3-Super NVFP4
通用知识
MMLU-Pro	83.73	83.63	83.33
推理
HMMT Feb25（带工具）	94.73	94.38	95.36
GPQA（无工具）	79.23	79.36	79.42
LiveCodeBench（v6 2024-08$\leftrightarrow$2025-05）	78.69	78.44	78.44
LiveCodeBench（v5 2024-07$\leftrightarrow$2024-12）	81.19	80.99	80.56
SciCode（subtask）	42.05	41.38	40.83
HLE（无工具）	18.26	17.42	17.42
Agentic
Terminal Bench（hard subset）	25.78	26.04	24.48
SWE-Bench（OpenCode）	60.47	-	59.90
TauBench V2
Airline	56.25	56.25	54.75
Retail	62.83	63.05	63.38
Telecom	64.36	63.93	63.27
平均	61.15	61.07	60.46
Chat 与指令跟随
IFBench（prompt）	72.58	72.32	73.30
Scale AI Multi-Challenge	55.23	54.35	52.8
Arena-Hard-V2（Hard Prompt）	73.88	76.06	76.00
长上下文
AA-LCR	58.31	57.69	58.06
RULER 128k	97.04	97.17	96.89
RULER 256k	96.83	96.84	96.81
RULER 512k	95.22	95.15	95.21
RULER 1M	91.64	91.43	91.60
多语言
MMLU-ProX（跨语言平均）	79.35	79.21	79.37

译注：Table 8 里 BF16 一列的 SWE-Bench (OpenCode) 记的是 60.47，而 Table 5 里 60.47 是 OpenHands 的分数、OpenCode 是 59.20；两张表对不上，疑为原文的行标签笔误。IFBench 在两张表里也差 0.02（72.56 与 72.58）。

4.3 Mamba 状态量化

在受内存带宽限制的场景下，对 Mamba 状态 cache（SSM cache）的 DRAM 读取会成为解码速度的主要瓶颈。SSM cache 默认以 FP32 存储。一个选项是把 SSM cache 存成 FP16 而算术仍在 FP32 里执行。这种情况下，cache 以 FP16 从内存取出，上转成 FP32 做递归更新，然后再转回 FP16 存储。Table 9 展示了在 Nemotron 3 Super 一个早期 checkpoint 上的实验。这些结果显示，直接把 SSM cache 转成 FP16 在与 W8A8 量化结合时，会导致 verbosity（输出啰嗦程度）增加最多 40%。即便权重和激活保持在 BF16，把 SSM cache 转成 FP16 也会导致 verbosity 增加最多 37%。

Table 9：SSM cache 方案对代码 benchmark 和 verbosity 的影响。精度与输出 token 数均为 pass@1 avg-of-8。

权重与激活精度	SSM cache 方案	精度 livecodebench	精度 scicode	输出 token 数 livecodebench	输出 token 数 scicode	verbosity 增幅 livecodebench	verbosity 增幅 scicode
W16A16	FP32	72.91	40.90	21769	3680	0.00%	0.00%
W16A16	FP16	73.24	42.01	29812	3760	36.95%	2.19%
W16A16	FP16+SR（Philox 5）	72.00	41.94	21392	3580	-1.73%	-2.72%
W8A8	FP16	73.13	40.98	30536	3780	40.27%	2.70%
W8A8	INT16+block128	72.22	41.46	22406	3521	2.90%	-4.30%
W8A8	FP16+SR（Philox 10）	72.22	40.38	22120	3672	1.71%	-0.74%
W8A8	FP16+SR（Philox 5）	72.63	41.86	22159	3720	1.79%	1.08%
W8A8	FP16+SR（Philox 4）	72.85	40.46	21631	3785	-0.63%	2.84%
W8A8	FP16+SR（Philox 3）	70.07	39.94	24098	3827	10.70%	3.98%

量化 Mamba cache 的一个关键挑战是量化误差不会局限在单个 step 内。因为 Mamba 解码是递归的，前面 step 的量化误差会传播进后面的 step 并随时间累积。把递归更新展开就能看到这种累积。设递归状态更新为 $h_t = A_t h_{t-1} + B_t x_t$，并设 step $t$ 处的 cache 量化引入一个加性误差 $e_t$，于是 $h_{q,t} = A_t h_{q,t-1} + B_t x_t + e_t$。把这个递归展开得到

$$ \begin{aligned} h_{q,t} &= h_t + e_t + A_t e_{t-1} + A_tA_{t-1}e_{t-2} + \cdots \\ &\quad + A_tA_{t-1}\cdots A_2 e_1 + A_tA_{t-1}\cdots A_1 e_0 \\ &= h_t + \sum_{i=0}^{t} \left( \prod_{j=i+1}^{t} A_j \right) e_i, \end{aligned} $$

这表明来自较早 step 的量化误差会通过后续的递归转移传播，并可能随解码时间累积。

通过改动训练（比如 QAT 或 QAD）来解决这些量化误差并不容易。Mamba 训练用的是分块的 State Space Duality 算法，它不显式地把递归关系和推理期的 cache 具体化。要在训练期间准确建模递归的解码期 cache 行为会引入很大开销。因此我们把重点放在免训练的方法上，以找回 cache 量化损失的精度。

在 PTQ 中降低量化误差累积的一个办法是提高尾数精度。我们通过给 SSM cache 用 INT16 而不是 FP16 来探索这条路。朴素的 INT16 量化并没有改善 verbosity，因为张量级分析显示 SSM cache 的动态范围很宽。我们随后在状态维度上引入了块大小为 128 的 FP32 逐块缩放来提高有效动态范围。这消掉了 verbosity 问题（Table 9）。

我们还探索了另一个假设：误差累积与从 FP32 转成 FP16 时的取整有关。关键问题在于 round to nearest, ties on even（RTNE）在量化过程中引入了偏差。因为 RTNE 把给定输入映射到同一个取整值，它的量化误差相对原值方差为零但偏差非零。相比之下，随机取整（SR）在期望上是无偏的。在递归设置里，RTNE 的偏差会随时间一致地累积，而随机取整用零均值噪声替换了这种系统性漂移。基于这个观察，我们在把 cache 转成 FP16 之前施加随机取整，这修好了 BF16 基线和 FP8 checkpoint 两者的 verbosity 问题（Table 9）。

Table 9 展示了不同 SSM cache 方案在 livecodebench 和 scicode 上的精度和 verbosity。INT16 加逐块 scale 和 FP16 加随机取整两者都能维持与 FP32 基线相近的精度和 verbosity。我们为 Nemotron 3 Super 选择了 FP16 加随机取整（SR）、用 Philox<5> 伪随机数生成作为 SSM cache 方案，出于三个理由：

• 它不需要计算、存储和加载块缩放因子。
• Blackwell 为类型转换期间的随机取整提供了专门的 PTX 指令。
• Blackwell 通过 cuRAND 支持基于 Philox 的伪随机数生成。

为了进一步改进效率，Table 9 还变化了 Philox 的轮数。增加轮数改进生成值的统计质量，而减少轮数降低伪随机数生成的开销。选 Philox<5> 是为了在维持精度和 verbosity 的同时最小化伪随机数生成开销。

5 结论

我们提出 Nemotron 3 Super，一个激活 12B、总参数 120B 的 MoE Mamba-Attention 混合模型，具备强的 agentic 能力。Nemotron 3 Super 采用 LatentMoE 来改进精度，并引入 MTP 层通过投机解码加速推理。我们用低精度的 NVFP4 在 25 万亿文本 token 上预训练 Nemotron 3 Super，随后在一批多样的 RL 环境上做后训练。最后，我们把模型量化到 FP8 和 NVFP4，在不牺牲模型精度的前提下取得显著更高的推理吞吐。Nemotron 3 Super 相对 GPT-OSS-120B 取得最多 2.2 倍的吞吐，同时在广泛的任务上维持更高的精度。我们在 HuggingFace 上释出 Nemotron 3 Super 的预训练、后训练和量化 checkpoint。

Contributors

我们感谢以下诸位对 NVIDIA Nemotron 3 Super 做出的宝贵贡献。（原文在此处列出 544 位贡献者姓名，完整名单见原报告¹。）

附录 A 逐 benchmark 的 merge 评测

Figure 17：整个 25T token 训练过程中，训练 checkpoint 与最优离线 checkpoint 合并的逐 benchmark 精度。这 12 个 benchmark 覆盖通用知识（MMLU-Pro、MMLU）、代码生成（HumanEval、HumanEval+、MBPP、MBPP+）、数学推理（GSM8K、MATH-500）和常识理解（RACE、ARC-Challenge、HellaSwag、WinoGrande）。阴影区表示 LR 衰减阶段。

附录 B FP4 训练后量化（PTQ）算法细节

B.1 PTQ 算法消融

这一节展示各种 PTQ 算法的评测精度。这些实验里，除了最后的分类层和 attention 线性层，所有线性层都被量化到 NVFP4。

Table 10：PTQ 算法消融。

算法	细节	MMLU-Pro	GPQA	LiveCodeBench	AA-LCR
BF16	—	83.49	79.92	72.907	53.00
默认 NVFP4 PTQ（基线算法）	逐张量的静态 scale 用 max 值校准算出；逐块 scale 从块内最大值动态算出。	82.99	79.29	70.18	55.50
最小化 MSE 的权重逐块 scale	权重逐块 scale 被扫参以最小化逐块 MSE。	83.31	79.92	71.37	56.75
最小化输出 MSE 的权重逐块 scale	权重逐块 scale 被独立扫参以最小化 GEMM 输出 MSE。	83.05	78.98	71.00	57.06
GPTQ	权重量化用 GPTQ。	83.11	80.05	69.79	57.87

B.2 AutoQuantize 算法

每个算子的敏感度在其紧邻（或最近可得）的输出处用一个二阶指标度量：

$$ S(\mathrm{Op}_i, Q_{i,f}) = \left(Y_i^{\mathrm{bf16}} - Y_i^{Q_{i,f}}\right)^\top H_i \left(Y_i^{\mathrm{bf16}} - Y_i^{Q_{i,f}}\right) $$

其中 $i$ 索引算子，$Q_{i,f}$ 表示算子 $i$ 在格式选择 $f$ 下的量化算子，$H_i$ 是在所选度量点处的局部 Hessian 近似。度量点 $Y_i$ 可以是任何把量化误差与 BF16 对比的位置；对线性层，我们用线性层的输出。

计算完整的 Hessian 很昂贵，所以我们用对角 Hessian 近似，并用对角 Fisher 信息矩阵来经验地估计它。定义

$$ \Delta Y_i = Y_i^{\mathrm{bf16}} - Y_i^{Q_{i,f}} \qquad g_i = \nabla_{Y_i} \mathcal{L} $$

其中 $Y_i, g_i \in \mathbb{R}^{d}$。由此得到的敏感度代理量为

$$ S(\mathrm{Op}_i, Q_{i,f}) \approx \sum_{k=1}^{d} (\Delta Y_{i,k})^2 (g_{i,k})^2 $$

性能代价定义为：

$$ C(\mathrm{Op}_i, Q_{i,f}) = \mathrm{FLOPs}(\mathrm{Op}_i, Q_{i,f}) $$

AutoQuantize 随后求解这个带约束的优化问题：

$$ \min_{\{f\}} \sum_i S(\mathrm{Op}_i, Q_{i,f}) \quad \mathrm{s.t.} \quad \sum_i C(\mathrm{Op}_i, Q_{i,f}) \leq B $$

其中 $Q_{i,f}$ 是为算子 $i$ 选定的格式，$B$ 是总的部署代价预算。

B.2.1 感知部署约束的搜索

1) 线性层融合

推理运行时经常融合线性算子，这就要求被融合的一组算子共享同一种量化格式。这个融合约束在每一层内部施加：只有该层的 Q、K、V 投影会被融合，并被要求共享一种量化格式。对融合后的 QKV 投影，我们把这一组建模为一个决策变量，并按如下方式聚合敏感度和代价

$$ \begin{aligned} S(\mathrm{Op}_{\mathrm{qkv}}, Q_{\mathrm{qkv},f}) &= S(\mathrm{Op}_{\mathrm{q}}, Q_{\mathrm{qkv},f}) + S(\mathrm{Op}_{\mathrm{k}}, Q_{\mathrm{qkv},f}) + S(\mathrm{Op}_{\mathrm{v}}, Q_{\mathrm{qkv},f}) \\ C(\mathrm{Op}_{\mathrm{qkv}}, Q_{\mathrm{qkv},f}) &= C(\mathrm{Op}_{\mathrm{q}}, Q_{\mathrm{qkv},f}) + C(\mathrm{Op}_{\mathrm{k}}, Q_{\mathrm{qkv},f}) + C(\mathrm{Op}_{\mathrm{v}}, Q_{\mathrm{qkv},f}) \end{aligned} $$

这个表述在我们的二阶敏感度近似下是成立的：当融合算子强制一种共享格式但保留了各分支的加性贡献时，融合输出的二次敏感度项在 Q、K、V 上仍然是可加的。

2) MoE 层约束

vLLM 和 TensorRT-LLM 的量化 MoE API 要求一个受约束 MoE 组内的所有稀疏专家共享一种量化格式。这个共享格式的限制同样在每个 MoE 层内部施加：只有同一层内的稀疏专家被耦合。在 Nemotron 3 Super 里，每个稀疏专家包含 up_proj 和 down_proj，因此这些稀疏专家的投影必须被联合分配。我们把稀疏专家集合表述为一个算子级的决策，

$$ \mathrm{Op}_{\mathrm{moe}} = \bigcup_{e \in \mathcal{E}} \{\mathrm{Op}_{e,\mathrm{up\_proj}}, \mathrm{Op}_{e,\mathrm{down\_proj}}\} $$

其中 $\mathrm{moe}$ 表示 MoE 稀疏专家组（一个 MoE 层内所有被耦合的稀疏专家 up_proj/down_proj 算子）。我们在 MoE 块的输出处度量敏感度，这样指标能捕捉到所有稀疏专家的合并贡献，

$$ S(\mathrm{Op}_{\mathrm{moe}}, Q_{\mathrm{moe},f}) = \left(Y_{\mathrm{moe}}^{\mathrm{bf16}} - Y_{\mathrm{moe}}^{Q_{\mathrm{moe},f}}\right)^\top H_{\mathrm{moe}} \left(Y_{\mathrm{moe}}^{\mathrm{bf16}} - Y_{\mathrm{moe}}^{Q_{\mathrm{moe},f}}\right) $$

并把部署代价定义为在各稀疏专家上求和，

$$ C(\mathrm{Op}_{\mathrm{moe}}, Q_{\mathrm{moe},f}) = \sum_{e \in \mathcal{E}} \left(C(\mathrm{Op}_{e,\mathrm{up\_proj}}, Q_{\mathrm{moe},f}) + C(\mathrm{Op}_{e,\mathrm{down\_proj}}, Q_{\mathrm{moe},f})\right) $$

MoE 块里的其他线性层，比如 latent 投影层和共享专家，不属于这个稀疏专家耦合约束，可以被分配不同的量化格式。