DGX Spark上提升MoE推理性能的三种方法

生成Token更快的前提，是先找出限制推理性能的瓶颈所在。在NVIDIA DGX Spark上针对Inclusion AI的Ling-3.0-flash所做的批大小为1的评估中，性能分析显示解码过程属于显存带宽受限：读取模型权重主导了执行时间。其中两个操作尤为突出——混合专家（MoE）计算，以及生成词表分数的输出层投影。

这些发现指出了两条提升性能的路径：减少每个解码步骤中的权重数据传输量，以及在每轮验证中生成更多的Token。本文探讨了针对这两类成本的三种技术：

使用Humming MXFP4 MoE内核来改进路由专家计算的执行效率。

对输出层（即LM head）进行在线FP8量化，以减少其权重读取量。

采用NEXTN实现多Token预测（MTP）的推测解码，同时起草并验证多个Token。

本文将说明每种优化方法的工作原理、测量其效果，并探讨一个可能导致组合配置比基线更慢的集成问题。文中以Ling-3.0-flash作为实现示例，相关代码和部署说明可在Ling cookbook中找到。

模型与基线配置

评估使用的是Ling-3.0-flash-fp4，这是一个混合专家模型，总参数量为1240亿，每个Token的激活参数量为51亿。该模型共有42层：35个Kimi Delta Attention（KDA）线性注意力层和7个多头潜在注意力（MLA）层。每个MoE层将每个Token路由至512个路由专家中的8个，同时附带1个共享专家。

针对智能体工作流，Ling-3.0-flash原生支持256K Token的上下文窗口，可扩展至1M Token。相比此前的Ling flash模型，该模型在长周期任务稳定性、工具调用准确性以及框架兼容性方面均有提升。开发者可以针对复杂智能体任务启用推理能力，也可以在对延迟敏感的交互场景中将其关闭。改进后的空间理解能力支持构建物理场景网格，并在编码任务中推理相对位置关系。

基线配置遵循官方cookbook中的W4A8设置：FlashInfer MXFP4 MoE内核、NVIDIA CUTLASS密集GEMM，以及–enable-fp32-lm-head选项。LM head将2,560维的隐藏层投影到157,184个Token的词表。

关于标准MXFP4部署说明，请参考MXFP4部署笔记。

优化一：Humming MXFP4 MoE后端

第一种优化方案是将flashinfer_mxfp4 MoE执行后端替换为humming。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数）来衡量。

优化二：在线FP8 LM head量化

在检查点文件中，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路径。

优化三：采用NEXTN的MTP推测解码

前两种优化方案降低了每个解码步骤的成本，而推测解码则走的是另一条路径：减少解码步骤的数量。

Ling-3.0-flash内置了NEXTN预测层（num_nextn_predict_layers: 1），可直接用作草稿模型，无需额外训练或下载。该配置使用三步起草和四Token验证窗口。在每一轮中，草稿模型依次预测三个Token，目标模型一次性验证四个位置，并接受正确的前缀部分。

这种方法的收益取决于两个指标：接受长度（每轮平均被接受的Token数量）以及验证成本比（一次验证步骤相对于一次正常解码步骤的成本）。实测的验证成本比约为2.26。验证成本的主要来源并非注意力计算；在批大小为1的情况下，相对于权重读取，KV读取量很小。真正的成本来自MoE专家激活：正常解码时一个Token激活8个专家，而验证过程需处理4个Token，最多可激活32个专家。

需要注意的是：

当在线FP8 LM head量化与MTP同时启用时，草稿模型必须与目标模型共享整个LM head模块，而不仅仅是其权重张量。Ling原始的NEXTN实现并未提供这一接口。如果缺少该接口，框架会悄无声息地回退：草稿模型接收到FP8权重，却将其误判为BF16格式，导致接受长度降至1.00，吞吐量甚至低于未启用任何优化的配置。通过该接口共享完整的LM head模块，可以恢复正常的Token接受率。请参照Ling cookbook来同时启用FP8 LM head量化与MTP。

GSM8K端到端测试结果

上述组件级结果基于32K输入/2K输出的合成工作负载测得。合成工作负载有助于分离出各项优化的单独收益，但其输出的重复性及简化的采样方式会系统性地高估推测解码带来的收益。为此，评估还在全部1,319道GSM8K题目上进行了严格的端到端对比测试。

该评估采用五样本提示（five-shot prompting），示例取自训练集，评估则使用完整的测试集，温度参数为0.6，top_p为0.95，top_k为29，最大Token数为32,768，并启用了思维链（chain-of-thought）。除三项优化本身之外，两组评估的所有变量均保持一致：采样参数、解析器、五样本协议、随机种子以及内存分配方式。首Token时间（TTFT）用于衡量生成第一个输出Token之前的延迟。

合成工作负载与真实工作负载的差异原因

合成输出的重复性更高，使得草稿预测更容易被接受。合成工作负载下的接受长度为3.90，而GSM8K下仅为2.68。

采样参数也有所不同。合成测试采用贪心解码，而真实评估使用的是温度=0.6、top_p=0.95、top_k=29的设置。

输出长度分布亦不相同。合成工作负载的输出固定为2K个Token，而GSM8K的输出中位数约为310个Token。这意味着前两项优化所带来的固定开销削减，被分摊到了更短的输出长度上。

在DGX Spark上评估这些优化方案时，应使用能够反映实际部署场景的工作负载。合成测试中测得的185.1%吞吐量提升，并不能代表在其他工作负载下的实际收益。

结论

在完整的GSM8K评估中，这三项优化使解码吞吐量提升了42.5%，平均端到端延迟降低了24.5%，且未观察到具有统计意义的准确率变化。这三种机制彼此并不重叠：Humming与FP8 LM head降低了每一步的成本，而MTP则减少了步骤数量，因此这些技术可以叠加组合使用。

然而，这种叠加效果并非自动实现。每项优化在独立使用时均能正常发挥作用，但若要同时启用全部三项，则必须让草稿模型共享完整的LM head模块。否则，系统会悄然退化为比未优化基线更慢的配置。在实际部署过程中，应在启动阶段验证每项优化是否均已生效，这比事后根据性能数据反推配置状态更为可靠。