DeepSeek 在開源路線上再落一子。這家正大規模擴張團隊的 AI 公司，今日與北京大學團隊聯合發佈論文，推出新的大模型推理加速框架 DSpark，並已將其部署到 DeepSeek-V4-Flash preview 和 DeepSeek-V4-Pro preview 的生產服務中，替代此前的 MTP-1 方案。
線上真實用戶流量的測試數據顯示，在系統總吞吐水平相同的情況下，DSpark 將 V4-Flash 的單用戶生成速度提升了 60% 至 85%，將 V4-Pro 的單用戶生成速度提升了 57% 至 78%。這意味著用戶在對話、代碼生成等高交互場景下，等待模型回覆的時間將顯著縮短。
大模型生成文本的“擠牙膏”感，根源在於主流的自迴歸解碼方式——模型每生成一個新 token，都需以前文為條件做一次前向計算，輸出越長延遲越高。業界為此引入推測解碼，思路是讓一個輕量級草稿模型先生成候選 token，再由目標模型並行驗證，從而在不改變輸出分佈的前提下提高生成速度。
但現有方案各有短板。自迴歸草稿模型雖候選質量高，但自身生成速度慢；並行草稿模型雖快，卻因候選 token 間缺乏依賴關係，越往後被目標模型接受的概率越低，論文將這種現象稱為後綴衰減。更關鍵的是，在高併發線上服務中，機械地驗證固定長度的候選塊會浪費目標模型的批處理容量，擠壓其他用戶請求。
DSpark 的解法可概括為“草稿寫得更像樣，審稿更會挑重點”。在生成側，它採用半自迴歸架構，保留並行草稿模型的主幹速度，同時在輸出端加入輕量級順序模塊，讓後續 token 能參考已採樣 token 的銜接關係，減少後綴衰減。論文默認使用計算成本低的 Markov head 來建模相鄰 token 轉移關係。
在驗證側，DSpark 引入基於置信度調度的驗證。系統為每個候選位置預測置信度分數，再由硬件感知前綴調度器根據當前系統負載、各位置置信度及引擎在不同批大小下的吞吐曲線，動態決定每個請求該驗證多少 token。系統空閒時驗證更長前綴以產出更多有效 token，負載升高時則縮短低置信度請求的驗證長度，減少資源佔用。
離線實驗覆蓋 Qwen3-4B、Qwen3-8B、Qwen3-14B 和 Gemma4-12B 四個目標模型，以及數學推理、代碼生成和日常聊天三類場景。結果顯示，DSpark 的宏平均接受長度相比自迴歸草稿模型 Eagle3 提升 26.7% 至 30.9%，相比並行草稿模型 DFlash 提升 16.3% 至 18.4%。接受長度越高，意味著草稿被大模型認可的比例越大，推理加速空間也越大。
不同任務間差異明顯。以 Qwen3-4B 為例，DSpark 在數學任務上的平均接受長度為 5.57，代碼任務為 5.12，聊天任務僅為 3.49。數學和代碼更結構化，續寫路徑穩定；開放式聊天不確定性更高，候選 token 更易被拒絕。這印證了固定驗證長度會浪費計算資源，動態調度確有必要。
線上部署數據更凸顯 DSpark 的工程價值。在 V4-Flash 每用戶每秒 80 token 的服務目標下，DSpark 較 MTP-1 將系統總吞吐提升 51%；在更嚴格的 120 token/s/user 目標下，MTP-1 已接近承載邊界，DSpark 的名義吞吐優勢達到 661%。V4-Pro 在 35 token/s/user 目標下吞吐提升 52%，在 50 token/s/user 嚴格目標下名義優勢達 406%。
DeepSeek 同步宣佈開放 DSpark 模型權重，包括 V4-Flash 和 V4-Pro 預覽版對應的模型檢查點，並開源了面向推測解碼訓練的代碼庫 DeepSpec，內含 Eagle3、DFlash 和 DSpark 實現。
從產業視角看，DSpark 的發佈揭示了大模型推理優化的一個關鍵轉向：單純讓草稿模型一次生成更多 token 已非最優解，如何根據任務特性與系統負載動態分配驗證資源，才是提升真實服務效率的核心。這對依賴大模型 API 的應用開發者而言，意味著更低的延遲與更高的吞吐上限；對基礎設施層，則指向更精細的 GPU 利用率管理。在 AI 應用加速落地的當下，推理引擎的系統工程能力正成為模型競爭力的重要一極。