英伟达测量DGX Spark上三项MoE推理优化：GSM8K吞吐提升42.5%

英伟达十月二十七日的技术文章，在一台 DGX Spark 上、批量大小为一的条件下，测试三种加速 Ling-3.0-flash 推理的办法。示例模型共有一千二百四十亿参数，但每个文本单位激活五十一亿参数。剖析显示，生成阶段主要受模型权重读取限制，混合专家运算和输出层投影尤其显著。原文确实附有基准测试，不能说它没有测试；同时，测试由厂商进行，不能称为本站独立实验，更不能推断其他模型和设备也会获得相同收益。

第一项变化把原先的 FlashInfer MXFP4 混合专家后端换成按模型形状编译的 Humming 内核。英伟达的合成负载包含三万二千个输入文本单位及两千个输出文本单位。在这组设置下，每个输出单位耗时从二十七点七一毫秒降到二十五点三五毫秒，吞吐从每秒三十六点〇九升至三十九点四五个单位，厂商计算提升百分之九点三。第二项变化只对语言模型输出头在线量化为 FP8。该层原本以 BF16 读取权重，每次生成都要处理很大的词表矩阵；改成 FP8 可以把该层权重读取量减半。与 Humming 合用的合成测试吞吐为每秒四十三点九四个单位，比原基线高百分之二十一点七。这些数字必须连同基线和测试配置一起报道。

第三项使用模型自带的 NEXTN 层进行多文本单位预测，也就是先草拟多个单位并一起验证。合成测试中每轮平均接受三点九〇个单位，三项优化合用后吞吐达每秒一百零二点八八个单位，比基线高百分之一百八十五点一。但文章特别指出一个集成陷阱：草稿模型必须与主模型共享完整的 FP8 输出头模块，而不只是共享权重张量。否则框架可能静默走到不匹配的解释路径，接受长度跌到一点〇，速度反而低于未优化配置。配置文件显示已启用某个选项，并不等于运行时一定走到了预期后端。

英伟达还对全部一千三百一十九道 GSM8K 测试题进行端到端比较，避免只依赖重复性较高的合成输出。双方使用同样的五例提示及采样控制。生成吞吐由每秒三十七点八一个单位增至五十三点八九个单位，提升百分之四十二点五；平均延迟由十五点二一秒降至十一点四九秒，缩短百分之二十四点五。准确率由百分之九十六点八九变为百分之九十六点八二，差距零点〇八个百分点，厂商称统计上未检测到显著变化。首个输出单位的平均等待时间则从零点二〇七秒变为零点二一四秒，并未改善。

合成测试的百分之一百八十五点一不能替换实际题集的百分之四十二点五：输入与输出长度、采样方法及草稿接受率不同。合成数据里每轮平均接受三点九〇个单位，GSM8K 中为二点六八。把两种数字混在同一个标题里，会让人误解可预期的生产收益。本文的结论应限于所测模型、设备、批量和基准。团队若要采用这些优化，须固定自己的原始配置，在真实请求分布上复测吞吐、端到端延迟、首单位延迟及正确性，并确认各后端实际生效。

三种机制解决的瓶颈也不相同：Humming 与 FP8 减少单步计算或权重读取成本，多单位预测则减少串行步骤。它们可以组合，但不保证简单叠加；正确的模块共享反而是组合成功的前提。原文附有部署手册，可供具备相应环境的工程师复演。报道应把这些限定、负载分母和厂商归属保留在正文、摘要及常见问答，而不是只留下最漂亮的一组百分比。

文章的准确率差距尤其需要准确表述。百分之九十六点八九与百分之九十六点八二都是 GSM8K 测试中的实测值，差零点〇七个百分点左右；表格按四舍五入给出负零点〇八个百分点。作者说未检测出统计上显著的改变，并不等于数学上完全相同，更不等于模型在所有任务上的回答质量不变。推测解码可能影响不同长度和不同采样策略下的行为，所以实际部署应另外保留自己的质量样本，并报告哪一版软件、哪一类请求和哪一次运行得到了结果。