2026年6月27日，一篇名為《DSpark：基於半自迴歸生成的置信度排程推測解碼》的論文引發行業關注。該論文由DeepSeek創始人梁文鋒署名，並與北京大學聯合完成。論文披露了一組令人矚目的數據：將DSpark部署在DeepSeek-V4線上服務系統、承接真實用戶流量時，單用戶生成速度出現了60%到85%（Flash版本）以及57%到78%（Pro版本）的大幅提升；在離線或高併發場景下，聚合吞吐量更是提升了51%至400%。
這組數據並非簡單的硬體堆砌帶來的線性增長，而是一次底層推理架構的質變。要理解這個數字的含金量，必須先看清大模型推理過程中的算力黑洞。
85%提速的真相：被“無效校驗”吃掉的算力
當前主流的大模型大多採用自迴歸生成機制。簡單來說，模型在生成文本時，是一個字一個字往外蹦的。每生成一個字，模型都需要把之前所有的上下文重新過一遍，計算出下一個字的機率分佈。這種序列生成方式導致GPU的並行計算能力被嚴重閒置。更關鍵的是，大模型推理通常是「訪存受限」的。
在硬體層面，這種訪存瓶頸主要體現在KV Cache（鍵值緩存）的讀寫上。為了不重複計算歷史上下文，模型會將之前每一步生成的隱藏狀態以Key和Value的形式保存在顯存中。隨著序列長度的增加，KV Cache的體積呈線性增長。在生成每一個新詞時，GPU的計算單元必須等待龐大的KV Cache從顯存搬運到計算核心。這意味著，GPU絕大部分時間並沒有在做矩陣乘法，而是在等數據。計算單元的空轉，加上反覆讀寫顯存帶來的頻寬壓力，構成了大模型推理最底层的成本黑洞。
為了打破這種序列瓶頸，業界引入了推測解碼技術。其基本思路是引入一個體積更小、速度更快的草稿模型，讓它先猜測接下來可能生成的幾個字，然後再由目標大模型對這些草稿進行批量校驗。如果草稿猜對了，大模型就能一次性確認多個字，從而大幅提速；如果猜錯了，大模型就推翻重來。
然而，傳統的推測解碼方案在提速的同時，製造了新的算力浪費。早期的並行草稿方案（如Medusa）或自迴歸草稿方案（如Eagle3），往往採用盲目猜測的策略。以並行草稿為例，它讓草稿模型在同一時間點並行猜測多個可能的下一個詞，但這忽略了詞與詞之間的先後依賴關係。而自迴歸草稿雖然考慮了依賴關係，讓草稿模型自己先生成一長串，但隨著序列變長，草稿模型猜錯的機率呈指數級上升。
當目標大模型對這些長串草稿進行校驗時，問題就暴露了。目標模型發現前面幾個詞猜對了，但後面大部分都是錯的。在傳統的校驗機制下，目標模型必須對整串草稿進行完整的前向傳播計算。在這個計算過程中，模型不僅要加載自身的巨大參數權重，還要處理草稿帶來的額外KV Cache。這意味著它在批改那些注定會被丟棄的廢稿時，消耗了大量的GPU算力和顯存頻寬。這種「無效校驗」在低併發時或許不明顯，但在DeepSeek-V4真實流量的高壓下，算力浪費被急劇放大，不僅拖慢了實際回應速度，更讓本就高昂的推理成本雪上加霜。DSpark的出現，就是為了把這部分被吃掉的算力搶回來。
實習生與導師：DSpark如何讓推測解碼不再盲目
DSpark的核心技術機制可以概括為半自迴歸生成與置信度排程推測解碼。這兩個聽起來晦澀的學術名詞，其本質是重塑了草稿模型與目標模型之間的協作關係，從根本上改變了GPU顯存讀寫與計算排程的邏輯。
我們可以用一個通俗的比喻來理解這個過程。假設目標大模型是一位嚴謹的導師，草稿模型是一位反應極快的實習生。在傳統的推測解碼中，導師讓實習生盲目猜接下來要寫的十句話。實習生雖然寫得快，但往往寫到第五句就開始跑題。導師拿過來一看，前四句可用，後六句全是廢稿。導師在批改這六句廢稿時花費的精力，就是被浪費的算力。
DSpark的半自迴歸生成機制，相當於給實習生配備了一個兼顧前後文邏輯的輔助大腦。實習生在猜測時，不再是完全脫離上下文的盲目發散，而是能夠根據已生成的內容進行一定程度的自我修正。在技術實現上，這意味著草稿模型在生成多個候選詞時，會利用前一步的隱藏狀態來指導下一步的生成，從而提高了長序列草稿的命中率，減緩了末尾內容通過率衰減的問題。
更關鍵的創新在於置信度排程。在DSpark框架下，實習生在提交草稿時，會給每一部分內容打上一個置信度分數，表示自己對這部分猜測的把握程度。導師在批改時，會根據這個分數進行動態排程。
在具體的演算法邏輯中，草稿模型的輸出層除了輸出詞表上的機率分佈外，還會輸出一個額外的純量值作為該預測詞的置信度。DSpark透過設定動態閾值機制，對草稿序列進行切分。如果某段草稿的置信度連續高於閾值，系統判定其大概率正確，將其歸為高優先級；如果置信度跌落閾值以下，系統則認為後續草稿出錯機率極大。
在底層的GPU計算邏輯中，這種排程改變了以往「一刀切」的批量校驗模式。對於實習生高置信度（大概率正確）的部分，導師會將其分配到高優先級的計算流中，集中精力快速批改；對於低置信度的部分，導師直接選擇丟棄，或者將其放入低優先級的計算流中減少校驗資源投入。這就避免了目標模型在必錯的廢稿上浪費寶貴的顯存頻寬和計算週期。
透過這種機制，DSpark有效減少了無效校驗帶來的算力浪費。據智東西等媒體報導，在Qwen3系列模型上，DSpark的平均接受長度比前代Eagle3提升了26.7%至30.9%，比DFlash提升了16.3%至18.4%。這意味著在同樣的時間內，目標大模型能夠採納更多正確的草稿，生成速度自然水漲船高。這種優化沒有增加任何額外的硬體投入，純粹依靠排程演算法的改進摳出了算力。
算力帳本：為什麼減少浪費比單純加卡更重要
從工程角度看，DSpark是一次漂亮的演算法優化。但從商業角度看，這是大模型廠商在殘酷成本戰中的生存指南。
大模型行業的財務模型極其敏感於推理成本。在OmniTools此前關於OpenAI洩露帳本的分析中，我們看到了一個令人震驚的成本結構：年入130億卻營運虧損209億。這種燒錢換規模的背後，除了高昂的訓練成本，更持續流血的是推理算力消耗。大模型的訓練成本雖然龐大，但通常是一次性或階段性的資本開支；而推理成本則是營運成本，每一次用戶調用API，每一次模型生成回答，都在消耗真金白銀的GPU算力、電費和折舊。
我們可以具體推演一次典型的API調用成本結構。假設用戶輸入1000個詞的提示詞，要求模型生成1000個詞的回答。在傳統的自迴歸模式下，Prefill階段處理1000個輸入詞，隨後Decode階段進行1000次序列生成。每一次生成都要加載龐大的模型權重，並讀寫不斷增長的KV Cache。在典型的千億參數模型中，單次Decode步驟的計算可能只需幾毫秒，但數據搬運可能耗時幾十毫秒。
如果採用傳統盲目推測解碼，雖然草稿模型快速生成了200個詞，但目標模型在校驗時發現只有前50個是對的，後150個全錯。那麼在處理後150個詞時，目標模型所調動的GPU計算單元、佔用的顯存頻寬、消耗的電力，全部變成了沉沒成本。當每天有數千萬次API調用時，這種無效校驗累積起的算力浪費，足以直接反映在廠商的季度財務報表上，成為吞噬利潤的無底洞。
當用戶量激增時，如果推理效率低下，廠商只有兩條路可選：要麼限制用戶訪問，要麼瘋狂採購顯卡擴容。前者損失市場份額，後者拖垮現金流。在資本逐漸趨於理性的當下，靠無限融資來填補算力窟窿的模式已經難以為繼。更致命的是，隨著模型參數規模的增大和上下文長度的擴展，單次推理的算力消耗呈指數級上升。如果任由無效校驗等算力浪費存在，大模型廠商的虧損缺口將隨著用戶規模的增長而無限放大。
DSpark所代表的推理優化路徑，給出了第三種解法。透過減少無效校驗的算力浪費，DeepSeek-V4在不增加硬體叢集的前提下，將高併發場景下的聚合吞吐量提升了最高400%。這意味著同樣的伺服器群，能夠承載數倍於以往的用戶請求。
對於大模型廠商而言，這種工程優化的價值遠勝於單純堆砌算力。加卡是線性增長的成本與線性增長的產能，每增加一張卡，就增加一份採購成本、維運成本和能耗壓力；而演算法層面的效率提升，則是固定成本下的指數級產能躍升。當行業進入價格戰階段，誰能在單次API調用中壓低算力成本，誰就能在保證毛利率的同時給出更具殺傷力的價格。DSpark不僅讓模型變快了，更讓大模型的商業閉環變得更加健康，為廠商在微利時代活下去提供了底氣。
開源DeepSpec：把武器發給中小團隊
在發布DSpark論文的同時，DeepSeek還開源了DeepSpec框架。據官方GitHub顯示，DeepSpec採用MIT協議開源，包含了DSpark、DFlash以及Eagle3等推測解碼演算法模組，並且相容Qwen3、Gemma等主流開源模型。
這是一個值得業界高度關注的動作。在當前的AI生態中，閉源巨頭如OpenAI、Anthropic等也在底層使用推測解碼或類似的推理加速架構，但他們極少將這些全棧的推理優化工具鏈開源。對於中小AI創業團隊來說，想要為自己的微調模型訓練一個高效的草稿模型，往往需要從零開始造輪子。
我們可以假想一個只有幾張A100顯卡的創業團隊的真實處境。他們可能微調了一個垂直領域的模型，但在部署時發現生成速度極慢，用戶體驗極差。如果他們想自己搞推測解碼，就需要懂CUDA算子開發，懂KV Cache的內存管理，還要自己設計草稿模型的訓練流程。這不僅意味著高昂的人力成本，更意味著漫長的試錯週期。很多中小團隊正是在這個階段耗盡了資金。
DeepSpec的開源，直接把最先進的推理優化武器發給了整個行業。在具體的框架設計中，DeepSpec提供了高度模塊化的接口。開發者不需要從底層重寫推理引擎，只需在配置文件中指定主模型路徑和草稿模型路徑，框架會自動接管草稿生成、置信度計算與目標模型校驗的完整流程。
對於想要訓練自有草稿模型的團隊，DeepSpec提供了標準化的數據蒸餾模塊，可以將目標大模型的隱藏狀態蒸餾出來供草稿模型學習，大幅降低了數據準備的門檻。開發者不再需要自己去摸索如何構建半自回歸的草稿模型，也不需要去反覆調試置信度調度的參數。通過DeepSpec提供的標準化工具鏈，中小團隊只需按照文檔配置參數，就能為自己的模型接入推測解碼能力，享受到生成速度大幅提升的紅利。
這種開源策略不僅加速了行業整體的技術迭代，也在一定程度上削弱了閉源巨頭在推理效率上的護城河。當最先進的工程優化能力成為行業公共基礎設施時，大模型競爭的焦點將被迫向更上層的應用創新和更底層的數據質量轉移。
主戰場轉移：模型之外皆屬Harness
DSpark的發布及其在DeepSeek-V4上的成功部署，印證了一個不可逆的行業趨勢：大模型競爭的主戰場已經轉移。
正如OmniTools在《模型之外皆屬Harness：Deepseek下場，國內AI競爭主戰場為何變了？》一文中所指出的，當各家廠商的基座模型參數規模都達到千億級別，且在各類基準測試中的表現趨於同質化時，單純拼參數已經無法拉開差距。決定一個AI產品生死和成本的，是模型之外的工具鏈、推理調度架構、API路由等系統級工程能力，也就是所謂的Harness。
對於不熟悉底層工程的人來說，“Harness”這個詞可能比較抽象。在軟體工程中，Harness通常指“測試線束”或“框架”，但在大模型語境下，它指的是包裹在基座模型外圍的整套系統工程基礎設施。它包括但不限於：管理用戶請求的API路由分發系統、負責加速生成的推理調度架構（如推測解碼和KV Cache管理）、讓模型能夠調用外部工具和聯網搜尋的工具鏈，以及保障高可用性的容災監控系統。基座模型就像一臺發動機，而Harness則是底盤、變速箱和傳動軸。發動機再強，如果Harness拉胯，動力也傳不到車輪上。
DSpark正是Harness層面的一次典型博弈。它不改變DeepSeek-V4的基座參數，不提升模型的智商，但它通過極致的工程優化，解決了真實流量下的算力浪費問題，直接改善了用戶體驗（回應速度）和廠商財務模型（推理成本）。未來的大模型競爭，將越來越多地表現為這種看不見的系統級工程博弈。誰的推理調度更智能，誰的KV Cache管理更高效，誰的推測解碼命中率更高，誰就能在同樣的算力儲備下打出更多的輸出。這種從“拼參數內卷”到“拼工程落地”的轉向，要求廠商不僅要懂算法，更要懂系統、懂硬體、懂真實的業務流量特徵。
局限與邊界：DSpark不是萬能藥
儘管DSpark在長文本生成和高併發場景下展現出了驚人的優化效果，但它並非解決大模型推理問題的萬能藥。任何技術方案都有其適用的邊界，DSpark也不例外。
首先是極高的存儲門檻。根據DSpark論文披露的數據，訓練一個適配中等規模模型（如Qwen3-4B）的草稿模型，所需的目標緩存體積高達38TB。這個數字對於擁有龐大算力叢集的頭部廠商來說或許只是常規配置，但對於資源有限的中小團隊而言，38TB的高速存儲訪問本身就是一道難以跨越的門檻。這意味著DeepSpec雖然開源了程式碼，但中小團隊想要完整復現並部署DSpark級別的優化，仍需克服硬體資源的現實阻礙。存儲成本和I/O瓶頸，可能成為阻礙這項技術全面普及的現實鴻溝。
其次是優化階段的局限性。大模型推理通常分為兩個階段：Prefill（預填充）和Decode（解碼）。Prefill階段是模型讀取用戶輸入的提示詞並生成第一個字的過程，這個階段屬於計算密集型，GPU算力被充分利用；而Decode階段則是後續逐字生成的過程，屬於訪存密集型，也是推測解碼主要發揮作用的階段。DSpark主要針對的是Decode過程。對於用戶極其敏感的首Token延遲（即Prefill階段），DSpark的優化作用相對有限。在極短文本交互場景（如簡單的問答或指令執行）下，由於生成內容本身就少，推測解碼能夠發揮的加速空間被壓縮，DSpark的速度優勢可能並不明顯。
最後是異構算力的適配問題。目前DSpark的線上驗證主要基於DeepSeek-V4的特定服務架構，其在非Nvidia硬體（如各類國產算力晶片）上的適配情況與實際加速比，尚缺乏公開的測試數據。在不同的硬體架構下，顯存帶寬和計算單元的調度邏輯存在差異，置信度調度策略是否需要重新調優，仍是一個待解的工程問題。
技術優化沒有銀彈。DSpark證明了通過算法調度消滅算力浪費的巨大潛力，為大模型行業打贏成本戰提供了一把利器。但在實際落地中，開發者仍需根據自身的業務場景、硬體儲備和延遲敏感度，理性評估這套方案的投入產出比。大模型的工程化之路，才剛剛進入深水區。
