DeepSeek 又一開源重器！深挖 DeepInfer 究竟藏著多少技術狠活？

單集群日處理約 155 萬億 Token，推理優化爭奪毫秒。作者丨鄭佳美 編輯丨岑 峰 昨天，DeepSeek 又在 GitHub 上開源了一個大項目，叫 DeepInfer。這次沒有發佈新模型，放出來的是 DeepSeek-V4.1-Flash 背後的推理引擎，包含 MoE 專家並行、異步 Batch 調度、定製 Kernel 和推測解碼等核心技術。DeepSeek 還披露了一組數據：單個集群每天需要處理約 155 萬億個 Token。如此龐大的流量，GPU 哪怕在每輪計算中浪費一點資源，累積起來也相當可觀。

目前 DeepInfer 開放的是離線推理能力，線上 KV Cache 存儲和跨副本負載均衡等組件尚未完整公開。不過，從已經放出的代碼中，可以看到 DeepSeek 如何安排大規模推理中的計算、通信和請求調度。其中有一套叫 Zero-Overhead Batch Scheduler 的異步調度機制。它解決的問題很具體：GPU 明明已經完成計算，卻要停下來等 CPU 整理上一輪生成結果、更新請求狀態，再安排下一輪工作。對於需要連續生成幾千個 Token 的請求，這種短暫等待會反覆發生，GPU 的實際利用率也會受到影響。

DeepInfer 讓 CPU 提前一輪安排計算，把原本串行執行的調度和模型前向重疊起來。但提前排程意味著下一輪計算啟動時，上一輪的 Token 可能還沒完成 CPU 後處理，序列長度、KV Cache 狀態和請求生命週期便會出現時間差。整個機制的技術難點，就藏在這種跨輪次的狀態管理裡。01重新安排 Decode 時序傳統推理引擎的 Decode 通常按照固定順序運行：CPU 選擇請求、組織 Batch 和 KV Cache 元數據，GPU 執行 Forward 與 Sampling，隨後 CPU 讀取結果、更新生成長度和請求狀態，再啟動下一輪計算。

隨著 DeepGEMM、FlashMLA 等底層 Kernel 持續優化，GPU 的單輪計算時間不斷縮短，CPU 調度與結果處理的耗時開始佔據更明顯的比例。尤其在 Decode 階段，模型每輪處理的 Token 數量有限，CPU 和 GPU 之間頻繁切換執行權，會產生持續累積的空檔。Zero-Overhead Batch Scheduler 調整了這套執行順序。按照公開的實現，當 GPU 處理第 N 輪 Forward 和 Sampling 時，CPU 已經開始準備第 N+1 輪 Batch，並利用設備計算期間的空檔處理更早一輪的採樣結果。

部分工作可以提前提交到 GPU 執行隊列，依賴關係則由 CUDA Stream 和 Event 維護。實現中，WorkerStepState 用來保存跨輪次執行狀態，包括 SequenceMetadata、SchedulerOutputs、SamplerOutput 以及 Forward 和 Sampling 對應的 CUDA Event。這樣，上一輪的結果可以暫時保留，CPU 無須等其全部完成後處理，便能繼續推進後續調度。LLMEngine 通過 Worker 回調銜接這些操作，將原本集中在相鄰 Decode Step 之間的 CPU 工作分散到 GPU 計算期間。

對於持續生成的請求，流水線進入穩定狀態後，CPU 與 GPU 可以分別處理不同輪次，減少設備因調度工作產生的等待。當然，流水線的啟動和收尾仍然需要特殊處理。剛開始執行時沒有更早的結果可供消費，請求全部完成後也可能留下尚未提交的採樣輸出。DeepInfer 通過 Flush 機制處理這些在途結果，確保最後一批計算完成後，請求狀態能夠正常收尾。這套方法的收益取決於 CPU 工作與 GPU 計算能夠重疊多少。當 CPU 處理時間超過設備計算能夠覆蓋的窗口時，仍然會出現等待，因此 Zero-Overhead 更接近一種執行調度目標。

02DeepInfer 如何修正狀態錯位CPU 提前安排下一輪時，上一輪的採樣結果可能尚未確定。普通自迴歸解碼通常只推進一個 Token，開啟推測解碼後，一條請求可能連續接受多個候選，不同序列的實際推進長度也會出現差異。假設一條請求已經緩存了 1000 個 Token，當前輪可能接受 3 個候選。CPU 準備下一輪時，尚不清楚這些候選最終會通過幾個，如果直接使用舊長度組織計算，Query Length、Key Length 和 RoPE 位置就可能出現偏移。DeepInfer 為此維護 totalinflighttokens，記錄已經下發、但尚未完成結果提交的 Token。

調度器分配計算資源時，會把這部分在途計算納入序列長度與 KV Cache 容量檢查，並提前預留可能需要的緩存空間，避免後續 GPU 執行時出現容量不足。容量預留之後，還要解決連續兩輪 Batch 中請求位置不一致的問題。請求可能結束、加入或被搶佔，同一條序列在不同 Batch 中的排列位置也可能改變。DeepInfer 因此通過 Remap 映射，將當前輪的請求對應到上一輪保存的執行狀態，新加入的請求則使用特殊標記。GPU 利用映射找到上一輪的實際採樣結果，再通過設備側 Kernel 修正 Query Length、Key Length 等參數，使當前輪注意力計算能夠訪問正確的上下文範圍。

對於變長推測驗證，還會根據實際接受結果更新需要處理的 Token 數量。由於 CUDA Graph 通常按照提前捕獲的執行規格運行，系統還需要區分計算圖預留容量與實際有效序列長度。設備側狀態修正減少了 CPU 與 GPU 之間頻繁傳輸少量長度數據的需要，也讓動態請求能夠適配固定規格的執行圖。另一處複雜性來自內存生命週期。同步執行時，請求完成後，CPU 通常可以直接釋放相關元數據和緩存引用。但在異步流水線中，某條請求雖然已經完成 CPU 後處理，GPU 上可能仍有尚未結束的操作引用其內存。

DeepInfer 使用 DeferredRelease 延遲迴收 SequenceMetadata、RequestOutput 以及相關緩存塊的固定引用。待釋放資源先進入隊列，再在後續的 presamplersync 階段統一處理。對於涉及 GPU 狀態複製的資源，系統利用 CUDA Event 確認操作完成後再解除引用，避免緩存提前被其他請求佔用。請求搶佔也要遵循相同的狀態邊界。如果某條序列已經離開運行集合，先前提交的計算結果返回時，就不能繼續按照原狀態更新 Token 計數或緩存位置，否則可能影響重新排程後的序列。

這些處理讓提前調度能夠跨越多個尚未完成的 Step，避免序列位置、緩存分配和資源回收之間發生衝突。03保證多卡執行步調一致DeepSeek-V4.1-Flash 的部署規模進一步增加了調度難度。官方方案中，Prefill 通常採用 EP2 至 EP8，Decode 則使用 EP64 至 EP128 的寬專家並行。擴大專家並行規模可以分散 MoE 權重讀取壓力，但參與同一個通信域的 GPU 必須採用一致的執行步型。

對於同時承擔 Prefill 和 Decode 的 NORMAL Engine，如果部分 Rank 進入 Prefill，其他 Rank 卻繼續 Decode，就可能發生集合通信不匹配。DeepInfer 在 Scheduler 中加入組內投票機制，協調不同 Rank 的執行模式。ALL 模式要求相關 Rank 滿足執行 Prefill 的條件，減少無任務設備陪跑。ANY 模式允許部分 Rank 的待處理請求觸發組級 Prefill，避免小規模請求長時間排隊。兩種模式受到各自觸發間隔的控制，減少頻繁切換帶來的額外開銷。

代碼裡還有一個細節：等待隊列存在請求，不代表這一輪能夠成功排出 Prefill。某個 Rank 可能因為 KV Cache 容量不足或序列槽位受限，最終沒有可執行任務。為此，DeepInfer 在初步決定切換 Prefill 後，還會執行第二輪確認。各 Rank 完成實際排程，再檢查組內是否存在有效 Prefill。如果沒有，就返回 Decode；如果部分 Rank 成功排出任務，其他 Rank 則執行空 Prefill Step，維持一致的通信順序。

啟用 Zero-Overhead Scheduling 時，部分組內調度協調還可以通過 CPU 側 Data Parallel 通信組執行，減少控制通信對 GPU 計算的干擾。多卡同步之外，MoE 的專家負載也會影響整輪執行時間。Router 可能將較多 Token 分配給少數熱點專家，導致對應 GPU 的工作量高於其他設備，即使 CPU 調度已經完成，計算仍需等待較慢的 Rank。DeepInfer 通過 Expert-Parallel Load Balancing 分散這類負載，在 GPU 上保留部分冗餘專家副本，並根據運行統計重新安排專家分佈。

官方 Decode 配置使用 1000 步統計窗口，每 10000 步調整一次專家分配，測得的慢速 Rank 與平均負載之比約為 1.090。這樣，組內步型協調負責處理跨設備的執行一致性，專家負載均衡則緩解部分設備長期拖慢整輪計算的問題。兩者配合異步調度，讓 DeepInfer 能夠在大規模 MoE 部署中維持較連續的 Decode 執行。04推理優化開始深入執行時序DeepInfer 的 Zero-Overhead Batch Scheduler 借鑑了 SGLang、NanoFlow 等已有異步調度實踐。

它的工程特點集中在跨輪次狀態修正、在途 Token 記賬、KV Cache 生命週期管理，以及與寬專家並行的協同實現。目前官方尚未單獨公佈這套調度機制相對同步方案的完整端到端加速數據，DeepInfer 的整體性能結果還包含底層 Kernel、模型並行和其他執行優化的共同作用。當前公開版本也主要面向 DeepSeek-V4.1-Flash，完整線上服務所需的部分基礎設施仍未開放。隨著 Coding Agent 和長鏈路推理任務不斷增加，Decode 需要執行的輪次持續增長。

DeepInfer 展示了一條明確的工程路線：通過跨輪次執行重疊減少調度空檔，再利用狀態修正與資源生命週期管理維護正確性，讓更多 GPU 時間用於實際模型計算。參考鏈接：https://github.com/deepseek-ai/DeepInfer/blob/main/README.md上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。