聞樂 發自 凹非寺

量子位 | 公眾號 QbitAI

梁文鋒署名的DeepSeek新論文DSpark你可能刷到過了——

單用戶速度提升85%、高并發場景有效吞吐翻4倍。

但你真的看懂了嗎？

別急，有人替你拆解了一遍。

Fireworks AI的聯合創始人兼CTO、PyTorch核心維護者Dmytro Dzhulgakov將整篇論文梳理成了10個概念，從最底層的GPU訪存特性講到最上層的在線自適應調度。

他認為：

DeepSeek這套方案真正的精髓在于系統工程和模型協同設計。

相關基礎思路前人已有提出，難能可貴的是其將各類技術融合為一套自適應完整系統，實現了端到端的顯著性能優化。

下面我們就順著這10個概念過一遍DSpark。

10個概念理解DSpark批處理解碼（Batching in LLM Decoding）

想要搞懂大模型各類推理加速技術，首先要理解GPU一個非常特殊的運行特性：

讓GPU同時解碼10個token，其實只比解碼1個token慢一點點。

卡帕西曾經講過，原因在于大模型推理的瓶頸不是浮點運算，而是顯存帶寬，GPU大部分時間花在把模型權重從顯存搬到計算核心上。

搬一次也是搬，搬十次也是搬，既然權重已經加載到了緩存里，不如一次搬運、干十件事。

這就是連續批處理：把多個請求的token塞進同一個batch，讓每一次顯存讀取都物盡其用。

理解了這一點，就明白為什么推測解碼能奏效，它的本質就是把“猜出來的多個候選token”打包成一個batch送給大模型驗證，而驗證batch的成本，遠低于逐個生成的成本。

推測解碼（Speculative Decoding）

大模型生成是自回歸的，第N+1個token依賴第N個token的結果，沒法直接并行。

但有一種繞路的辦法，如果你能「猜」出接下來幾個token是什么，就可以把猜出來的候選序列一次性喂給大模型做批量驗證。

驗證是通過拒絕***樣，系統逐個檢查候選token，接受最長的正確前綴，在第一個分歧點重新***樣一個token。

這套規則在數學上保證輸出分布與原模型完全一致，沒有任何質量損失。

所以推測解碼的本質是用“猜+驗”替代“逐字生成”。

猜的環節用小模型可以很快，驗的環節進行批量驗證可以很高效，所以最終每一步都能往前跳好幾個token。

DSpark就是這個方向上的最新進展。

草稿模型（Draft Model）

那怎么猜呢？

最直接的方案是拿一個小模型當“草稿器”。

比如用Qwen 0.8B給Qwen 3***B探路，小模型跑得快，把候選序列生成好，大模型只需要做一次前向傳播來驗證。

通過了就全收，沒通過就從分歧點重新來。

這個設計把推理過程分成了兩個角色，速度型選手草稿器負責猜，力量型選手目標模型負責判。

二者配合得好，整體速度就能大幅提升。

但要想配合得好，背后需要權衡大量工程取舍，接下來幾個概念就是在講這些取舍。

推測并不免費（Speculation is Not Free）

草稿模型引入了額外開銷。

如果草稿器自己跑得太慢，或者一次猜了16個token但只有前3個被接受，那這筆帳就不劃算了。

論文給出了一個核心公式來描述實際延遲：

每個token的耗時= （草稿耗時+驗證耗時） /被接受的token數τ。

在這個理論下，加速只有三條路可以走，降低草稿耗時（猜得更快）、提高τ（猜得更準）、減少驗證浪費（驗得更聰明）。

猜得越多不一定越好，因為如果多猜的token大概率被拒絕，它們只會白白占用驗證batch的寶貴算力。

所以DSpark的整篇論文，可以理解為同時拉動這三個杠桿的一次系統性嘗試。

Eagle與MTP，復用目標模型的內部理解

第一根杠桿，就是優化草稿模型本身的構造。

草稿模型不用從零訓一個完整的小模型，有一種更聰明的做法是直接把目標模型最后一層的隱藏狀態拿過來，在上面加1–2層Transformer頭當草稿器。

這就是Eagle系列和MTP（Multi-Token Prediction）的思路。

△圖源：DeepSeek-V3 Technical Report

好處有兩個，一個是快，草稿器只有1–2層，計算量極低；

二是準，因為它直接吃的是目標模型的內部理解，也就是最后一層激活值，等于站在巨人肩膀上猜下一步，比從頭用小模型獨立推理要靠譜得多。

DeepSeek-V3就已經在用MTP做單token推測（MTP-1）。

DSpark論文中所有的加速數字都是跟MTP-1這個基線對比的，也就是說，60%–85%的速度提升是在已經優化過的基礎上再疊加的。

DFlash，用并行一口氣猜完

但Eagle/MTP的問題在于，要生成N個候選token，就得跑N步，第2個token依賴第1個的輸出，第3個依賴第2個……串行的鏈條沒法打破。

DFlash的思路是借鑒擴散模型的做法，一次前向傳播就把全部N個候選位置同時產出。

速度確實快，但代價是各位置之間沒有依賴關系。開頭幾個token可能很準，因為上下文信息充足，但越往后越拉胯。

論文管這個問題叫多模態碰撞。

舉個例子，位置1***樣出“of”，位置2獨立***樣出“problem”，各自看概率都合理，拼在一起就變成了“of problem”這種不通順的組合。

位置越靠后，這種跑偏的概率越大，接受率急劇下滑。

這就是所謂的后綴衰減（suffix decay），也是純并行方案在實際部署中加速效果打折的主因。

DSpark≈Eagle+DFlash，兩頭都要

DSpark的核心創新，用一句話說清就是把并行和串行拼在一起，各取所長。

具體做法分兩步。第一步，用DFlash的并行骨干網絡一口氣生成所有位置的基礎logits，這一步負責速度。

第二步，用一個輕量級的順序頭從前往后逐個位置注入前綴依賴偏置，這一步負責修正后綴衰減。

用上面的例子來看，效果是：

位置1***樣出“of”之后，順序頭會把位置2的概率分布往“course”方向推，同時壓低“problem”的概率。

并行骨干保證了整體速度不拖后腿，順序頭保證了后半段的接受率不崩盤。

在論文的離線測試中，DSpark的平均接受長度比Eagle3高26%–31%，比DFlash高16%–18%。

兩層DSpark甚至打得過五層DFlash。

更便宜的串行模塊，馬爾可夫頭

既然第二步要加一個順序頭，那它的成本不就把第一步省下來的時間又吃回去了嗎？

DSpark的回答是：不會，因為并行骨干已經把上下文信息編碼好了，串行步驟不需要再做完整的注意力計算，只需要做極輕量的修正。

默認方案是一個馬爾可夫頭，它只看前一個token就決定當前位置的修正方向，通過低秩分解（rank 256），即使詞表有十幾萬個token，計算成本也幾乎可以忽略。

實測數據就很能說明問題，草稿長度從4擴展到16，每輪額外增加的延遲只有0.2%–1.3%，但接受長度最高提升了30%。

論文里還提供了一個 RNN 頭的可選方案，可以追蹤整個草稿塊的前綴信息，但實際增益有限，所以默認沒有開啟。

這也體現了DSpark的工程審美，不是越復雜越好，而是找到成本和收益的最優折中。

可變長度草稿與硬件感知調度

那每次應該猜幾個token呢？這個問題沒有固定答案。

首先，不同類型的請求天然不同。

代碼生成的可預測性高（語法模式強），草稿器猜8–16個token可能都能過審；開放式閑聊不確定性大，猜4個就可能翻車。

其次，服務器的實時負載也在變化。

GPU空閑時，多猜幾個token沒什么額外成本，反正算力閑著也是閑著；高并發時，每一塊驗證batch的算力都很金貴，不該浪費在大概率被拒絕的尾部token上。

于是DSpark用一個置信度頭給每個草稿位置打分，預估它在驗證中存活的概率。

這套方案會預先測算GPU在各類批次尺寸下的硬件吞吐數據，生成吞吐量參考曲線，再依據曲線結果為每條請求動態匹配最優驗證長度。

整套調度邏輯完全在GPU內部執行，無需CPU參與，雖然實現門檻極高，但該方案已經落地了。

在線草稿器校準

接下來，就是最后一塊拼圖，在線草稿置信度校準。

置信度頭的思路很好，但有一個實際問題是“神經網絡天生過度自信”。

它覺得自己猜的每個token都對，這就會導致原始置信度評分不可靠，該停的時候不停，該放手的時候死撐。

如果直接用模型輸出的概率設閾值，系統表現會跑偏。

DSpark 的做法是在運行時持續觀察草稿器的實際表現。

論文中使用順序溫度縮放做后處理校準，把預期校準誤差從3%–8%壓到了約1%。

更關鍵的是，這個校準過程是在線的，系統邊跑邊調，根據當前工作負載的實際接受率動態修正閾值。

代碼任務跑多了，它就學會對代碼草稿更寬容；聊天任務來了，它自動收緊閾值。

越跑越準，真正做到了自適應。

這10個概念單獨拎出來，大部分確實算不上全新，但整套方案完成了算法、調度、硬件適配三位一體的端到端工程閉環。

而且DeepSpec全棧訓練庫一并開源，Eagle3、DFlash、DSpark三種草稿模型的訓練代碼全部放出，支持Qwen3和Gemma等外部模型——

你想給自己的模型訓一個草稿器，直接拿過去改就行。

OMT

DSpark配套的DeepSpec庫目前在GitHub已經拿下1.4k Star，各路開發者都開始實操內卷。

海外大佬看完論文火速掏出兩塊RTX PRO 6000在家折騰DSpark。

兩塊顯卡火力拉滿

，看得出來很努力了（doge）。

論文地址：***s://github***/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

參考鏈接：

[1]***s://x***/dzhulgakov/status/2070922887595499930?s=20

[2]***s://x***/Hikari_07_jp/status/2070842526450479188?s=20返回搜狐，查看更多