Nemotron 3 Super: Open, Efficient Mixture-of-Experts Hybrid Mamba-Transformer Model for Agentic Reasoning

Paper: arXiv:2604.12374 Code: NVIDIA-NeMo/Nemotron; NVIDIA-NeMo/Megatron-Bridge Code reference: NVIDIA-NeMo/Nemotron main @ bf876166 (2026-05-20); NVIDIA-NeMo/Megatron-Bridge main @ 0cb4440d (2026-05-26)

1. Motivation (研究动机)

当前大模型在 agentic reasoning 场景里同时遇到三类瓶颈。第一，长上下文与多步工具调用让标准 Transformer 的 KV cache、注意力计算和服务延迟变得很重；只堆 dense 参数或普通 Transformer-MoE，容易在吞吐、显存带宽、跨卡通信和在线延迟上失衡。第二，现有 MoE 设计多以 FLOPs 稀疏性为核心，但线上服务的真实成本还包括专家权重读取、all-to-all 通信、路由开销和专家并行切分；一个“FLOPs 看起来便宜”的 MoE，在低延迟服务里仍可能被内存带宽和通信拖垮。第三，代码修复、终端操作、搜索、多轮工具调用等 agent 任务需要长轨迹、环境交互和可验证奖励，传统 SFT 很便宜但容易只学到行为表面，端到端 RL 更有效但 rollout 慢、系统复杂、容易因单环境训练导致其它能力退化。

本文要解决的具体目标是：在开放权重模型中，把 120B 总参数级别的模型压到约 12B active 参数的推理预算，同时保留强推理、强 coding、长上下文和工具使用能力。Nemotron 3 Super 因此不是单纯“更大的 MoE”，而是把 Hybrid Mamba-Attention、LatentMoE、Multi-Token Prediction、NVFP4 预训练、SFT/RL post-training 和 FP8/NVFP4 部署量化串成一个完整训练与服务配方。

这个问题值得研究，是因为 agentic workload 的瓶颈通常不是单题 benchmark 分数，而是“高质量 + 长输出 + 多工具调用 + 可本地部署”的综合成本。论文报告 Nemotron 3 Super 是 120B total / 12B active 的 hybrid Mamba-Attention MoE，在 8k input / 64k output 设置下，相比 GPT-OSS-120B 和 Qwen3.5-122B 分别最高达到 $2.2\times$ 和 $7.5\times$ throughput，同时支持 1M context；这直接面向长任务代理、代码修改、终端执行和企业部署。

Figure 1 解读：这张总览图把准确率与吞吐放在同一个比较框架里。横向看，Nemotron 3 Super 的 benchmark accuracy 接近 GPT-OSS-120B / Qwen3.5-122B；纵向看，它在长输出服务场景下明显更快。论文的核心动机正是：agentic reasoning 需要长上下文和长生成，单看参数规模或单点准确率不足以解释真实可用性。

2. Idea (核心思想)

核心洞察：agentic reasoning 模型要同时优化“模型质量”和“服务形态”，因此稀疏 MoE 不能只按 FLOPs 设计，而要按内存带宽、通信、长上下文状态和 speculative decoding 一起设计。Nemotron 3 Super 用 LatentMoE 把 routed expert computation 投影到较小 latent dimension 里，用 Mamba-2 承担大部分线性时间序列建模，用少量 attention layer 做全局 anchor，再用共享权重 MTP head 做 native speculative decoding。

关键创新可以概括为三层：模型架构层面是 Hybrid Mamba-Attention + LatentMoE + shared-weight MTP；训练层面是在 25T tokens 上用 BF16/NVFP4 混合精度预训练，并通过 checkpoint merge、long-context CPT 和 agent-heavy post-training 强化能力；部署层面是给出 FP8 与 NVFP4 PTQ/QAD 路线，让 Blackwell/Hopper 上的低精度推理尽量不牺牲 benchmark。

与普通 Transformer-MoE 的根本差异在于：普通 MoE 通常在 full hidden dimension 上路由和执行专家，成本随 top-$K$、专家维度和 all-to-all 通信上涨；LatentMoE 把 routed expert path 降到 latent size $\ell =1024$，让模型可以在近似成本下使用 $N=512$ experts 和 top-$K=22$ active experts。与 DeepSeek-R1 / Qwen3-Next 等外部 speculative serving 路线相比，Nemotron 3 Super 的 MTP 是模型原生训练目标的一部分，不需要单独 draft model。

3. Method (方法)

3.1 Overall framework：从预训练到量化部署的端到端路线

Nemotron 3 Super 的 pipeline 分为四段：Stage 0 预训练 base model；Stage 1 SFT 做 instruction / agentic data alignment；Stage 2 多阶段 RL，包括 RLVR、SWE-RL、RLHF 和 MTP healing；Stage 3/4 评测与量化，输出 BF16、FP8、NVFP4 等 checkpoint。论文强调“模型架构 + 数据 + RL 系统 + 低精度部署”必须共同设计，否则 agentic reasoning 的长轨迹和长输出场景会把某个单点瓶颈放大。

Figure 2 解读：post-training pipeline 先用 SFT 提供基本聊天、代码、搜索、工具使用格式，再用 multi-environment RLVR 训练可验证任务，用 SWE-RL 单独处理慢速长上下文代码任务，最后用 RLHF 改善交互质量，并用 MTP healing 恢复 speculative head 的准确性。把 SWE-RL 单独拆出，是因为软件工程 rollout 慢且 context 长，混在短任务 RLVR 中会成为吞吐瓶颈。

3.2 Hybrid Mamba-Attention + sparse MoE 主干

主干是 88-layer hybrid Mamba-2 / MoE stack：大部分层使用 Mamba-2 与 sparse MoE 来降低长序列生成时的 KV cache 压力，少量 self-attention layer 作为 global anchors 让 token 间可以做全局交互。模型配置包括 hidden size 4096、GQA 32 query heads / 2 KV heads、head dimension 128、Mamba state dimension 128、Mamba groups 8、Mamba heads 128、Mamba head dimension 64、expert hidden dimension 2688、shared expert intermediate size 5376、512 experts/layer、top-$K=22$、MoE latent size 1024、2 个 shared-weight MTP layers。总参数 120.6B，每次 forward active 参数 12.7B（不含 embedding 为 12.1B）。

Figure 3 解读：layer pattern 展示了 Mamba、MoE 和少量 attention anchors 的周期性插入。Mamba 负责低成本长序列状态传递，attention anchors 负责补回全局 token interaction，MoE/LatentMoE 负责在 active 参数预算内提供大容量专家组合。

直觉上，这个架构把“长上下文成本”拆成两部分处理：Mamba-2 避免每层都维护随上下文二次增长的 attention 交互；少量 attention anchors 则防止纯状态空间模型丢失远距离 token 之间的显式交互。对 agentic coding 来说，模型既要读很多上下文，也要在局部代码片段和远端 issue/test 信息之间建立全局依赖，因此纯 Mamba 或纯 attention 都不是最优折中。

3.3 LatentMoE：在更小 latent dimension 上做专家计算

普通 MoE 的 routed expert 在 hidden dimension $d$ 上执行，top-$K$ 增大时会线性增加专家权重读取、通信和 memory bandwidth 压力。LatentMoE 的做法是把 token hidden state $h\in {\mathbb{R}}^d$ 先投影到 latent dimension $\ell$： $z=W_{\text{down}}h,z\in {\mathbb{R}}^{\ell },\ell =1024<d=4096.$ router 在 full hidden dimension 上保留信息，shared expert 与非 routed computation 也保留 full dimension；但 routed expert computation 在 $z$ 上执行，再映射回主干维度。一个简化表达是： $y=W_{\text{up}}\left({\sum }_{i\in \mathrm{TopK}(g(h))}{g}_i(h)E_i(z)\right)+E_{\text{shared}}(h).$ 这里 $N=512$，$K=22$。论文给出的设计原则是：低延迟服务中 MoE 常被专家权重读取和 all-to-all 通信主导；若把 routed hidden dimension 降低 $\alpha$ 倍，就可以把 top-$K$ 或专家数按近似成本放大，从而提升专家组合空间。质量约束来自有效非线性预算 $K\cdot m$ 与任务有效特征秩 $r_{\mathrm{eff}}$：$d$ 不能无限降，否则表示坍塌；但在合理 latent size 下，增加 $N$ 与 $K$ 能换来更高 accuracy per byte。

Figure 4a–4b 解读：左侧 standard MoE 在原 hidden dimension 上执行专家层；右侧 LatentMoE 先降维再做 routed expert，再升维回主干。这不是简单低秩压缩，而是把“昂贵的 per-expert routed computation”移到更便宜的 latent channel，同时保留 router、shared expert 和全局主干信息。

3.4 Multi-Token Prediction：共享权重 MTP head 做 native speculative decoding

标准 next-token training 只预测 $y_{t+1}$。MTP 在每个位置预测多个未来 token，给表示学习更强的多步监督，同时在 inference 时作为 speculative decoding 的 draft mechanism。Nemotron 3 Super 的关键变化是 shared-weight MTP：不是为第 1/2/…/N 个 future offset 各训练一个独立 head，而是训练一个共享 head，让它在训练中见到多个 offset，推理时可递归地产生更长 draft。

论文没有给完整 MTP 损失公式，但结合 training recipe 的 mtp_num_layers=2 与 mtp_loss_scaling_factor=0.3，可以把目标理解为： $\mathcal{L}={\mathcal{L}}_{\text{AR}}+0.3{\sum }_{j=1}^2{\mathcal{L}}_{\text{MTP},j}.$ released Megatron-Bridge recipe 中，src/megatron/bridge/recipes/nemotronh/nemotron_3_super.py 将 cfg.model.mtp_num_layers = 2、cfg.model.mtp_loss_scaling_factor = 0.3、cfg.model.mtp_use_repeated_layer = True；Nemotron repo 的 tiny provider 也保留 mtp_num_layers=2 以覆盖 Super3 特有路径。

Figure 5 解读：SPEED-Bench 上 draft index 越深，acceptance rate 越自然下降；但 Nemotron 3 Super 在较深 draft index 上相对 DeepSeek-R1 更稳定，并接近或超过 Qwen3-Next 的若干段。这说明 shared-head autoregressive drafting 缓解了“训练时看 ground-truth hidden state、推理时看自己生成状态”的分布偏移。

Figure 6 解读：TRT-LLM 性能图展示了 draft depth 从 $D=1$ 到 $D=3$ 时 throughput-latency Pareto frontier 的移动。MTP 的价值不是只减少单 token 计算，而是在同一次 verification 中接受多个 token，使长输出 agent 任务的有效输出 TPS 上升。

3.5 Pretraining：25T tokens、NVFP4、checkpoint merge 与 long-context CPT

预训练使用 Warmup-Stable-Decay schedule，总 horizon 25T tokens。LR 在前 200B tokens warmup 到 $4.5\times 10^{-4}$，最后 5T tokens 用 minus-sqrt decay 到 $4.5\times 10^{-6}$；AdamW weight decay 0.1，${\beta }_1=0.9$、${\beta }_2=0.95$；sequence length 8192，global batch size 3072 sequences，约 25.17M tokens/batch；MTP loss scaling 0.3；BF16/NVFP4 hybrid precision。released Megatron-Bridge recipe 的 nemotron_3_super_pretrain_config() 对应 train_iters=39735、global_batch_size=3072、seq_length=8192、TP=4、EP=8、mixed precision nemotron_3_super_bf16_with_nvfp4_mixed。

数据采用两阶段 curriculum：Phase 1 强调 16 类高层数据源的多样性；Phase 2 转向更高质量数据。数据包括 web crawl 质量分层、synthetic crawl、math、Wikipedia、code、Nemotron-CC-Code、academic text、Crawl++、multilingual、finepdfs，以及 general/stem/code SFT-style reasoning data。论文还新加了 Synthetic Code Concepts、Synthetic Unconditional Algorithmic、Synthetic Multiple Choice 等更偏 reasoning/code 的 synthetic pretraining 数据。

Figure 7 解读：Phase 1 data mixture 强调覆盖面，让模型在早期稳定接触 web、code、math、academic、multilingual 和 synthetic SFT-style 数据。这个阶段的目标不是立即追求最高质量，而是为 120B/12B hybrid architecture 建立广覆盖能力。

Figure 8 解读：Phase 2 data mixture 把权重推向更高质量数据，配合最后 5T LR decay。论文中的 checkpoint merge 结果显示 stable LR 阶段 merge readout 比原 checkpoint 高 2–4 points，但最终长 decay 会让真实训练 checkpoint 逐步追上。

Figure 9 解读：平均 12 benchmark 的曲线说明，stable LR 时 checkpoint 噪声较大，滑动窗口 weight-space merge 是便宜的质量读数；进入 20T–25T 的 LR decay 阶段后，merge 与真实训练曲线差距收窄。最终 base checkpoint 本身选用 500B merge，因此 merge 仍是 practical selection tool，而不是替代训练 decay。

Figure 10 解读：per-benchmark breakdown 显示 merge 的收益并非所有任务一致；它主要在 stable LR 阶段给出更平滑的质量估计。对训练监控来说，这意味着不能只看单步 checkpoint 的 benchmark 波动来判断训练是否退化。

long-context extension 在预训练尾部做 CPT：1M context stage 使用 constant LR $4.5\times 10^{-6}$、global batch size 16、64-way context parallelism、2-way tensor parallelism、64-way expert parallelism，在 GB200 上训练；1M stage 论文报告持续 34B tokens，随后加入 1M 与 4k 序列交替训练 17B tokens，以缓解 math benchmark 的小幅影响。released stage0_pretrain/config/long_context_1m.yaml 明确记录了 seq_length=1048576、global_batch_size=16、context_parallelism=64、tensor_model_parallel_size=2、expert_model_parallelism=64、lr=4.5e-6。

3.6 SFT：two-stage loss、agentic data 与 reasoning control

SFT 只监督 assistant/output token，prompt token 通过 loss mask 排除。对 packed global batch $\mathcal{B}$，conversation $c$ 的 output-token 集合为 ${\mathcal{O}}_c$，token NLL 为 ${\ell }_t=-\log p_{\theta }(y_t\mid x,y_{<t})$。Stage 1 使用 output-token 全局平均： ${\mathcal{L}}_{\text{tok}}=\frac{{\sum }_{c\in \mathcal{B}}{\sum }_{t\in {\mathcal{O}}_c}{\ell }_t}{{\sum }_{c\in \mathcal{B}}|{\mathcal{O}}_c|}.$ Stage 2 改为每个 conversation 先归一化再平均，避免长回答支配训练： ${\mathcal{L}}_{\text{samp}}=\frac{1}{|\mathcal{B}|}{\sum }_{c\in \mathcal{B}}\left(\frac{1}{|{\mathcal{O}}_c|}{\sum }_{t\in {\mathcal{O}}_c}{\ell }_t\right).$ 论文报告 Stage 1 用 256k sequence-length packing、global batch size 64、constant LR $1e^{-5}$、30k warmup samples；Stage 2 用 512k packing、加入最高 512K 的 long-context data、global batch size 32、constant LR $1e^{-5}$。同时继续训练 2 层 shared MTP head，以保留 speculative decoding 能力。

Figure 11 解读：SWE-SFT data 图展示了 agentic CLI 数据如何从任务 taxonomy、真实/合成 GitHub issue、不同 CLI 环境和 teacher model traces 中构造。重点不是单轮代码补全，而是收集“命令行交互轨迹”，让模型学习类似 Codex/OpenCode/Claude Code 的多步操作格式。

Figure 12 解读：specialized conversational tool-use pipeline 先生成 domain、scenario、tool specs 与用户任务，再让多个 teacher model 产生轨迹，并用 LM-as-a-judge 进行 outcome/process 级验证；最后只保留成功且难度合适的 trajectory 进入 SFT。

Figure 13 解读：general-purpose tool-calling pipeline 扩大了 tool set 与 scenario 来源。论文表明 conversational tool-use 数据规模从 Nano 的 5 domains / 15,588 conversations 增到 Super 的 838 domains / 279,116 conversations，提升的是工具组合和交互场景的多样性。

Figure 14 解读：SFT blend 体现了这篇技术报告的定位：不是只训练聊天对齐，而是显著增加 software engineering、search、terminal、long-context、multilingual、tool-use 和 safety/policy 数据。reasoning control 包含 reasoning-off、regular、low-effort 三种模式；low-effort 样本约占 SFT sample count 的 2%，reasoning-off 通过随机 3% 样本去除 reasoning traces 实现，预算控制则在主 SFT 后追加 350 steps semi-on-policy SFT，并截断 12% reasoning traces 到随机预算。

3.7 RL：RLVR、SWE-RL、RLHF 与 PivotRL

RL 阶段包含四个子阶段：multi-environment RLVR、SWE-RL、RLHF、MTP healing。Stage 1 RLVR 同时训练 21 environments / 37 RL datasets，覆盖 math、code、STEM、instruction following、safety、long context、agentic tool use、Reasoning Gym 等。论文明确说，单环境 RL 会导致其它 benchmark 严重回退；统一 mixture 训练能让每次 update 感知完整环境分布。RLVR prompts 会过滤掉 SFT model 已稳定答对的样本，再按 difficulty curriculum 排序。

low-effort RL 把 correctness 和 generated tokens 一起纳入 reward：早期低努力 prompt mix 包含 math、STEM QA、competitive coding，占 RL prompts 2%；后期缩到 math/STEM QA，占 1%。这对应用户可控“少想一点、快一点”的模式，而不是简单减少 max tokens。

SWE-RL 单独做：每个 rollout 启动 Apptainer container，加载目标 repo，用 OpenHands agent loop 生成 patch，再跑 ground-truth tests 得到 binary reward。为了 tool diversity，作者在 OpenHands 内实现 OpenCode 与 Codex agent classes，模拟 Claude Code / Codex CLI 的 tool format；这样训练时 harness 多样，推理时对不同 agent 外壳更泛化。

RLHF 使用 principle-following GenRM，而不是 vanilla GenRM；GenRM 初始化来自 Qwen3-235B-A22B-Thinking-2507，训练数据包括 HelpSteer 3、commercially friendly lmarena-140k subsets 和新收集 human preference data。RLHF 既贯穿 multi-environment RL，也在 post-training 最后有单独阶段。

算法上，released configs 和 paper 都指向 asynchronous GRPO：inference workers 连续生成 trajectory，rollout buffer 满后发给 training engine 更新；权重更新会 in-flight 推给 inference workers。因为单条 trajectory 可能混合不同 model version 的 token，作者限制 inference workers 最多落后一轮，并 mask training/inference logprob importance ratio 来降低 policy lag/off-policy 影响。RLVR full config 中 num_prompts_per_step=256、num_generations_per_prompt=16、train_global_batch_size=4096、max_total_sequence_length=65536、LR $3e^{-6}$；paper 文中写起始 max generation length 49K 后增到 64K，这与 released config 的 65,536 token 上限一致但更偏最终配置。

SWE config 更长：stage2_swe1/config/default.yaml 使用 64 prompts/step、16 generations/prompt、batch size 1024、max sequence length 131,072、TP/CP=8/8、LR $1e^{-6}$、overlong filtering enabled、prefix caching enabled、64 nodes / 512 GPUs；stage2_swe2/config/default.yaml 将 prompts/step 改为 16、generations/prompt 改为 32、batch size 512、max sequence length 196,608。RLHF config 则是 128 prompts/step、16 generations/prompt、batch size 2048、max length 49,152、LR $1e^{-6}$、KL penalty $1e^{-4}$、72 nodes / 576 GPUs。

3.8 Quantization：FP8、NVFP4 与 SSM cache 处理

量化目标是把 post-trained model 变成 Hopper 上的 FP8 W8A8 checkpoint 和 Blackwell 上的 NVFP4 W4A4 checkpoint。FP8 用 Model-Optimizer PTQ / AutoQuantize；NVFP4 对 sparse expert GEMMs 普遍使用 NVFP4，但 attention/Mamba projection GEMMs 由 AutoQuantize 在 NVFP4/FP8/BF16 中按 sensitivity 与 4.75-bit effective precision budget 选择。Mamba SSM cache 不是简单压到最低精度：表格显示 W8A8 + FP16 SSM cache 会显著增加 verbosity；INT16+block128 或 FP16+stochastic rounding 能更好控制代码 benchmark 与 completion length。

Figure 15 解读：NVFP4 magnitude pattern 图显示 routed expert FC1/FC2 的 channel norm 在训练中形成结构化模式。低 norm FC1 输出 channel 与低 norm FC2 输入 channel 对齐，解释了低精度下某些梯度/权重量化现象并非随机噪声。

Figure 16 解读：Nano 上的对照实验显示，NVFP4 在 1T tokens 时 zero-valued weight gradient 数量可接近 BF16 25T 模型，且切回 BF16 后 zero gradients 回到基线。这说明很多 zero gradient 来自小量级梯度 underflow，而非训练完全失效。

Figure 17 解读：分层 zero gradient 来源图说明 FC1 的 zero-valued weight gradients 更多，且主要来自 FC2 的 dgrad underflow。对工程实现而言，这解释了为什么 precision policy 必须按 layer/operator 区分，而不是全模型统一 W4A4。

Figure 18 解读：从 NVFP4 切到 MXFP8 的 healing 没有带来持续 downstream accuracy 改善，说明最终 NVFP4 recipe 的主要 benchmark 质量已经接近更高精度部署；这里的风险更多在 verbosity、cache precision 和 operator sensitivity，而不是简单“FP4 一定掉点”。

3.9 Pseudocode：按 released recipes 抽象关键组件

Code reference: NVIDIA-NeMo/Nemotron main @ bf876166 (2026-05-20); NVIDIA-NeMo/Megatron-Bridge main @ 0cb4440d (2026-05-26) — pseudocode and mapping based on these commits

3.9.1 LatentMoE forward（论文机制抽象 + released provider 参数）

import torch
import torch.nn.functional as F
 
class LatentMoEBlock(torch.nn.Module):
    def __init__(self, d_model=4096, latent_dim=1024, num_experts=512, top_k=22):
        super().__init__()
        self.down = torch.nn.Linear(d_model, latent_dim, bias=False)
        self.up = torch.nn.Linear(latent_dim, d_model, bias=False)
        self.router = torch.nn.Linear(d_model, num_experts, bias=False)
        self.experts = torch.nn.ModuleList([
            torch.nn.Sequential(
                torch.nn.Linear(latent_dim, 2688, bias=False),
                torch.nn.ReLU(),
                torch.nn.Linear(2688, latent_dim, bias=False),
            ) for _ in range(num_experts)
        ])
        self.shared = torch.nn.Sequential(
            torch.nn.Linear(d_model, 5376, bias=False),
            torch.nn.ReLU(),
            torch.nn.Linear(5376, d_model, bias=False),
        )
        self.top_k = top_k
 
    def forward(self, h):
        z = self.down(h)                         # routed computation in latent dimension
        logits = self.router(h)                  # router keeps full hidden information
        weights, expert_ids = torch.topk(torch.sigmoid(logits), self.top_k, dim=-1)
        routed = torch.zeros_like(z)
        for slot in range(self.top_k):
            # production code uses all-to-all / expert parallel dispatch, not this Python loop
            eid = expert_ids[..., slot]
            w = weights[..., slot].unsqueeze(-1)
            routed = routed + w * dispatch_to_experts(self.experts, eid, z)
        return self.up(routed) + self.shared(h)

3.9.2 Pretraining recipe loading（Megatron-Bridge production path）

def build_super3_pretrain_config():
    cfg = _pretrain_common()
    cfg.model = AutoBridge.from_hf_pretrained(
        "nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-Base-BF16"
    ).to_megatron_provider(load_weights=False)
    cfg.model.seq_length = 8192
    cfg.train.train_iters = 39735
    cfg.train.global_batch_size = 3072
    cfg.model.tensor_model_parallel_size = 4
    cfg.model.expert_model_parallel_size = 8
    cfg.model.mtp_num_layers = 2
    cfg.model.mtp_loss_scaling_factor = 0.3
    cfg.mixed_precision = "nemotron_3_super_bf16_with_nvfp4_mixed"
    cfg.optimizer.lr = 4.5e-4
    cfg.optimizer.min_lr = 4.5e-6
    cfg.scheduler.lr_decay_style = "WSD"
    return cfg
 
 
def run_pretrain(config_path, overrides):
    config = load_omegaconf_yaml(config_path)
    config = apply_overrides(config, overrides)
    train_cfg = build_super3_pretrain_config()
    setup_artifact_tracking(config)
    return pretrain(train_cfg, forward_step_func=forward_step)

3.9.3 Two-stage SFT loss

import torch
import torch.nn.functional as F
 
def sft_loss_stage1(logits, labels, loss_mask):
    token_loss = F.cross_entropy(
        logits.view(-1, logits.size(-1)), labels.view(-1), reduction="none"
    ).view_as(labels)
    return (token_loss * loss_mask).sum() / loss_mask.sum().clamp_min(1)
 
 
def sft_loss_stage2(logits, labels, loss_mask, conversation_ids):
    token_loss = F.cross_entropy(
        logits.view(-1, logits.size(-1)), labels.view(-1), reduction="none"
    ).view_as(labels)
    losses = []
    for cid in conversation_ids.unique():
        m = (conversation_ids == cid) & (loss_mask > 0)
        if m.any():
            losses.append(token_loss[m].mean())
    return torch.stack(losses).mean()

3.9.4 Asynchronous GRPO / SWE-RL rollout skeleton

def async_grpo_loop(policy, inference_workers, trainer, rollout_buffer, cfg):
    while not trainer.done():
        for worker in inference_workers:
            worker.refresh_weights(max_lag_steps=1, recompute_kv_cache=False)
            prompts = sample_prompts(cfg.num_prompts_per_step)
            trajectories = worker.generate(
                prompts,
                n=cfg.num_generations_per_prompt,
                max_tokens=cfg.max_total_sequence_length,
                return_logprobs=True,
            )
            rewards = [env_or_verifier_reward(t) for t in trajectories]
            rollout_buffer.add(trajectories, rewards)
 
        if rollout_buffer.ready(cfg.train_global_batch_size):
            batch = rollout_buffer.pop(cfg.train_global_batch_size)
            batch = mask_importance_ratios_for_policy_lag(batch)
            loss = trainer.grpo_update(policy, batch)
            trainer.push_weights_to_generation_workers(inference_workers)

3.9.5 AutoQuantize / PTQ selection skeleton

def autoquantize_backbone(model, calibration_data, budget_bits=4.75):
    candidates = ["NVFP4", "FP8", "BF16"]
    assignment = {}
    for op in searched_gemm_ops(model):
        scores = {}
        for precision in candidates:
            q_op = quantize_operator(op, precision)
            scores[precision] = sensitivity_objective(q_op, calibration_data)
        assignment[op.name] = choose_under_budget(scores, budget_bits)
    apply_assignment(model, assignment)
    keep_in_bf16(model.embedding, model.output_layers, model.mamba_conv)
    set_ssm_cache_precision(model, "FP16_or_INT16_block128_with_SR")
    return model

论文公式与 released code/config 实现差异：论文正文给出的是内部 full-scale training run 的设置（例如 SFT Stage 1/2 的 256k/512k packing、global batch 64/32、LR $1e^{-5}$；RL 起始 max generation 49K 后增至 64K）。公开 NVIDIA-NeMo/Nemotron repo 主要是可复现 recipe 与 config scaffold：stage1_sft/config/default.yaml 通过 artifact pack_size 控制 sequence length，默认 global_batch_size=4；NVIDIA-NeMo/Megatron-Bridge 的 nemotron_3_super_sft_config() 默认 seq_length=2048、LR $5e^{-6}$。因此笔记中实验设置优先引用论文报告的 full-scale 数值，同时在 code mapping 中标出公开 recipe 的实际路径，避免把 runnable defaults 误当成论文内部最终 launch config。

Paper Concept	Source File	Key Class/Function
Super3 training recipe entry	NVIDIA-NeMo/Nemotron/src/nemotron/recipes/super3/README.md	CLI stages: pretrain, sft, rl, eval
Stage 0 pretraining launcher	NVIDIA-NeMo/Nemotron/src/nemotron/recipes/super3/stage0_pretrain/train.py	_default_recipe_builder, pretrain(..., forward_step)
Super3 model/provider config	NVIDIA-NeMo/Megatron-Bridge/src/megatron/bridge/recipes/nemotronh/nemotron_3_super.py	nemotron_3_super_pretrain_config, nemotron_3_super_sft_config
Long-context CPT config	NVIDIA-NeMo/Nemotron/src/nemotron/recipes/super3/stage0_pretrain/config/long_context_1m.yaml	seq_length=1048576, global_batch_size=16, context_parallelism=64
SFT data packing / launcher	NVIDIA-NeMo/Nemotron/src/nemotron/recipes/super3/stage1_sft/	data_prep.py, train.py, config/default.yaml
RLVR / GRPO config	NVIDIA-NeMo/Nemotron/src/nemotron/recipes/super3/stage2_rl/stage1_rlvr/config/default.yaml	prompts/generations/batch/sequence-length config
SWE-RL config	NVIDIA-NeMo/Nemotron/src/nemotron/recipes/super3/stage2_rl/stage2_swe1/config/default.yaml; stage2_swe2/config/default.yaml	Apptainer/OpenHands/Nemo-Gym SWE settings
RLHF config	NVIDIA-NeMo/Nemotron/src/nemotron/recipes/super3/stage2_rl/stage3_rlhf/config/default.yaml	KL penalty, GenRM-stage batch/sequence config
Tiny integration model	NVIDIA-NeMo/Nemotron/src/nemotron/recipes/super3/tiny_model.py	Nemotron3SuperTinyProvider, make_tiny_super3_model

4. Experimental Setup (实验设置)

Datasets / scale. Pretraining uses 25T text tokens over 16 high-level categories, with Phase 1/Phase 2 curriculum and newly released/used synthetic sets such as Nemotron-Pretraining-Specialized-v1.1. SFT reuses Chat, Infinibyte, Formal Proofs and refreshes Competition Math, Competition Code, Conversational Tool Use, Multilingual and Science with newer teacher models. Conversational tool-use SFT grows from Nano’s 5 domains / 15,588 conversations to Super’s 838 domains / 279,116 conversations. RL trains on 21 environments and 37 RL datasets, including math, code, STEM, instruction following, safety, long context, agentic tool use and Reasoning Gym. RLHF uses HelpSteer 3, commercially friendly lmarena-140k subsets and newly collected human preference data.

Baselines. Main comparisons include GPT-OSS-120B, Qwen3.5-122B-A10B, DeepSeek-R1, Qwen3-Next, Ling-flash base-2.0, GLM-4.5 Air-Base, and Nemotron 3 Nano in scaling/data comparisons. Quantization compares BF16, FP8 and NVFP4 checkpoints, plus PTQ algorithm variants including default NVFP4 PTQ, MSE-minimized per-block scales, output-MSE-minimized scales and GPTQ.

Metrics / benchmarks. Reasoning and knowledge use MMLU-Pro, AIME25, HMMT Feb25, GPQA, HLE and BrowseComp with Search. Coding/agentic tasks include LiveCodeBench v5/v6, SciCode, Terminal Bench, SWE-Bench under OpenHands/OpenCode/Codex, SWE-Bench Multilingual and BIRD Bench. Tool use uses TauBench V2; instruction/chat use IFBench, Scale AI Multi-Challenge, Arena-Hard-V2 and AA-LCR. Long context uses RULER 128k/256k/512k/1M. MTP uses SPEED-Bench average acceptance length with fixed draft length 7. Quantization reports benchmark accuracy plus completion-token/verbosity effects for SSM cache variants.

Training config. Paper full-scale pretraining: 25T tokens; WSD LR schedule with 200B-token warmup to $4.5\times 10^{-4}$, final 5T decay to $4.5\times 10^{-6}$; AdamW weight decay 0.1, ${\beta }_1=0.9$, ${\beta }_2=0.95$; sequence length 8192; global batch 3072 sequences; about 25.17M tokens/batch; MTP loss scaling 0.3; BF16/NVFP4 mixed precision. Released Megatron-Bridge pretrain recipe: train_iters=39735, global_batch_size=3072, micro_batch_size=1, TP=4, EP=8, mixed_precision=nemotron_3_super_bf16_with_nvfp4_mixed. Long-context CPT: 1M context, global batch 16, LR $4.5e^{-6}$, CP=64, TP=2, EP=64 on GB200. RLVR released config: 256 prompts/step, 16 generations/prompt, train batch 4096, max sequence 65,536, LR $3e^{-6}$. SWE-RL stage uses 64 or 16 prompts/step depending substage, 16/32 generations, max sequence 131,072/196,608, LR $1e^{-6}$. RLHF uses 128 prompts/step, 16 generations, batch 2048, max sequence 49,152, KL penalty $1e^{-4}$.

5. Experimental Results (实验结果)

Base model results. Nemotron 3 Super 120B-A12B-Base beats Ling-flash base-2.0 and GLM-4.5 Air-Base on most reported base benchmarks: MMLU 86.01 vs 81.00/81.00; MMLU-Pro 75.65 vs 62.10/58.20; AGIEval-En 77.92 vs 61.70/62.40; GPQA-Diamond 60.00 vs 36.00/23.20; MATH 84.84 vs 63.80/50.36; MATH Level 5 70.00 vs 39.80/26.30; AIME 2024 pass@32 53.33 vs 30.00/20.00; HumanEval 79.40 vs 70.10/76.30; RULER 1M 71.00 where the compared baselines do not report 1M.

Post-trained main comparison. Against Qwen3.5-122B-A10B and GPT-OSS-120B, Nemotron 3 Super reports: MMLU-Pro 83.73 vs 86.70 vs 81.00; AIME25 no tools 90.21 vs 90.36 vs 92.50; HMMT Feb25 with tools 94.73 vs 89.55 vs unavailable; GPQA no tools 79.23 vs 86.60 vs 80.10; GPQA with tools 82.70 vs unavailable vs 80.09; LiveCodeBench v5 81.19 vs 78.93 vs 88.00; SciCode 42.05 vs 42.00 vs 39.00; SWE-Bench OpenHands 60.47 vs 66.40 vs 41.90; SWE-Bench Multilingual OpenHands 45.78 vs unavailable vs 30.80; RULER 1M 91.64 vs 91.33 vs 22.30; MMLU-ProX average 79.36 vs 85.06 vs 76.59. 结论不是“所有 benchmark 第一”，而是“在同级 accuracy 下明显提高吞吐并保持长上下文/agentic 覆盖”。

MTP results. SPEED-Bench fixed draft length 7 的 average acceptance length：DeepSeek-R1 2.70，Qwen3-Next 3.33，Nemotron 3 Super 3.45。分类上 Nemotron 3 Super 在 Humanities 3.26、Multilingual 4.05、QA 3.16、RAG 3.78、Reasoning 3.59、Roleplay 2.82、Summarization 3.48、Writing 2.99 等项超过或接近 Qwen3-Next。结合 Figure 5/6，MTP 对长输出服务的价值主要体现在更多 draft token 被接受，从而提高 output TPS。

Quantization results. FP8/NVFP4 与 BF16 主模型平均分非常接近：main quantization comparison average 为 BF16 61.15、FP8 61.07、NVFP4 60.46；RULER 1M 为 91.64/91.43/91.60；MMLU-ProX average 为 79.35/79.21/79.37。PTQ algorithm ablation 中，BF16 baseline 为 MMLU-Pro 83.49、GPQA 79.92、LiveCodeBench 72.907、AA-LCR 53.00；Default NVFP4 PTQ 为 82.99/79.29/70.18/55.50；Weight per-block MSE 为 83.31/79.92/71.37/56.75；GPTQ 为 83.11/80.05/69.79/57.87。SSM cache 表显示 W8A8 + FP16 cache 的 verbosity 增加 40.27%，而 W8A8 + INT16+block128 仅 2.90%，且 SciCode 41.46 高于 W16A16 FP32 baseline 40.90。

Ablation / practical findings. Checkpoint merge 在 stable LR 阶段带来 2–4 point average gain，最终 5T decay 后 gain 缩小；这支持“merge 是中途质量读数/选择工具，不是替代完整 decay”。多环境 RLVR 比单环境 RL 更稳定，因为单环境会让其它 benchmark regress。SWE-RL 必须独立 stage，是因为端到端 software rollout 慢、context 长、环境重；若与短任务混训会拖慢所有更新。NVFP4 healing 切到 MXFP8 没有持续改善，说明最终低精度 recipe 对主 benchmark 已足够稳。

Limitations. 论文没有公开完整内部训练日志与所有 launch manifests，released repo 中部分 defaults 是 recipe/scaffold 而非论文最终 full-scale run；因此复现者需要区分 paper-reported config、Nemotron recipe config 和 Megatron-Bridge provider defaults。RL 部分也承认 1k GPU scale 下有硬件/软件间歇失败、端口绑定 TOCTOU race、SWE rollout 容器内存管理等系统问题。性能上，Nemotron 3 Super 并非所有 benchmark 都胜过 Qwen3.5 或 GPT-OSS，例如 AIME25、GPQA no-tools、SWE-Bench OpenHands/OpenCode/Codex 和 Arena-Hard-V2 等仍有差距；它的主要优势是开放权重、agentic data/RL recipe、长上下文与高吞吐的综合平衡。