單用戶提速 60-85% ！DeepSeek 聯手北大開源 DSpark ，突破推理加速工程問題

本文作者：樊天驕鄭佳美

2026-06-29 15:12

導語：把算力花在刀刃上，梁文鋒再次大幅降低推理優化門檻。

單用戶提速 60-85% ！DeepSeek 聯手北大開源 DSpark ，突破推理加速工程問題

把算力花在刀刃上，梁文鋒再次大幅降低推理優化門檻。

作者丨樊天驕

編輯丨馬曉寧

2026年6月27日，AI圈迎來了一則重磅消息，DeepSeek聯合北京大學正式發布了DSpark推理加速框架，并同步開源了支撐該版本的全棧推測性解碼框架DeepSpec。

這是DeepSeek在完成500億元融資后首次放出的開源新成果。在DeepSeek-V4-Pro-DSpark和DeepSeek-V4-Flash-DSpark兩款模型上，DSpark將單用戶生成速度提升了60%至85%。

梁文鋒本人署名、聯合北京大學完成的論文《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》同步上傳。雷峰網(公眾號：雷峰網)

論文、代碼庫、模型已經全部開源：

論文：

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

開源代碼庫：

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

模型下載：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

DSpark 如何讓草稿模型又快又準

先澄清一個容易誤解的點：DeepSeek-V4-Pro-DSpark 不是全新架構的模型，而是在 DeepSeek-V4-Pro 基礎上引入了推測性解碼模塊。這次更新的重點在于工程落地，不是模型能力本身的迭代。

說人話就是：模型還是那個模型，但讓它跑起來的方法變聰明了，所以你用起來會感覺明顯變快。

要理解 DSpark 的價值，得先搞清楚它在解決什么問題。

▎推測解碼是什么？

大語言模型生成文本時采用自回歸方式：每生成一個新 token 都需要一次完整的前向傳播，推理延遲隨輸出長度線性增長。這是目前 AI 對話系統響應偏慢的核心原因之一。

推測解碼（Speculative Decoding）提供了一條解決路徑：

第一步，先用一個輕量級的小模型，快速生成若干候選token（草稿模型）

第二步，再由完整規模的大模型，通過單次并行前向傳播進行批量驗證這些token

第三步，接受其中符合目標分布的連續前綴

由于驗證階段可并行計算，且拒絕采樣機制嚴格保證了輸出分布與原始模型一致，推測解碼能夠在無損生成質量的前提下提升速度。

這個思路不是 DSpark 發明的，這兩年一直有人在做。但是這次，Deepseek 精準解決了這個技術路線在實際落地中遇到的兩個關鍵瓶頸。雷峰網

▎DSpark 的破局思路

早期的草稿模型是自回歸的，也就是跟大模型一樣一個字一個字猜。這樣猜出來的質量確實高，但小模型自己猜也要時間，猜得多了草稿本身就變慢了，得不償失。

舉個例子：你讓 AI 寫一段 500 字的回復，它需要連續做 500 次完整計算，每次只能輸出一個字。就算每次計算只要 10 毫秒，總共也要 5 秒。用戶感知到的就是"轉圈等待"。

后來有人想到了并行草稿，一次前向傳播直接猜好幾個字，草稿速度一下就上來了。但新的問題來了：因為每個位置是獨立猜的，沒有考慮字跟字之間的依賴關系。

"of course" 和 "no problem" 都是合理的回復開頭，但并行草稿可能會猜出 "of problem" 這種四不像組合。越往后猜，這種錯誤累積越嚴重，接受率斷崖式下跌。大家把這個現象叫"后綴衰減"。

過去通行做法是：草稿模型生成多少個 token，就原封不動地提交多少個 token 給大模型驗證，這是一種“全量驗證”模式。但因為越往后的字越不靠譜，驗證這些低置信度的字是要占用算力的。

把低置信度的 token 送去驗證，看似只是“浪費了一點算力”，但在真實的、高并發的生產系統中，這種浪費是災難性的系統性損耗。

為了解決這兩大問題，DSpark 作了兩套核心設計：半自回歸生成架構和置信度調度驗證。

半自回歸生成架構非常具有創新性，其主要針對的是并行草稿的后綴衰減問題。這種并行主干 + 輕量串行頭的兩階段設計，可以在在幾乎不犧牲生成速度的前提下補齊塊內的 Token 依賴，直接拉高每輪驗證的有效接受長度。

并行主干可單次前向輸出全塊基礎 Logits 與隱藏態，草稿生成的核心延遲與純并行方案持平，完整保留了并行架構塊長大、生成快的速度優勢。

輕量串行模塊則是補齊短板的關鍵。DSpark 在并行輸出的基礎上，疊加了一個極簡的串行單元（默認采用 Markov head），為每個位置的 Token 補充前綴依賴的轉移偏置，修正并行獨立生成導致的多模態語義沖突，大幅緩解了尾部 Token 接受率下滑的問題。

從速率角度看，這套設計收益極高：串行模塊開銷極小，卻讓 Qwen3 系列模型的平均接受長度相對 DFlash 提升 16.3 % - 18.4 %，相對自回歸的 Eagle3 提升 26.7 % - 30.9%。

2 層深度的 DSpark，有效接受長度甚至超過 5 層深度的純并行 DFlash。這說明局部自回歸的速度 - 參數效率，遠高于單純堆疊并行層。

這種優勢還會隨著塊長放大：當草稿塊長從 7 增加到 15 時，DSpark 相對 DFlash 的接受長度優勢從 15% - 18% 擴大至 22% - 30%。換言之，并行架構的長塊速度潛力，此前一直被后綴衰減封印，而半自回歸設計將其徹底釋放了出來。

如果說半自回歸解決了 “生成得更有效”，那么置信度調度解決的就是 “驗證得更聰明”。從源頭杜絕無效 Token 占用寶貴的驗證算力，讓大模型的每一次前向計算都產出最大價值，尤其能穩住高并發場景下的生成速度。

▎這套機制分為兩層設計：

第一層是置信度預判。 DSpark 在草稿模型上加了一個輕便的打分模塊（置信度頭 Confidence Head ），草稿每生成一個候選 Token，它就實時預測該 Token 的條件接受概率（Conditional Acceptance Probability）。

不過 AI 打分天生容易 “自我感覺良好”，估出來的通過率往往偏樂觀。所以 DSpark 還搭配了 “順序溫度縮放（STS）” 校準方法，把對草稿的打分的誤差從原來的 3%-8% 下降到約 1% ，讓概率預估變得足夠精準，給后續的調度調整提供了可靠的判斷依據。

第二層，是硬件感知動態調度。基于預測試的引擎吞吐曲線，將驗證長度選擇轉化為全局吞吐量最大化問題，用貪心算法為每個請求動態分配驗證預算：低負載時自動拉長驗證塊，把空閑算力用滿，拉滿單用戶生成速度；高負載時主動裁剪低價值 Token，避免資源爭搶，穩住系統整體吞吐量與用戶體感速度。

驗證！推理速度全場景飆升

加速技術的真實分量要靠實測來印證。

首先是離線基準評測。團隊選取數學推理、代碼生成、日常對話三大領域共 9 個通用數據集，在 Qwen3-4B/8B/14B、Gemma4-12B 四款目標模型上進行橫向對比。結果顯示，DSpark 的平均接受長度全面超越當前業界 SOTA 方案，對應的單 Token 理論延遲顯著低于 Eagle3 與 DFlash。

測試數據同時呈現出清晰的領域差異：數學、代碼這類結構化較強的任務，接受長度明顯更高，開放對話場景的接受長度則相對更低。這一差異印證了固定驗證長度的先天局限 —— 不同類型的請求，最優驗證塊長本就不同，而動態調度的策略能讓每一類請求都拿到最優的加速收益。

線上真實流量的表現最能體現用戶的實際體感。目前 DSpark 已全量部署于 DeepSeek-V4 線上服務，對比前代 MTP-1 單 Token 生產基線，在速度、服務容量和穩定性上都有實質提升：

同吞吐下絕對提速：在系統總吞吐量持平的配置下，V4-Flash 單用戶生成速度提升 60% - 85%，V4-Pro 提升 57% - 78%，用戶可直接感知到輸出跟手度提升、長文本生成等待時間大幅縮短。

高 SLA 下容量擴容：在嚴格的交互性要求下（如 Flash 要求 120 token/s、Pro 要求 50 token/s），傳統單 Token 基線已接近性能極限，僅能支撐極低并發；而 DSpark 仍能維持可觀的服務容量，解鎖了此前無法實現的高速響應檔位，向外推移了推理服務的性能帕累托邊界。

全負載下速度穩定：動態調度器會隨并發壓力自動調整驗證預算：低并發時用滿算力、拉滿速度；高并發時平滑收縮、避免跳水。全程不會出現傳統靜態方案的速度驟降，用戶體驗一致性顯著提升。