NVIDIA 解决方案架构师 Yang Liu：在 DGX Spark 叠加 MoE 推理优化时，一个接口缺失会让性能低于基线
Yang Liu 在 NVIDIA 开发者博客中记录了在 DGX Spark 上对 Ling-3.0-flash 模型应用三项 MoE 推理优化的过程。核心发现是：Humming 内核替换、FP8 LM 头在线量化和 NEXTN 投机解码三项优化各自有效，但 FP8 LM 头量化与 NEXTN 投机解码同时启用时，草稿模型必须共享完整 LM 头模块，否则框架静默回退使吞吐量低于未优化基线。此外，合成负载测得的 185.1% 吞吐增益在 GSM8K 真实评测中仅为 42.5%，提醒开发者用实际部署负载验证优化效果。
在 batch size 为 1 的边缘推理场景中，MoE 模型的性能瓶颈往往不是算力而是显存带宽。NVIDIA 解决方案架构师 Yang Liu 在 2026 年 10 月 27 日的开发者博客中记录了这一判断：对 Inclusion AI 的 Ling-3.0-flash（1240 亿总参数、每 token 激活 51 亿参数的 MoE 模型）在 DGX Spark 上的 profile 显示，解码阶段受限于权重读取，两个热点操作是 MoE 路由专家计算和输出层词表投影。
针对这两个瓶颈，Yang Liu 测试了三项互补优化：用 Humming 内核库替换 FlashInfer MXFP4 MoE 后端（利用 NVRTC 运行时编译适配具体维度，吞吐提升 9.3%）；对 LM 头施加在线 FP8 量化将权重读取量减半（叠加 Humming 后吞吐提升 21.7%）；启用模型内置 NEXTN 层作为草稿模型进行多 token 投机解码（合成负载下吞吐提升 185.1%）。三项机制互不重叠——前两项降低每步成本，第三项减少步数——理论上可以叠加。
但叠加并非自动生效。Yang Liu 发现了一个关键的集成陷阱：当 FP8 LM 头量化与 MTP 投机解码同时启用时，草稿模型必须共享完整的 LM 头模块，而不仅仅是权重张量。原始 Ling NEXTN 实现未暴露这一接口。缺少该接口时，框架会静默回退——草稿模型收到 FP8 权重却按 BF16 解释，接受长度降至 1.00，吞吐量反而低于未优化的基线配置。这一失败模式没有任何报错，只能通过启动时逐项验证每个优化是否真正激活来检测。
另一个值得注意的教训是合成负载与真实负载的巨大差距。合成测试（32K 输入、2K 输出、贪心解码）中 MTP 接受长度为 3.90，吞吐增益 185.1%；而在全量 1319 题 GSM8K 评测（temperature 0.6、top_p 0.95、中位输出约 310 token）中，接受长度降至 2.68，三项优化合计吞吐增益为 42.5%，平均延迟降低 24.5%，准确率无统计显著变化。Yang Liu 明确提醒：合成负载的重复性输出和简单采样会系统性高估投机解码收益，部署时应使用反映实际工作负载的评测。
所有数据均为 NVIDIA 第一方在 DGX Spark 硬件上的自测结果，使用单一模型和单一基准，未经独立第三方复现。对开发者而言，可迁移的认识有两点：一是在叠加量化与投机解码时，务必验证模块级接口兼容性而非仅确认配置参数已设置；二是不要将合成基准的百分比增益直接外推到真实工作负载。