NVIDIA博客：DGX Spark上三项优化使Ling-3.0-flash解码吞吐提升 42.5%
NVIDIA技术博客称，在batch size为 1、完成GSM8K全部 1,319 道题的端到端评测中，Humming MoE后端、FP8 LM head在线量化与NEXTN多token预测三项叠加后，解码吞吐从 37.81 tok/s升至 53.89 tok/s，平均端到端延迟下降 24.5%；合成负载下 185.1% 的吞吐增幅并未被作者视为可外推的结论。
AI解读：NVIDIA技术博客作者Yang Liu报告了在DGX Spark上优化Ling-3.0-flash（Inclusion AI的MoE模型，总参数 124B、每token激活 5.1B）推理的三项手段：Humming MXFP4 MoE后端、LM head在线FP8量化、基于NEXTN的MTP推测解码。
三项优化机制不同：前两项降低每个解码步的权重读取成本，MTP减少解码步数。作者称三者可叠加，但需让草稿模型共享完整LM head模块，否则框架会静默回退到比未优化基线更慢的配置。
合成负载（32K输入、2K输出）下，三项叠加使TPOT从 27.71 ms降至 9.72 ms，吞吐从 36.09 tok/s升至 102.88 tok/s；作者明确指出这类负载会高估推测解码收益，不能代表其他工作负载。
GSM8K全量 1,319 题五样本评测中，TPOT从 26.45 ms降至 18.56 ms，吞吐提升 42.5%，平均延迟从 15.21 s降至 11.49 s，准确率从 96.89% 变为 96.82%，请求错误与截断均为 0。
作者将结果限定在batch size 1与DGX Spark平台，并建议用贴近实际部署的负载验证，同时在启动时逐项确认优化是否生效，而不是从后续性能数字反推配置状态。
NVIDIA技术博客发布文章，介绍在DGX Spark上加速Ling-3.0-flash推理的三项优化，并给出合成负载与GSM8K全量评测两组数据。文章作者为Yang Liu，模型来自Inclusion AI，代码与部署说明指向Ling cookbook。
在GSM8K全部 1,319 道题、batch size 1的评测中，三项优化同时启用后解码吞吐从 37.81 tok/s升至 53.89 tok/s（+42.5%），平均端到端延迟下降 24.5%，准确率变化为 −0.08 个百分点。
三项优化分别做了什么
文章先对Ling-3.0-flash做性能剖析，结论是decoding受内存带宽限制：读取模型权重驱动执行时间，其中MoE计算和输出层投影（LM head，将 2,560 维隐状态映射到 157,184 词表）最突出。据此提出两条路径：减少每步权重读取量，以及每轮验证产出更多token。
Humming是独立的kernel库（humming-kernels pip包），用NVRTC在运行时按实际M/N/K维度、数据类型和GPU架构编译CUBIN并缓存。文章称单个kernel数秒完成编译，而FlashInfer CUTLASS路径用ninja编译 97 个目标、需数十分钟。
LM head在检查点中以BF16存储且被列入modules_to_not_convert，未在加载时量化。只对LM head应用动态FP8量化后，该层权重读取量减半，通过SGLANG_ENABLE_FP8_LM_HEAD=1 启用，并与基线的 –enable-fp32-lm-head选项互斥。
MTP使用模型自带的NEXTN预测层（num_nextn_predict_layers: 1）作草稿模型，配置为 3 个草稿步、4 token验证窗口；每轮草稿依次预测 3 个token，目标模型一次验证 4 个位置并接受正确前缀。
- Humming MoE后端：TPOT 27.71→25.35 ms，吞吐 +9.3%
- 叠加FP8 LM head：TPOT 22.76 ms，吞吐 43.94 tok/s，较Humming单独再增 11.4%
- 再叠加MTP（steps=3/topk=1/draft_tokens=4）：TPOT 9.72 ms，吞吐 102.88 tok/s，合成负载接受长度 3.90
合成负载与真实评测的差距
文章用 32K输入、2K输出的合成负载做组件级测量，但同时说明合成输出重复性高、采样简单，会系统性高估推测解码收益：合成负载接受长度为 3.90，GSM8K上为 2.68。
作者列出三项差异：合成测试用贪心解码，GSM8K用temperature 0.6、top_p 0.95、top_k 29；合成输出固定 2K token，GSM8K中位输出约 310 token，使前两项优化的固定开销摊薄效果不同。
GSM8K评测采用五样本提示、完整测试集、max_tokens 32,768、开启chain-of-thought，除三项优化外对齐采样参数、解析器、随机种子和内存分配。优化后平均输出长度 607 token，基线为 567 token。
延迟分位数方面，P50从 8.36 s降至 6.11 s（−27%），P95从 50.20 s降至 38.60 s（−23%）；平均TTFT从 0.207 s微升至 0.214 s。
- GSM8K准确率 96.89%→96.82%，作者称无统计上可检测的准确率变化
- 平均延迟 15.21 s→11.49 s，请求错误与截断均为 0/0
- MTP验证成本约为普通解码步的 2.26 倍，主要来自MoE专家激活：普通解码激活 8 个专家，验证 4 个token最多激活 32 个
叠加时的配置陷阱
文章特别指出，同时启用FP8 LM head量化与MTP时，草稿模型必须共享整个LM head模块，而不只是其权重张量。原Ling NEXTN实现没有暴露该接口，框架会静默回退：草稿拿到FP8权重却按BF16解释，接受长度降到 1.00，吞吐低于完全未优化的基线。
作者建议部署时在启动阶段逐项确认每个优化确实生效，这比事后从性能数字推断配置状态更可靠。所有数据均在batch size 1与DGX Spark上测得，文章未给出其他硬件或批大小的结果。