單用戶提速 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-DSpark01DSpark 如何讓草稿模型又快又準先澄清一個容易誤解的點：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，避免資源爭搶，穩住系統整體吞吐量與用戶體感速度。02驗證！推理速度全場景飆升加速技術的真實分量要靠實測來印證。首先是離線基準評測。團隊選取數學推理、代碼生成、日常對話三大領域共 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 仍能維持可觀的服務容量，解鎖了此前無法實現的高速響應檔位，向外推移了推理服務的性能帕累託邊界。全負載下速度穩定：動態調度器會隨併發壓力自動調整驗證預算：低併發時用滿算力、拉滿速度；高併發時平滑收縮、避免跳水。全程不會出現傳統靜態方案的速度驟降，用戶體驗一致性顯著提升。總而言之，DSpark 跳出了過往推測解碼非此即彼的技術侷限，依靠半自迴歸架構補齊並行草稿尾部準確率短板，再通過置信度動態調度解決傳統全量驗證的算力浪費問題，完成了草稿生成與在線驗證的全鏈同優化。雷峰網值得一提的是，團隊還配套開源的 DeepSpec 全棧訓練工具鏈，將這套無損推理加速方案對外開放。過去，中小開發者和輕量化應用很難低成本實現高速大模型推理，而DSpark以高性價比大幅降低了推理優化的門檻，讓“每個小app都能用上大模型”不再是一句口號，而是正在落地的行業現實。上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。