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

請喝咖啡