SPEED-Bench 登場：投機解碼的統一且多樣化基準測試

SPEED-Bench 簡介：推測解碼的統一且多樣化基準測試

儘管推測解碼（Speculative Decoding, SD）演算法取得了快速進展，但其評估方式仍然零散，且往往無法代表真實世界的數據與服務條件。在實踐中，SD 的推測品質和推理加速本質上取決於數據、服務機制以及系統環境。然而，現有的大多數基準測試依賴於小型提示詞集、有限的語義多樣性、短輸入序列長度、批次大小為一（batch size one），或是無法反映生產環境的高階推理堆疊。

為了填補這些空白，我們推出了 SPEED-Bench：一個統一的基準測試，旨在利用生產級推理引擎，在多樣化的語義領域和真實的服務機制下評估 SD。

什麼是 SPEED-Bench？

評估 SD 必須從兩個維度進行。

一方面，草稿品質（draft quality）取決於輸入文本的語義領域和熵（entropy）。另一方面，真實世界的加速效果取決於批次大小、輸入序列長度（ISL）和系統限制，這些因素決定了推理是受限於記憶體（memory-bound）還是受限於計算（compute-bound）。

因此，SPEED-Bench 為 SD 引入了一個基準測試生態系統。它結合了兩個專門設計的數據集切分（splits）和一個統一的測量框架，每個部分旨在捕捉 SD 行為的不同面向：

這些組件共同使從業者和研究人員能夠分析那些經常被現有基準測試掩蓋的 SD 行為。

圖 1 提供了 SPEED-Bench 生態系統的高階概覽。

定性切分（Qualitative split）：語義覆蓋與草稿準確度

定性切分的目標是在廣泛的語義領域中，測量推測解碼的品質，特別是條件接受率（ARs）和接受長度（ALs）。

SpecBench 通過將廣泛使用的數據集實例整合到統一的測試環境中，引入了第一個跨多種應用場景（如多輪對話、翻譯和數學推理）的統一 SD 基準測試。然而，儘管這是邁向標準化評估的重要一步，但它在規模和多樣性方面存在關鍵局限。大多數類別僅包含 10 個樣本，且平均輸入長度較短（< 100 tokens），可能無法對現代草稿模型（drafters）施加足夠壓力。此外，其某些類別往往缺乏結構多樣性，例如多語言類別完全由德語到英語的翻譯提示詞組成。

雖然理論上可以對無數數據集進行廣泛評估，但這既繁瑣又不切實際，不利於快速實驗，也阻礙了發布 SD 演算法和模型的不同研究小組之間的直接比較。我們沒有依賴於對零散數據集的窮舉式評估，而是策劃了一個精簡但極具代表性的子集，旨在最大化語義多樣性。我們匯總了來自 18 個公開來源的數據，並將其組織成 11 個類別，包括：程式碼、數學、人文、STEM、寫作、摘要、角色扮演、RAG、多語言、推理和問答。

每個類別包含 80 個樣本，總計 880 個提示詞。與以往經常受困於類別內多樣性不足的基準測試不同，SPEED-Bench 的定性切分明確優先考慮語義多樣性。

為了實現這一點，每個候選提示詞都使用預訓練的文本嵌入模型（openai/text-embedding-3-small）嵌入到稠密向量空間中。然後，我們應用一種選擇演算法，最小化每個類別內的平均成對餘弦相似度。這確保了所選樣本盡可能廣泛地覆蓋語義空間，減少冗餘並提高評估的保真度。

這種方法的有效性如圖 2 所示，該圖比較了 SPEED-Bench 和 SpecBench 的平均語義相似度。

這種語義多樣性對於揭示 SD 中依賴於領域的行為至關重要，例如低熵領域（如程式碼、數學）與高熵領域（如角色扮演、寫作）之間的強烈對比。

吞吐量切分（Throughput split）：真實的服務負載

雖然定性切分捕捉了草稿準確度，但不足以評估系統級的加速效果。

我們使用兩個指標評估系統級加速：吞吐量（輸出 TPS），即所有並行請求每秒生成的總 token 數；以及用戶 TPS，即每個請求的 token 生成速率。用戶 TPS 可作為終端用戶延遲的代理指標。

在生產環境中，模型在高度並行和廣泛的輸入序列長度下提供服務，這些長度通常遠長於許多 SD 基準測試中使用的短 ISL 樣本。隨著批次大小增加，推理通常會從計算受限轉變為記憶體受限，這從根本上改變了推測解碼的成本效益權衡。

吞吐量切分專為捕捉這種行為而設計。

我們構建了從 1k 到 32k tokens 的固定 ISL 桶（buckets），反映了長上下文應用（如程式碼助手和檢索增強生成）日益增長的重要性。對於每個 ISL 桶，提示詞被匯總到對應於低、混合和高熵領域的三個粗略難度類別中。

每個 ISL 桶包含 1,536 個提示詞（每個難度類別 512 個），提供了足夠的量來構建跨廣泛批次大小的穩定吞吐量 Pareto 曲線（圖 3）。

為了確保確定的 Prefill 成本，提示詞會以受控方式進行截斷或填充，同時保留其語義內容。

重要的是，SPEED-Bench 避免在吞吐量基準測試中使用隨機 token 輸入。正如我們稍後展示的，隨機 token 會嚴重扭曲接受行為、MoE 模型中的專家路由以及吞吐量測量，從而導致過於樂觀的結論。

統一的測量框架

在不同推理引擎之間對 SD 進行基準測試面臨著細微但關鍵的挑戰。

不同的引擎可能會應用不同的對話模板、以不同方式處理 BOS token，或是不一致地對輸入進行分詞（tokenize）。這些差異可能會默默地改變生成的序列，使得跨引擎比較變得不可靠。

SPEED-Bench 引入了一個輕量級測量框架，在外部處理分詞和提示詞格式化。推理引擎接收預分詞的序列，確保所有系統處理完全相同的輸入。

該框架與生產級引擎整合：TensorRT-LLM、vLLM 和 SGLang。它從串流響應中捕捉細粒度的時間資訊，以計算接受行為、步驟延遲、用戶級每秒 token 數以及整體吞吐量。

以下是在 SPEED-Bench 的定性切分上，使用 TensorRT-LLM（批次大小 32，8 張 H100 GPU），以 Llama 3.3 70B Instruct 為目標模型、EAGLE3 為草稿模型運行測量框架的範例：

這種設計將 SD 演算法和系統優化的效果與預處理的人為因素隔離開來。

來自 SPEED-Bench 的洞察

依賴於領域的準確度與加速

下表報告了在真實批次大小（32）和草稿長度為 3 的情況下，跨領域和模型的平均接受長度與加速比。

結果證實，SD 的接受長度高度依賴於領域。低熵領域（如程式碼和數學）始終產生較高的接受長度，而高熵任務（如角色扮演和寫作）則更難以推測。

該表還突顯了不同推測方法之間的差異。輕量級方法（如 N-Gram 推測）在中等批次大小下可能會導致淨減速。我們進一步看到，原生 MTP（Multi-Token Prediction）頭實現的 AL 顯著大於像 EAGLE3 這樣的後訓練替代方案，這突顯了從頭開始共同訓練基礎模型和草稿模型的好處。

所有類別和不同模型在定性切分上的完整結果請參見我們的論文。

詞表剪枝揭示了長尾失效

SPEED-Bench 還可以協助揭示激進系統優化的副作用。

EAGLE3 中使用詞表剪枝（Vocabulary pruning）來降低最終投影層的計算成本。雖然在窄領域有效，但這種優化可能會降低用戶輸入「長尾」部分的接受長度。

圖 4 顯示了在 GPT-OSS 120B 搭配 EAGLE3 時，使用完整詞表與剪枝詞表在各領域的接受長度。在程式碼和數學領域影響微乎其微，但在多語言、RAG 和摘要類別中影響巨大。

這些效應在低多樣性的基準測試中幾乎不可見，這強調了評估數據中廣泛語義覆蓋的重要性。

隨機 Token 會高估吞吐量

推理基準測試中的一種常見做法是使用隨機 token 來模擬提示詞負載。雖然這對於自回歸解碼可能足夠，但對於 SD 演算法，甚至對於沒有推測的混合專家模型（MoE）來說，這種方法都存在根本性缺陷，如下所示。

隨機 token 會觸發兩種扭曲測量的失效模式：

範例輸出（基礎模型：GPT-OSS 120b，草稿模型：EAGLE3，草稿長度：3，平均 AL：3.44）：

It looks like you’ve pasted a very long block of mixed‑language text that doesn’t form a clear question or request. I’m happy to help, but I need a bit more guidance.Could you let me know what you’d like to do with this text? For example: ...

範例輸出（基礎模型：GPT-OSS 120b，草稿模型：EAGLE3，草稿長度：3，平均 AL：1.877）：

Below is an expanded, production‑ready roadmap that takes you from the very first Unity install all the way to a complete, polished 2‑D platformer (player, camera, enemies, collectibles, UI, audio, level loading, and a final build). Everything is broken into bite‑size tasks, each with the exact actions you need to perform and ready‑to‑copy C# snippets....

圖 5 比較了使用隨機 token 與 SPEED-Bench 負載測得的吞吐量。當啟用 SD 時，隨機 token 會高估吞吐量約 23%。

隨機輸入也無法在 MoE 模型中觸發真實的專家路由，導致即使在非推測設置下也會產生不準確的吞吐量測量，如圖 6 所示。

開始使用 SPEED-Bench

SPEED-Bench 的發布旨在為研究和生產環境中評估 SD 建立統一標準。

它使從業者能夠分析跨多樣化領域的草稿準確度，在真實服務機制下測量吞吐量，並使用相同的負載比較推理引擎。

數據集和測量框架已公開提供，旨在直接與現有的 SD 實現整合。

資源

我們希望 SPEED-Bench 能幫助推動更嚴謹、更現實且更關注部署的推測解碼評估！

社群

· 註冊或登入以發表評論