DeepSeek開源了一種新的推理最佳化方法DSpark，附帶一篇極其詳細的論文、草稿模型以及訓練它們的框架DeepSpec。在 dsv4 生產環境中的結果顯示，吞吐量和延遲提高了 +50%（延遲甚至可以達到 ~80%，太瘋狂了）
DeepSpec是一個用於訓練和評估推測解碼草稿模型的完整程式碼庫，包含資料準備、草稿模型實現、訓練程式碼和評估指令碼，目前支援 DSpark、DFlash 和 Eagle3 三種演算法。
paper：
https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
github：
https://github.com/deepseek-ai/DeepSpec
DSpark機制
LLM吐字慢的根本原因在於它的工作機制。每次只能根據前面的內容預測下一個詞。字數越多等待時間越長，GPU算力還吃不飽。
業內一直在用投機解碼技術來提速。簡單說就是找個小模型先草擬一堆詞，再讓大模型一次性判斷對錯。全對就一起輸出，錯了就從錯的地方重新算。
不過目前用來打草稿的小模型都有硬傷。
傳統的按順序寫草稿的小模型，自己生成就很慢，拖累了整體進度。
後來大家發明了一次性把所有草稿詞全寫出來的平行小模型。速度是快了，但詞與詞之間毫無關聯。這導致越往後的草稿瞎編的機率越大，被大模型瘋狂打回重做。
另外不管草稿好壞，全都交給大模型去檢查，在系統閒著的時候沒關係。一旦系統滿載，這些註定要被廢棄的草稿會白白搶佔寶貴的計算資源，導致整個系統的吞吐量暴跌。
為了拔掉這兩根毒刺，DSpark使出了兩招。
第一招叫半自回歸生成。
既然完全順序寫太慢，完全平行寫容易瞎編，那就把兩者結合起來。
DSpark的主體部分依然保持平行計算，這樣能保住極致的生成速度。它在最後面加了一個極其輕量的順序處理模組。有了這個小模組，草稿詞之間就有了上下文聯絡。比如前一個詞預測了理所，後一個詞就會順理成章地給出當然，徹底避免了那種前言不搭後語的跨頻道聊天。
這樣一來即使是長串的草稿，也能保持極高的採納率。
第二招叫硬體感知的置信度調度。
有了高品質的長草稿，下一步就是決定讓大模型檢查多少個詞。
DSpark給小模型裝了一個打分器，專門預測每個草稿詞存活下來的機率。
光有機率還不夠，系統還會即時監控當前的算力負載。如果當前訪問人數少算力富裕，調度器就會放行更多的草稿詞去驗證，充分榨乾閒置算力。如果當前並行請求極高算力緊張，調度器就會立刻變得冷酷無情，直接砍掉那些得分低的墊底詞。
這樣好鋼全用在刀刃上，確保大模型的計算資源只花在最有可能成功的詞上。
這套組合拳打下來效果非常明顯。
在純演算法測試中，無論是數學邏輯解答程式碼編寫還是日常聊天，DSpark在Qwen和Gemma等不同規模的模型上都碾壓了現有的各種草稿模型，草稿採納長度大幅提升。
更重要的是真實生產環境的實戰成績。
研發團隊將DSpark直接部署到了DeepSeek V4的線上服務系統中，迎接海量真實使用者的考驗。
資料表明，在和老一代生產基線保持相同整體吞吐能力的前提下，DSpark讓V4 Flash和V4 Pro的每個使用者生成速度大幅度加快，提升幅度最高達到了85%。
在系統面臨極限高並行挑戰時，老系統會因為資源爭搶而崩潰掉速，DSpark卻能遊刃有餘地動態縮減驗證長度，死死穩住系統的響應底線。
這等同於在不增加顯示卡的條件下，生生拉高了整個大模型服務系統的性能天花板。
目前研發團隊已經把DSpark的模型權重連同底層的演算法訓練庫DeepSpec一併開放，所有開發者都可以直接體驗這套前沿的推理加速方案。 (AI寒武紀)