英伟达优化 Ling-3.0-flash 推理:吞吐提升 42.5%

11 月 3 日,英伟达官方技术博客公布一组在单台 DGX Spark 桌面设备上优化 MoE 推理的实测数据,测试模型是蚂蚁百灵 inclusionAI 的 Ling-3.0-flash。三项优化叠加后,全部 1,319 道 GSM8K 题目的解码吞吐从每秒 37.81 个 token 涨到 53.89 个,提升 42.5%,准确率从 96.89% 变为 96.82%,官方判定这一差异在统计上不可察觉。

三项优化分别动了哪里

第一项是把 FlashInfer 的 MoE 后端换成独立内核库 Humming,它用 NVRTC 按实际矩阵形状在运行时编译内核,编译只需数秒,而 FlashInfer 的 CUTLASS 路径要编译 97 个目标、耗时数十分钟,吞吐因此涨 9.3% 到每秒 39.45 个 token。第二项是在加载时把 LM head 这层 157,184×2,560 的矩阵量化成 FP8,每生成一个 token 都要整层读一遍,量化后读取量减半,吞吐来到每秒 43.94 个 token。第三项用模型自带的 NEXTN 层做投机解码,一次草拟 3 个 token、一次校验 4 个位置,合成测试里每轮平均接受 3.90 个 token,吞吐跳到每秒 102.88 个。


真实负载没有合成数据那么好看

英伟达随后跑了完整的 1,319 道 GSM8K。结果是单 token 耗时从 26.45 毫秒降到 18.56 毫秒,平均延迟从 15.21 秒降到 11.49 秒,但每轮接受的 token 数只有 2.68,明显低于合成测试的 3.90。官方给出三条解释:合成测试用贪心解码而 GSM8K 用温度 0.6 的采样;GSM8K 答案本身短,中位数只有约 310 个 token,而合成测试固定输出 2K;合成输出更重复,草稿更容易被接受。

还有一个坑:FP8 LM head 与 MTP 同时开启时,草稿必须共享同一个 LM head 模块,否则框架会静默回退、把 FP8 权重当成 BF16 读,接受长度直接掉到 1.00,吞吐反而低于未优化基线。官方建议启动时逐项确认三个优化确实生效。

Ling-3.0-flash 为什么适合桌面卡

Ling-3.0-flash 是 124B 总参数、每 token 激活 5.1B 的稀疏 MoE,512 个路由专家里每层只激活 8 个再加 1 个共享专家,单 token 激活权重比例约 4.1%,原生上下文 256K 并可扩到 1M。承载它的 DGX Spark 用 GB10 Grace Blackwell,128GB 统一内存、273GB/s 带宽、稀疏 FP4 峰值算力 1 petaFLOP,官方标称可推理 200B 以内模型。

蚂蚁百灵这条路线在开源圈已有完整布局,同系列的 Ling-3.1-flash 此前也放出了权重,560B MoE、1M 上下文,可参考这篇深度解读。inclusionAI 报告 Ling-3.0-flash 在 SWE-Bench Pro 得 56.6、SWE-Bench Multilingual 72.4、MathArena AIME 2026 得 93.2,Artificial Analysis 给出的 API 定价是每百万输入 0.075 美元、输出 0.22 美元。