北大與 DeepSeek 聯合開源 DSpark

6 月 27 日消息，今日，DeepSeek 聯合北京大學正式發佈 DSpark 推理加速框架，旨在解決大語言模型在高併發生產環境中的推理效率瓶頸。

該框架已部署於 DeepSeek-V4-Flash 與 DeepSeek-V4-Pro 的預覽版服務引擎中，相比此前生產環境採用的單 token 推測解碼基線 MTP-1，在同等吞吐量水平下可將單用戶生成速度提升 60% 至 85%。相關論文、訓練代碼等已在 GitHub 上開源。

大語言模型生成文本時採用自迴歸方式，每生成一個新 token 都需要一次完整的前向傳播，推理延遲隨輸出長度線性增長，這是目前 AI 對話系統響應偏慢的核心原因之一。推測解碼技術提供了一條解決路徑：用一個輕量級的小模型快速生成若干候選 token，再由完整規模的大模型通過單次並行前向傳播進行批量驗證，接受其中符合目標分佈的連續前綴。由於驗證階段可並行計算，且拒絕採樣機制嚴格保證了輸出分佈與原始模型一致，推測解碼能夠在無損生成質量的前提下提升速度。

但推測解碼的實際加速效果受制於兩個因素：一是候選生成的質量，二是驗證階段對目標模型計算資源的佔用。當前主流方案分爲兩派。自迴歸式草稿模型（如 Eagle3）逐 token 串行生成候選序列，依賴關係建模能力強、接受率高，但生成延遲隨候選長度線性增長，迫使實際部署中只能使用短候選塊和淺層網絡。並行式草稿模型（如 DFlash）則在一個前向傳播內一次性產出全部候選 token，生成延遲幾乎與候選長度無關，理論上支持更長的候選塊。

然而並行生成每個位置時無法依賴塊內先前已採樣的 token，導致隨着候選位置後移，不同語義路徑相互衝突、接受率迅速衰減，長候選塊的後綴 token 往往在驗證階段被大量拒絕，造成目標模型計算資源的浪費。此外，在併發請求較多的生產環境中，固定長度的驗證策略會迫使目標模型將寶貴的批量處理能力消耗在高拒絕風險的尾部 token 上，導致整體吞吐量下降。

DSpark 的設計圍繞上述兩個瓶頸展開，提出了兩項互補機制。在候選生成階段，DSpark 採用半自迴歸架構：計算量較大的並行主幹網絡（基於 DFlash 改進）一次性產出全部候選位置的隱藏狀態和基礎 logits，隨後由一個輕量級順序模塊逐 token 注入前綴依賴信息。該順序模塊提供兩種實現 —— 僅依賴前一個 token 的馬爾可夫頭，以及通過循環狀態累積完整前綴信息的 RNN 頭。

實驗表明，兩層 Transformer 深度的 DSpark 即可在所有測試領域上超過五層 DFlash 的接受長度，表明少量自迴歸依賴的引入在參數效率上優於單純堆疊並行層。

在驗證調度階段，DSpark 引入置信度調度驗證機制。模型在每個候選位置輸出一個置信度分數，預測該 token 在給定此前所有 token 均被接受的條件下的存活概率。受訓階段完成後，團隊在驗證集上通過逐位置溫度縮放對置信度進行校準，使其與經驗接受率對齊。

在此基礎上，硬件感知前綴調度器將驗證長度選擇建模爲全局吞吐量最大化問題：給定一批併發請求及其各位置置信度，結合預先實測的引擎吞吐量曲線，調度器爲每個請求動態決定驗證多長的候選前綴，優先將目標模型的計算資源分配給全局存活概率最高的 token。

在離線基準測試中，研究團隊選取了 Qwen3 系列（4B/8B/14B）和 Gemma4-12B 作爲目標模型，對比自迴歸草稿模型 Eagle3 與並行草稿模型 DFlash。

在數學推理（GSM8K、MATH500、AIME25）、代碼生成（MBPP、HumanEval、LiveCodeBench）和日常對話（MT-Bench、Alpaca、Arena-Hard）三類任務上，DSpark 的平均每輪接受長度均優於兩類基線。

以 Qwen3-4B 爲例，DSpark 相比 Eagle3 提升約 30.9%，相比 DFlash 提升約 16.3%。進一步的位置級條件接受率分析顯示，DFlash 在首位的較高接受率源於並行架構可支撐更深網絡帶來的容量優勢，但從第 2 位開始接受率迅速下降；Eagle3 雖然後續位置保持穩定甚至上升，但首位接受率受限於淺層網絡。DSpark 繼承了並行架構的首位容量優勢，同時通過順序依賴緩解了後續位置的衰減。

生產部署方面，DSpark 草稿模型與 DeepSeek-V4-Flash 及 DeepSeek-V4-Pro 預覽版共同部署，並行主幹包含三個 MoE 層與滑動窗口注意力，最大候選塊長度設爲 5，並採用馬爾可夫頭作爲順序模塊。

訓練階段，研究團隊在內部框架中實現了兩項系統優化：其一，並行訓練時僅傳遞目標模型的隱藏狀態而非完整詞表 logits，將通信複雜度從 O (V) 降至 O (d)；其二，採用錨點定長序列打包策略，將訓練序列中隨機採樣的多個預測塊壓縮爲密集批次，避免傳統填充帶來的計算和內存開銷。

在實際系統集成中，DSpark 的調度器面臨兩個工程約束：

其一是 CUDA 圖重放和零開銷調度要求下一輪批處理大小在當前輪完成前即已確定，同步調度會導致 GPU 流水線停滯。團隊將調度器改造爲異步模式：以當前輪置信度排序候選 token，但截斷長度（即批次容量上限）依據兩輪前的歷史置信度預測來確定，從而隱藏調度延遲併兼容現有系統框架。

其二是動態變長驗證前綴會導致標準解碼內核因填充和負載不均而利用率下降。團隊將物理執行與邏輯序列跟蹤解耦，將所有 token 展平爲獨立元素處理，通過稀疏注意力中的標記張量傳遞序列內依賴關係，僅需修改索引注意力與壓縮內核即可支持動態調度。

在線生產環境實測中，DSpark-5 與原有的單 token 基線 MTP-1 在真實用戶流量下進行了對比。IT之家注意到，在 V4-Flash 引擎上，當系統保證單用戶生成速度不低於 80 token/s 時，DSpark 的聚合吞吐量相比基線提升 51%；當 SLA 收緊至 120 token/s 時，單 token 基線已接近運行邊界，DSpark 在維持可用併發批處理的前提下實現了標稱 661% 的吞吐量優勢。

在 V4-Pro 引擎上，35 token/s 的 SLA 下 DSpark 吞吐量提升 52%，50 token/s 的 SLA 下提升 406%。在匹配的實際吞吐量水平下，DSpark 將單用戶生成速度提升了 57% 至 85%。

同時，調度器在系統併發數較低時會分配 4 至 6 個 token 的驗證長度以充分利用空閒計算資源，隨着併發數上升則平滑縮減驗證長度以避免資源爭用，表現出負載自適應的驗證預算分配能力。

DSpark 的侷限在於，即使後綴 token 最終被調度器截斷，並行主幹仍需爲所有請求生成完整的初始候選塊。對於接受率本身較低的複雜查詢，這部分草稿計算開銷無法回收。

目前 DeepSeek 已在 GitHub 的 DeepSpec 項目中開源了 DSpark、DFlash 和 Eagle3 三種草稿模型的訓練代碼、評估腳本及模型檢查點。

參考資料：

GitHub：https://github.com/deepseek-ai/DeepSpec

Hugging Face：huggingface。co/deepseek-ai/DeepSeek-V4-Pro-DSpark