Nemotron-3 在 DGX Spark 上的评估：全栈分析——架构、量化和结果

问题

我们在 DGX Spark（spark-56bc，NVIDIA GB10 Grace-Blackwell，121 GB 统一内存）上运行了两个生产模型：

• Qwen3.6-35B-A3B-NVFP4 — 350亿总参数 / 30亿活跃参数，NVFP4 量化，vLLM 0.24.0
• Gemma-4-26B-A4B-NVFP4 — 260亿总参数 / 40亿活跃参数，NVFP4 量化，vLLM nightly

两者都是纯 Transformer MoE 模型。NVIDIA 的 Nemotron-3 系列走了一条根本不同的架构路线：Mamba-Transformer 混合模型 + MoE。Mamba 层（状态空间模型）以不同于注意力机制的方式处理序列——它们维护一个循环状态，而不是关注所有先前的 token。这带来了不同的推理特性：可能更好的长上下文处理、不同的失效模式，以及不同的精度/吞吐量权衡。

问题：对于我们的工作负载，Mamba 混合架构是否比我们当前运行的模型更稳健？

我们将在自己的硬件上，使用自己的基准测试，用自己的数据来找出答案。

我们评估的内容

Nemotron-3 系列有三个等级。我们评估前两个等级：

模型总参数量 / 活跃参数格式内存架构Nemotron-3-Nano-30B-A3B316亿 / 36亿FP831.4 GiBMoE + Mamba混合模型Nemotron-3-Super-120B-A12B1200亿 / 120亿NVFP4 混合75.0 GiB（实测）MoE + Mamba混合模型

Super 等级的活跃参数是 Nano 的 3.3 倍——这才是真正的能力提升。但它首先需要能够适配我们的硬件。

为何 Mamba 很重要

标准 Transformer 模型会关注所有先前的 token——序列长度计算复杂度为 O(n²)。Mamba（状态空间模型）维护一个固定大小的循环状态——计算复杂度为 O(n)。在像 Nemotron-3 这样的混合模型中，一些层是 Mamba，一些层是 Transformer Attention。架构决定每层使用哪种。

这很重要，原因有二：

• 长上下文： Mamba 层不会随着上下文增长而内存爆炸。对于 32K+ token 的上下文，Mamba 层比 Attention 更便宜。
• 不同的推理特性： 循环状态压缩信息的方式与 Attention 不同。某些任务可能受益，某些则不然。唯一的方法是进行基准测试。

NVIDIA 公布的基准测试数据

根据 ModelOpt 0.45.0 教程（examples/megatron_bridge/tutorials/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16/README.md），官方 Nemotron-3-Nano-30B-A3B-BF16 得分：

基准测试得分重复次数MMLU Pro78.21GPQA Diamond70.3 ± 1.78GPQA Diamond（带工具）74.2 ± 1.98LiveCodeBench v668.9 ± 0.94AIME 202586.8 ± 4.432AIME 2025（带工具）97.7 ± 3.332IFBench69.28SciCode（子任务）31.8 ± 1.28平均值72.1

FP8 变体保留了 70.2 的平均值——下降了 1.9 个点。在单个 H100 上的 vLLM 吞吐量（ISL=32768，OSL=1024）：

检查点内存输出 tok/s加速比BF16（官方）58.9 GiB5981.0×FP8（官方）31.4 GiB1,3232.2×

这些是 NVIDIA 在 H100 上的数据。我们的 GB10 是不同的硬件——我们需要自己的测量结果。

我们的测试方法

smf-bench：我们自己的测试标准

我们构建了 smf-bench —— 一个内部基准测试套件，旨在评估 LLM 在我们自己的工作负载上的表现，而不是学术代理指标。它兼容 OpenAI 且与端点无关：指向任意 vLLM 实例即可运行。

• 仓库： github.com/smfworks/smf-bench（MIT 许可，公开）
• 测试： 9 个套件共 181 项测试
• 套件： 推理 (8)、数学 (30)、编程 (30)、reasoning_tier0 (30)、指令遵循 (30)、散文 (30)、写作 (5)、工具调用 (2)、智能体 (16)
• 难度等级： 5 个等级 —— 简单 / 中等 / 困难 / 专家 / 前沿
• 评估器： 正则匹配、单元测试执行、结构计数、推理内容回退
• 持久化： 每次测试后增量保存 JSON
• 重试逻辑： 每次测试最多 4 次尝试，指数退避
• 推理模型检测： 推理模型（Nemotron、DeepSeek-R1、Qwen3）自动使用 max_tokens=4096，非推理模型无限制

为何使用我们自己的基准测试

我们不想依赖那些超出我们控制范围的第三方基准测试套件。NVIDIA 在 H100 上发布标准学术基准测试（MMLU、GPQA、AIME、LiveCodeBench）的数据。这些是有用的参考点，但是：

• 不同的硬件 —— GB10 Grace-Blackwell 不是 H100。内存带宽、SM 数量和统一内存架构都不同。
• 不同的工作负载 —— 学术基准测试测试学术技能。我们的生产工作负载包括智能体工具使用、结构化输出生成和多步骤指令遵循——这些是学术基准测试不一定覆盖的。
• 不同的软件栈 —— vLLM 版本、容器镜像和 vLLM 标志都会影响性能。NVIDIA 的数据使用他们自己的栈；我们使用我们的。
• 所有权 —— 测试标准应由 SMF Works 拥有，而不是绑定到其他人不断发展的项目。当第三方基准测试更改其测试集或评分方法时，历史比较将变得无效。我们的基准测试在我们自己的控制之下。

硬件

• DGX Spark (spark-56bc)
• NVIDIA GB10 Grace-Blackwell, aarch64
• 121 GB 统一内存（CPU + GPU 共享）
• CUDA 13.0, 驱动 580.159.03
• 3.7 TB NVMe 存储

阶段 1：Nano 等级 —— 三方比较

比较中的模型

#模型格式总参数量 / 活跃参数内存vLLM 版本1Qwen3.6-35B-A3B-NVFP4NVFP43500亿 / 30亿~30 GiBv0.24.02Gemma-4-26B-A4B-NVFP4NVFP42600亿 / 40亿~22 GiBnightly3Nemotron-3-Nano-30B-A3B-FP8FP8316亿 / 36亿31.4 GiBNGC 容器

每个模型单独部署，独占 GPU 访问——无并发推理工作负载。测试顺序运行，每个测试超时 120 秒，每次测试最多重试 4 次。

总体结果

模型通过失败错误通过率耗时Gemma-4-26B-A4B-NVFP4152263**84.0%**56.3 分钟Qwen3.6-35B-A3B-NVFP412952071.3%27.6 分钟Nemotron-3-Nano-30B-A3B-FP89982054.7%212.0 分钟

Gemma-4-26B 是阶段 1 在精度上的明显赢家。Qwen3.6-35B 是速度冠军——比 Nemotron 快 7.7 倍，比 Gemma 快 2 倍。Nemotron-3-Nano 是三者中最慢且得分最低的。

阶段 2：Super 等级 —— 部署与适配

挑战

Nemotron-3-Super-120B-A12B-NVFP4 是一个总参数 1200 亿、12B 活跃参数的模型。NVFP4 检查点在磁盘上占用 80.4 GB（17 个 safetensors 分片）。在 121 GB 统一内存上，问题很简单：它能放下吗？

混合精度配方

根据 ModelOpt 0.45.0 发布版中的 modelopt_recipes/models/Nemotron-3-Super-120B-A12B/super-nvfp4.yaml，公布的 NVFP4 检查点使用：

组件格式备注MoE 路由专家NVFP4 W4A4group_size 16，权重 MSE + FP8-scale sweepMoE 共享专家FP8 每张量Mamba mixer 的 in/out_projFP8 每张量KV cacheFP8Attention 线性层 (q/k/v/o)BF16未量化lm_head、MTP head、conv1dBF16未量化SSM cacheFP32vLLM 中为 FP16

这是一种混合精度策略：模型主体（MoE 专家）采用 4 位 NVFP4，而 Attention 路径和 Mamba 状态转换保持更高精度。校准使用权重 MSE，并对 128 个 e4m3 尺度值进行 FP8-scale sweep。

部署

NVIDIA 官方模型卡提供了 DGX Spark 特定的部署说明。我们严格按照说明操作：

# vLLM v0.20.0 — NVIDIA 推荐用于 DGX Spark 上的 Nemotron-3-Super
docker run -d \
  --name nemotron-3-super-120b-nvfp4-vllm \
  --runtime nvidia --gpus all \
  --ipc=host \
  --ulimit memlock=-1 --ulimit stack=67108864 \
  -e VLLM_NVFP4_GEMM_BACKEND=marlin \
  -e VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 \
  -e VLLM_FLASHINFER_ALLREDUCE_BACKEND=trtllm \
  -e VLLM_USE_FLASHINFER_MOE_FP4=0 \
  -v /home/mikesai3/nemotron-3-super-120b/checkpoint:/model \
  -p 8888:8000 \
  vllm/vllm-openai:v0.20.0 \
  --model /model \
  --served-model-name nvidia/nemotron-3-super \
  --host 0.0.0.0 --port 8000 \
  --async-scheduling \
  --dtype auto --kv-cache-dtype fp8 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 4 \
  --max-model-len 1000000 \
  --moe-backend marlin \
  --mamba_ssm_cache_dtype float16 \
  --quantization fp4 \
  --speculative_config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}' \
  --reasoning-parser-plugin /app/super_v3_reasoning_parser.py \
  --reasoning-parser super_v3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --trust-remote-code

关键部署决策：

参数值原理容器镜像vllm/vllm-openai:v0.20.0NVIDIA 推荐用于 DGX Spark 上的 Super量化fp4NVFP4 混合精度（ModelOpt 检查点）MoE 后端marlinMarlin NVFP4 GEMM 内核推测解码MTP, 3个token来自模型自身 MTP 头的多 Token 预测KV 缓存FP8减少 1M token 上下文的内存占用最大模型长度1,000,000完整上下文窗口（需要 VLLM_ALLOW_LONG_MAX_MODEL_LEN=1）GPU 内存利用率0.90在 121 GB 上最大化内存余量最大序列数4NVIDIA 推荐用于此模型大小推理解析器super_v3Nemotron-3 Super 推理格式工具调用解析器qwen3_coderNVIDIA 推荐的工具调用格式

下载问题

检查点下载是最大的障碍。该模型在 HuggingFace 上公开（无门槛），但未认证的下载会受到速率限制。我们的首次尝试：

• 容器启动时下载 —— vLLM 尝试在启动时从 HuggingFace 下载。卡在 104 KB。在第一个分片完成之前，未认证的速率限制就扼杀了它。
• 使用 HF_HUB_ENABLE_HF_TRANSFER=1 的 huggingface_hub.snapshot_download —— 3 分钟内下载了 4.3 GB，然后卡住。HF_HUB_ENABLE_HF_TRANSFER 标志已弃用；新标志是 HF_XET_HIGH_PERFORMANCE。
• 使用 16 个工作线程的 HF_XET_HIGH_PERFORMANCE=1 —— 进展到 10.6 GB，然后在网络中断后再次卡在 13.5 GB。

解决方案：使用 xargs -P4 的并行 wget —— 直接从 HuggingFace 的 resolve URL 下载 17 个 safetensors 分片，每次 4 个文件。这有效：

尝试方法速度结果1容器启动时0 MB/s卡在 104 KB2snapshot_download + hf_transfer~1.4 GB/min卡在 4.3 GB3snapshot_download + XET~2 GB/min卡在 13.5 GB4并行 wget -P4~4 GB/min18 分钟完成 75 GB

经验教训：未认证的 HuggingFace 速率限制是按连接而非按 IP 的。打开多个并行连接可以绕过限制。如果有 HuggingFace token（我们没有），huggingface_hub 应该可以全速工作——但如果没有 token，并行 wget 是回退方案。

内存适配 —— 确认

模型成功加载：

Loading safetensors checkpoint shards: 100% Completed | 17/17 [01:13<00:00, 4.34s/it]
Loading weights took 73.82 seconds
Model loading took 75.03 GiB memory and 606.32 seconds

121 GB 统一内存中的 75.03 GiB —— 利用率 62%。模型已适配，为 KV 缓存和激活缓冲区留出空间。在 –gpu-memory-utilization 0.90 的情况下，vLLM 有 108.9 GB 可用，模型权重后剩余约 34 GB 用于 KV 缓存。

运行时性能

加载完成后，Super 120B 以以下指标提供推理服务：

指标值生成吞吐量~30 tokens/sMTP 接受率84-92%平均接受长度3.5-3.8 tokensKV 缓存使用率1.3%（负载下）Attention 后端FlashInferMoE 后端Marlin NVFP4检测到的架构NemotronHForCausalLM + NemotronHMTPModel

推测解码运行良好——84% 的草稿接受率意味着 MTP 头正在生成有用的推测 token。30 tokens/s 的生成速率低于阶段 1 的模型（Qwen 约 150+ tok/s），但这是一个 12B 活跃参数的模型 vs 3-4B——能力差距应该在基准测试中可见。

阶段 2：基准测试 —— 完整结果

smf-bench 的 181 项测试套件在 Super 120B 上运行了 8.8 小时的挂钟时间。以下是完整结果，并与阶段 1 的三模型比较集成在一起。

四模型总体比较

模型通过失败错误通过率耗时活跃参数Gemma-4-26B-A4B-NVFP4152263**84.0%**56.3 分钟4BQwen3.6-35B-A3B-NVFP412952071.3%27.6 分钟3BNemotron-3-Super-120B-A12B-NVFP4126124369.6%530.1 分钟12BNemotron-3-Nano-30B-A3B-FP89982054.7%212.0 分钟3.6B

Super 120B 以 69.6% 的成绩位列第三，落后于 Gemma (84.0%) 和 Qwen (71.3%)，但比其较小的兄弟 Nano-30B 高出 14.9 个百分点。活跃参数增加 3.3 倍（3.6B → 12B）带来了 14.9 个百分点的精度提升，但并未缩小与 Qwen 和 Gemma 的较小 Transformer MoE 模型之间的差距。

挂钟时间的故事至关重要： Super 120B 完成基准测试耗时 530 分钟（8.8 小时）——是 Gemma 的 9.4 倍，Qwen 的 19.2 倍。这是推理链的成本：Mamba-Transformer 混合模型在每次回答前生成大量思考 token，并且拥有 12B 活跃参数，每个 token 需要更长时间生成。55 个未通过测试中的 43 个错误都是超时——模型在得出答案前用尽了其 4096 个 token 的推理预算。只有 12 个测试产生了错误答案。

按类别细分 —— 全部四个模型

类别Nemotron-3-Nano-30BQwen3.6-35BGemma-4-26BNemotron-3-Super-120B智能体7/16 (43.8%)14/16 (87.5%)**15/16 (93.8%)**8/16 (50.0%)编程22/30 (73.3%)19/30 (63.3%)**28/30 (93.3%)**22/30 (73.3%)指令遵循17/30 (56.7%)22/30 (73.3%)**27/30 (90.0%)**28/30 (93.3%)数学9/30 (30.0%)**16/30 (53.3%)**15/30 (50.0%)12/30 (40.0%)散文12/30 (40.0%)21/30 (70.0%)**27/30 (90.0%)**20/30 (66.7%)推理25/38 (65.8%)31/38 (81.6%)**36/38 (94.7%)29/38 (76.3%)工具调用2/2 (100%)2/2 (100%)**0/2 (0%)**2/2 (100%)写作5/5 (100%)**4/5 (80%)4/5 (80%)5/5 (100%)

Super 120B 的突出表现：指令遵循。 它得了 28/30 (93.3%)——是所有模型中最好的，略胜 Gemma (27/30, 90.0%)。Mamba 混合模型的循环状态可能有助于在长输出中维持结构约束（行数、句子数、节格式）。只有 1 个测试是真正的失败（字符串操作任务中的字符换位）；其余是超时。

Super 120B 相对于 Nano 的优势所在：

• 指令遵循： 93.3% vs 56.7%（+36.6 点）——最大的改进
• 散文： 66.7% vs 40.0%（+26.7 点）——更大的活跃参数有利于结构格式化
• 推理： 76.3% vs 65.8%（+10.5 点）——12B 活跃参数改进了逻辑推理
• 数学： 40.0% vs 30.0%（+10.0 点）——推理能力更强，但仍受 token 预算限制

Super 120B 的不足之处：

• 智能体： 50.0% —— 仅略好于 Nano (43.8%)，远落后于 Qwen (87.5%) 和 Gemma (93.8%)。智能体测试需要文件创建和多步骤工具使用。Super 120B 通过了 8/16——它通过的测试是应用生成任务（计数器、待办事项、乒乓球、贪吃蛇、弹球、星空），其中它可以一次性生成完整的 HTML/JS。它未通过所有 8 个需要文件系统操作的任务（compute-write、config-extract、script-and-output、bugfix-run、json-spec、multifile-summary、rename、reasoning-only）。
• 编程： 73.3% —— 与 Nano 相同。12B 活跃参数并未提高编程准确性。所有 8 个失败都是超时，而不是代码错误——模型生成了正确的代码，但在专家/前沿问题上完成输出之前用尽了推理预算。
• 数学： 40.0% —— 比 Qwen (53.3%) 和 Gemma (50.0%) 差。18 个未通过测试中有 15 个是超时。数学问题上的推理链极其冗长，4096 token 的预算不足以解决专家/前沿问题。

按难度细分 —— 全部四个模型

难度Nano-30BQwen-35BGemma-26BSuper-120B简单10/10 (100%)10/10 (100%)10/10 (100%)10/10 (100%)中等13/15 (86.7%)14/15 (93.3%)14/15 (93.3%)14/15 (93.3%)困难18/25 (72.0%)21/25 (84.0%)22/25 (88.0%)21/25 (84.0%)专家16/40 (40.0%)27/40 (67.5%)32/40 (80.0%)20/40 (50.0%)前沿20/60 (33.3%)30/60 (50.0%)**47/60 (78.3%)**22/60 (36.7%)

难度细分清晰地揭示了 Super 120B 的特性：

• 简单和中等： 所有四个模型都可比（86-100%）。这些等级没有区分度。
• 困难： Super 120B 与 Qwen (84.0%) 相当，接近 Gemma (88.0%)。这就是 12B 活跃参数开始发挥作用的地方。