梁文鋒署名的DSpark，看懂這10個點就夠了！

📌 【DeepSeek 研究】DSpark 如何讓 LLM 推理速度提升 85%？系統工程的極致協同

TL;DR：DSpark 透過最佳化推測解碼的「猜」與「驗」，在單使用者速度提升 85% 並將高併發吞吐量翻 4 倍。

大模型推理的瓶頸不在於運算力，而是在於視訊記憶體頻寬。當 GPU 大部分時間都在搬運模型權重時，如何讓每一次搬運都能處理更多 token，成了效能最佳化的核心。

🤔 推理瓶頸：搬運權重的成本遠高於運算

GPU 具有一個特殊特性：同時解碼 10 個 token 的速度，其實只比解碼 1 個 token 慢一點點。這是因為瓶頸在於視訊記憶體頻寬，將權重從記憶體搬到計算核心的開銷極大。既然權重已經載入快取，一次搬運並處理多個 token 才是最高效的利用方式。這也是「連續批處理（Continuous Batching）」與「推測解碼（Speculative Decoding）」能奏效的底層邏輯。

🧩 推測解碼：用「猜 + 驗」取代逐字生成

由於 LLM 生成是自迴歸的（第 N+1 個 token 依賴第 N 個），無法直接並行。DSpark 採用的推測解碼採取繞道策略：

1. 猜測：由速度較快的「草稿模型」預先生成數個候選 token 序列。
2. 驗證：將候選序列打包成一個 batch 餵給目標模型進行一次性驗證。
3. 取樣：透過拒絕取樣，接受最長的正確字首，在第一個分歧點重新取樣。

這套機制在數學上保證了輸出分佈與原模型完全一致，且驗證 batch 的成本遠低於逐個生成，從而實現加速。

🧩 草稿模型（Draft Model）的設計取捨

為了讓「猜」更高效，DSpark 探討了草稿模型的構造。最直接的方式是使用小模型（如 Qwen 0.8B）為大模型（如 Qwen 397B）探路，但這種方式存在權衡：若草稿器太慢，或猜測準確率（接受率 $\tau$）太低，額外的開銷反而會增加延遲。

論文定義的實際延遲公式為： 每個 token 的耗時 = (草稿耗時 + 驗證耗時) / 被接受的 token 數 $\tau$

因此，加速的關鍵在於三個槓桿：降低草稿耗時、提高 $\tau$（猜得更準）、減少驗證浪費。

💡 Eagle 與 MTP：站在巨人的肩膀上猜測

為了同時拉動上述槓桿，DSpark 參考了 Eagle 與 MTP (Multi-Token Prediction) 的思路，不再從零訓練獨立小模型，而是：

• 直接複用目標模型最後一層的隱藏狀態 (Hidden State)。
• 在其上方僅增加 1-2 層 Transformer 頭作為草稿器。

這種設計帶來兩個核心優勢：

• 速度快：草稿器層數極少，計算量極低。
• 準確率高：直接利用目標模型的內部理解（啟用值）來預測，比獨立小模型更可靠。

🎯 實務啟示：系統工程與模型協同的重要性

DSpark 的成功並非單靠某個新演算法，而是在於「系統工程」與「模型協同設計」。對於 AI 工程師而言，這提醒我們在最佳化推理效能時，不能只關注模型結構，而應從 GPU 訪存特性出發，將模型設計（如 MTP）與系統排程（如批處理）端到端地整合，才能實現顯著的效能突破。

🔗 來源

• 標題：梁文鋒署名的DSpark，看懂這10個點就夠了！
• 作者／機構：聞樂 / 量子位
• 連結：https://www.qbitai.com/2026/06/439548.html

#DeepSeek #DSpark #LLM #Inference #SpeculativeDecoding #GPU #SystemEngineering #MTP #PerformanceOptimization #Batching