最近忙著大規模招兵買馬的 DeepSeek，也始終沒有忘記開源這條主線。

今天，DeepSeek 與北京大學團隊聯合發佈論文《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》，提出了一套新的大模型推理加速框架 DSpark。

技術報告 🔗 https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

論文披露，DSpark 已經進入 DeepSeek-V4-Flash preview 和 DeepSeek-V4-Pro preview 的生產服務系統，並替代此前的 MTP-1 方案。

線上上真實使用者流量中，在系統總吞吐水平相同的情況下，DSpark 將 DeepSeek-V4-Flash 的單使用者生成速度提升了 60% 至 85%，將 DeepSeek-V4-Pro 的單使用者生成速度提升了 57% 至 78%。

速度飆成這樣，DeepSeek 究竟給自家的推理引擎喂了什麼靈丹妙藥？當然，本文難免有些枯燥，感興趣的朋友不妨耐心閱讀。

為什麼每次等到大模型的回覆總感覺在「擠牙膏」？原因並不複雜。

主流語言模型生成文字時，基本採用 autoregressive（自回歸）方式。模型每生成一個新 token，都需要做一次以前文為條件的前向計算，因此輸出越長，解碼步驟越多，延遲也越容易累積。

對於即時聊天、多輪 Agent workflow（智能體工作流）、程式碼助手這類高互動場景，生成速度會直接影響使用者體驗，也會影響 GPU 利用率。

speculative decoding（推測解碼）就是為瞭解決這個問題。

為方便閱讀，圖片由 AI 生成，僅供參考

它的思路像是讓一個「小模型」先寫草稿，再讓「大模型」快速審稿。系統先用一個輕量級 draft model（草稿模型）生成一串候選 token，再由真正負責輸出質量的 target model（目標模型）一次性驗證這些候選 token。

通過驗證的 token 會被接受；一旦某個位置被拒絕，後面的候選 token 全部作廢，target model 再生成一個修正 token。由於 verification（驗證）階段可以平行完成，speculative decoding 可以在不改變 target model 輸出分佈的前提下提高生成速度。

更直觀地說，它想讓大模型一次前向計算確認更多 token，而不是每次只確認一個。

speculative decoding 已經是大模型推理加速的重要方向，但已有方案仍有明顯限制。

第一類方案是 autoregressive draft model（自回歸草稿模型）。

它像正常語言模型一樣，一個 token 接一個 token 地生成候選內容。優點是前後關係更自然，候選質量較高；缺點也明顯：draft model 自己寫草稿時也要一步一步來，候選 token 越多，draft 階段越慢。

第二類方案是 parallel draft model（平行草稿模型）。

它可以一次性生成多個候選 token，速度很快，也更適合生成較長的 candidate block（候選塊）。問題在於，candidate block 內部的 token 之間缺少足夠的依賴關係。

論文裡舉了一個很直觀的例子。模型面對某個上下文時，可能同時存在 「of course」 和 「no problem」 兩種合理續寫。parallel draft model 因為沒有真正按順序生成，很容易把兩條續寫路徑混在一起，生成 「of problem」 或 「no course」 這種前後不一致的組合。

結果就是，parallel draft model 開頭幾個 token 往往還不錯，但越往後，候選 token 被 target model 接受的機率下降越快。論文把這種現象稱為 suffix decay（後綴衰減）。

更現實的問題發生線上上服務裡。

parallel draft model 很容易一次生成一長串候選 token，但在真實高並行服務中，把這些 token 全部送給 target model 驗證，未必划算。

數學、程式碼這類結構化任務，答案路徑相對明確，候選 token 更容易被接受。開放式聊天不確定性更高，後面的 token 更容易被拒絕。

系統空閒時，多驗證幾個 token 影響不大；系統繁忙時，驗證那些大機率會被拒絕的 token，會佔用 batch capacity（批處理容量），影響其他使用者請求。

換句話說，推測解碼的問題已經不只在於能不能一次生成更多 token，還在於那些 token 值得交給 target model 驗證。

DSpark 的思路可以概括為兩件事：草稿要寫得更像樣，審稿要更會挑重點。

在生成側，DSpark 採用 semi-autoregressive architecture（半自回歸架構）。

它保留 parallel draft model 的主幹，讓大部分計算仍然一次完成；同時在輸出端加入一個輕量級順序模組，讓後面的 token 能參考前面已經採樣出來的 token。

可以把它理解成：前面用平行方式快速鋪開候選，後面再用一個很輕的順序模組檢查相鄰 token 的銜接關係。

論文默認使用 Markov head，也測試了 RNN head。Markov head 主要建模相鄰 token 之間的轉移關係，計算成本低，部署更方便；RNN head 能保留更長的塊內歷史，但收益有限，複雜度更高。

因此，論文把 Markov head 作為默認方案。

這種架構的目標很明確：保留 parallel draft model 的速度，同時補上部分 autoregressive draft model 的前後連貫性。

在驗證側，DSpark 引入 confidence-scheduled verification（基於置信度調度的驗證）。

系統會給每個候選位置預測一個 confidence score（置信度分數）。這個分數表示：在前面的 token 都已經被 target model 接受的情況下，當前位置繼續被接受的機率有多高。

隨後，hardware-aware prefix scheduler（硬體感知前綴調度器）會根據三個因素動態決定每個請求該驗證多少 token：當前系統負載、每個候選位置的置信度、引擎在不同 batch size（批大小）下的 throughput curve（吞吐曲線）。

因此，DSpark 不會機械地驗證固定長度的 candidate block。

系統資源寬鬆時，它可以驗證更長的 prefix（前綴），讓一次 target model 前向計算儘量產出更多有效 token。系統負載升高時，它會縮短低置信度請求的驗證長度，減少對 target model batch capacity 的佔用。

這也是 DSpark 相比傳統推測解碼更接近真實生產環境的地方：它不只追求單次生成更多候選 token，也會根據系統負載調整驗證預算。

大模型的盡頭，是複雜的系統工程問題

離線實驗部分，論文在 Qwen3-4B、Qwen3-8B、Qwen3-14B 和 Gemma4-12B 四個 target model 上測試 DSpark，並與兩類代表方案對比：autoregressive draft model Eagle3，以及 parallel draft model DFlash。

評測覆蓋數學推理、程式碼生成和日常聊天三個場景，包含 GSM8K、MATH500、AIME25、MBPP、HumanEval、Live-CodeBench、MT-Bench、Alpaca 和 Arena-Hard 等 benchmark（基準測試）。

結果顯示，在 Qwen3-4B、Qwen3-8B 和 Qwen3-14B 上，DSpark 相比 Eagle3 的 macro-average accepted length（宏平均接受長度）分別提升 30.9%、26.7% 和 30.0%；相比 DFlash 分別提升 16.3%、18.4% 和 18.3%。在 Gemma4-12B 上，DSpark 也保持領先。

accepted length 可以理解為每一輪 speculative decoding 中，平均有多少 token 能被 target model 接受。這個數字越高，說明 draft model 寫出的草稿越能被大模型認可，推理加速空間也越大。

論文還觀察到，不同任務之間差異很大。以 Qwen3-4B 為例，DSpark 在數學任務上的平均 accepted length 為 5.57，在程式碼任務上為 5.12，在聊天任務上為 3.49。

數學和程式碼更結構化，續寫路徑更穩定；聊天更開放，模型可能有很多種合理回答方式。因此，同樣長度的候選 token，在不同任務裡的價值並不一樣。固定 verification length（驗證長度）會浪費一部分計算資源。

更詳細的實驗解釋了 DSpark 為什麼行之有效。

DFlash 這類 parallel draft model 在第一個候選 token 上表現很強，因為它可以用更深的網路一次性生成候選。但從第二個 token 往後，它缺少塊內依賴，接受率下降更明顯。

Eagle3 這類 autoregressive draft model 在後段一致性上更好，因為它確實按順序生成。但為了控制 draft 階段延遲，它通常不能做得太深，因此第一個 token 的預測能力受限。

DSpark 介於兩者之間。第一個 token 繼承 parallel draft model 的強預測能力，後面的 token 通過 sequential module 減少 suffix decay。

結構實驗也支援這個判斷。論文顯示，2 層 DSpark 已經超過 5 層 DFlash，說明輕量級順序建模比單純增加平行層數更有效。

隨著 proposal length（候選長度）從 4 增加到 16，DSpark 相對 DFlash 的優勢繼續擴大。在最長設定下，DSpark 在數學、程式碼和聊天任務上分別領先 DFlash 30%、26% 和 22%。

延遲方面，sequential module 帶來的額外開銷很小。在 batch size 128 的測試中，相比 DFlash，DSpark 的單輪延遲只增加 0.2% 至 1.3%，但 accepted length 最多提升 30%。

置信度模組也經過了單獨驗證。論文在 Qwen3-4B 上做了 confidence threshold sweep（置信度閾值掃描），也就是不斷提高置信度門檻，觀察系統會保留那些 token。

結果不言而喻：門檻越高，系統過濾掉的低價值候選 token 越多，整體 acceptance rate（接受率）越高。聊天任務變化最明顯，acceptance rate 從 45.7% 提升到 95.7%；數學任務從 76.9% 提升到 92.5%；程式碼任務從 67.6% 提升到 92.0%。

DeepSeek 在 DeepSeek-V4-Flash preview 和 DeepSeek-V4-Pro preview 的 production engine（生產引擎）中部署 DSpark，最大 draft 長度設為 5，對比對像是此前的 MTP-1 生產基線。

MTP-1 隻做單 token 預測，加速空間有限，但在高並行下比較安全。原因在於，靜態 multi-token draft（多 token 草稿）雖然看起來一次生成更多 token，但如果很多 token 最後被拒絕，反而會浪費 target model 的驗證資源，拖累系統總吞吐。

DSpark 的意義在於，它讓 multi-token draft 在真實線上流量中變得可控。

面對中等並行時，DSpark 會把驗證預算從 MTP-1 的靜態 2 個 token 擴展到大約 4 到 6 個 token，讓每次前向計算產生更多有效輸出。

當並行繼續升高、target model 接近飽和時，DSpark 會自動縮短驗證長度，減少低置信度 token 對 batch capacity 的佔用。

線上上測試中，V4-Flash 在 80 token/s/user（每使用者每秒 token 數）的服務目標下，DSpark 相比 MTP-1 將系統總吞吐提升 51%。在更嚴格的 120 token/s/user 目標下，MTP-1 已經接近可承載邊界，DSpark 給出的名義吞吐優勢達到 661%。

這個 661% 不應理解成所有常規場景都能獲得 6 倍以上提升。更準確的理解是：在高互動、強 SLA 約束下，MTP-1 已經很難繼續維持服務能力，而 DSpark 把原本難以達到的性能區間打開了。

V4-Pro 的趨勢類似。在 35 token/s/user 的目標下，DSpark 總吞吐提升 52%；在 50 token/s/user 的嚴格目標下，名義吞吐優勢達到 406%。在相同系統容量下，DSpark 讓 V4-Pro 的單使用者生成速度提升 57% 至 78%。

故事的最後，自然是熟悉的配方、熟悉的味道。

DeepSeek 還宣佈開放 DSpark 的模型權重，包括 DeepSeek-V4-Flash preview 和 DeepSeek-V4-Pro preview 對應的 DSpark checkpoints（模型檢查點）。同時，DeepSeek 開源了 DeepSpec，一個面向 speculative decoding 訓練的程式碼庫，包含 Eagle3、DFlash 和 DSpark。

🔗 https://github.com/deepseek-ai/DeepSpec

簡言之，大模型推理加速已經不只是模型結構問題，也越來越是系統調度問題。

單純讓 draft model 一次生成更多 token，並不等於服務一定更快。候選 Token 的質量、通過率、驗證長度、系統負載、吞吐目標……每一個變數都在極其微妙地互相牽扯。

大模型競爭正在進入更精細的階段。訓練出更強的模型，仍然是牌桌上的硬實力；但能否把模型以更快、更便宜、更穩定的方式送到真實使用者面前，同樣會決定一款 AI 產品的上限。

DeepSeek 選擇把這套生產環境裡的加速經驗開源，相當於把一部分真正能提高推理效率、降低服務成本的核心方法，無私分享給全行業。

只能說，做人不要太 OpenAI，多學學 DeepSeek。 (APPSO)

6月27日，DeepSeek團隊聯合北京大學發佈名為《DSpark》的研究論文（基於speculative decoding方向），提出一種用於加速大模型推理的新方法。

該技術在保持生成文字分佈完全無損（Lossless）的前提下，成功突破了大語言模型（LLM）在高並行生產環境中的推理性能瓶頸，實測資料顯示，其單使用者生成速度較現有主流方案最高提升 85%。

目前，該框架已被部署在DeepSeek-V4-Flash 與 DeepSeek-V4-Pro的真實線上流量中，大幅加速了大語言模型（LLM）的推理速度。

值得注意的是，DeepSeek創始人梁文鋒也位列論文作者名單之中。

據瞭解，主流語言模型生成文字時，基本採用 autoregressive（自回歸）方式。每生成一個新token都需要一次完整的前向傳播，推理延遲隨輸出長度線性增長。這也造成了大模型回覆總感覺很慢的原因。

在即時對話、多輪智能體工作流等高互動場景中，生成速度直接影響使用者體驗，也會影響GPU利用率。

推測解碼技術提供了一條解決路徑：用一個輕量級草稿模型快速生成若干候選token，再由大模型批次驗證。

然而，現有方案各有缺陷。自回歸草稿模型逐token序列生成，質量雖高但生成延遲隨候選長度線性增長；平行草稿模型雖能一次產出全部候選，但token間缺少依賴關係，導致後續候選被大量拒絕，浪費計算資源。

圍繞上述兩大瓶頸，DSpark提出了兩項互補機制。

一個是“半自回歸生成”架構（Semi-Autoregressive Generation）。

DSpark在平行生成主幹的基礎上引入輕量級順序模組，逐token注入前綴依賴資訊。可以理解為：前面用平行方式快速鋪開候選，後面再用一個很輕的順序模組檢查相鄰 token 的銜接關係。

該模組提供兩種實現——僅依賴前一個token的馬爾可夫頭，以及通過循環狀態累積完整前綴資訊的RNN頭。實驗表明，兩層Transformer深度的DSpark即可在所有測試領域上超過五層DFlash的接受長度。

另一個是置信度調度驗證機制。

傳統方案對整段候選無差別校驗，在高負載時大量算力被浪費在極可能被拒絕的尾部token上。

置信度調度驗證機制，可根據不同請求的成功機率與系統負載，自適應調整驗證長度，從而減少無效計算開銷。

在離線測試中，該方法顯著提升了可接受生成長度；在DeepSeek-V4線上系統中，相比基線模型，推理速度提升約60%–85%，並有效降低高並行下的吞吐損耗。

DSpark在每個候選位置輸出置信度分數，預測該token的存活機率。硬體感知前綴調度器根據即時引擎吞吐量，為每個請求動態決定最優驗證長度，優先將算力分配給預期回報最高的token。

據瞭解，論文還同時開源了模型檢查點與訓練框架DeepSpec，以推動社區進一步研究。DeepSpec是一個面向speculative decoding訓練的程式碼庫，包含Eagle3、DFlash 和 DSpark。 (TechWeb)

DeepSeek開源了一種新的推理最佳化方法DSpark，附帶一篇極其詳細的論文、草稿模型以及訓練它們的框架DeepSpec。在 dsv4 生產環境中的結果顯示，吞吐量和延遲提高了 +50%（延遲甚至可以達到 ~80%，太瘋狂了）

DeepSpec是一個用於訓練和評估推測解碼草稿模型的完整程式碼庫，包含資料準備、草稿模型實現、訓練程式碼和評估指令碼，目前支援 DSpark、DFlash 和 Eagle3 三種演算法。

https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

LLM吐字慢的根本原因在於它的工作機制。每次只能根據前面的內容預測下一個詞。字數越多等待時間越長，GPU算力還吃不飽。

業內一直在用投機解碼技術來提速。簡單說就是找個小模型先草擬一堆詞，再讓大模型一次性判斷對錯。全對就一起輸出，錯了就從錯的地方重新算。

不過目前用來打草稿的小模型都有硬傷。

傳統的按順序寫草稿的小模型，自己生成就很慢，拖累了整體進度。

後來大家發明了一次性把所有草稿詞全寫出來的平行小模型。速度是快了，但詞與詞之間毫無關聯。這導致越往後的草稿瞎編的機率越大，被大模型瘋狂打回重做。

另外不管草稿好壞，全都交給大模型去檢查，在系統閒著的時候沒關係。一旦系統滿載，這些註定要被廢棄的草稿會白白搶佔寶貴的計算資源，導致整個系統的吞吐量暴跌。

為了拔掉這兩根毒刺，DSpark使出了兩招。

既然完全順序寫太慢，完全平行寫容易瞎編，那就把兩者結合起來。

DSpark的主體部分依然保持平行計算，這樣能保住極致的生成速度。它在最後面加了一個極其輕量的順序處理模組。有了這個小模組，草稿詞之間就有了上下文聯絡。比如前一個詞預測了理所，後一個詞就會順理成章地給出當然，徹底避免了那種前言不搭後語的跨頻道聊天。

這樣一來即使是長串的草稿，也能保持極高的採納率。

第二招叫硬體感知的置信度調度。

有了高品質的長草稿，下一步就是決定讓大模型檢查多少個詞。

DSpark給小模型裝了一個打分器，專門預測每個草稿詞存活下來的機率。

光有機率還不夠，系統還會即時監控當前的算力負載。如果當前訪問人數少算力富裕，調度器就會放行更多的草稿詞去驗證，充分榨乾閒置算力。如果當前並行請求極高算力緊張，調度器就會立刻變得冷酷無情，直接砍掉那些得分低的墊底詞。

這樣好鋼全用在刀刃上，確保大模型的計算資源只花在最有可能成功的詞上。

這套組合拳打下來效果非常明顯。

在純演算法測試中，無論是數學邏輯解答程式碼編寫還是日常聊天，DSpark在Qwen和Gemma等不同規模的模型上都碾壓了現有的各種草稿模型，草稿採納長度大幅提升。

更重要的是真實生產環境的實戰成績。

研發團隊將DSpark直接部署到了DeepSeek V4的線上服務系統中，迎接海量真實使用者的考驗。

資料表明，在和老一代生產基線保持相同整體吞吐能力的前提下，DSpark讓V4 Flash和V4 Pro的每個使用者生成速度大幅度加快，提升幅度最高達到了85%。

在系統面臨極限高並行挑戰時，老系統會因為資源爭搶而崩潰掉速，DSpark卻能遊刃有餘地動態縮減驗證長度，死死穩住系統的響應底線。

這等同於在不增加顯示卡的條件下，生生拉高了整個大模型服務系統的性能天花板。

目前研發團隊已經把DSpark的模型權重連同底層的演算法訓練庫DeepSpec一併開放，所有開發者都可以直接體驗這套前沿的推理加速方案。 (AI寒武紀)

彙整鉅亨號中所有使用「DSpark」關鍵字，所發布的內容 (依照時間排序，最新在前，舊的在後)`