Skip to content
AI-Daily-Builder

2026-05-24 次浏览

llama.cpp 合并原生 MTP 推测解码 — Qwen3.6 单请求解码提速约 2.16×,DGX Spark 受益

PR #22673 为 llama.cpp 带来原生多 token 预测(MTP)推测解码(build b9180+)。在 GB10 DGX Spark 上,Qwen3.6-27B Q4_K_M 单请求从 13.1 升到 28.3 tok/s — 但在并发下反而退步。

家用与个人自托管用户期待已久的功能本月正式进入上游:原生多 token 预测(MTP)推测解码通过 PR #22673(“llama + spec: MTP Support”,作者 am17an)于 2026-05-16 合并至 master,收录于 build b9180 及之后。在 GB10 DGX Spark 上,它让 Qwen3.6 的单请求解码吞吐量大致翻倍 — 但有一个关键但书,会在高负载下翻转它的价值。

MTP 推测解码是什么

推测解码通过先廉价地”草拟”数个候选 token,再用一次前向传递验证它们来加速生成。传统做法需要一个独立的小型 draft 模型并行运行 — 额外的内存、额外的设置,还有质量匹配的麻烦。

MTP 移除了第二个模型。 Qwen3.6 内置原生多 token 预测头:模型本身就会预测数个未来 token。llama.cpp 新增的 --spec-type draft-mtp 模式直接拿这些内置头当草稿来源,因此同一份权重同时负责草拟与验证。不需要找 draft 模型、没有不匹配风险,而且草稿质量更高,因为它们来自目标模型本身。

两个可调参数控制激进程度:

实测数据 — GB10 DGX Spark

NVIDIA 开发者论坛上一份社区实测(2026-05-15)在 DGX Spark 上跑 Qwen3.6-27B dense、Q4_K_M

情境无 MTP有 MTP(草拟 5)变化
单请求13.1 tok/s28.3 tok/s+2.16×
4 个并发请求41.5 tok/s29.9 tok/s−28%

单流的提升真实且巨大。但注意第二行:在四个并发请求下,MTP 反而拖累总吞吐量。这不是 bug — 而是推测解码的根本权衡。

但书:延迟 vs 吞吐量

推测解码是用闲置算力换取更低延迟。当你一次只服务一个请求,GB10 的张量核心在解码循环中大多闲置(在 Spark 的 273 GB/s LPDDR5X 上,解码受内存带宽限制),因此额外草拟 token 几乎免费,于是得到 2× 加速。

在批处理下则相反:并发请求已经吃满算力,因此草稿会抢占周期,被拒绝 token 的浪费工作会拖累总吞吐量。这让 MTP 成为单人交互式自托管的杀手级功能 — 却是多人服务机器的错误默认值。 如果你的 DGX Spark 是个人编码/助理端点,就打开它;若是面向多位同事,就关掉。

跨硬件可复现

这个效果并非 Spark 专属。一份在 RTX 3090 上的跨平台报告测到 Qwen3.6-27B 从 38 → 65 tok/s(1.71×),且无质量损失,并在 Qwen3.6-35B-A3B 上同样确认。已启用 MTP 的 GGUF 已上架 Hugging Face(例如 froggeric/Qwen3.6-27B-MTP-GGUF),所以你不必自行转换权重 — 拉一个 MTP build、抓一个 MTP GGUF,加上 --spec-type draft-mtp 旗标即可。

配套进展:TensorRT-LLM v1.3.0rc15

在 Spark 生态的生产级推理这一侧,NVIDIA 于 2026-05-21 发布 TensorRT-LLM v1.3.0rc15(项目维持约每周一个 rc — rc14 是 2026-05-07)。与 GB10(SM 12.1)相关的重点:

两条路线互补:llama.cpp MTP 是今天单人交互使用最省事的路径,而 TensorRT-LLM 则是量化 MoE 与多模态服务性能在 Blackwell 上成熟之处。

重点整理

如果你把 DGX Spark 当作个人 LLM 端点,MTP 的合并是本月杠杆最高的更新:升一个 build 加一个旗标,就能在 Qwen3.6 上获得约 2× 的交互加速,且不需要 draft 模型。只要记住它是单流优化 — 在共用机器上启用前,先用你自己的并发水平实测一次。


Sources

请喝咖啡