deep nvidia nemotron3 super.md
论文类深度解读 · 2026-04-16
基于 NVIDIA 2026-04-03 发布的 Nemotron 3 Super Technical Report 完整技术报告
速查卡
| 维度 | 内容 |
|---|---|
| 论文/报告 | NVIDIA Nemotron 3 Super Technical Report (2026-04-03) |
| 一句话总结 | 120B 总参 / 12B 激活的混合 Mamba-Transformer MoE 模型,首次将 Latent MoE、Multi-Token Prediction 和 NVFP4 原生预训练三项技术同时整合进单一开源架构,专为 Agent 长任务推理设计 |
| 大白话版 | NVIDIA 把三种完全不同的”发动机”拼成一台混合引擎——Mamba 负责跑长路省油、Transformer Attention 负责关键弯道精确操控、MoE 负责在不增加油耗的前提下塞更多马力——然后用 4-bit 精度从出厂就调好了油门,专门给需要长时间干活的 AI Agent 用 |
| 核心要点 | 120B/12B 参数 · Hybrid Mamba-2 + Latent MoE + Transformer Attention · 原生 1M context · MTP 最高 3x 结构化生成加速 · NVFP4 原生预训练(Blackwell B200 上 4x vs FP8 H100)· 25T tokens 预训练 + 1.2M RL rollouts · PinchBench 85.6% · 吞吐 5x+ vs 上代 |
| 价值评级 | S — 这不是普通模型发布,而是一份完整的”Agent 原生模型架构设计规范”,三项首创技术的整合深度在开源模型中前所未见 |
| 适用场景 | 多 Agent 编排(主脑/规划层)、长代码仓库分析与修改、安全事件分类/溯源、工具调用密集型工作流、百万级上下文检索与推理 |
| 主要来源 | NVIDIA 技术博客 · 技术报告 PDF · NVIDIA Research |
与此前报道的关系
2026-04-02 我们发布了 NVIDIA Nemotron Coalition 深度解读,覆盖的是 GTC 2026 上宣布的八大 AI 实验室联盟事件。本文聚焦的是完全不同的事件——Nemotron 3 Super 模型本身的技术报告,深入拆解其架构设计、训练策略和性能表现。Coalition 是生态战略,Super 是工程产物。
核心 Insight:为什么是 Mamba + Attention + MoE 三体混合
在进入具体架构之前,先回答一个根本问题:为什么 NVIDIA 要同时混合三种完全不同的计算范式?
答案在于 Agent 工作负载的三个不可调和的需求:
| Agent 需求 | 单一架构的困境 | Nemotron 3 Super 的解法 |
|---|---|---|
| 超长上下文处理(100K-1M tokens 的工具输出、代码仓库、历史对话) | 纯 Transformer:注意力 O(n^2) 计算量和 KV cache 线性增长使 1M context 成本极高 | Mamba-2 层:线性时间复杂度,常量状态大小,高效处理长序列 |
| 精确信息检索(在百万 token 中定位特定事实、变量名、API 签名) | 纯 SSM/Mamba:缺乏显式注意力机制,“大海捞针”能力先天不足 | Transformer Attention 层:在关键深度交叉插入,提供精确的全局 recall |
| 高容量但低推理成本(Agent 任务高度异构——写代码、做计划、调工具、做判断) | Dense 模型:每次推理激活全部参数,Agent 高频调用下成本不可接受 | Latent MoE 层:120B 知识容量,12B 激活成本,压缩路由使 4x 专家数可用 |
这三者之间存在根本张力——没有一种单一架构能同时最优化三个维度。NVIDIA 的工程判断是:与其妥协于一种架构的”还行”,不如让三种架构各负其责。
这不是理论上的审美选择。它直接来自一个产业观察:
多 Agent 系统在真实运行中,上下文 token 消耗量是普通聊天的 15 倍以上,且任务高度异构——规划、检索、代码生成、工具调用、结果汇总在同一会话中反复交替。
在这种负载模式下,用单一 dense Transformer 跑所有事情,就像用一台赛车同时跑高速公路和越野赛——不是不能跑,但系统级成本会失控。
方法详解
一、整体架构
1.1 宏观层组成
Nemotron 3 Super 的骨架是一个重复块状结构,每个块由三类层按固定模式交替组成:
╔══════════════════════════════════════════════════════════════════════╗
║ Nemotron 3 Super — 整体架构 ║
╠══════════════════════════════════════════════════════════════════════╣
║ ║
║ 输入 Token Embeddings ║
║ │ ║
║ ▼ ║
║ ┌─────────────────────────────────────────────────────────────┐ ║
║ │ Block 1 │ ║
║ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ ║
║ │ │ Mamba-2 (x4) │→ │ Latent MoE(x2)│→ │ Transformer │ │ ║
║ │ │ 线性时间 │ │ 压缩路由 │ │ Attention (x1)│ │ ║
║ │ │ 长序列压缩 │ │ 稀疏激活 │ │ 精确检索 │ │ ║
║ │ └───────────────┘ └───────────────┘ └───────────────┘ │ ║
║ └─────────────────────┬───────────────────────────────────────┘ ║
║ │ ║
║ ▼ ║
║ ┌─────────────────────────────────────────────────────────────┐ ║
║ │ Block 2 │ ║
║ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ ║
║ │ │ Mamba-2 (x4) │→ │ Latent MoE(x2)│→ │ Transformer │ │ ║
║ │ │ │ │ │ │ Attention (x1) │ │ ║
║ │ └───────────────┘ └───────────────┘ └───────────────┘ │ ║
║ └─────────────────────┬───────────────────────────────────────┘ ║
║ │ ║
║ ... ║
║ │ ║
║ ▼ ║
║ ┌─────────────────────────────────────────────────────────────┐ ║
║ │ Block N (final) │ ║
║ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ ║
║ │ │ Mamba-2 (x4) │→ │ Latent MoE(x2)│→ │ Transformer │ │ ║
║ │ │ │ │ │ │ Attention (x1) │ │ ║
║ │ └───────────────┘ └───────────────┘ └───────────────┘ │ ║
║ └─────────────────────┬───────────────────────────────────────┘ ║
║ │ ║
║ ▼ ║
║ ┌─────────────────────────────────────────────────────────────┐ ║
║ │ MTP Head(s) — 多 token 并行预测 │ ║
║ │ ┌──────┐ ┌──────┐ ┌──────┐ │ ║
║ │ │ t+1 │ │ t+2 │ │ t+3 │ ... (共享权重设计) │ ║
║ │ └──────┘ └──────┘ └──────┘ │ ║
║ └─────────────────────────────────────────────────────────────┘ ║
║ ║
╚══════════════════════════════════════════════════════════════════════╝
1.2 关键参数一览
| 参数 | 数值 |
|---|---|
| 总参数量 | 120B |
| 推理激活参数量 | 12B |
| 激活/总参比 | 10% |
| 原生上下文窗口 | 1,000,000 tokens |
| 预训练 token 总量 | 25T(其中 10T 唯一去重 token) |
| Reasoning 额外训练 | 10B tokens |
| 编程问题数量 | 1500 万 |
| SFT 样本 | ~700 万(从 4000 万候选中筛选) |
| RL rollouts | 120 万(21 种环境配置) |
| 量化格式 | NVFP4(原生预训练) |
| 目标硬件 | NVIDIA Blackwell (B200) |
1.3 三类层的分工逻辑
这三类层不是随意堆叠,而是各自解决特定计算瓶颈:
数据流视角:一个 token 在 Nemotron 3 Super 中的旅程
Token x_i 进入模型
│
▼
┌──────────────────────────────────────────────┐
│ Mamba-2 层(多层连续) │
│ │
│ x_i → SSM State Update → 压缩表示 │
│ │
│ ● 时间复杂度:O(n) — 线性于序列长度 │
│ ● 状态大小:常量 — 不随 context 增长 │
│ ● 能力:高效编码长程依赖、顺序模式 │
│ ● 弱点:无法像 attention 一样"回头看" │
│ 任意位置 │
└──────────────────┬───────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Latent MoE 层(多层连续) │
│ │
│ h_i ──→ [压缩投影] ──→ latent_i │
│ │ │
│ [Router 选择 top-K 专家] │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ ▼ ▼ ▼ │
│ Expert_a Expert_b Expert_c │
│ │ │ │ │
│ └─────────────┼─────────────┘ │
│ │ │
│ [加权合并] │
│ │ │
│ [反投影回全维度] │
│ ▼ │
│ output_i │
│ │
│ ● 专家数量:因压缩可达标准MoE的4倍 │
│ ● 激活成本:与标准MoE相当 │
│ ● 能力:高容量异构知识存储 │
└──────────────────┬───────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Transformer Attention 层(关键深度交叉插入) │
│ │
│ Q = W_q · h_i │
│ K = W_k · H_all (全序列) │
│ V = W_v · H_all │
│ │
│ Attention(Q, K, V) = softmax(QK^T/√d) · V │
│ │
│ ● 时间复杂度:O(n^2) — 但仅在少量层出现 │
│ ● 能力:精确的全局信息检索、跨位置关联 │
│ ● 角色:为 Mamba 层积累的压缩表示 │
│ 提供"校准锚点" │
└──────────────────┬───────────────────────────┘
│
▼
下一个 Block...
为什么 Attention 层只在”关键深度”出现?
这是一个精心的工程权衡。如果每一层都用 attention,1M context 的 KV cache 和计算量会完全不可行。但如果完全没有 attention,Mamba 的压缩状态会在长序列中逐渐丢失细节。NVIDIA 的做法是在模型的特定深度交叉插入 attention 层——类似于在高速公路每隔一定距离设置一个检查站,让信息流定期”校验”自己有没有偏离。
二、Latent MoE 详解
Latent MoE 是 Nemotron 3 Super 在 MoE 架构上最重要的创新。它解决的核心问题是:如何在不增加推理成本的前提下,大幅增加专家数量。
2.1 标准 MoE 的瓶颈
在传统 MoE 中,每个 token 以 full hidden dimension(比如 d=8192)直接送入 router,router 在全维度上计算每个专家的亲和度分数,然后选择 top-K 专家进行计算:
标准 MoE 流程:
h_i (d=8192)
│
▼
┌──────────────┐
│ Router │ ← 在 d=8192 维度上计算 N 个专家的分数
│ W_r: d × N │ 当 N 很大时,这个矩阵本身就很大
└──────┬───────┘
│ top-K selection
▼
┌──────────────────────────────┐
│ Expert_1 Expert_2 ... │ ← 每个专家接收 d=8192 的输入
│ (d → 4d → d) │ 每个专家的参数量 ∝ d^2
└──────────────────────────────┘
问题在于:
- Router 计算量 ∝ d × N(隐藏维度 × 专家数量)
- 每个专家的参数量 ∝ d^2
- 想增加专家数量 N → router 成本和专家总参数同时线性增长
- 在固定推理预算下,N 的上限非常有限
2.2 Latent MoE 的核心思路:压缩后再路由
Latent MoE 的关键洞察是:token 不需要在全维度上进行路由决策和专家计算。
Latent MoE 流程:
h_i (d=8192)
│
▼
┌──────────────────────┐
│ Down-Projection │ ← W_down: d → d_latent (e.g., 8192 → 1024)
│ h_i → z_i │ 压缩 8x
│ (d_latent = d/r) │
└──────────┬───────────┘
│
▼
z_i (d_latent=1024)
│
┌─────┴──────┐
│ │
▼ ▼
┌─────────┐ ┌──────────────────────────────────────┐
│ Router │ │ Expert Computation │
│ W_r: │ │ │
│ d_l × N │ │ Expert_k(z_i) = W_up_k · σ(W_gate_k │
│ │ │ · z_i) │
│ N 可达 │ │ │
│ 标准MoE │ │ 每个专家参数 ∝ d_latent^2 │
│ 的 4x │ │ = (d/r)^2 = d^2 / r^2 │
└────┬────┘ │ 比标准专家小 r^2 倍 │
│ └───────────────────┬────────────────────┘
│ top-K │
└───────────┬───────────────┘
│ 加权合并
▼
o_i (d_latent=1024)
│
▼
┌───────────────────────┐
│ Up-Projection │ ← W_up: d_latent → d (1024 → 8192)
│ o_i → y_i │ 恢复到全模型维度
└───────────┬───────────┘
│
▼
y_i (d=8192) + 残差连接
2.3 数学上为什么能”4 倍专家同成本”
假设压缩比 r = 8(从 d=8192 压到 d_latent=1024):
| 组件 | 标准 MoE (N 专家) | Latent MoE (4N 专家) |
|---|---|---|
| Router 参数 | d × N = 8192N | d_latent × 4N = 1024 × 4N = 4096N |
| Router 计算 | 8192N FLOPs | 4096N FLOPs(减半) |
| 单专家参数 | ~2 × d × d_ff | ~2 × d_latent × d_ff_small |
| 单专家计算 | ∝ d^2 | ∝ d_latent^2 = d^2/64 |
| K 个专家总计算 | K × d^2 | K × d^2/64 |
| 投影开销 | 0 | 2 × d × d_latent(down + up) |
| 总推理成本 | ~K × d^2 | ~K × d^2/64 + 2 × d × d_latent ≈ 同量级 |
关键点在于:虽然多了 down/up projection 的额外成本,但每个专家在低维空间里计算量大幅缩减。净效果是:相同 FLOPs 预算下,可以容纳约 4 倍数量的专家。
2.4 为什么更多细粒度专家对 Agent 特别重要
Agent 任务的异构性远高于普通对话:
Agent 典型工作流中一个 session 内的任务类型切换:
时间 ──────────────────────────────────────────────────→
[Python代码生成] → [SQL查询构建] → [API文档理解]
→ [JSON Schema验证] → [安全漏洞分析]
→ [自然语言摘要] → [Bash脚本生成]
→ [数学推理] → [工具调用编排]
如果只有 N 个粗粒度专家,每个专家必须覆盖多种子任务,导致”样样通样样松”。而 4N 个细粒度专家可以实现更精确的任务-专家匹配——Python 有 Python 专精的专家,SQL 有 SQL 专精的专家,安全分析有安全分析的专家。
这不是理论推演。技术报告明确给出了结论:Latent MoE 使模型在多任务 benchmark 上的表现显著优于等激活参数的标准 MoE baseline。
三、Multi-Token Prediction (MTP) 详解
3.1 核心机制
标准自回归模型每次前向传播只预测下一个 token。MTP 让模型在单次前向传播中同时预测未来多个 token(t+1, t+2, t+3, …):
标准自回归 vs Multi-Token Prediction
标准自回归(1 token/step):
═══════════════════════════════════════════
Step 1: [context...] → 预测 t+1
Step 2: [context... t+1] → 预测 t+2
Step 3: [context... t+1 t+2] → 预测 t+3
...
总步数 = 生成 token 数
MTP(k tokens/step,k=3 为例):
═══════════════════════════════════════════
┌──→ Head_1 → t+1 (主预测)
│
Model Forward ──────┼──→ Head_2 → t+2 (辅助预测)
│
└──→ Head_3 → t+3 (辅助预测)
如果 t+2 和 t+3 的预测通过验证 → 直接接受
如果不通过 → 回退到标准逐 token 生成
理想情况下:总步数 ≈ 生成 token 数 / k
3.2 共享权重设计
Nemotron 3 Super 的 MTP 实现有一个关键设计决策:MTP heads 之间共享权重。
MTP 共享权重架构:
Transformer/Mamba/MoE Backbone
│
▼
┌────────────────┐
│ Shared Trunk │ ← 所有 MTP head 共用
│ (最后几层) │ 的特征提取层
└────────┬───────┘
│
┌─────────┼─────────┐
▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐
│Head 1 │ │Head 2 │ │Head 3 │
│(t+1) │ │(t+2) │ │(t+3) │
│ │ │ │ │ │
│ W_out │ │ W_out │ │ W_out │ ← 各 head 仅有轻量
│ +bias │ │ +bias │ │ +bias │ 独立参数
└───────┘ └───────┘ └───────┘
共享权重优势:
● 参数增量极小(仅 head 层的差异参数)
● 训练时梯度信号更丰富(每步更新利用多 token loss)
● 不影响模型整体大小
3.3 训练价值 vs 推理价值
MTP 的价值在训练和推理中有不同体现:
训练价值:
- 强迫模型理解更长程的 token 依赖关系
- 每步提供更密集的梯度信号(不只是”下一个 token 对不对”,而是”未来几个 token 的连续分布对不对”)
- 特别有利于学习结构化输出的模式(代码、JSON、工具调用的固定格式)
推理价值:
- 天然实现 speculative decoding 的 draft 功能
- 不需要额外的小 draft model
- 对高确定性序列(模板代码、JSON key、函数签名)加速最显著
- 技术报告声明:结构化生成场景最高 3x wall-clock 加速
3.4 为什么结构化生成加速最大
加速效果与 token 可预测性的关系:
自然语言对话(加速较小):
"I think the best approach would be to [???] the [???] and then [???]"
↑ ↑ ↑
难以准确预测多步 分支点多
结构化代码生成(加速最大):
"def calculate_total(items: list[dict]) -> float:\n total = 0.0\n for item in items:"
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
大量 token 序列高度可预测(语法模板、缩进、类型标注)
JSON 工具调用(加速最大):
{"tool": "search", "parameters": {"query": "...", "max_results": 10}}
↑↑↑↑ ↑↑↑↑↑↑ ↑↑↑↑↑↑↑↑↑↑↑↑
结构固定、key 名可预测、格式化字符高度确定
Agent 场景中,工具调用、代码生成、结构化输出占据了大量生成 token。MTP 正好命中了这些高频、高确定性的生成模式。这就是为什么 NVIDIA 说它是”为 Agent 设计的”——不是营销话术,而是架构上的精准匹配。
四、NVFP4 原生预训练
4.1 与”训后量化”的根本区别
大多数量化模型走的是 PTQ(Post-Training Quantization)路线:
传统路线(训后量化):
═══════════════════════════════════════════
FP32/FP16/BF16 预训练 → 高精度模型 → 量化到 INT8/FP8/INT4
↑
精度损失在这里发生
模型从未"见过"低精度算术
某些权重分布对量化不友好
NVFP4 原生预训练路线(Nemotron 3 Super):
═══════════════════════════════════════════
NVFP4 预训练 → 模型从第一步就在 4-bit 算术下学习
↑
模型权重分布从一开始就适应 4-bit 表达
不存在"高精度到低精度的落差"
量化友好的权重分布是训练出来的,不是压出来的
4.2 NVFP4 的数值格式
NVFP4 是 NVIDIA 专为 Blackwell 架构设计的 4-bit 浮点格式:
NVFP4 格式(4 bits total):
┌───┬───┬───┬───┐
│ S │ E │ E │ M │
└───┴───┴───┴───┘
│ └──┬──┘ │
│ 指数(2bit) 尾数(1bit)
符号位
可表示值域:{±0, ±0.5, ±1, ±1.5, ±2, ±3, ±4, ±6} × scale
对比:
● FP16: 16 bits → 65536 种不同值
● FP8: 8 bits → 256 种不同值
● NVFP4: 4 bits → 16 种不同值(含 scale)
每个参数存储:FP16=2字节 → FP8=1字节 → NVFP4=0.5字节
120B 参数模型显存需求:
FP16: ~240 GB
FP8: ~120 GB
NVFP4: ~60 GB ← 单块 B200 (192GB HBM3e) 轻松容纳
4.3 Blackwell 硬件加速
NVFP4 不是一个通用格式——它是专为 Blackwell 架构的 Tensor Core 设计的:
| 对比维度 | FP8 on H100 | NVFP4 on B200 | 倍数 |
|---|---|---|---|
| 单卡算力(理论) | ~1979 TFLOPS (FP8) | ~4500+ TFLOPS (FP4) | ~2.3x |
| 显存带宽 | 3.35 TB/s | 8 TB/s (HBM3e) | ~2.4x |
| 显存容量 | 80 GB | 192 GB | 2.4x |
| 模型容纳 | 120B FP8 刚好 | 120B FP4 余裕极大 | — |
| 端到端吞吐 | 基线 | 约 4x | 4x |
NVIDIA 技术报告声明的 4x 加速不是纯算力提升,而是 FP4 精度 × Blackwell 架构 × 显存带宽三者叠加的综合效果。
4.4 生态锁定效应
必须指出一个事实:NVFP4 目前只有 Blackwell 架构原生支持。这意味着:
- 在 H100/A100 上运行 Nemotron 3 Super 需要回退到 FP8 或更高精度,性能优势大打折扣
- AMD MI300X、Intel Gaudi 等竞品硬件目前没有 FP4 Tensor Core
- 选择 Nemotron 3 Super 作为核心模型,在某种程度上也是选择了 NVIDIA Blackwell 生态
这不是缺点——这是 NVIDIA 的商业战略。但使用者需要清醒认识到这一层绑定关系。
五、训练策略:25T Tokens 到 1.2M RL Rollouts
5.1 训练阶段全景
Nemotron 3 Super 训练流程:
Phase 1: 大规模预训练
══════════════════════════════════════════════════
● 25T tokens 总计(10T 唯一去重 token)
● NVFP4 原生精度
● Mamba-2 + Latent MoE + Transformer 混合架构
● 目标:建立广泛的世界知识和语言能力
│
▼
Phase 2: Reasoning 专项强化
══════════════════════════════════════════════════
● 额外 10B tokens
● 重点:数学推理、逻辑链、代码推理
● 1500 万编程问题
│
▼
Phase 3: SFT(监督微调)
══════════════════════════════════════════════════
● ~700 万样本(从 4000 万候选语料中筛选)
● 筛选率:17.5% — 表明数据质量把控非常严格
● 覆盖指令遵循、对话、代码、工具调用等
│
▼
Phase 4: RL 后训练
══════════════════════════════════════════════════
● 120 万环境 rollouts
● 21 种不同环境配置
● 环境类型涵盖:
- 代码执行验证
- 工具调用序列验证
- 多步规划可验证性
- 动态环境行为稳定性
5.2 数据规模对比
| 模型 | 预训练 token | SFT 样本 | RL 策略 |
|---|---|---|---|
| Nemotron 3 Super | 25T(10T 唯一) | ~7M | 1.2M rollouts / 21 环境 |
| DeepSeek-V3 | 14.8T | 150 万 | GRPO |
| Llama 3.1 405B | 15T | 未公开 | RLHF (DPO + PPO) |
| Qwen 2.5 72B | ~18T | 未公开 | RLHF |
25T tokens 是目前公开报告中最大的预训练规模之一。但更关键的不是数量,而是 10T 唯一 token + 多 epoch 策略。这意味着模型在大量数据上做了 2-3 遍以上的训练,这在最近的研究中被证明对深度理解和长尾知识有显著帮助。
5.3 RL 训练的 21 种环境配置
这是 Nemotron 3 Super 训练中最值得关注的设计。21 种环境不是 21 个 benchmark,而是 21 种不同的交互模式和验证标准:
RL 环境配置(推测性分类,基于技术报告描述):
代码执行类:
├── Python 单元测试通过率
├── 多语言代码编译/运行验证
├── 代码修改后回归测试
└── 代码安全审计
工具调用类:
├── 单工具正确调用
├── 多工具顺序编排
├── 工具输出解析与决策
└── 工具调用失败恢复
规划推理类:
├── 多步计划可执行性验证
├── 子目标分解与追踪
├── 长程任务 goal drift 检测
└── 条件分支决策
对话交互类:
├── 多轮指令遵循一致性
├── 信息提取准确性
├── 安全边界遵守
└── 拒绝不当请求
Agent 系统类:
├── 多 Agent 协作编排
├── 网络安全事件分类
├── 长文档理解与问答
├── 结构化报告生成
└── 环境状态感知与适应
这种多环境 RL 训练的意义在于:模型不是在静态 benchmark 上刷分,而是在模拟真实 Agent 工作的动态环境中学习。这和纯 RLHF(基于人类偏好排序)有本质区别——RLHF 学的是”人觉得哪个回答好”,环境 RL 学的是”哪个行为真的能完成任务”。
实验结果
一、PinchBench:85.6%
PinchBench 是 NVIDIA 主推的综合 Agent 能力评测基准,覆盖代码生成、工具调用、多步推理、长上下文理解等维度。
| 模型 | PinchBench 综合 | 激活参数 | 备注 |
|---|---|---|---|
| Nemotron 3 Super | 85.6% | 12B | 开源最佳 |
| DeepSeek-V3 | ~78% (推测) | ~37B | 3x 激活参数 |
| Llama 3.1 70B | ~72% (推测) | 70B | Dense,6x 激活参数 |
| Qwen 2.5 72B | ~74% (推测) | 72B | Dense,6x 激活参数 |
需要注意的是:PinchBench 是 NVIDIA 自家的 benchmark。虽然 NVIDIA 声称其设计经过第三方审计,但在社区广泛采用和独立验证之前,这个分数的可比性需要打折扣。
二、吞吐量:5x+ vs 上一代
| 对比维度 | 上一代 Nemotron Super | Nemotron 3 Super | 提升 |
|---|---|---|---|
| tokens/sec (batch serving) | 基线 | 5x+ | 5 倍以上 |
| 结构化生成 wall-clock | 基线 | ~3x faster (via MTP) | 3 倍 |
| 显存效率 (FP4 vs FP8) | 基线 | ~2x | 2 倍 |
5x 吞吐提升来自三个因素的叠加:
- Latent MoE:压缩维度使路由和专家计算更快
- MTP:单次前向传播输出多 token
- NVFP4:4-bit 计算在 Blackwell 上原生加速
三、Nemotron 3 系列首次引入的技术
| 技术 | Nemotron 3 Super 之前 | Nemotron 3 Super |
|---|---|---|
| Latent MoE | 无 | 首次引入 |
| Multi-Token Prediction | 无 | 首次引入 |
| NVFP4 原生预训练 | 无 | 首次引入 |
| Mamba-2 + Attention 混合 | 有(前代已有原型) | 成熟化 |
三项技术同时首次整合进同一模型——这在工程复杂度上非常激进。通常一个模型版本引入一项新架构特性已经需要大量验证,同时引入三项说明 NVIDIA 在这代模型上投入了极大的工程资源。
复现与部署评估
一、开放程度评级:A+
Nemotron 3 Super 在开放程度上是 2026 年开源模型的标杆之一:
| 开放维度 | 状态 | 详情 |
|---|---|---|
| 模型权重 | 开放 | 完整权重可下载 |
| 训练数据集 | 部分开放 | 数据配方和来源公开,部分原始数据可获取 |
| 训练 recipes | 开放 | 预训练、SFT、RL 的完整配方 |
| 评估 recipes | 开放 | PinchBench 及其他评测方法论 |
| 部署 cookbooks | 开放 | 多框架部署指南 |
二、部署生态
部署支持的广度非常突出:
推理服务平台:
| 平台 | 类型 |
|---|---|
| Perplexity | API 服务 |
| OpenRouter | API 聚合 |
| build.nvidia.com | NVIDIA 原生 |
| Baseten | 模型托管 |
| Cloudflare | 边缘推理 |
| CoreWeave | GPU 云 |
| DeepInfra | 推理 API |
| Fireworks AI | 推理优化 |
| Google Cloud | 云平台 |
| Lightning AI | ML 平台 |
| Modal | Serverless |
| Together AI | 推理 API |
推理框架:
| 框架 | 用途 |
|---|---|
| vLLM | 通用高效推理 |
| SGLang | 结构化生成优化 |
| TensorRT-LLM | NVIDIA 原生高性能推理 |
微调框架:
| 框架 | 用途 |
|---|---|
| NeMo Megatron-Bridge | LoRA / SFT |
| NeMo Automodel | 自动化微调 |
| NeMo RL | GRPO / DAPO 强化学习 |
三、实际复现门槛
虽然开放程度很高,但完整复现面临几个现实门槛:
- 预训练:25T tokens + NVFP4 精度需要大规模 Blackwell 集群,成本在数千万美元级别
- RL 训练:21 种环境配置的 1.2M rollouts 需要自建或获取环境基础设施
- 微调/适配:LoRA 微调在单机多卡 B200 上可行,门槛相对可接受
- 推理部署:通过上述平台直接使用零门槛;自建部署需 Blackwell GPU 以获得最优性能
实操建议:对绝大多数团队来说,合理路径是”通过 API 使用 + LoRA 微调适配”,而非完整复现训练流程。
批判性分析
一、优势与创新点
1. 架构层面的系统性思考
Nemotron 3 Super 最大的价值不在于任何单一技术,而在于把”Agent 工作负载特征”作为架构设计的第一原则。Mamba 解决长序列效率、Attention 解决精确检索、Latent MoE 解决异构任务容量、MTP 解决结构化生成速度、NVFP4 解决部署成本——每个组件都对应一个明确的 Agent 痛点。
这种”从负载特征倒推架构”的思路,在开源模型领域不常见。大多数开源模型仍然是”通用模型 + Agent prompt”的范式。
2. Latent MoE 的原创性
Latent MoE 是本报告中最具原创性的架构贡献。压缩后路由的思路虽然在学术界有先例(如 Sparse Upcycling、Soft MoE 的变体),但将其系统化地整合进 120B 规模模型并给出”4x 专家同成本”的工程验证,这是首次。
3. 开放程度
在 2026 年”开源 vs 开放权重”的争论中,NVIDIA 站在了”全栈开放”一边:权重、数据配方、训练 recipe、评测方法论、部署指南全部公开。这对社区的价值远超只开放 checkpoint。
二、局限性与待验证点
1. PinchBench 的独立性问题
NVIDIA 用自家 benchmark 作为核心性能指标,虽然声称经过第三方审计,但在学术界和社区的独立验证之前,85.6% 这个数字的含金量需要打折。对比之下,SWE-bench、AIME、GPQA 等社区广泛采用的 benchmark 结果未见详细报告。
建议等待:HuggingFace Open LLM Leaderboard 或 LMSYS Arena 上的独立评测结果。
2. Mamba-Transformer 混合的工程成熟度
纯 Transformer 架构经过了 7 年以上的工程优化积累。vLLM、TensorRT-LLM、llama.cpp 等框架对 Transformer 的 attention、KV cache、量化等都有深度优化。Mamba-Transformer 混合架构的工具链成熟度远不及此:
- Mamba 层的推理优化库仍在早期
- 混合架构的 KV cache 管理(只有部分层需要)增加了 serving 复杂度
- 社区贡献者对 Mamba 层的熟悉度远低于 attention 层
- llama.cpp / GGML 等社区推理引擎对混合架构的支持可能滞后
3. 120B/12B 的”有效容量”问题
120B 总参 / 12B 激活听起来是很好的效率比,但一个未回答的问题是:12B 激活参数的有效推理能力,和一个 12B dense 模型相比到底强多少?
MoE 的理论优势是”用更大的参数池存储更多知识”。但实际效果取决于:
- 路由器是否真的能在需要时选到正确的专家
- 专家之间的知识是否有大量冗余
- Latent MoE 的压缩是否丢失了关键的路由信号
技术报告给出了正面结论,但独立消融实验(12B dense vs 120B/12B MoE)的对比数据不够详细。
4. NVFP4 的生态锁定
如前分析,NVFP4 原生预训练将最优推理性能深度绑定到 Blackwell 硬件。这对于在 H100、AMD MI300X 或其他硬件上部署的团队意味着性能折扣。虽然模型可以以 FP8 或更高精度运行在其他硬件上,但这会失去 NVFP4 预训练的精度优势——因为模型的权重分布是针对 4-bit 算术优化的,“升精度”不一定能带来预期的精度提升。
三、与竞品的横向对比
Nemotron 3 Super vs DeepSeek-V3
| 维度 | Nemotron 3 Super | DeepSeek-V3 |
|---|---|---|
| 总参数 | 120B | 671B |
| 激活参数 | 12B | ~37B |
| MoE 类型 | Latent MoE(压缩路由) | 标准 MoE |
| 序列建模 | Mamba-2 + Attention 混合 | 纯 Transformer |
| 上下文窗口 | 1M | 128K |
| 量化 | NVFP4 原生 | FP8 |
| MTP | 有 | 有 |
| 训练 token | 25T | 14.8T |
| 开源程度 | 权重 + recipe + 数据配方 | 权重 + 部分文档 |
| 硬件绑定 | Blackwell 最优 | 硬件中立 |
| 通用 benchmark | 待独立验证 | 已有广泛独立验证 |
判断:Nemotron 3 Super 在架构创新和 Agent 专项设计上更激进,但 DeepSeek-V3 在通用 benchmark 验证和硬件中立性上更成熟。对于 NVIDIA 生态内的 Agent 应用,Super 可能是更优选择;对于跨硬件的通用部署,DeepSeek-V3 的风险更低。
Nemotron 3 Super vs Llama 3.1 405B
| 维度 | Nemotron 3 Super | Llama 3.1 405B |
|---|---|---|
| 总参数 | 120B | 405B |
| 激活参数 | 12B | 405B (Dense) |
| 架构 | Hybrid Mamba-Transformer MoE | Dense Transformer |
| 上下文 | 1M | 128K |
| 推理成本 | 极低(12B 激活 + FP4) | 极高(405B dense) |
| 通用能力 | Agent 专精 | 通用强 |
| 部署门槛 | 中等(需 Blackwell 最优) | 极高(需多卡大显存) |
判断:两者面向不同场景。Llama 405B 是”不计成本的通用能力最大化”,Nemotron 3 Super 是”Agent 场景下的效率最大化”。在多 Agent 系统中,Super 的经济性优势(12B vs 405B 激活)可能是决定性的。
Nemotron 3 Super vs Qwen 2.5 系列
| 维度 | Nemotron 3 Super | Qwen 2.5 72B |
|---|---|---|
| 激活参数 | 12B | 72B |
| 架构 | Hybrid MoE | Dense |
| 中文能力 | 待验证(技术报告未重点覆盖) | 强 |
| 上下文 | 1M | 128K(扩展至 1M) |
| 工具调用 | 原生 RL 训练 | SFT + RLHF |
| 社区生态 | NVIDIA 主导 | 阿里 + 开源社区 |
判断:对于中文场景和非 NVIDIA 硬件环境,Qwen 系列仍是更稳妥的选择。Nemotron 3 Super 的优势集中在英文 Agent 工作负载和 NVIDIA 生态。
Nemotron 3 Super vs Gemma 4
| 维度 | Nemotron 3 Super | Gemma 4 31B |
|---|---|---|
| 总参数 | 120B | 31B |
| 激活参数 | 12B | 31B (Dense) |
| 架构 | Hybrid Mamba-Transformer MoE | Dense Transformer + PLE |
| 模态 | 文本 | 多模态(图+文+音) |
| 上下文 | 1M | 256K |
| 许可证 | 开源 | Apache 2.0 |
| Agent 专项 | 深度优化 | 通用+Agent |
| Arena Elo | 待独立评测 | 1452 |
判断:Gemma 4 在多模态和 Arena Elo 上有明确优势。Nemotron 3 Super 在 Agent 专项能力(超长上下文、工具调用 RL、MoE 效率)上更强。两者是互补关系而非直接替代。
四、深层问题
1. 混合架构是否会成为主流?
Nemotron 3 Super 押注的”Mamba + Attention + MoE”三体混合是一个大胆赌注。如果成功,它可能定义下一代 Agent 模型的架构范式。但风险在于:
- 工程复杂度远高于纯 Transformer
- 社区贡献者需要同时理解三种范式
- 工具链适配成本高
- 如果纯 Transformer + 高效注意力(如 FlashAttention-3、Ring Attention)能够以更简单的方式解决长上下文问题,混合架构的复杂度回报比可能不够高
2. “Agent 原生模型”是真需求还是过度设计?
NVIDIA 的核心叙事是:“Agent 时代需要专门为 Agent 设计的模型”。但反面论点是:
- 通用强模型 + 好的 Agent 框架 + 好的 prompt engineering 可能已经够用
- Agent 的瓶颈可能不在模型架构,而在 Agent 框架、工具生态、记忆管理等基础设施
- 过度专项化可能牺牲通用能力
技术报告对这个问题的回应是:Super 在通用 benchmark 上也表现强劲。但独立验证仍需时间。
3. NVFP4 原生预训练的可复现性
NVFP4 原生预训练是一项重要的工程创新,但其可复现性取决于:
- 是否有非 NVIDIA 硬件可以训练 FP4 模型
- 训练中的数值稳定性技巧是否完整公开
- 社区是否有足够的 Blackwell 集群来验证
如果只有 NVIDIA 自己能训练 NVFP4 模型,这项技术的开源价值会大打折扣。
总结判断
Nemotron 3 Super 技术报告的核心价值可以用三句话概括:
第一,它给出了”Agent 原生模型应该长什么样”的一份完整工程答案。 不是理论推导,不是概念原型,而是一个经过 25T token 预训练、120 万次 RL rollout、12 个推理平台部署验证的实际产品。
第二,Latent MoE 是本报告最重要的架构贡献。 “压缩后路由”这一思路将 MoE 的专家容量从线性成本提升到了亚线性成本,为未来超大规模 MoE 模型指出了一条清晰的效率路线。
第三,这份报告也是 NVIDIA “硬件-模型-生态”纵向整合战略的技术载体。 NVFP4 原生预训练将模型性能与 Blackwell 硬件深度绑定,12 个推理平台的首发部署将 NVIDIA 从芯片供应商延伸为 AI 基础设施架构师。技术创新和商业战略在这里是一体两面。
对于从业者的实操建议:
- 正在做 Agent 系统的团队:立即评估 Nemotron 3 Super 作为主脑/规划层模型。12B 激活参数 + 1M context + MTP 加速的组合,在 Agent 场景的性价比可能是目前最优的
- 在 NVIDIA 生态内的团队:这可能是目前最适合 Blackwell 部署的开源模型,没有之一
- 在非 NVIDIA 硬件上部署的团队:等待独立 benchmark 验证,对比 DeepSeek-V3、Qwen 系列在你的具体任务上的表现后再决策
- 模型架构研究者:Latent MoE 和 Mamba-Transformer 混合的具体工程选择值得深入研究,这份技术报告是难得的工程参考文献