最近忙著大規模招兵買馬的 DeepSeek
，也始終沒有忘記開源這條主線。
今天，DeepSeek 與北京大學團隊聯合發布論文《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》，提出了一套新的大模型推理加速框架 DSpark。
▲ 技術報告 
論文披露，DSpark 已經進入 DeepSeek-V4-Flash preview 和 DeepSeek-V4-Pro preview 的生產服務系統，並替代此前的 MTP-1 方案。
在線上真實用戶流量中，在系統總吞吐水平相同的情況下，DSpark 將 DeepSeek-V4-Flash 的單用戶生成速度提升了 60% 至 85%，將 DeepSeek-V4-Pro 的單用戶生成速度提升了 57% 至 78%。
速度飆成這樣，DeepSeek 究竟給自家的推理引擎餵了什麼靈丹妙藥？當然，本文難免有些枯燥，感興趣的朋友不妨耐心閱讀。
天下苦 AI 「蹦字」久矣
為什麼每次等到大模型的回覆總感覺在「擠牙膏」？原因並不複雜。
主流語言模型生成文本時，基本採用 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 之間缺少足夠的依賴關係。
▲ 為方便閱讀，圖片由 AI 生成，僅供參考
論文裡舉了一個很直觀的例子。模型面對某個上下文時，可能同時存在 「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 的思路可以概括為兩件事：草稿要寫得更像樣，審稿要更會挑重點。
在生成側，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。
▲
簡言之，大模型推理加速已經不只是模型結構問題，也越來越是系統調度問題。
單純讓 draft model 一次生成更多 token，並不等於服務一定更快。候選 Token 的質量、通過率、驗證長度、系統負載、吞吐目標……每一個變量都在極其微妙地互相牽扯。
大模型競爭正在進入更精細的階段。訓練出更強的模型，仍然是牌桌上的硬實力；但能否把模型以更快、更便宜、更穩定的方式送到真實用戶面前，同樣會決定一款 AI 產品的上限。
DeepSeek 選擇把這套生產環境裡的加速經驗開源，相當於把一部分真正能提高推理效率、降低服務成本的核心方法，無私分享給全行業。
只能說，做人不要太 OpenAI，多學學 DeepSeek。
作者；莫崇宇
