推測解碼在可負擔硬體上到底有沒有用？RTX 3090 / V100 / vLLM 的三組可重現 benchmark

先講結論。推測解碼（speculative decoding）能不能加速，主要不是看你的卡多舊，而是看推論引擎、草稿方法，以及每步草稿長度。我在三種硬體各做了一組可重現的實測，結果分歧到值得一次講清楚：

值得先點出的是：第一列和第二列用的是同型的卡（RTX 3090），但一邊是單卡 llama.cpp draft、一邊是雙卡 vLLM MTP。變的不只引擎，還有卡數、量化和草稿方法，所以嚴格說這是「換到 vLLM + MTP 這條路徑會翻正」，不是單一變因的乾淨對照。但至少它說明：淨損不是這張卡的宿命。三組的原始資料、raw log、重現腳本都在 GitHub，各有 Zenodo DOI，下面逐段連結。

推測解碼在做什麼

做法是用一個便宜的草稿來源先猜幾個 token，再讓目標模型一次驗證。在貪婪解碼下，輸出會逐字等於不用推測解碼的結果；在有溫度的取樣下則是分佈無損，也就是抽自與目標模型相同的分佈，但單次序列未必逐字相同。本文 3090 那組用貪婪，vLLM 那組用 temp=0.5。

草稿來源有幾種：經典做法是另一個小的自迴歸模型；DFlash 和 MTP 則是單次前傳就吐一整塊候選，差別在 MTP 是與模型 co-train 的 head，DFlash 是擴散式的 block drafter。理論上加速不改變輸出分佈，問題只在：草稿加驗證的固定開銷，在你的硬體與引擎上換不換得回時間。

一、單張 RTX 3090 + llama.cpp：MoE 上沒有淨加速

第一組在單張 RTX 3090 上，目標是 Qwen3.6-35B-A3B（A3B 是 MoE）配 Q4_K_XL，用 llama-server。

我跑了一個 19 種設定的矩陣：ngram-cache、ngram-mod、經典 draft（用詞表對齊的 Qwen3.5-0.8B 當草稿）。結論是沒有一種帶來淨加速，平均 decode 掉 3 到 12%，在推理和程式類 prompt 上還會掉到 59 到 67 tok/s。

最值得講的一點：即使草稿接受率是 100%（逐 token 核對過，115 中 115），它還是淨損。這直接說明瓶頸不在草稿猜得準不準，而在驗證與 expert 載入的開銷。草稿全中，但驗證這一整塊候選在這個引擎上的成本，壓過了省下的解碼時間。有讀者猜結構化、低熵的輸入（程式碼、JSON）也許能翻盤，我用 5 段 code/JSON prompt × 3 trial × 3 配置測了，還是淨損；工作負載的形狀不是原因。

後來 PR #22105 併入 DFlash，我另外補測。最佳配置（--draft-max=8）77.0 tok/s、基線 138.9，等於 −44.6%。要講清楚這是刻意讓推測全程觸發的結構化 prompt 最壞情況，不是上面那個矩陣的平均；經典 draft-spec 在同樣情境更差，約 −52%。

要強調的是，這個負面結果是引擎與方法特定的，不是硬體等級決定的。這也是我後來更正過的一點：早期版本把它寫成「與硬體等級無關的通則」，但底下 vLLM 那組顯示，換到 vLLM + MTP，同型的 3090 就翻正（雖然那組同時也改了卡數與量化）。至於機制，我的猜測是 batch=1 下草稿長度沒達到 expert 飽和門檻，驗證仍要載入多個位置的 expert 聯集，開銷換不回時間；我沒有量 expert 啟用數，所以這是推測。

就我所知，這是 RTX 3090 + DFlash + Q4 的首個公開 datapoint。完整資料與重現腳本：qwen3.6-speculative-decoding-rtx3090，DOI 10.5281/zenodo.19776558。

二、2× RTX 3090 + vLLM：換引擎和方法，反而 +27.5%

把引擎換成 vLLM、草稿方法換成模型自帶的 MTP（co-trained speculative head），同型的 3090，結果翻過來。MTP k=1 的 decode TPOT 從 7.620 ms 降到 5.976 ms，等於 −21.6%，也就是 decode rate 快 27.5%。

這一段值得講的是怎麼修正自己。我最早報的是 −12% 淨損，後來查出兩個干擾：一是 serve flag 沒對齊（0.80/2 對 0.90/8），二是 prefix caching 開著，而它跟 MTP 有已知的負向交互（vllm #38182：MTP 會讓 prefix-cache 命中率從約 92% 掉到約 71%，cache 開著就用 cache 損失蓋掉了 MTP 的算力加速）。把 flag 對齊、兩邊都關掉 prefix caching 重測，MTP 才顯出正的效益；原始 v1/v2 資料留在 repo 裡供稽核。

要誠實補兩個條件：這 +27.5% 是單流、而且必須關掉 prefix caching 的數字。關掉 prefix caching 對多輪共享系統 prompt 的工作負載是有代價的（MTP 的 head 領先一個 token，本來就無法重用最後一塊 KV）。這組的應用背景是具身機器人：一顆統一模型同時服務視覺與對話，在視覺 prefill 併發下，對話吞吐只掉 4.3%（125.8 降到 120.4 tok/s），低於 10% 的門檻。

完整方法、逐 prompt、併發資料：qwen3.6-vllm-2x3090，DOI 10.5281/zenodo.19776536。

三、2× Tesla V100 + DFlash：峰值在低 n

第三組把 DFlash 搬到 2× Tesla V100（sm_70），做一個控制良好的 dense 對 MoE sweep，量化對齊。這裡的 n 指 --spec-draft-n-max，每步最多草稿幾個 token；DFlash 的 block_size 是 16，所以上限被 clamp 在 15。

主要發現：DFlash 的加速在低 n（約 2 到 4）達到峰值，然後隨 n 上升而侵蝕，dense 和 MoE 都一樣。MoE 更早翻負（n8 起穩定淨損，約 0.83×；n15 約 0.68×），dense 到 n15 還在損益兩平附近。比較意外的是，dense 和 MoE 的草稿接受率幾乎一樣（差 0.7 到 3.3 個百分點），但基線吞吐差了 2.57×（dense 37.6、MoE 96.6 tok/s，MoE 靠 A3B 稀疏比較快）。所以在乾淨量化下，MoE 的弱勢不在草稿接受率，而在吞吐與開銷這一側。

這組也接到一個上游討論。llama.cpp 作者 @ggerganov 在 PR 串裡問過 --spec-draft-n-max 15 是不是推薦值。我在串裡補上一組 V100 的 sweep：在這個硬體上，15 已經過了最佳點，對 block-size-16 的模型照抄 15，大部分加速根本沒吃到，對 MoE 還會翻負。機制我的猜測是 drafter 上的 Amdahl 效應，MoE 每 token 解碼便宜約 2.57×，同樣的草稿加驗證開銷占它的預算比例更大，於是更早翻負；但我沒有量 expert 啟用數，這只說明 dense 對 MoE 的順序可重現，不證實 PR 描述的 expert-union 機制。

範圍要講清楚：這些數字只限 V100-class（sm_70，約 900 GB/s），不要外推。PR 作者在 DGX Spark 上同一個 dense 模型報 2.69×，這台機器只有約 1.46×，而且只測吞吐，沒有評估輸出品質。完整 sweep 與重現：qwen3.6-speculative-decoding-v100，DOI 10.5281/zenodo.21220227。

綜合：決定效益的是引擎和方法，不是硬體等級

把三組並起來，真正決定效益的順序是這樣：

• 引擎與方法最關鍵。同型的 3090，llama.cpp 外掛式 draft 是淨損，vLLM co-trained MTP 是淨賺（這個對照也改了卡數與量化，不是單一變因，但方向很清楚）。而且 llama.cpp 那組即使草稿接受率 100% 還是淨損，說明卡關在驗證開銷，不在草稿品質。
• 草稿長度有甜蜜點。V100 上 DFlash 的加速峰值在低 n（2 到 4），高 n 侵蝕甚至翻負；跨硬體照抄別人的大 n（例如 15）通常是虧的。
• 硬體頻寬還分不出來。兩組淨損的卡（3090 Ampere、V100 Volta）剛好都用 llama.cpp 系的草稿方法，所以「頻寬弱」和「用了 llama.cpp draft」在我的資料裡是共線的，無法單獨把帳算到頻寬頭上。

實務上一句話：在可負擔硬體上，不要假設推測解碼一定會加速，先確定你的引擎與方法組合真的有用，也別直接照抄別人的 n。三組的每個數字都能用 repo 內的腳本重跑（DOI 見各段），過程中的 datapoint 也回饋到了 llama.cpp PR #22105 與 issue #25117。

限制

三組都只測吞吐、沒有評估輸出品質；每組都綁定特定硬體、模型與量化，不宜跨類外推；文中提到的機制（驗證與 expert 載入開銷、drafter 的 Amdahl 效應）都是推測，不是直接量到的。