DGX Spark 实测 Ling MTP：接受长度翻倍，散文反而更慢

niacolhealth · reddit · 2026-09-07

作者整理 DGX Spark 上 Ling 3.0-flash 投机解码（MTP）基准的修正数据，补上了此前缺失的对照组。

关键数据（单个 128GB DGX Spark，官方 INT4 checkpoint，vLLM 官方 fork，短编码任务）：

| 配置 | tok/s |

|---|---|

| Eager、MTP 关 | 20.8 |

| CUDA graphs、MTP 关 | 22.9 |

| CUDA graphs、MTP n=1 | 40.9 |

即 CUDA graphs 带来约 10% 提升，MTP 再带来约 79%（分母不同）。此前「两个 flag」的结果把 graphs 与 MTP 一起改动，无法归因——这是本次修正的关键。

MTP n=1/2/3 对比：平均接受长度 1.87 → 2.39 → 2.77，但散文 512-token 输出从 38.7 降到 34.8、33.6 tok/s，2k 输出同理；编码吞吐在波动范围内持平。结论：接受长度不是优化目标，n=1 才是此 checkpoint 的最优设置。

注意事项：接受长度指标来自厂商 fork，计数实现未公开；计时口径未完全说明，数字应视为「报告吞吐」而非独立复现。可迁移的实验方法：先隔离无 MTP 基线，再在实际生成的输出类型上比较 draft 设置。

「Infra」频道最新