DeepSeek再放大招，推理速度狂飆85%，怎么做到的？

出品 | 網易智能

作者 | 小爪

編輯 | 王鳳枝

6月27日，DeepSeek公開DSpark技術報告和DeepSpec代碼庫。DeepSeek-V4的底座模型沒有變，新增的是一個服務端推測解碼模塊：DSpark。

DeepSeek在Hugging Face模型頁里把話說得很直白：V4-Pro-DSpark和V4-Flash-DSpark"不是新模型"。這兩個頁面指向的是同一個模型檢查點，加上推測解碼模塊后的服務版本。

這意味著，DSpark沒有讓模型突然變聰明。它瞄準的是模型上線之后，怎樣更快、更便宜地把答案吐出來。

技術報告稱，DSpark已部署在DeepSeek-V4的線上服務系統中。在真實用戶流量下，相比此前的MTP-1生產基線，也就是DeepSeek上一代線上推測生成方案，V4-Flash的每用戶生成速度提升60%到85%，V4-Pro提升57%到78%，前提是匹配吞吐條件。

這里的"快"也要收住口徑。它主要指生成階段，也就是模型持續輸出token的那一段速度，不等于所有用戶請求的端到端響應時間都同步快了85%。長提示詞的預填充、檢索、工具調用、排隊和網絡延遲，仍然會影響用戶實際等多久。

模型上線后，

還有一筆推理賬

這件事沒有新模型發布熱鬧，但它更接近AI公司每天面對的現實：模型訓練完之后，成本沒有結束。

聊天機器人、代碼助手、智能體和搜索式產品，每一次調用都在繼續消耗GPU時間。模型慢一點，用戶等得久一點；推理貴一點，廠商就更難把高質量模型開放給更多場景。

AI行業過去兩年更習慣討論訓練成本：一家公司要買多少GPU、建多大的集群、花多少錢訓練下一代模型。但模型真正變成產品之后，另一類成本會不斷冒出來：推理。

訓練像一次大工程，推理更像水電費。只要用戶還在問問題、智能體還在跑任務、代碼助手還在生成補丁，模型就要繼續消耗算力。

大模型服務最后都會回到兩個指標：速度和單位token成本。API定價頁面通常按輸入token和輸出token收費，企業內部也會把不同模型、緩存、路由和上下文長度拆成成本項。

DSpark不能直接等同于降價，但如果同樣的GPU集群能在相近吞吐下讓用戶更快拿到答案，它意味著同樣的硬件可以服務更多用戶，或者同樣的用戶體驗可以用更少的卡來提供。

"先猜，再驗"

推測解碼的思路，可以粗略理解成"先猜，再驗"。

大模型生成文本時，通常是一個token接一個token往外吐。前一個token出來，后一個token才知道該接什么。這種方式穩，但慢。推測解碼會讓一個更輕的草稿模塊提前猜出一段候選token，目標大模型再批量驗證。猜對的部分直接接受，猜錯的位置再修正。

小模型不能替大模型做決定。最終接受哪些token，仍然由目標模型校驗；正確實現下，它改變的是生成方式，不改變目標模型的輸出分布。加速來自讓大模型批量驗證候選，而非逐步生成。

DSpark改的，

是草稿怎么生成

論文沒有只停在"先猜，再驗"這層解釋。它重點處理了草稿怎么生成。

現有的草稿策略大致分兩類。自回歸草稿器更穩，因為后一個token會看見前一個token，但草稿變長，延遲也就跟著上去。而并行草稿器更快，可以一次猜出一整段，但每個位置各猜各的，后面的token容易和前面脫節，接受率越往后越容易下滑。

DSpark選擇折中。論文題目里的關鍵詞是"半自回歸生成（Semi-Autoregressive Generation）"，它先用并行方式提出一段候選，再用一個輕量順序層修正后續token的條件關系。這樣既保留并行生成的速度，又讓后面的候選能看到前面已經猜了什么。

另一個關鍵點，是驗證多長一段。

候選token猜得越多，不一定越省。如果明知道后半段很可能被拒絕，還交給大模型驗證，就是把GPU時間花在低價值位置上。DSpark會看候選的置信度，也看當前系統負載，動態決定驗證長度。GPU空一些，可以多驗；負載高時，就把算力留給更可能被接受的部分。

論文標題里的"置信度調度（Confidence-Scheduled）"，說的就是這件事。

DSpark站在

已有技術路線之上

DSpark站在推測解碼已有路線之后，更像是DeepSeek把這條技術路線推到線上服務后的公開參照。

SpecInfer早在2023年就把小模型預測、token樹（token tree）和并行驗證放進大模型服務系統里；Medusa在2024年提出給模型加多個解碼頭，一次預測多個后續token；EAGLE系列則圍繞草稿模型和動態草稿樹（draft tree）繼續提高接受率。vLLM、SGLang、TensorRT-LLM這類推理框架，也早就把推測解碼當作降低延遲的重要工具。

DSpark的位置，在于它把幾個生產問題放到一起處理：草稿怎么生成，候選怎么保持連貫，驗證長度怎么隨負載變化，線上真實流量下速度到底能提高多少。

論文里反復出現的關鍵詞，也從"模型能力提升"轉向每用戶生成速度（per-user generation speed）、匹配吞吐（matched throughput）、服務等級協議（SLA）這些服務側詞匯。

這也解釋了為什么不能只挑最大的數字看。論文里確實還有661%、406%這樣的高倍吞吐數據，但它們來自更嚴苛的每用戶速度目標：在那種設定下，舊基線本身已經接近服務能力的邊界，DSpark的相對優勢會被放大。

真正能說明常態收益的，還是前面那組數字：匹配吞吐、真實流量分布、對比對象是MTP-1。

DeepSpec能復現什么

DeepSeek同時開源了DeepSpec。這是一套用于訓練和評估推測解碼草稿模型的代碼庫，包含數據準備、訓練和評估流程，也放出了Qwen3、Gemma等模型上的相關檢查點。

不過，開源不等于"下載即復現"。項目文檔里提示，默認Qwen3-4B配置下，目標模型緩存可能接近38TB；默認訓練腳本假設單節點8張GPU；如果要對齊論文結果，訓練設置必須嚴格一致，特定領域還需要對草稿模型做額外微調。

外界可以驗證方法的一部分，也可以把DeepSpec移植到其他開源模型上，但DeepSeek-V4線上服務里的那組速度提升數字，仍然來自DeepSeek自己的硬件規模、流量分布和生產系統調度。

開源的是方法，不是環境。

社區最關心的是復現邊界

X上的討論沒有停在叫好，更像一群工程師在追問：這套辦法到底怎么跑、能不能復現、邊界在哪里。

AI研究者Ravid Shwartz Ziv把DSpark概括為兩類草稿器的折中：并行草稿器快，但接受率沿候選塊衰減；自回歸草稿器穩，但延遲隨草稿長度上升。他特別提到DSpark加入的兩個組件：置信度判斷頭和負載感知調度器，并補了一句關鍵邊界："和所有推測解碼一樣，它是無損的。"

工程師更關心的是能不能跑起來。vLLM貢獻者Rafael Caricio稱自己在雙DGX Spark GB10上把DeepSeek-V4-Flash的DSpark模式跑通，單流解碼約60 tok/s，大約是MTP-1的1.5倍。

他同時提到，真實代碼會話暴露了合成基準測試看不到的問題：瓶頸不只是計算核心的速度，而是長上下文下草稿接受率會明顯下滑。

Tech2Wild也給出了相近方向的現場數據，顯示V4-Flash-DSpark已有人在特定vLLM環境里試跑。但這類結果高度依賴硬件型號、框架補丁版本、上下文長度和并發設置，換一套環境結果可能完全不同。

也有人專門提醒邊界。AcingAI在X上指出，DeepSeek報告里的高倍數仍然是"自家硬件、自家MTP-1基線、匹配吞吐條件下"的結果，外部尚未完整復現。

這提醒我們，DSpark的一部分優勢來自負載感知調度，而調度效果天然依賴生產環境的流量規模和硬件配置。

同樣的能力，

更少的算力

南華早報在6月28日的報道中，把DSpark放在推理瓶頸、芯片壓力和用戶等待時間里看。這個角度比"DeepSeek又發了什么模型"更接近產品現實。

AI公司還會繼續比模型能力，但當能力差距被壓縮，誰能把同樣的能力更快、更便宜地交付出去，也會成為競爭的一部分。

DeepSeek這類公司尤其需要把這件事講清楚。DeepSeek一直把低成本、高效率作為外界理解它的重要入口，從模型訓練敘事到API價格，最被關注的不是它有沒有再堆一個更大的參數規模，而是它能不能把同等能力做得更便宜。

DSpark延續的正是這條線：它不證明V4突然更聰明，它證明V4在服務用戶時可以少浪費一部分推理算力。

如果把視角再放寬一點，推理優化也會影響開源模型生態。開源模型過去常被認為"便宜"，但真正部署時，顯存、吞吐、并發、延遲和運維復雜度都會變成成本。

一個模型能開源，只說明大家能拿到它；能不能便宜地服務大量用戶，還要看推理棧能不能跟上。

DeepSpec放出Qwen3、Gemma等檢查點，說明這件事已經不只停在DeepSeek-V4自己身上。遷移到什么程度，還要看社區適配、框架支持和硬件兼容的實際進展；但從目前公開信息看，DeepSeek已經讓這條路線走出了自家模型。

DSpark的價值就在這里。它給V4增加了一層更接近生產系統的推理服務工具，而不只是一個新能力標簽。

接下來值得看的，已經不止是DeepSeek自己能跑多快，還包括這條路線能被多少人走通。DeepSpec已經放出檢查點和訓練流程，推測解碼正在從一家公司的工程選擇，變成開源推理降低成本的通用手段，前提是其他框架和硬件能跟上。