NVIDIA 在单台 DGX Spark 上叠加三项优化，Ling-3.0-flash 的 MoE 推理吞吐提升 42.5%

NVIDIA 最新技术博客展示了如何在一台 DGX Spark 上加速混合专家（MoE）推理。测试模型是蚂蚁集团 inclusionAI 的 Ling-3.0-flash，一个总参数 124B、激活参数 5.1B 的 MoE。NVIDIA 叠加了三项优化：新的 MoE kernel 后端、FP8 输出层以及内置的投机解码。在全部 1,319 道 GSM8K 题目上，decode 吞吐提升 42.5%，准确率没有统计上可检测的变化。

那么这对开发者意味着什么？DGX Spark 是一台桌面系统，不是数据中心节点。NVIDIA 的结果表明，一个 124B 的 MoE 能在这台桌边盒子上更快地服务单用户请求。这篇技术文章还展示了 MoE decode 时间花在哪里，以及如何把它降下来。

TL;DR

• 规模：Ling-3.0-flash-fp4，总参数 124B，每 token 激活 5.1B；原生 256K 上下文。
• 运行环境：一台 NVIDIA DGX Spark（GB10，128 GB 统一内存，273 GB/s），batch size 为一。
• 性能：三项叠加优化把 GSM8K decode 吞吐从 37.81 提升到 53.89 tokens/s。
• 最佳结果：吞吐 +42.5%，平均延迟 -24.5%，准确率持平（96.89% 对 96.82%）。
• 落后项：合成测试的增益（+185.1%）在 GSM8K 上缩水，因为 MTP 接受长度从 3.90 降到 2.68。

为什么 DGX Spark 上的 MoE 解码是内存受限的？

DGX Spark 是 NVIDIA 基于 GB10 Grace Blackwell 超级芯片打造的桌面系统。它提供 128 GB 统一内存和 273 GB/s 的内存带宽。稀疏 FP4 峰值算力最高 1 petaFLOP。NVIDIA 给出的定位是可用于最高 200B 参数模型的推理。

在这篇 NVIDIA 技术文章中，NVIDIA 团队对 Ling-3.0-flash-fp4 在 batch size 为 1 时做了 profiling。解码是内存受限的：读取模型权重主导了执行时间。其中两个操作格外突出——MoE 计算，以及给词表打分的 LM head。这指向两个杠杆：每个 decode 步骤搬运更少的字节，以及每轮验证生成更多的 token。

基线遵循官方 W4A8 配方，使用 FlashInfer MXFP4 MoE kernel、CUTLASS dense GEMM 和 FP32 LM-head 路径。在一个 32K 输入、2K 输出的合成测试上，它每 token 耗时 27.71 ms（36.09 tokens/s）。

三项优化是什么？

1. Humming MXFP4 MoE kernel：NVIDIA 把 FlashInfer 的 MoE 后端换成了 Humming，一个独立的 kernel 库。Humming 使用 NVRTC 在运行时针对实际矩阵形状、数据类型和 GPU 编译 kernel，包括宽度仅 768 的专家层。每个 kernel 编译只需数秒。FlashInfer 的 CUTLASS 路径用 ninja 编译 97 个目标，耗时在数十分钟量级。吞吐提升 9.3%，达到 39.45 tokens/s。
2. 在线 FP8 LM head：LM head 是一个以 BF16 存储的 157,184 x 2,560 矩阵。每生成一个 token 都要把它完整读一遍。只在加载时把这一层量化为 FP8，就能把这些读取减半。设置 SGLANG_ENABLE_FP8_LM_HEAD=1 即可启用。它不能与基线的 --enable-fp32-lm-head 选项同时使用。与 Humming 组合后，吞吐达到 43.94 tokens/s，比基线高 21.7%，比只用 Humming 高 11.4%。
3. 基于 NEXTN 的 MTP 投机解码：Ling-3.0-flash 自带 NEXTN 预测层，因此不需要额外的 draft 模型。它起草三个 token，模型一次性验证四个位置。验证成本约为正常 decode 步骤的 2.26 倍。主要开销在 MoE，而非 attention。验证四个 token 最多可激活 32 个专家，而不是 8 个。在合成测试上，每轮平均接受 3.90 个 token。吞吐跃升至 102.88 tokens/s，提升 185.1%。

这三项技术互不重叠。Humming 和 FP8 LM head 降低每一步的成本，MTP 减少步数。

集成陷阱：把这几项叠起来并不是自动生效的。当 FP8 LM head 和 MTP 同时开启时，draft 必须共享完整的 LM-head 模块。否则框架会静默回退，draft 把 FP8 权重当成 BF16 来解读，接受长度掉到 1.00，吞吐跌到未优化基线以下。NVIDIA 团队建议在启动时检查每项优化是否生效。NVIDIA 指向 Ling cookbook notebook，其中展示了如何同时启用两者。

在真实负载上表现如何？

合成测试会美化投机解码的效果，因此 NVIDIA 团队还跑了全部 1,319 道 GSM8K 题目。使用 5-shot prompting 加 chain-of-thought，temperature 0.6、top_p 0.95、top_k 29。三项优化全开时，每个输出 token 的耗时从 26.45 ms 降到 18.56 ms。decode 吞吐提升 42.5%，从 37.81 到 53.89 tokens/s。平均延迟下降 24.5%，从 15.21 秒降到 11.49 秒。准确率从 96.89% 变为 96.82%，NVIDIA 称这一变化在统计上不可检测。

这里的接受长度是 2.68，而合成数据上是 3.90。NVIDIA 团队给出三点原因。合成输出更重复，因此 draft 更容易被接受。合成测试用贪心解码，而 GSM8K 用了采样。GSM8K 的答案也更短，中位数接近 310 token，而合成测试固定为 2K。

Ling 3.0 是什么，为什么适合 DGX Spark？

Ling-3.0-flash 属于蚂蚁集团 inclusionAI 的 Ling 3.0 系列，以 MIT 许可证发布。开放权重阵容还包括 Ling-3.0-tiny，一个总参数 7.9B、激活参数 1.3B 的 MoE。两者都提供 base checkpoint 以及 FP8、INT4 和 GGUF 版本，flash 还有 FP4。OpenRouter 还列出了 inclusionAI 基于 Ling 3.0 Flash 构建的视觉语言、金融和健康变体。

Ling-3.0-flash 的设计目标就是压低每 token 成本：

• 稀疏 MoE：每个 MoE 层把 token 路由到 512 个路由专家中的 8 个，外加 1 个共享专家。每 token 约有 4.1% 的权重处于激活状态。
• 混合线性注意力：35 层 Kimi Delta Attention（KDA）与 7 层 Gated MLA 以 5:1 交替排列。KDA 来自 Moonshot AI 的 Kimi Linear 论文，维护固定大小的状态，而不是不断增长的 KV cache。该布局从预训练开始就是原生设计。
• 内置 MTP：模型在训练时就加入了多 token 预测。那个 NEXTN 层就是 NVIDIA 使用的 draft 模型。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）