梁文鋒署名的DSpark，看懂這10個(gè)點(diǎn)就夠了！

來源：量子位 | 公眾號(hào) QbitAI

聞樂 發(fā)自 凹非寺

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

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

但你真的看懂了嗎？

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

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

他認(rèn)為：

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

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

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

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

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

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

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

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

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

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

推測解碼（Speculative Decoding）

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

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

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

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

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

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

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

草稿模型（Draft Model）

那怎么猜呢？

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

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

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

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

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

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

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

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

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

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

每個(gè)token的耗時(shí)= （草稿耗時(shí)+驗(yàn)證耗時(shí)） /被接受的token數(shù)τ。

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

猜得越多不一定越好，因?yàn)槿绻嗖碌膖oken大概率被拒絕，它們只會(huì)白白占用驗(yàn)證batch的寶貴算力。

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

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

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

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

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

圖源：DeepSeek-V3 Technical Report

好處有兩個(gè)，一個(gè)是快，草稿器只有1–2層，計(jì)算量極低；

二是準(zhǔn)，因?yàn)樗苯映缘氖悄繕?biāo)模型的內(nèi)部理解，也就是最后一層激活值，等于站在巨人肩膀上猜下一步，比從頭用小模型獨(dú)立推理要靠譜得多。

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

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

DFlash，用并行一口氣猜完

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

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

速度確實(shí)快，但代價(jià)是各位置之間沒有依賴關(guān)系。開頭幾個(gè)token可能很準(zhǔn)，因?yàn)樯舷挛男畔⒊渥悖酵笤嚼琛?/p>

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

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

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

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

DSpark≈Eagle+DFlash，兩頭都要

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

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

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

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

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

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

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

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

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

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

DSpark的回答是：不會(huì)，因?yàn)椴⑿泄歉梢呀?jīng)把上下文信息編碼好了，串行步驟不需要再做完整的注意力計(jì)算，只需要做極輕量的修正。

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

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

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

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

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

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

首先，不同類型的請(qǐng)求天然不同。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

閱讀最新前沿科技趨勢報(bào)告，請(qǐng)?jiān)L問21世紀(jì)關(guān)鍵技術(shù)研究院的“未來知識(shí)庫”

未來知識(shí)庫是 “21世紀(jì)關(guān)鍵技術(shù)研究院”建 立的在線知識(shí)庫平臺(tái)，收藏的資料范圍包括人工智能、腦科學(xué)、互聯(lián)網(wǎng)、超級(jí)智能，數(shù)智大腦、能源、軍事、經(jīng)濟(jì)、人類風(fēng)險(xiǎn)等等領(lǐng)域的前沿進(jìn)展與未來趨勢。目前擁有超過8000篇重要資料。每周更新不少于100篇世界范圍最新研究資料。 歡迎掃描二維碼或訪問https://wx.zsxq.com/group/454854145828進(jìn)入。

截止到2月28日 ”未來知識(shí)庫”精選的百部前沿科技趨勢報(bào)告

（加入未來知識(shí)庫，全部資料免費(fèi)閱讀和下載）