DeepSeek 於 2026 年 10 月 16 日在 GitHub 開源 DeepInfer，這是支撐其大規模線上服務的推理框架。首版僅支援自家 DeepSeek-V4.1-Flash 模型，採 Apache-2.0 授權，硬體同時涵蓋 NVIDIA SM100 繪圖卡與華為昇騰 950 NPU。專案上線四日累積逾 3,200 顆星標，外界關注的重點並非又一個通用推理服務，而是該公司把生產環境使用的批次排程、專家平行與確定性取樣設定一併公開。
DeepInfer 是什麼？
DeepInfer 是 DeepSeek 開源的生產級推理框架，Apache-2.0 授權，首版僅支援 DeepSeek-V4.1-Flash。
專案定位寫得相當直接：它是驅動 DeepSeek 大規模生產服務的推論引擎，此次釋出的是「離線推論」版本，包含規模化服務所需的核心能力。README 列出的支援範圍只有一個模型，即 10 月 17 日上架的 DeepSeek-V4.1-Flash-1017，並未提供其他模型家族的轉換腳本或相容層。這種克制與多數開源推理框架截然不同，後者通常以「支援數十個模型」作為賣點。
從提交節奏觀察，儲存庫於 10 月 16 日建立，四日內已推送多次更新，並累積 230 次複製與 28 個待處理議題。公開的貢獻者名單相當精簡，反映這是內部服務程式碼的一次性釋出，而非社群共建專案；企業評估時應把這一點納入維護風險的考量。
為什麼 DeepSeek 要自行開發推理引擎？
通用框架難以同時滿足超長上下文、混合專家平行與批次不變性需求，自建引擎可針對特定模型結構調整核心與排程，換取可預測的延遲與成本。
MoE 架構的推理瓶頸與密集模型不同。專家層需要跨裝置交換 token，通訊量隨批次組成劇烈變動，通用框架往往只能在吞吐與延遲之間取捨。DeepInfer 的並行策略因此寫得相當細：注意力層採資料平行搭配平衡的上下文平行，專家層採專家平行並結合 EPLB 做負載平衡，讓不同節點上的專家熱度趨於一致。
另一個動機是可重現性。批次不變性推論讓同一段輸入不論與哪些請求同批處理，輸出結果都完全相同；確定性取樣則進一步保證相同種子與參數下輸出逐字一致。這兩項特性對評估流程與除錯至關重要，因為多數框架的輸出會隨批次組成漂移，導致基準測試無法比較。
DeepInfer 有哪些技術亮點？
核心包括 FlashMLA、DeepGEMM 等自研算子，DSpark 推測解碼與信心排程驗證，SWA 有界重播，零開銷非同步批次排程，以及批次不變性與確定性取樣。
算子層面採用自家累積的元件，包括注意力用的 FlashMLA、矩陣運算用的 DeepGEMM、專家通訊用的 DeepEP，以及 TileKernels、DeepSelect 與以 TileLang 撰寫的自訂核心。這些元件過去已分別開源，DeepInfer 的角色是把組裝方式與排程策略一併交代清楚。
解碼加速則依賴 DSpark 與信心排程驗證。系統先以草稿 token 產生候選，再依信心估計決定驗證範圍，環境變數 DEEPINFER_USE_NEXTN_DECODE 控制最大草稿長度，預設為 5。前填充階段另有 SWA 有界重播機制，只重播固定長度的尾段以降低計算量，預設保留 140 個 token，且保留長度必須覆蓋滑動視窗加上最大回溯距離。
非同步排程是另一項實際影響吞吐的設計。CPU 端的批次排程與裝置端執行重疊進行，預設開啟，等於把排程延遲藏在運算時間之內。此外，結構化輸出支援正規表達式、JSON Schema 與 EBNF 文法三種約束方式，可直接套用於工具呼叫與表單填寫場景。
硬體支援與部署門檻有哪些？
硬體限 NVIDIA SM100 與華為昇騰 950，需 Linux、GCC 13、Python 3.12，且須自行提供 KV 快取。
建置流程要求先建立乾淨的 Python 3.12 環境，再執行 build.sh；NVIDIA 平台需設定 DEEPINFER_ACCELERATOR=nvidia 並具備 CUDA 13，昇騰平台則改用 ascend 與 CANN 9.2。首次執行會從 Hugging Face 下載預設檢查點，也可透過 DEEPINFER_HF_MODEL_DIR 指向本地下載的權重目錄，適合內網或離線環境。
README 明列三項未包含於此次釋出的元件：KV 快取系統、預填充與解碼分離，以及資料平行副本之間的負載平衡。其中分離式部署的多數引擎功能其實已實作，缺的是把它們串成完整服務的最後一層。這意味著此次開源更适合當作研究與自建服務的起點，而非開箱即用的推論伺服器。
官方公布的效能數據說明了什麼？
官方以 4 張 SM100 跑前填充、64 張跑解碼，於單一擴充域內量測吞吐與延遲曲線，並附上可重現的掃描腳本，但未提供與其他框架的直接對照。
效能章節以兩張帕雷托曲線呈現，前填充比較輸入吞吐與延遲，解碼比較輸出吞吐與每位使用者速度。量測規模為 4 張 SM100 處理前填充、64 張處理解碼，兩者都落在同一個擴充域之內，避免跨域網路成為瓶頸。專案同時附上 examples/sweep/run_sweep.sh，讓第三方可在自家硬體重跑同一組掃描。
值得注意的是，README 並未把 DeepInfer 與 vLLM、SGLang 或 TensorRT-LLM 並列比較。缺乏對照組的情況下，這些曲線的意義在於驗證特定模型在特定硬體上的行為，而非證明框架整體更快。評估者若打算以此作為選型依據，仍需自行補做跨框架基準測試。
與 vLLM、SGLang 的淵源代表什麼？
專案自述主要建構於 vLLM 之上，並參考 SGLang 與 TensorRT-LLM 的設計，屬於針對自家模型深度改造的分支，而非從零重寫的全新架構。
致謝段落寫得坦白：DeepInfer 最初主要建構於 vLLM，另從 SGLang 與 TensorRT-LLM 取得靈感。這樣的血緣關係解釋了為何它的程式結構與 vLLM 相似，例如取樣參數物件、模型執行器分層與範例腳本的組織方式，都帶有明顯的通用框架痕跡。
差異在於深度。DeepSeek 針對自家 MoE 結構重寫了專家並行、通訊核心與排程器，並把生產環境驗證過的預設值直接寫進程式。這種做法對想理解「大規模部署究竟需要調整哪些環節」的開發者極具參考價值，因為多數框架只提供可調參數，卻不說明在真實負載下的取捨。
開發者可以如何使用 DeepInfer？
先備妥 SM100 或昇騰 950 環境與 Python 3.12，建置後執行離線推論範例，再依結構化輸出與批次不變性設定調整，最後自行補上快取與服務層。
最短路徑是執行 examples/offline_inference.py，它會載入預設檢查點並跑完一次生成，適合驗證環境是否完備。接著可參考 examples/_structured_output.py 的寫法，把 JSON Schema 或正規表達式傳入取樣參數，觀察約束解碼的實際效果。
若要用於服務，建議先釐清三件事：推論請求的批次組成是否穩定、是否需要逐字可重現的輸出、以及 KV 快取要自建還是接現有方案。批次不變性與確定性取樣都需要額外開啟環境變數，且官方註明僅支援 NVIDIA 平台，在昇騰上無法取得同等保證。
出處連結有哪些？
主要出處為 GitHub 儲存庫 deepseek-ai/DeepInfer，內含功能清單、範例腳本與評估說明。
本文數據取自專案公開資料，包括儲存庫統計、README 的功能與硬體段落、examples/ 目錄下的範例腳本，以及 Hugging Face 模型頁面。讀者如需核對個別技術細節，可依下列連結前往原始來源。
- 儲存庫：https://github.com/deepseek-ai/DeepInfer
- 預設模型：https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017
- 範例目錄：https://github.com/deepseek-ai/DeepInfer/tree/main/examples
- 評估說明：https://github.com/deepseek-ai/DeepInfer/tree/main/eval
總結：哪些團隊值得關注 DeepInfer？
已部署 DeepSeek 模型、具備 SM100 或昇騰資源，且在意延遲可預測性的團隊最值得研究；應用開發者可先觀望。
這次開源的意義，在於把「模型之外的成本」攤開。長期以來，開源社群能取得權重，卻難以複製廠商的服務效率；DeepInfer 至少公開了排程、平行與取樣的具體設定，讓外界得以檢視推理成本由哪些環節構成。
限制同樣鮮明。單一模型支援、專屬硬體門檻、缺少快取與服務層，都讓它難以直接取代通用框架。對於正在自建 DeepSeek 服務的團隊，這份程式碼是難得的參考樣本；對於只想快速上線應用的開發者，等待社群補齊周邊元件，或改用成熟框架，仍是更務實的選擇。
