# 在 NVIDIA DGX Spark 上提升 MoE 推理性能的 3 种方法 - 原标题：3 Ways to Boost MoE Inference on NVIDIA DGX Spark - 类型：博客 - 来源：developer.nvidia.com - 发布时间：2026-10-27 - 首次精选：2026-10-29 09:33 - 分级：值得看 - 学习层级：深入 - 主题：[decoding-acceleration]()（第 12 位）、[model-quantization]()（第 15 位）、[model-serving-compute]()（第 50 位） - 原文链接：[https://developer.nvidia.com/blog/3-ways-to-boost-moe-inference-on-nvidia-dgx-spark]() - 本站页面：[https://oplearnx.com/resources/pk\_db74e56c10da]() ## 摘要 这是 NVIDIA 技术博客的一篇文章，以 1240 亿参数、每 token 激活 51 亿参数的 Ling-3.0-flash 混合专家模型为例，在 NVIDIA DGX Spark、batch size 为 1 的条件下评测三项优化：Humming MXFP4 MoE 后端、在线 FP8 LM head 量化、以及结合 NEXTN 的 MTP 投机解码。文中给出配置对比数据：基线每输出 token 耗时 27.71 ms、解码吞吐 36.09 tok/s，逐项叠加后分别提升 9.3%、21.7%，三项全开时为 9.72 ms、102.88 tok/s、相对基线提升 185.1%。文中还提到性能剖析显示解码受内存带宽限制，MoE 计算与输出层投影占主要执行时间。 ## 中文精读 ### 1. 导读：解决 DGX Spark 上 MoE 推理的三个瓶颈 - 在 NVIDIA DGX Spark 上以 batch size 1 评测 Inclusion AI 的 Ling-3.0-flash，性能剖析（profiling）显示解码阶段受内存带宽限制，耗时主要来自权重读取。 - 两个最耗时的操作是专家混合（MoE）计算和生成全词表分数的输出层投影（LM head）。 - 由此得出两条改进思路：减少每个解码步的权重量（weight traffic），以及在每轮验证中生成更多 token。 - 文中介绍三项技术：Humming MXFP4 MoE 内核、LM head 的在线 FP8 量化、基于 NEXTN 的多 token 预测（MTP）投机解码。 - 文章还分析了一个集成问题：三项优化全部开启时，配置可能反而比基线更慢。代码与部署说明见 Ling cookbook。 ### 2. 模型与基线配置 - 评测对象是 Ling-3.0-flash-fp4：总参数 1240 亿，每 token 激活 51 亿参数。 - 模型共 42 层，其中 35 层为 Kimi Delta Attention（KDA）线性注意力层，7 层为多头潜在注意力（MLA）层。 - 每个 MoE 层把每个 token 路由到 512 个路由专家中的 8 个，另加 1 个共享专家。 - 原生上下文窗口为 256K token，可扩展到 1M；相比上一代 Ling flash 在长程任务稳定性、工具调用准确性和框架兼容性上有所改进。 - 基线采用官方 cookbook 的 W4A8 配置：FlashInfer MXFP4 MoE 内核、NVIDIA CUTLASS 稠密 GEMM，以及 --enable-fp32-lm-head 选项。 - LM head 把 2,560 维隐层投影到 157,184 个词表 token；标准 MXFP4 部署步骤见官方部署 notebook。 ### 3. 优化一：Humming MXFP4 MoE 后端 - 第一项优化把 MoE 执行后端从 flashinfer\_mxfp4 换成 humming，后者是通过 humming-kernels pip 包提供的独立内核库。 - 与 FlashInfer 的 CUTLASS 路径不同，Humming 借助 NVIDIA 的 CUDA 运行时编译（NVRTC），按实际的 M/N/K 维度、数据类型和 GPU 架构在运行时生成并编译 CUBIN，编译结果缓存在 \~/.humming/cache。 - 这样可针对 Ling-3.0-flash 的形状做特化，包括相对较窄的 moe\_intermediate\_size=768。 - 编译粒度也更细：单个内核数秒即可完成；而 FlashInfer 的 CUTLASS 路径用 ninja 编译 97 个目标，需要数十分钟量级的时间。 - 性能以单输出 token 时间（TPOT）和每秒 token 解码吞吐衡量：在 32K 输入、2K 输出、batch size 1 的合成负载下，TPOT 从 27.71 ms 降到 25.35 ms，吞吐从 36.09 tok/s 升到 39.45 tok/s，相对基线提升 9.3%。 ### 4. 优化二：LM head 在线 FP8 量化 - 检查点中 LM head 以 BF16 保存，并列入 modules\_to\_not\_convert，因此加载时不被量化。 - 其词表 GEMM 为 157,184 × 2,560，每生成一个 token 都要读完整块权重，在带宽受限时是优先压缩对象。 - 做法是仅在构建 LM head 时应用动态 FP8 量化配置，模型其余部分仍按检查点原配置加载 FP8/MXFP4 格式。 - LM head 权重由 BF16 转为 FP8 后，该层读取量减半，通过 SGLANG\_ENABLE\_FP8\_LM\_HEAD=1 开启。 - 该设置与基线的 --enable-fp32-lm-head 互斥，后者以 FP32 输出 logits 并使用更慢的词表 GEMM 路径。 - 与 Humming 叠加后 TPOT 降至 22.76 ms、吞吐 43.94 tok/s，相对基线提升 21.7%，即在 Humming 之上再增 11.4%。 ### 5. 优化三：基于 NEXTN 的 MTP 投机解码 - 前两项优化降低单步成本，投机解码则走另一条路：减少解码步数。 - Ling-3.0-flash 自带 NEXTN 预测层（num\_nextn\_predict\_layers: 1），可直接当草稿模型使用，无需额外训练或下载。 - 配置为 3 个草稿步加 4 token 的验证窗口：每轮草稿依次预测 3 个 token，目标模型一次验证 4 个位置并接受正确前缀。 - 收益取决于两个量：接受长度（accept length，每轮平均被接受的 token 数）和验证成本比（一次验证相对一次正常解码的成本），实测该比值约 2.26。 - 验证成本主要不来自注意力计算（batch size 1 时 KV 读取相对权重读取很小），而来自 MoE 专家激活：正常解码为 1 个 token 激活 8 个专家，验证 4 个 token 最多可激活 32 个专家。 - 注意事项：FP8 LM head 与 MTP 同开时，草稿模型必须与目标共享整个 LM head 模块，而不只是权重张量；原 Ling NEXTN 实现未暴露该接口。否则框架静默回退，草稿把 FP8 权重当 BF16 解读，接受长度掉到 1.00，吞吐比不做任何优化时还低；通过该接口共享完整 LM head 模块后接受恢复正常。 ### 6. 优化三：基于 NEXTN 的 MTP 投机解码（续） - 三项叠加后（steps=3 / topk=1 / draft\_tokens=4），TPOT 9.72 ms、吞吐 102.88 tok/s，相对基线提升 185.1%，每轮接受长度达 3.90 个 token。 ### 7. GSM8K 上的端到端结果 - 上面的分项结果基于 32K 输入 / 2K 输出的合成负载；合成负载输出重复、采样简单，会系统性高估投机解码收益。 - 因此另做了覆盖全部 1,319 道 GSM8K 题目的严格端到端对比，评测条件为五样本提示（few-shot）、temperature 0.6、top\_p 0.95、top\_k 29、max\_tokens 32,768，并开启思维链。 - 除三项优化外，两次评测的采样参数、解析器、五样本协议、随机种子和内存分配保持一致；首 token 延迟（TTFT）衡量第一个输出 token 之前的等待。 - TPOT 从 26.45 ms 降到 18.56 ms（−29.8%），解码吞吐从 37.81 升到 53.89 tok/s（\+42.5%）。 - GSM8K 准确率 96.89% → 96.82%（−0.08 个百分点），MTP 接受长度 2.68。 - 平均端到端延迟 15.21 s → 11.49 s（−24.5%），P50/P95 延迟为 8.36/50.20 s → 6.11/38.60 s（−27%/−23%）；平均 TTFT 0.207 s → 0.214 s，两轮均无请求错误或截断。 ### 8. GSM8K 上的端到端结果（续） - 基线组与优化组平均输出长度分别为 567 和 607 token，输出长度中位数约 310 token，P95 约在 1,900 到 2,060 token 之间。 ### 9. 合成负载与真实负载为何不同 - 合成输出更重复，草稿预测更容易被接受：合成负载接受长度 3.90，GSM8K 只有 2.68。 - 采样参数不同：合成测试用贪婪解码，真实评测用 temperature=0.6、top\_p=0.95、top\_k=29。 - 输出长度分布不同：合成负载固定输出 2K token，而 GSM8K 中位输出长约 310 token，使前两项优化带来的固定开销削减被摊到更短的输出上。 - 在 DGX Spark 上评估这些优化时，应使用贴近实际部署的负载；合成测试中的 185.1% 吞吐提升不能代表其他负载的收益。 ### 10. 结论 - 在完整 GSM8K 评测中，三项优化合计使解码吞吐提升 42.5%、平均端到端延迟下降 24.5%，未出现统计上可检测的准确率变化。 - 三者机制不重叠：Humming 与 FP8 LM head 降低每步成本，MTP 减少步数，因此可以叠加使用。 - 但叠加并非自动生效：每项优化单独都可用，三项全开时却要求草稿模型共享整个 LM head 模块，否则系统静默退化到比未优化基线更慢的配置。 - 部署时应在启动阶段验证每项优化确实生效，这比事后从性能数字反推配置状态更可靠。 ### 11. Tags - 文章标签涵盖 Agentic AI / 生成式 AI、开发者工具与技术、边缘计算、通用、中级技术、最佳实践。 - 主题标签包括 AI 推理、DGX Spark、推理性能、大语言模型（LLM）、低延迟推理、专家混合（MoE）与开源。 ### 12. 作者简介 - Yang Liu 是 NVIDIA 高级解决方案架构师，专注推动 AI 加速方案、Agentic AI 方案及相关技术在合作伙伴与行业客户中的采用与落地。 --- 来源：LearnMap · 学径（https://oplearnx.com）