騰訊混元團隊的 AngelSpec 是統一 MTP 與區塊並行推測解碼的訓練框架；其 DFly 區塊擴散方案在 Hy3-A21B 模型上較自回歸解碼達 1.98–2.40 倍端到端加速、吞吐量較 DFlash 高 10.5–11.8%，並把訓練程式碼與 Hy3-A21B 草稿模型權重開源。
推測解碼的老問題：沒有一種草稿器通吃
推測解碼的運作方式，是讓一個輕量草稿器先預測多個 token，再由目標模型一次性驗證，用多餘的算力換取吞吐量。它的加速上限取決於一道張力：草稿被接受的比例愈高愈快，但草稿器本身又不能太重，否則驗證省下的時間會被生成成本吃掉。AngelSpec 由騰訊混元團隊提出，開宗明義點破一個實務盲點：沒有任何單一草稿結構能在所有真實工作負載上都最好。
開放式聊天與程式碼、數學的 token 分布截然不同。前者高熵、難以預測，後者存在大量可預測的長延續。用同一種草稿器應付兩者，必然在其中一端犧牲接受率。AngelSpec 的核心主張，就是把這種工作負載的異質性，從單點最佳化拆成三個層次分別處理。
訓練層的共特化：草稿器對應工作負載
第一層在訓練階段。AngelSpec 對結構與資料做共特化：MTP 草稿器以多樣化的對話資料訓練，擅長高熵的開放式聊天；區塊擴散草稿器則以程式碼與數學資料訓練，鎖定較長且可預測的延續。這不是隨機分工，而是刻意讓草稿器的結構與它所見的資料統計對齊。
對部署團隊的意義在於，推測解碼的增益不是只看模型大小，而是看草稿器與實際流量的匹配程度。一個在數學基準上表現亮眼的草稿器，搬到客服對話場景可能反而拖累延遲；為不同負載準備對應的草稿器，是比換更強的單一草稿器更務實的路徑。
DFly：區塊擴散結合前置條件自回歸
第二層在架構。AngelSpec 提出 DFly，一個區塊擴散框架，結合混合的目標條件主幹與前置條件自回歸頭。它的設計意圖是讓草稿器在同一個主幹上，既能利用擴散對可預測區塊的批量生成能力，又能靠自回歸頭處理需要逐 token 條件化的段落。
「混合主幹」這個選擇背後是一道權衡。純擴散草稿器擅長連續可預測片段，但在需要嚴格依賴前文的 token 上容易出錯；純自回歸又失去批量並行的速度優勢。DFly 把兩者掛在同一個目標條件主幹上，讓擴散與自回歸各自負責自己擅長的環節，本質上是用架構分工呼應訓練層的資料分工。
推論層：把驗證當共享資源並線上調適深度
第三層在推論調度。DFly 把驗證視為批次層級的共享資源，而非每個請求各自負擔的成本，並根據一份剖析過的成本模型，以期望效用線上調適每次的驗證深度。也就是說，系統不固定要驗證多少草稿 token，而是即時估算多驗證一段划不划算，再動態決定。
這一層最容易在工程實務被忽略。推測解碼的教科書討論常假設固定的驗證長度，但在真實並發服務裡，草稿接受率會隨查詢類型波動；把驗證深度寫死，等於在某些負載下浪費算力、在另一些負載下錯失加速。線上調適深度，是把架構與訓練的增益在系統層面真正兌現的關鍵一步。
1.98–2.40 倍背後的三層疊加與開源意義
實測數字聚焦在騰訊自家的 Hy3-A21B 模型。DFly 帶來的平均接受長度增加約 30%，端到端較自回歸解碼加速 1.98 至 2.40 倍，吞吐量較 DFlash 高 10.5 至 11.8%，並在並發數 4 到 64 的區間內全程取得最高平均吞吐量。訓練程式碼與 Hy3-A21B 的 MTP／DFly 草稿模型權重已開源。
看待這組數字有兩點必須留意。其一，1.98 至 2.40 倍是區間而非定值，實際倍數隨工作負載浮動，正呼應沒有單一草稿器通吃的核心主張；其二，所有數字皆為論文在自家模型上的自測結果，採購或遷移前應以自身工作負載重新量測。就加速曲線的拆解風格而言，它與〈SANA-Video 2.0〉把提速拆成架構與系統兩層的思路遙相呼應，兩者都指向同一個結論：真實部署的加速從來不是單一技巧的功勞，而是多層最佳化的相乘；而在推論管線的另一端，〈GigaToken〉則示範了分詞環節的加速如何成為端到端成本的另一個槓桿。
