這項由上海交通大學EPIC實驗室主導，聯合華中科技大學軟件工程學院、電子科技大學、復旦大學以及華為的研究團隊共同完成的工作，于2026年5月28日以預印本形式發布，論文編號為arXiv:2605.29707。有興趣深入了解的讀者可以通過該編號查詢完整論文。

**一、AI對話為什么有時候慢得像打字機？**

每次你和一個大型AI助手聊天，不知道有沒有注意到一個現象：它回答問題的時候，文字是一個一個蹦出來的，就像有人在一旁慢慢打字。這不是AI在賣關子，而是它真實的工作方式——大語言模型（也就是GPT、Qwen這類AI的底層技術）在生成文字時，天生就是"一個字一個字往外蹦"的串行結構，每蹦出一個字，都需要經歷一次完整的計算。

這個設計有一個嚴重的問題：現代GPU（顯卡）是為大規模并行計算而生的，就像一個可以同時開動幾千條流水線的工廠，但大語言模型的工作方式偏偏只用其中一條流水線，其余幾千條全部閑置。結果就是：算力浪費嚴重，回答速度慢。

為了解決這個問題，研究人員發明了一種叫做"推測解碼"（Speculative Decoding）的加速技術。核心思路可以用一個"快遞打包"的比喻來理解：正常情況下，你每次下單，倉庫都要單獨打包、發貨，一次只發一件；推測解碼則是，先讓一個"見習員工"預測你接下來可能買的幾件商品并提前打好包，然后讓"資深員工"一口氣審核這批包裹，如果預測對了就統一發出，錯了就從出錯的地方重新來過。由于"資深員工"審核多件商品的速度和審核一件差不多，整體效率就大幅提升了。

然而，這套方法在實踐中遇到了一個棘手的困境，正是這篇論文要正面解決的核心問題。

**二、"見習員工"的兩難困境：質量與速度不可兼得**

繼續用"快遞打包"的比喻。"見習員工"（負責草擬答案的小模型，稱為"草稿模型"）需要預測接下來幾個字，這件事做得好不好，決定了整套流程能快多少。

做得好意味著什么？意味著"見習員工"每次猜對的字越多，"資深員工"就能一口氣確認越多，效率越高。研究人員把"見習員工"平均每輪能猜對多少個字叫做"接受長度"——這個數字越大，加速效果越好。

那么怎樣才能猜得準？關鍵在于，見習員工在猜第二個字的時候，必須知道第一個字是什么；猜第三個字的時候，必須知道前兩個字是什么……這種"后一個字依賴前一個字"的鏈式關系，叫做"因果依賴"。順著這條鏈子一步步猜，準確率高，這就是"自回歸起草"方法（以EAGLE系列為代表）——它讓見習員工像真人一樣，一字一字順序往下寫，后面的字都參考前面的字。

但問題來了：這種方式雖然準，卻慢。要預測16個字，就要讓見習員工跑16次完整的計算，而且每次都要再經過一次龐大的"詞典查找"（LM Head投影，即把內部計算結果映射到幾萬個詞匯上選出最可能的字），這個步驟本身就很費時間。計算的時間開銷隨著預測字數線性增長，最終把省下來的時間又吃掉了一大半。

另一條路是"并行起草"——讓見習員工一次性把所有字都預測出來，不管前后依賴，全部并行計算（以DFlash為代表）。這樣只需要跑一次計算，速度快很多。但代價是，因為沒有考慮前后字的關系，猜測的準確率下降，接受長度縮短，加速效果也因此打折扣。

具體數字可以說明這個兩難局面：在同等條件下，EAGLE-3（自回歸方法）的平均接受長度達到4.86個字，但最終加速比只有3.28倍；DFlash（并行方法）加速比提升到3.42倍，但接受長度卻降到了4.03個字。兩種方法各有明顯短板，誰也無法做到又快又準。

這就引出了這篇論文的核心問題：有沒有可能把并行起草的速度，和自回歸起草的準確率，同時拿到手？

**三、"多米諾骨牌"的靈感：分開做兩件事**

研究團隊給出的答案是"Domino"框架，名字本身就是一個絕妙的比喻。多米諾骨牌的精妙之處在于：每一塊牌倒下時，都會推動下一塊，前后之間有嚴格的因果依賴鏈——但如果你想知道這排骨牌會不會全部倒下，你不必等著它們一塊一塊倒，你可以先把整排骨牌的擺放情況（初步預測）一次性掃描清楚，然后再做一個輕量級的"因果修正"，檢查每塊牌受前面那塊牌影響之后會如何變化。

Domino框架正是如此運作的。它把整個草稿生成過程分成兩個階段，這兩個階段各司其職，互不干擾。

第一個階段叫做"并行草稿骨干"（Parallel Draft Backbone）。這個階段直接沿用DFlash的架構，做的事情就是：給定當前已經確認的文字前綴，一次性并行生成整個草稿塊的初步預測分布。技術上講，模型接收目標大模型的上下文特征，以及一個"遮罩草稿塊"（把待預測位置都用MASK標記遮住），然后一次性并行跑完所有層，輸出每個位置的隱藏狀態，再經過目標大模型凍結的LM Head得到每個位置的"基礎概率分布"（base logits）。這一步非常快，因為整個草稿塊只需要一次前向計算。

第二個階段就是Domino的核心創新，叫做"Domino頭"（Domino Head）。這是一個輕量級的"因果修正模塊"，專門負責把因果依賴信息注入到第一階段生成的初步預測里，而且開銷極小。

**四、Domino頭是怎么工作的？**

Domino頭由兩個部分構成：因果編碼器和低秩修正頭。

因果編碼器用的是一種叫做GRU（門控循環單元）的輕量級神經網絡結構，隱藏維度只有1024。GRU本身就是為了處理序列信息而生的——它就像一個小小的記事本，每讀入一個新的詞，就把之前所有詞的信息壓縮成一個"狀態摘要"記錄下來，供下一個詞參考。在Domino中，因果編碼器從草稿塊的第一個位置開始，依次讀入每個已經采樣出的草稿詞的嵌入表示，不斷更新這個"狀態摘要"，到了第i個位置時，記事本里就存儲了前i-1個草稿詞的因果信息。這個過程確實是順序的，但GRU極其輕量，順序開銷遠比跑一次完整的大模型小得多。

低秩修正頭負責把因果信息轉化為對初步預測的"修正量"。具體做法是：把第一階段輸出的隱藏狀態，和GRU輸出的因果摘要狀態拼接在一起，先用一個矩陣W1壓縮到一個低維瓶頸空間（維度只有256），經過SiLU激活函數后，再用矩陣W2映射回詞匯空間，得到一個"修正邏輯值"（correction logits）。這個修正值直接加到第一階段的基礎邏輯值上，得到最終的草稿分布。

關鍵的設計決策在于：修正是在"邏輯值空間"完成的，而不是在"隱藏狀態空間"。如果在隱藏狀態空間做修正，每次修正后還需要重新跑一遍完整的LM Head投影，又把昂貴的全詞匯投影計算引回來了。而在邏輯值空間做修正，只需要一次低秩的矩陣運算，計算量極小。

最終的效果非常顯著：和DFlash相比，Domino只增加了5600萬參數（參數量增幅僅5.3%），總的起草加驗證延遲只增加2.8%，但平均接受長度提升了16.6%，端到端加速比提升了12.3%。

**五、訓練的兩個關鍵決策：為什么不能直接訓練？**

模型設計好了，怎么訓練它同樣大有講究。研究團隊在訓練階段遇到了兩個不同的"坑"，并分別給出了解決方案。

第一個坑是：因果編碼器在訓練時應該喂什么數據。一種自然的想法是，讓模型在訓練時就模擬實際使用時的情況——先自己生成草稿詞，然后把這些自己生成的（可能有錯的）草稿詞喂給因果編碼器，學習如何修正。這種方式叫做"訓練時測試"（TTT），EAGLE-3就是這么做的。

然而研究團隊選擇了另一種方式：教師強制（Teacher Forcing），也就是在訓練時直接把正確答案的詞喂給因果編碼器，而不是自己生成的詞。理由有兩個方面。第一，自己生成的詞在訓練早期往往大量出錯，用錯誤的輸入去監督正確的輸出，相當于在教模型"從錯誤的前提出發，推出正確的結論"，這個映射關系在真實數據中根本不存在，會讓因果編碼器學偏。第二，從推測解碼的運作邏輯來看，第i個位置的草稿詞能否對最終接受長度作出貢獻，前提是前面所有位置的草稿詞都已經被目標模型驗證為正確。換句話說，因果修正真正起作用的場合，恰恰是前綴都是正確詞的情況——這和教師強制訓練時的輸入分布完全吻合。實驗證明，教師強制相比TTT，平均接受長度從3.80提升到3.96。

第二個坑是教師強制引入的新問題。由于訓練時因果編碼器總是拿到干凈的正確前綴，修正分支學起來會特別"輕松"，以至于它可以越俎代庖，把并行骨干的功勞都搶過來——骨干輸出的基礎預測越來越差（"反正有修正分支兜底，隨便預測就行"），修正分支越來越強，最終整個模型對骨干嚴重退化，只靠修正分支單打獨斗。這種現象叫做"骨干崩潰"，從訓練曲線上看就是并行骨干的損失值一路居高不下，無法正常下降。

為了解決這個問題，研究團隊設計了"基礎錨定課程"（Base-anchored Curriculum）。訓練目標被設計為兩個損失的加權組合：一個是針對基礎預測的損失，一個是針對最終（經修正后）預測的損失。權重隨訓練進程動態變化：訓練初期，權重完全傾向于基礎預測損失，強制骨干先把基礎分布學好；隨著訓練推進，權重線性從基礎預測損失向最終預測損失過渡，讓修正分支逐漸接管"精修"任務。這就像教一個學徒廚師：先讓他把刀工、火候等基本功練扎實，再教他各種調味技巧——而不是一開始就讓他堆砌各種調料掩蓋食材本身的問題。

實驗數據驗證了這個設計的價值：教師強制加上基礎錨定課程（TF+Curr）的平均接受長度達到4.19，比單純教師強制（TF）的3.96又進一步提升，比TTT的3.80更是提升明顯。

此外，在實現層面，Domino頭的順序修正循環采用了融合Triton內核和CUDA Graph技術進行優化，將內核啟動和Python層面的調度開銷大幅壓縮，Domino頭的實際延遲從2.64毫秒降低到1.20毫秒。

**六、實驗結果：數字說話**

研究團隊在Qwen3-4B和Qwen3-8B兩個目標模型上進行了全面評測，任務覆蓋數學推理（GSM8K、MATH-500、AIME25）、代碼生成（HumanEval、MBPP、LiveCodeBench）和開放對話（MT-Bench、Alpaca）三大類別。對比方法包括自回歸起草的EAGLE-3（樹大小16和60兩種配置）、并行起草的DFlash和DART，以及詞匯裁剪方法FR-Spec。

在Transformers后端的低并發場景下，Domino的表現相當突出。以貪婪解碼（溫度為0）為例，在Qwen3-8B上，Domino在GSM8K上實現了7.92倍加速，在MATH-500上實現了7.38倍，在HumanEval上實現了5.89倍，在MBPP上實現了5.53倍，在LiveCodeBench上實現了5.27倍，在MT-Bench上實現了3.29倍，在Alpaca上實現了2.78倍，八個任務的平均加速比達到5.49倍。而同等條件下，EAGLE-3（16）的平均加速比僅為1.97倍，EAGLE-3（60）為2.26倍，DFlash（16）為4.66倍，DART（60）為2.29倍。即便與最接近的競爭者DFlash相比，Domino也多出了近一個百分點。在Qwen3-4B上，Domino的平均加速比進一步達到5.47倍，同樣優于DFlash的4.70倍。

在采樣解碼（溫度為1，輸出更隨機）的條件下，Domino同樣保持領先：Qwen3-8B上的平均加速比為4.46倍，高于DFlash的3.96倍；Qwen3-4B上為4.61倍，高于DFlash的4.03倍。

在高并發場景下，研究團隊使用SGLang推理服務框架測試了吞吐量。以Qwen3-8B、GSM8K任務為例，在并發數為2時，Domino達到942 tokens/秒（約為基線的5.1倍），并發32時達到3650 tokens/秒（約為基線的2.1倍）。同等條件下，DFlash在并發2時為672 tokens/秒（3.7倍），并發32時為2801 tokens/秒（1.6倍）。EAGLE-3（16）在并發32時已經接近或低于基線水平（0.8倍），說明在高并發下，自回歸起草的順序開銷極大地拖累了整體吞吐量，而并行起草類方法在高并發下優勢更為明顯。

為了排除訓練數據差異對結果的影響，研究團隊還專門做了同數據對比實驗：所有方法均在相同的ShareGPT數據集上訓練，使用相同的16詞草稿預算。在這種嚴格控制的條件下，Domino在GSM8K、HumanEval、LiveCodeBench三個任務上的低并發（1個請求）加速比分別為3.01倍、2.82倍、2.55倍，均優于EAGLE-3（2.35/2.27/1.99倍）、FR-Spec（2.77/2.67/2.36倍）和DFlash（2.68/2.58/2.36倍）。這說明Domino的增益來自模型設計本身，而非數據優勢。

消融實驗進一步拆解了Domino頭的具體貢獻：在同一個訓練好的模型上，關閉因果修正分支時，平均接受長度為3.49，平均加速比為2.84倍；開啟因果修正分支后，平均接受長度提升至4.19，平均加速比提升至3.31倍。GSM8K上的提升最為明顯，接受長度從3.82提升到4.80，加速比從3.17倍提升到3.84倍。這證明輕量級因果修正是Domino超越純并行骨干的關鍵所在。

**七、客觀看待這套方案的邊界**

研究團隊在論文末尾也坦誠地指出了這項工作目前的局限。Domino當前的實現主要適配SGLang推理框架，在其他推理框架（例如vLLM等）上的兼容性尚未系統評估。此外，實際加速效果受硬件平臺差異的影響較大——不同GPU的顯存帶寬、計算能力和內核效率各不相同，在不同硬件環境下部署時可能需要針對性的優化調整。這項研究聚焦于推理階段的加速，并不涉及模型訓練或微調成本的降低。

歸根結底，Domino給出了一個清晰的技術答案：并行起草和因果建模并不是非此即彼的選擇，完全可以通過架構設計把兩者的優勢疊加起來。用極小的參數開銷和極低的時延代價，把遺漏的因果依賴信息補回來，最終實現"魚和熊掌兼得"。隨著大語言模型在越來越多的實際場景中部署，這類面向推理效率的精細化工程探索，可能比單純追求更大模型更具現實意義——畢竟，同樣的算力資源，如果能多服務幾倍的用戶，本身就是一件很有價值的事。對這個課題有興趣的讀者，可以通過arXiv編號2605.29707查閱完整論文，代碼和模型權重也已在GitHub和Hugging Face上公開。

Q&A

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

A：推測解碼的核心是用一個小模型提前猜測大模型接下來會輸出的幾個詞，然后讓大模型一次性審核這批猜測，審核多個詞的時間和審核一個詞差不多。如果猜對了，就一次性推進多步，相當于大模型的每次計算能產生更多輸出，整體速度因此提升。

Q2：Domino方法與EAGLE-3和DFlash相比，分別在哪些方面做了改進？

A：EAGLE-3是逐詞順序生成草稿，因果建模準確但速度慢；DFlash是一次性并行生成所有草稿詞，速度快但丟失了詞與詞之間的因果依賴，準確率下降。Domino保留DFlash的并行骨干做快速初稿，再用輕量級GRU編碼器把因果信息以"修正量"的形式補回來，兼顧了速度和準確率。

Q3：基礎錨定課程訓練策略解決了什么問題？

A：在教師強制訓練中，因果修正分支拿到干凈的正確前綴后很容易"搶功"，導致并行骨干的基礎預測退化。基礎錨定課程通過動態調整損失權重，訓練初期強制骨干先把基礎預測學好，后期再逐步讓修正分支發揮作用，避免了骨干崩潰，最終接受長度比單純教師強制又提升了約5.8%。