聞樂 發(fā)自 凹非寺
量子位 | 公眾號 QbitAI

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

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

但你真的看懂了嗎？

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

Fireworks AI的聯(lián)合創(chuàng)始人兼CTO、PyTorch核心維護(hù)者Dmytro Dzhulgakov將整篇論文梳理成了10個概念，從最底層的GPU訪存特性講到最上層的在線自適應(yīng)調(diào)度。

他認(rèn)為：

DeepSeek這套方案真正的精髓在于系統(tǒng)工程和模型協(xié)同設(shè)計

相關(guān)基礎(chǔ)思路前人已有提出，難能可貴的是其將各類技術(shù)融合為一套自適應(yīng)完整系統(tǒng)，實(shí)現(xiàn)了端到端的顯著性能優(yōu)化。

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

10個概念理解DSpark

批處理解碼（Batching in LLM Decoding）

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

讓GPU同時解碼10個token，其實(shí)只比解碼1個token慢一點(diǎn)點(diǎn)。

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

搬一次也是搬，搬十次也是搬，既然權(quán)重已經(jīng)加載到了緩存里，不如一次搬運(yùn)、干十件事。

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

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

推測解碼（Speculative Decoding）

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

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

驗證是通過拒絕采樣，系統(tǒng)逐個檢查候選token，接受最長的正確前綴，在第一個分歧點(diǎn)重新采樣一個token。

這套規(guī)則在數(shù)學(xué)上保證輸出分布與原模型完全一致，沒有任何質(zhì)量損失。

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

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

DSpark就是這個方向上的最新進(jìn)展。

草稿模型（Draft Model）

那怎么猜呢？

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

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

通過了就全收，沒通過就從分歧點(diǎn)重新來。

這個設(shè)計把推理過程分成了兩個角色，速度型選手草稿器負(fù)責(zé)猜，力量型選手目標(biāo)模型負(fù)責(zé)判

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

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

推測并不免費(fèi)（Speculation is Not Free）

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

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

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

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

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

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

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

Eagle與MTP，復(fù)用目標(biāo)模型的內(nèi)部理解

第一根杠桿，就是優(yōu)化草稿模型本身的構(gòu)造。

草稿模型不用從零訓(xùn)一個完整的小模型，有一種更聰明的做法是直接把目標(biāo)模型最后一層的隱藏狀態(tài)拿過來，在上面加1–2層Transformer頭當(dāng)草稿器。

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

△圖源：DeepSeek-V3 Technical Report

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

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

DeepSeek-V3就已經(jīng)在用MTP做單token推測（MTP-1）。

DSpark論文中所有的加速數(shù)字都是跟MTP-1這個基線對比的，也就是說，60%–85%的速度提升是在已經(jīng)優(yōu)化過的基礎(chǔ)上再疊加的

DFlash，用并行一口氣猜完

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

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

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

論文管這個問題叫多模態(tài)碰撞

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

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

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

DSpark≈Eagle+DFlash，兩頭都要

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

具體做法分兩步。第一步，用DFlash的并行骨干網(wǎng)絡(luò)一口氣生成所有位置的基礎(chǔ)logits，這一步負(fù)責(zé)速度。

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

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

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

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

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

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

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

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

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

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

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

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

這也體現(xiàn)了DSpark的工程審美，不是越復(fù)雜越好，而是找到成本和收益的最優(yōu)折中。

可變長度草稿與硬件感知調(diào)度

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

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

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

其次，服務(wù)器的實(shí)時負(fù)載也在變化。

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

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

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

整套調(diào)度邏輯完全在GPU內(nèi)部執(zhí)行，無需CPU參與，雖然實(shí)現(xiàn)門檻極高，但該方案已經(jīng)落地了。

在線草稿器校準(zhǔn)

接下來，就是最后一塊拼圖，在線草稿置信度校準(zhǔn)

置信度頭的思路很好，但有一個實(shí)際問題是“神經(jīng)網(wǎng)絡(luò)天生過度自信”

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

如果直接用模型輸出的概率設(shè)閾值，系統(tǒng)表現(xiàn)會跑偏。

DSpark 的做法是在運(yùn)行時持續(xù)觀察草稿器的實(shí)際表現(xiàn)。

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

更關(guān)鍵的是，這個校準(zhǔn)過程是在線的，系統(tǒng)邊跑邊調(diào)，根據(jù)當(dāng)前工作負(fù)載的實(shí)際接受率動態(tài)修正閾值。

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

越跑越準(zhǔn)，真正做到了自適應(yīng)。

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

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

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

OMT

DSpark配套的DeepSpec庫目前在GitHub已經(jīng)拿下1.4k Star，各路開發(fā)者都開始實(shí)操內(nèi)卷。

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

兩塊顯卡火力拉滿，看得出來很努力了（doge）。

論文地址：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
[1]https://x.com/dzhulgakov/status/2070922887595499930?s=20
[2]https://x.com/Hikari_07_jp/status/2070842526450479188?s=20