DeepSeek DSpark：推論快51%到400%，數字是怎麼算出來的

2026-06-27，DeepSeek 開源了 DSpark，一個讓 V4 系列推論變快的新方法，官方數字寫著「throughput 提升 51% 到 400%」。同一天他們也把訓練這套東西用的框架 DeepSpec 整包放上 GitHub，MIT 授權。

400% 這種數字通常代表兩件事：真的很猛，或者基準線選得很划算。這篇不是要幫你複誦官方新聞稿，而是把「51%」跟「400%」拆開——它們其實在量完全不同的兩件事——然後查一下 DSpark 說能用在 Gemma、Qwen 上是不是真的，還是社群自己腦補的。

先搞懂 speculative decoding 是什麼

speculative decoding（推測解碼）說白了就是：模型平常一次只吐一個字，慢的原因不是算力不夠，是每吐一個字都要把整個模型的參數從顯卡記憶體重新搬一次，搬運比計算還花時間。

解法是找一個小又快的「草稿模型」，先連猜好幾個字，再讓大模型一次性檢查這一串猜對了幾個。猜對的直接收下，猜錯的地方打掉重猜。因為大模型還是照樣把每個字都驗過一遍，最後吐出來的內容跟它自己一個字一個字慢慢生成完全一樣，不會因為用了這招而變笨或變爛。

這件事已經是 2026 年推論優化的主流打法了，Google 稍早給 Gemma 4 出的 MTP Drafters 走的也是同一個邏輯，DSpark 是 DeepSeek 在同一個賽道上交出的新答案。

DSpark 做對了兩件事

DSpark 的草稿模型跟大部分同類方法一樣是平行產生一整串猜測、速度快，但這種做法有個老毛病叫「suffix decay」——猜的字越後面越不準，因為每個位置都獨立亂猜、互相不知道對方猜了什麼。

DSpark 在猜測 backbone 上多掛了一個很輕量的「Markov head」，讓每個被猜的字能看一眼前一個字猜了什麼，準度因此往後拉住，不會猜到後面整串垮掉。第二個改動是驗證這一步不再固定驗兩個字——系統會看當下 GPU 有多忙，忙的時候少驗幾個省資源，閒的時候多驗幾個多賺一點，原本 DeepSeek 舊系統（MTP-1）是不管忙不忙都只驗兩個字，浪費掉很多本來可以順手多驗的空間。

這套東西已經在 DeepSeek 自己的正式流量上跑著，不是實驗室數字。

51% 跟 400%，量的根本不是同一件事

這是整篇文章最容易被誤讀的地方，拆開來看：

「400%」那個數字，是門檻訂得非常硬的時候量出來的——這種時候舊系統 MTP-1 幾乎要撐不住，能同時服務的人數會先崩掉一大截，對比之下 DSpark 的相對倍數自然被放大。日常情境比較接近第一行：單人拿到回應的速度快 6 成到 8 成多。這不是灌水，是 DeepSeek 自己在公開的技術報告裡把三種算法都列出來，老實講清楚哪個數字對應哪種情境。

Gemma、Qwen 真的能用嗎——查過了，是真的

DSpark 不是只綁死在 DeepSeek 自家模型上。DeepSpec 的 GitHub repo 直接放出了 dspark_qwen3_4b_block7、dspark_qwen3_8b_block7、dspark_qwen3_14b_block7 和 dspark_gemma4_12b_block7 這幾組 checkpoint，NVIDIA NeMo Automodel 的官方訓練文件也把 Qwen3（dense 與 MoE 版本）跟 Gemma4 列為支援的 target 模型。

離線測試的結果是：在 Qwen3 三種尺寸（4B/8B/14B）上，DSpark 平均接受長度比 Qwen3.6-Max 系列常用的 Eagle3 方法多 26.7% 到 30.9%，比另一個開源方法 DFlash 多 16.3% 到 18.4%。這幾個數字是 DeepSeek 自己論文裡的比較，還沒看到外部團隊獨立重現，但檢查方式（不同模型家族、不同尺寸都測過）看起來比單一個案可信一些。

說白了，這代表 DSpark 想解決的不是「DeepSeek 模型太慢」，是「推測解碼這件事本身可以做得更好」——這種通用性，正是它值得被記錄下來的原因。

對本地端跑模型的人意味著什麼

如果你是在自己的顯卡上跑開源模型，推測解碼帶來的好處其實更明顯。單張卡通常沒有大型服務商那種批次流量去攤平記憶體頻寬成本，一個人跑推論時 GPU 大半時間都在「等資料搬完」而不是在算，這正是推測解碼設計來解決的場景。

像 麗臺 RTX PRO 4000 Blackwell 這張 24GB VRAM 的工作站卡，規格上剛好卡在能跑 Llama 3 70B Q4 量化版的門檻——這類單卡本地推論的場景，一旦上游框架（vLLM、SGLang）把 DSpark 支援做穩，末端使用者不用換硬體，光是換個啟動參數就能拿到明顯的速度提升。

DSpark 目前在 vLLM 走的是加一段 --speculative-config '{"method":"dspark",...}'，SGLang 那邊的支援也已經有人送出 PR。想自己訓練專屬 drafter 的人得先有心理準備：預設的 target cache 就要 38TB 儲存空間，外加一台 8 GPU 的機器，這不是筆電能碰的東西——但如果只是想用 DeepSeek 官方放出的現成 checkpoint，幾乎就是改一行指令的事。

利益揭露：本文部分連結為聯盟連結，點擊購買我會獲得回饋，不影響你的價格。我只推薦自己用過 3 個月以上的工具。

DSpark 證明了一件事：2026 年推論速度的戰場，已經不在「誰的模型更大」，而在「誰能把同一顆模型的每一分 GPU 頻寬榨得更乾淨」。DeepSeek 這次把訓練框架整套開源，等於把這場戰爭的入場券發給所有人——接下來要看的是，Qwen、Llama 這些陣營會不會端出自己的反擊。

常見問題

DSpark 只能用在 DeepSeek 自家模型嗎？ 不是。DeepSpec 的官方 GitHub repo 直接放出了 Qwen3（4B/8B/14B）和 Gemma4-12B 的 DSpark checkpoint，NVIDIA 官方的訓練文件也把 Qwen3、Gemma4 列為支援的 target 模型。DSpark 的 draft head 是一個可以掛在別的模型上的通用元件，不是寫死給 DeepSeek 自己用的。

這個加速是白吃的午餐嗎，有沒有代價？ 對一般使用者來說幾乎是免費的——輸出跟原本一模一樣，不用重訓 target 模型，vLLM 只要在啟動指令加一段 speculative-config 就能開。真正的代價在「自己訓練 drafter」這件事上：DeepSpec 預設一份 target cache 就要 38TB 儲存空間，還得有一台 8 GPU 的機器才跑得動訓練流程。

DSpark 跟 EAGLE、DFlash 這些既有方法比起來如何？ 照 DeepSeek 自己論文裡的數字，DSpark 在 Qwen3 系列（4B/8B/14B）上，平均接受長度比 EAGLE3 多 26.7% 到 30.9%，比 DFlash 多 16.3% 到 18.4%。這是 DeepSpec 官方揭露的比較，不是外部獨立重現的結果。三種算法現在都收進同一個 DeepSpec 框架，可以直接切換著測。

51% 到 400% 這麼大的區間，我實際會遇到哪一頭？ 看你把服務門檻訂多嚴。如果門檻寬鬆，你大概會落在接近 51% 這頭；如果門檻訂得很硬，舊系統會先撐不住、能同時服務的人數暴跌，這時候「相對舊系統」的倍數才會衝到 400% 那麼誇張。多數日常場景會落在 51% 到 85% 這個比較實際的區間。