NVIDIA研究團隊打造"加速大模型推理"的統一標準

這項由NVIDIA研究團隊主導完成的研究成果，以預印本形式發布于2026年2月，論文編號為arXiv:2604.09557v1，收錄于計算機分布式系統領域（cs.DC）。有興趣深入了解的讀者可以通過該編號在arXiv平臺查閱完整論文。

每次你向ChatGPT或者其他大型語言模型提問，背后發生的事情比你想象中復雜得多。模型不是一次性"想出"完整答案然后發給你的，而是像打字員一樣，一個字一個字地生成。這種逐字生成的方式，在今天的硬件條件下，成了制約AI速度的最大瓶頸。為了突破這個瓶頸，研究人員想出了一種叫做"推測解碼"（Speculative Decoding，簡稱SD）的聰明辦法——但評估這個辦法到底好不好，本身就是一門大學問。

NVIDIA的研究團隊發現，現有的評估方法存在嚴重缺陷：測試題目不夠多樣、測試環境脫離現實、測試指標只看單用戶場景。于是他們構建了一套全新的評測體系，命名為SPEED-Bench（推測解碼評估數據集）。這套體系不僅提供了精心挑選的多樣化數據，還配備了能對接真實生產環境的測量框架，試圖為整個行業建立一套公平、可信的評測標準。

一、大模型"一個字一個字說話"的困境

要理解SPEED-Bench解決的問題，得先明白大模型推理究竟慢在哪里。可以把大型語言模型比作一本放在遠處書架上的百科全書，每次你想知道下一個詞，圖書管理員就得跑到書架把這本厚重的書搬過來翻一下，然后再放回去，然后再跑過去翻下一個詞。這里最耗時間的不是翻書的動作本身，而是"來回搬運"這本大書的過程——在計算機術語里，這叫做從高帶寬內存（HBM）到芯片緩存的數據搬運，是一種"內存受限"的操作。

在只有一兩個用戶同時請求的低并發場景下，GPU的計算單元大部分時間都在等待數據搬運完成，閑置得相當厲害。推測解碼的核心思路，就是利用這些閑置的計算能力。具體做法是引入一個體量小得多的"草稿模型"，讓它先快速猜出接下來可能的一批詞（比如一次猜3到7個），然后讓大模型一次性驗證這批猜測是否正確。因為驗證多個詞和驗證一個詞在數據搬運成本上相差無幾，所以一旦猜對了多個，整體速度就會顯著提升。更關鍵的是，通過一種叫做"拒絕采樣"的數學機制，這個過程完全不會改變最終輸出的質量，結果和大模型自己逐字生成的完全一致。

DeepSeek-R1、Qwen3-Next、NVIDIA的Nemotron-3、小米的MiMo-V2-Flash等前沿模型，已經把這種多詞預測能力直接內嵌進了自己的架構之中。

二、現有評測方法的三個致命傷

然而，一個技術再好，如果沒有靠譜的評測方法，研究人員就無法判斷它到底進步了多少，也無法比較不同方法的優劣。NVIDIA團隊梳理了當前SD評測領域的三大痛點。

第一個問題是數據不夠多樣。推測解碼的效果高度依賴于輸入文本的類型和復雜度——寫代碼的提示詞和寫詩的提示詞，對草稿模型來說難度天差地別。但現有研究常用的數據集，比如MT-Bench，每個類別只有10個樣本，而且這10個樣本彼此相似度極高，完全無法代表真實世界用戶的多樣需求。更有甚者，MT-Bench的多語言子集清一色都是"把德語翻譯成英語"這種模板式任務，而在SPEED-Bench的對比分析中，這個類別被發現存在嚴重的代表性偏差。

第二個問題是評測環境脫離現實。許多論文用HuggingFace這類面向研究者的高層庫來測速度，但真實的生產部署環境用的是vLLM、TensorRT-LLM、SGLang這類經過深度優化的推理引擎，兩者的性能差異不可忽視。在研究環境里測出來的漂亮數字，到了真實部署里可能大打折扣。

第三個問題是只測單用戶場景。大量論文只報告批量大小為1（即一次只處理一個請求）的加速比，但真實的模型服務要同時應對幾十甚至幾百個用戶的并發請求。隨著并發量增加，系統會從"內存受限"轉向"計算受限"，推測解碼的優勢會迅速收縮，有時甚至會變成負擔。此外，現有數據集幾乎都是短文本，而當今越來越多的應用場景需要處理長達數萬詞的上下文，這個領域的評測幾乎是空白。

三、SPEED-Bench的核心設計：兩套數據加一個測量框架

針對上述三個問題，SPEED-Bench提出了三位一體的解決方案。

首先是"質量評估數據集"（Qualitative Split）。這套數據的核心任務是衡量草稿模型的預測準確率，因此必須盡可能覆蓋各種不同類型的文本。研究團隊從18個公開數據集中取材，劃分成11個大類：編程、數學、人文學科、自然科學、寫作、摘要、角色扮演、檢索增強問答、多語言、推理、問答。每個類別精選80個樣本，總計880個樣本。這個規模看似不大，但每個樣本都經過精心篩選，確保語義上盡可能不重復。與SpecBench相比，SPEED-Bench在多語言類別覆蓋了23種不同語言和多種任務類型，而不是只有德英翻譯；在編程類別涵蓋了Python、C++、Java、Go、JavaScript、Rust等多種語言；大約20%的樣本還包含多輪對話，最多五輪，遠超SpecBench只有兩輪的限制。此外，每個樣本都附有難度標簽和子類別標簽，數學、編程、人文和自然科學類別中約80%的樣本屬于"困難"級別，且經過驗證，用GPT-4生成的回答平均長度約650個詞，足以產生有意義的評測信號。

其次是"吞吐量評估數據集"（Throughput Split）。這套數據專門用于評測系統在不同負載下的實際速度表現。數據按照輸入長度被劃分成5個固定桶：1千、2千、8千、1.6萬、3.2萬個詞元，每個桶里包含來自3個難度層次（低熵、混合熵、高熵）的各512個樣本，合計每個桶1536個樣本。"低熵"指的是結果比較確定、可預測的任務，比如代碼排序；"高熵"指的是開放性強、創意成分多的任務，比如自由寫作；"混合熵"則介于兩者之間，如自然科學問題。這種設計允許研究人員在現實負載下繪制出"吞吐量-延遲"的權衡曲線，直觀看出在什么并發條件下推測解碼是否有益。對于過短的樣本會用中性后綴"請現在作答"補齊，對于過長的則截斷，確保每個桶的輸入長度完全統一。

第三個組件是統一測量框架。這個框架充當一個"標準翻譯官"，在把同一批數據送給不同推理引擎時，確保每個引擎收到的詞元序列完全一致——所有分詞和格式化操作都在框架外部完成，繞過各引擎內部可能不一致的預處理邏輯。框架通過異步事件循環同時發送大量并發請求，模擬真實的高并發服務場景，并通過分析引擎返回的流式響應來計算接受率、接受長度、首詞延遲、用戶每秒詞元數、整體吞吐量等關鍵指標。目前原生支持TensorRT-LLM、vLLM、SGLang三大生產級引擎，以及面向研究社區的SpecBench接口。

四、"最大語義多樣性"的選樣算法

質量評估數據集的880個樣本并非隨機抽取的，而是通過一套精心設計的算法篩選出來的。研究團隊用OpenAI的文本嵌入模型把每個候選樣本轉換成一個高維數字向量，然后用余弦相似度來衡量任意兩個樣本之間的"語義距離"——距離越大，說明兩個樣本內容差異越大。

選樣的目標是找到一組樣本，使得它們兩兩之間的相似度之和最小，也就是讓整個子集盡可能地"散開"，覆蓋語義空間的各個角落。這個優化問題在數學上屬于NP難問題（意味著暴力窮舉計算量大到無法實現），于是研究團隊采用了一種"貪心選擇加局部交換"的啟發式算法：先隨機選一個起點，然后每次加入與當前集合相似度最低的那個候選樣本；初步選完后，反復嘗試將集合內的某個樣本換成集合外的某個樣本，只要這次交換能降低總相似度就執行，直到無法繼續優化為止。

實測結果相當令人信服：與SpecBench相比，SPEED-Bench的平均樣本間相似度降低了40%，在多語言類別降低了整整83%。更有趣的是，即使對同樣的候選數據集做隨機抽樣，效果也普遍優于SpecBench——這說明SPEED-Bench數據來源本身的質量就更高，而優化算法又在此基礎上進一步挖掘了多樣性。團隊還嘗試了一種基于二次規劃的數學近似算法，結果表明貪心算法得到的多樣性分數與之相當，但速度更快、可擴展性更好。

五、合成數據的陷阱：隨機詞元為何會欺騙你

在講述實驗發現之前，有必要先說一個業界常見的壞習慣，以及SPEED-Bench如何揭示了它的危害。

工業界評測推理吞吐量時，有人會圖省事，用隨機生成的詞元序列來充當測試輸入，省去收集真實數據的麻煩。但SPEED-Bench的研究表明，這種做法對于推測解碼評測來說是根本錯誤的。

隨機詞元輸入會觸發兩種截然相反的模型行為，都會扭曲評測結果。第一種是"平凡響應"：模型識別出輸入是亂碼，然后輸出一段通用的"我看不懂你說什么，能否說清楚一點"之類的套話。因為草稿模型也很容易猜到這種模板式回應，所以接受率會被人為抬高。論文舉了一個實例，用隨機輸入測試GPT-OSS 120B配合EAGLE3草稿模型時，平均接受長度高達3.44，模型回答是"看起來您粘貼了一段混合語言文本，我需要更多信息……"第二種是"話題鎖定"：隨機詞元中偶爾出現的某個詞讓模型抓住了一個話題，開始天馬行空地擴展。論文另一個實例中，模型看到隨機輸入后扯到了Unity游戲引擎，洋洋灑灑地開始講制作2D平臺游戲的教程，但此時草稿模型跟不上這種任意跳躍的思路，接受長度只有1.877，遠低于正常水平。

除了影響推測解碼，隨機詞元對混合專家（MoE）架構模型的基礎性能評測也會造成扭曲。MoE模型每次只激活一部分"專家"子網絡，由路由器根據輸入內容決定激活哪些。隨機詞元會讓路由器"崩潰"到少數幾個專家上，違背負載均衡假設，導致步驟延遲測量失真。實驗數據顯示，GPT-OSS 120B在處理8千詞元長度、批量32的輸入時，隨機詞元會導致某些層有20%到30%的專家根本不被激活，而SPEED-Bench的真實數據則產生接近均勻的專家激活分布。正因如此，開啟推測解碼后，隨機數據測出的吞吐量平均比SPEED-Bench真實數據高出23%，是嚴重的高估。

六、主要實驗發現：從接受率到跨引擎性能

研究團隊用SPEED-Bench對多個前沿模型和SD方法進行了系統評測，包括Llama 3.3 70B、GPT-OSS 120B、Qwen3 235B、Qwen3-Next和DeepSeek R1，以及N-Gram、Vanilla SD（外部草稿模型）、EAGLE3和原生MTP四種SD方案。所有質量評測均使用批量大小32，草稿長度3，運行環境為單塊NVIDIA B200 GPU（DeepSeek和Qwen模型使用8塊）。

從質量評估數據集的結果來看，不同類別之間的接受長度差異相當顯著，與直覺相符：編程和數學等"低熵"任務的接受長度最高，而角色扮演等"高熵"任務最低。以Llama 3.3 70B配合EAGLE3為例，編程類的平均接受長度達到3.00，而角色扮演只有2.04。N-Gram方案在批量32的條件下出現了凈減速（加速比低于1），說明在這種并發水平下驗證成本已經超過了收益。Vanilla SD（外部小模型）在某些配置下速度低于EAGLE3，盡管接受長度相近，原因在于運行獨立草稿模型本身有額外開銷。

原生MTP方案（Qwen3-Next）表現出色，在草稿長度3時接受長度達2.81，顯著高于同模型的EAGLE3方案（2.36）。更有意思的是隨草稿長度增加的趨勢：Qwen3-Next的MTP接受率隨草稿長度延長依然保持高位，而EAGLE3在草稿長度超過5之后會出現比較明顯的精度衰退。研究團隊將此歸結為預訓練集成的多詞預測與后訓練附加的推測頭在長推測鏈上的根本性差異——預訓練的方式顯然更有優勢。Vanilla SD（外部模型）也表現出比EAGLE3更好的長草稿鏈穩定性，盡管其單步開銷更大。

在吞吐量評估數據集上，不同熵類別的接受長度走勢與預期一致：低熵任務始終最高，高熵任務最低，混合熵居中。不過GPT-OSS 120B配合EAGLE3出現了一個有趣的異常：在短上下文（1千詞元）時低熵類別表現最好，但隨著輸入長度增加，低熵類別的接受長度急劇下滑，甚至跌至混合熵以下。研究團隊將此歸因于該EAGLE3草稿模型的訓練數據來源——主要是UltraChat和Magpie數據集，其中編程內容極少，自然在代碼排序這類低熵任務上缺乏適應性。

關于最優草稿長度隨批量大小的變化，實驗結果非常直觀：在低批量（系統處于內存受限狀態）時，更長的草稿鏈更有優勢，比如草稿長度3明顯優于草稿長度1；但隨著批量增大到128甚至更高，系統逐漸進入計算受限狀態，驗證多個草稿詞元的額外計算成本開始壓過收益，草稿長度1反而更高效。SPEED-Bench通過吞吐量-延遲曲線幫助工程師找到這個"交叉點"，從而為自己的實際部署場景選擇合適的草稿長度。

關于推理引擎之間的差異，TensorRT-LLM在峰值吞吐量上優于vLLM，主要原因是TensorRT-LLM支持"單模型運行時"模式——將草稿頭直接附加到目標模型上，用一個統一的CUDA計算圖捕獲整個草稿-驗證循環，大幅減少了主機端的調度開銷。vLLM采用"雙模型"方式，草稿模型作為獨立引擎運行，兩者之間的通信會引入額外延遲，盡管異步調度機制能部分掩蓋這種開銷。不過vLLM的分段式圖構建在需要動態調整草稿策略時有更大的靈活性。

七、詞匯表裁剪：優化手段的雙刃劍

EAGLE3為了降低計算瓶頸，采用了一種"詞匯表裁剪"技術：從完整的詞匯表（可能有十幾萬個詞元）中只保留最高頻的3.2萬個，用這個縮減版詞匯表來預測草稿詞元，從而大幅減少最后投影層的計算量。這個做法在標準輸入上效果不錯，但SPEED-Bench的多樣性評測揭示了它隱藏的代價。

研究團隊分析了GPT-OSS 120B用貪心采樣生成的輸出中，有多少詞元落在不同大小的裁剪詞匯表之外。結果顯示：在使用3.2萬詞匯表時，整體覆蓋率達到94.7%，看上去還不錯；但在多語言類別上，覆蓋率只有76.9%，意味著每4個目標詞元就有1個不在詞匯表里，草稿模型根本無法預測這些詞元，接受率必然大幅下滑。實測接受長度數據印證了這一點：與使用完整詞匯表相比，數學類別的接受長度下降了2.28%，編程類別下降了2.94%，寫作類別基本持平（下降0.65%），而RAG（檢索增強問答）下降了10.05%，摘要類別下降了9.51%，多語言類別下降了10.22%，平均下降5.53%。

這個發現表明，如果只在編程和數學任務上評測，詞匯表裁剪幾乎沒有感知成本；但一旦部署到多語言客服、文檔摘要等場景，性能損失就會相當顯著。SPEED-Bench的寬覆蓋評測正是為了把這類"長尾失效"暴露出來。

八、從SpecBench到SPEED-Bench：一個具體的案例對比

為了直觀展示評測數據集多樣性的重要性，研究團隊做了一個對比實驗：用SpecBench和SPEED-Bench分別評測Llama 3.3 70B上的EAGLE3和Vanilla SD，草稿長度設為7。

在SpecBench的編程類別（只有10個樣本）上，EAGLE3和Vanilla SD的接受長度非常接近，看起來兩者水平相當。但切換到SPEED-Bench的編程類別（80個語義多樣的樣本）后，Vanilla SD的接受長度明顯高于EAGLE3，符合外部模型在長草稿鏈上更穩定的預期。

多語言類別的差距更為戲劇性。SpecBench的多語言子集全部是德英翻譯，在這種高度同質的任務上，兩種方法差距不大。但SPEED-Bench的多語言子集覆蓋23種語言和多種任務類型，在這里Vanilla SD展現出了對EAGLE3相當顯著的優勢。這一結果與詞匯表裁剪分析相互印證：EAGLE3在詞匯表外詞元比例高的語言上表現更差，而SpecBench的兩種語言根本無法暴露這個問題。這也正是SPEED-Bench多語言選樣算法取得最高多樣性提升（語義相似度降低83%）的類別——多樣性最高的地方，也是最能區分方法優劣的地方。

九、訓練上下文長度對草稿模型的影響

吞吐量數據集的另一項重要應用，是評測草稿模型在超出其訓練上下文長度時的性能穩定性。研究團隊專門訓練了多個不同訓練序列長度（1千、2千、4千詞元）的GPT-OSS 120B EAGLE3草稿模型，并在SPEED-Bench的全部5個上下文長度桶上評測。

結論是清晰的：一旦推理時的輸入長度超過訓練時的最大長度，接受率就會迅速崩潰。以1千詞元訓練的模型在4千詞元輸入時接受率已經大幅下滑，在1.6萬詞元時幾乎接近基線。不過，研究團隊還發現了一個相對簡單的補救措施：在推理時應用YaRN位置編碼縮放技術，即使對訓練序列只有1千詞元的模型，也能在長上下文下顯著恢復接受率。用2千詞元訓練、配合YaRN縮放的模型，甚至能在3.2萬詞元輸入上維持接近合理的性能。

這對實踐者的指導意義很直接：如果你部署的應用場景涉及長文本處理，草稿模型的訓練序列長度必須足夠，并且推理配置中要正確設置位置編碼縮放，否則實際效果會與短文本測試結果天差地別。研究團隊還順帶檢查了HuggingFace上兩個公開EAGLE3模型在長上下文下的表現，發現都存在明顯的接受率衰退，并分析了可能的原因——其中一個模型可能位置編碼配置與實際訓練長度不一致。

說到底，SPEED-Bench這項工作解決的不是一個花哨的新算法問題，而是一個更基礎卻常被忽視的問題：如何可信地評測已有算法。推測解碼技術本身已經相當成熟，但評測方法的混亂讓研究人員無法準確判斷進步的真實幅度，也讓工程師無法放心地在生產環境中選擇合適的方案。

NVIDIA團隊通過這項工作揭示了若干在傳統評測中看不見的現象：合成數據會系統性高估23%的吞吐量；詞匯表裁剪在多語言場景下會帶來10%以上的接受率損失；最優草稿長度會隨并發量變化發生質的躍遷；訓練上下文長度不足會在長文本場景下造成草稿模型的"斷崖式"失效，而YaRN縮放是一個值得嘗試的低成本緩解手段。

這對普通用戶意味著什么？歸根結底，更好的評測標準會推動更可靠的技術進步，最終讓每次與AI對話的等待時間更短、響應更流暢。有深度興趣的讀者可以通過arXiv編號2604.09557查閱完整論文，或訪問HuggingFace上的SPEED-Bench數據集頁面直接體驗這套評測工具。

Q&A

Q1：推測解碼（Speculative Decoding）是什么原理，為什么能加速大模型？

A：推測解碼利用一個體量小得多的"草稿模型"先快速猜出接下來可能出現的若干詞，然后讓大模型一次性驗證這批猜測。由于驗證多個詞和驗證一個詞的內存搬運成本相差不大，猜對了就相當于"一步走了多步"，整體速度明顯提升。通過拒絕采樣機制，這個過程不改變輸出質量，結果與大模型逐字生成完全一致。

Q2：SPEED-Bench和SpecBench相比有哪些具體改進？

A：SPEED-Bench在多個維度上超越了SpecBench。數據量方面，每類別80個樣本對比SpecBench的10個；數據來源方面，24個數據集對比5個；語義多樣性上平均相似度降低40%，多語言類別降低83%；多語言覆蓋23種語言和多種任務，而非只有德英翻譯；還新增了最長3.2萬詞元的長上下文評測和大批量并發吞吐量測試，這些在SpecBench中完全沒有。

Q3：詞匯表裁剪對EAGLE3在不同任務上的影響有多大？

A：影響差異很大。在數學和編程任務上，接受長度下降只有2%到3%，基本可以忽略；但在多語言、檢索增強問答和摘要類任務上，接受長度下降高達10%左右，原因是這些類別中約22%的目標詞元不在裁剪后的3.2萬詞匯表內，草稿模型根本無法預測。這說明詞匯表裁剪在單一領域評測中看起來無害，但在真實多樣化部署場景中代價不小。