把算力花在刀刃上,梁文鋒再次大幅降低推理優化門檻。
作者丨樊天驕
編輯丨馬曉寧
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
01
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,避免資源爭搶,穩住系統整體吞吐量與用戶體感速度。
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
大會報告全文
熱門論文解讀
學術新星訪談
未經「AI科技評論」授權,嚴禁以任何方式在網頁、論壇、社區進行轉載!
公眾號轉載請先在「AI科技評論」后臺留言取得授權,轉載時需標注來源并插入本公眾號名片。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.