昨日，DeepSeek 喺 GitHub 開源咗一個新項目 DeepInfer。呢個唔係新模型，而係承載 DeepSeek-V4.1-Flash 嘅底層推理引擎，涵蓋 MoE（Mixture of Experts，專家混合）專家並行、非同步 Batch 調度、定製 Kernel 同推測解碼（Speculative Decoding，先試生成再驗證嘅解碼策略）。DeepSeek 同時披露咗一組數據：單個集群每日要處理約 155 萬億 Token。
喺如此流量之下，GPU 每一輪計算浪費一少少資源，累積起來都相當可觀，所以推理優化係逐毫秒去拚。
目前 DeepInfer 開放嘅只係離線推理能力，線上 KV Cache 存儲同跨副本負載均衡等組件仲未完整公開。但由已放出的代碼，可以看到 DeepSeek 點樣安排大規模推理入面嘅計算、通訊同請求調度。
核心係一套叫 Zero-Overhead Batch Scheduler 嘅非同步調度機制。佢解決嘅問題好具體：GPU 明明已經完成計算，卻要停低等 CPU 整理上一輪生成結果、更新請求狀態，再安排下一輪工作。對需要連續生成幾千個 Token 嘅請求，呢種短暫等待會反覆發生，直接拉低 GPU 實際利用率。
DeepInfer 令 CPU 提前一輪安排計算，將原本串行的調度同模型前向推送重疊落去。當 GPU 處理第 N 輪 Forward 同 Sampling 時，CPU 已經開始準備第 N+1 輪 Batch，並利用空檔處理更早一輪嘅採樣結果。跨輪次狀態由 WorkerStepState 保存，包括 SequenceMetadata、SchedulerOutputs、SamplerOutput 以及對應嘅 CUDA Event；LLMEngine 透過 Worker 回調將原本集中在相鄰 Decode Step 之間嘅 CPU 工作，分散到 GPU 計算期間。
資料圖片：Pixabay
推測解碼帶來嘅變長問題，由 total_inflight_tokens 記錄已下發但未完成結果提交嘅 Token，調度器將呢部分納入序列長度同 KV Cache 容量檢查，並預先保留緩存空間。連續兩輪 Batch 之間請求位置不一致，則由 Remap 映射處理，GPU 利用設備側 Kernel 修正 Query Length、Key Length 等參數。
內存生命週期方面，因非同步流水線下 GPU 可能仍有未結束操作引用其內存，DeepInfer 採用 DeferredRelease 延遲回收機制：待釋放資源先入隊，再喺後續 pre_sampler_sync 階段統一處理；涉及 GPU 狀態複製嘅資源，用 CUDA Event 確認完成後先解除引用。
DeepSeek-V4.1-Flash 嘅部署規模進一步加大調度難度。官方方案中，Prefill 通常採用 EP2 至 EP8，Decode 則使用 EP64 至 EP128 嘅寬專家並行。對同時承擔兩種任務嘅 NORMAL Engine，若部分 Rank 進入 Prefill 而其他 Rank 繼續 Decode，就可能出現集合通訊不匹配。DeepInfer 喺 Scheduler 加入組內投票機制：ALL 模式要求相關 Rank 滿足執行 Prefill 嘅條件，ANY 模式允許部分 Rank 觸發組級 Prefill，兩種模式均受觸發間隔控制。此外，若初步決定切換 Prefill 後某 Rank 因 KV Cache 容量不足或序列槽位受限最終無可執行任務，系統會執行第二輪確認，未有有效 Prefill 就返回 Decode；部分 Rank 成功排出任務，其餘 Rank 則執行空 Prefill Step 以維持一致嘅通訊順序。
模姐驗嚇貨：官方披露嘅 155 萬億 Token/日係廠商聲稱，並非本站實測；DeepInfer 目前開放嘅係離線推理能力，線上組件未完整公開，所以仲無從評價實際服務環境下嘅表現。呢套代碼對想深入理解大規模推理調度嘅開發者係好嘅參考，但「Zero-Overhead」本身更接近一個調度目標，實際收益取決於 CPU 同 GPU 工作重疊到幾多，當 CPU 處理時間超出設備計算能覆蓋嘅窗口時，等待仍會出現。
模姐｜深度調教
