DeepInfer 開源解析：推論引擎公開了，離完整服務還差什麼？（2026）

2026 年 10 月 20 日，DeepSeek 在 GitHub 留下了 DeepInfer 的初始提交，公開這套用於自家大規模服務的推論框架。這次 DeepInfer 開源最值得看的，是原本藏在服務後面的計算與調度方法；同時也要看清楚，下載程式碼後，離真正接住線上流量還有哪幾段路。

先看原文交出了什麼，再拆開效能曲線與硬體條件，最後判斷誰能直接受益。這份開源值得重視，但「引擎可研究」、「離線測試能跑」與「線上服務能穩定交付」需要分別驗收。

DeepInfer 開源的核心：把推論方法交到工程師手上

This open-source release provides offline inference with the core features needed for serving at scale.

中文：這次開源提供離線推論，以及支撐大規模服務所需的核心功能。

DeepInfer README

這句話把範圍說得很清楚。截至 2026 年 10 月 22 日，README 列出的模型是 DeepSeek-V4.1-Flash，硬體目標是 NVIDIA SM100 GPU 與 Huawei Ascend 950 NPU，程式碼採 Apache-2.0 授權。它讓開發者可以檢查、修改與重用實作；模型權重及相依元件的條款，仍要各自核對。

公開的底層核心包括 FlashMLA、DeepGEMM、DeepEP、TileKernels、DeepSelect 與自訂 TileLang kernels。這些實作處理注意力、矩陣計算、通訊與其他細部工作；它們與上層引擎如何安排批次、移動資料一起，決定硬體能有多少時間用在有效計算。

把模型想成一份已經學會的能力，推論框架就是安排這份能力如何使用晶片、搬移資料、輪流處理請求的工作系統。同樣的模型，若計算單元一直等資料或等下一批工作，硬體規格再漂亮，也會有昂貴的空檔。

README 也承認技術脈絡：DeepInfer 起初主要建立在 vLLM 之上，並受到 SGLang 與 TensorRT-LLM 啟發。這次公開的價值，在於可以具體比較它如何把既有想法與自家模型、硬體配置接起來，而非把它想成與開源社群無關、憑空出現的一套系統。

原文的完整服務圖，比「開源引擎」多了什麼？

官方部署 Q&A把系統分成視覺編碼器、Prefill、Decode，以及獨立快取儲存。Prefill 先處理輸入內容，Decode 接續產生輸出；KV cache 保存注意力計算可重用的中間結果。圖中的藍色路徑把快取送往不同階段，黑色路徑則安排請求。

圖頂端另有 DeepSeek Recipe。官方把它定位為 API 請求與模型 token 序列之間的編碼、解碼及協定轉換元件，並與引擎一同公開。它讓服務介面與模型處理方式接合；完整快取、路由與服務整合仍是另外的工作。

README 明列三項完整服務所需、此次未隨釋出提供的部分：KV cache 系統、視覺編碼／Prefill／Decode 的分離部署，以及 Prefill、Decode 跨資料平行副本的負載平衡。其中分離部署所需的多數引擎功能，官方說已經實作；這仍與整套服務整合完成有距離。

這裡有兩個容易讀錯的地方。第一，缺的是完整 KV cache 系統，不能寫成引擎完全不使用快取。第二，跨服務副本的負載平衡未包含，不等於所有負載平衡都缺席：模型內部的專家平行負載平衡 EPLB，已在公開功能清單裡。兩者管理的是不同層次。

這種拆分有技術理由。vLLM 的分離 Prefill 文件也把首字等待與字間延遲分開處理。讀長輸入與接續吐字的工作不同，分開配置能各自調整；但快取傳輸、路由與故障恢復會變成需要處理的新工作，不能只把分離本身當成提速保證。

DeepInfer 怎麼省下等待與重算？四組機制

一、把專家工作分散，也把熱門專家的負擔攤平

DeepInfer 列出 Attention 的資料平行／平衡上下文平行，以及 MoE 的專家平行與 EPLB。白話說，一方面讓不同裝置分擔工作，另一方面避免某些熱門專家把少數裝置塞滿。官方部署設計偏向在 Decode 使用較寬的專家平行範圍；它追求的是計算、記憶體流量與通訊之間的平衡。

二、先猜幾個 token，再決定值得驗證多少

DSpark 的草稿解碼搭配信心排程驗證：草稿先提出後續 token，再依接受可能性安排驗證工作。它要減少的是花在低收益候選上的計算。這不代表每段文字都能接受同樣多的草稿；題目、設定與當下併發量都會影響收益。

三、少重播一部分舊內容，並讓 CPU 與裝置交錯工作

SWA bounded replay 透過重播有限尾段，降低解碼器部分的 Prefill 重算。非同步排程則把 CPU 準備下一批工作的時間，與裝置執行當前工作重疊。前者處理重算範圍，後者處理流水線空檔；它們改善的瓶頸不同，效益也不能直接相加。

四、重現與格式控制，也屬於推論品質

功能清單另包含批次不變推論、確定性取樣與結構化輸出。README 將前兩者標為 NVIDIA 限定，確定性取樣還有固定輸入、取樣參數與種子等設定條件；不能寫成兩種硬體天然完全一致。JSON schema、正規表示式與 EBNF 約束能控制輸出形狀，內容是否正確則仍須另驗。

效能圖怎麼讀：先保留分母，再談省多少

官方 README 說明，Prefill 曲線使用 4 顆 SM100，Decode 使用 64 顆，兩者各自在單一 scale-up domain 內量測。這不是一部普通電腦的成績，也不是 NVIDIA 與 Ascend 的對照試驗。以下是官方公布的離線結果與換算條件；本次沒有在相容加速器上重跑。

這張圖把非快取輸入吞吐量，對上每個 Prefill step 的時間。一次處理更多工作，可以攤提一些成本，卻也會拉長單步時間。把縱軸最高點當成所有使用者都更快，會忽略橫軸的交換條件；首字等待還包含排隊、快取與其他處理。

Decode 圖的關鍵藏在副標題：固定草稿長度 3，並以每個草稿 token 接受率 75%，換算每步有效長度 τ=3.25。範例文件與 繪圖程式交代了換算方式：基礎量測提供步速，圖上的輸出速度再套用接受率參數。75% 是這張圖使用的換算假設，不能寫成此次掃描已量得的真實接受率。

圖上的另一個訊息是：同時處理更多請求，總吞吐可以提高，每位使用者的輸出速度卻可能降低。你要先決定服務承諾的等待門檻，再挑曲線上合適的點。把低併發時的個人速度，與高併發時的總吞吐拼成同一份宣傳成績，會創造圖上不存在的服務。

README 將兩張圖的量測硬體都標為 SM100，因此本文不據此對 Ascend 950 的吞吐量下結論。雙平台程式路徑是可檢查的進展；相同負載、相同品質與相同服務門檻下的成本勝負，需要另外一組資料。

原文的大數字與承諾，各自能證明什麼？

A model defines the boundary of what is possible

中文：模型定義了可能做到的能力邊界。

DeepSeek V4.1 Flash Inference Deployment Q&A

原文接著把焦點放在如何用合理成本，將能力服務給大量使用者。Q&A 自述單一叢集每天服務 155 兆 tokens，並以離峰價格計算，每 GPU 小時營收 US$38。這些是 DeepSeek 的營運陳述，本文沒有取得可獨立核對的完整流量與財務資料，因此保留公司歸屬。

營收不等於成本，也不等於利潤。要推算利潤，還需要硬體折舊、電力、網路、儲存與營運支出；要解讀 token 總量，還需要知道輸入、輸出及快取的計算口徑。這兩個大數字可以描述公司想展示的規模，不能直接替第三方部署開出獲利保證。

官方另提供 AIME、GPQA 與 HLE 評估流程，將生成與評分分開，要求樣本覆蓋完整後才採用 Pass@1。這類檢查有助發現部署設定錯誤；它與服務能接住多少併發、故障時能否恢復，是不同的驗收問題。本文不把參考模型分數當成新引擎已通過所有實際工作。

原文也承諾未來 DeepSeek 模型的推論程式與後續效能工作，會持續在 DeepInfer 開源。這是一項可以日後對帳的承諾：新模型推出後，是否同步有可讀的實作、支援條件、測試與可比較的結果，比單看今天的關注度更有資訊量。

AlphaLab 的判讀：方法公開了，營運責任也更清楚了

我同意：真正有價值的是可以拆開研究與改進

權重讓人取得模型，推論程式則讓人研究能力如何被送到使用者手上。當排程、專家分工、草稿驗證與有限重播變成可讀程式，外部團隊有了具體的比較對象，也有機會將適合的想法接回其他系統。能否降低採用成本，首先取決於這些方法是否吻合自己的模型與流量。

我存疑：把開源範圍直接換算成服務成本降幅

若現有服務最慢的是檢索、資料庫或人工檢查，換推論引擎只會改善其中一段；若主要成本來自低利用率與備援，離線峰值也不會自動填滿那些空檔。可以期待效率改善，但應把重複請求、失敗重試與閒置資源一起算進分母。

這與 TorchNeuron 的硬體遷移分析相通：程式能接上另一平台，是開始比較的條件；要決定是否搬家，還得比較完整工作負載的正確性、效能與維護成本。DeepInfer 的雙平台支援值得追蹤，卻不足以單獨推導某家硬體必勝。

完整服務圖中的空白，應成為導入清單

快取、路由、排程與備援互相影響。省下重算若要靠更多儲存與傳輸，應連同後兩者一起評估；高吞吐若需要更大批次，也要核對等待是否仍合格。Prometheus 的有效產出分析談的是訓練，但其中「硬體存在」與「產出能交付」分開記帳的原則，同樣適用這裡。

DeepInfer 開源之後，下一步先交出哪三張成績單？

對一般使用者，這次不是一個必須立即安裝的新聊天介面。你可以觀察服務商是否真的改善等待、穩定性與費用；對正在自架推論的團隊，先盤點是否有符合條件的硬體、模型及工程資源，再安排試驗。

第一張是範圍單：固定程式提交、模型版本、硬體與啟用功能，逐一標明公開引擎提供什麼、自己補上什麼。尤其把引擎內部 EPLB 與服務副本路由分開，避免因同名的「負載平衡」漏掉一層。

第二張是品質與等待單：用同一批代表性請求，記錄答案是否合格、端到端首字等待、字間延遲，以及完整完成時間。保留冷快取、熱快取、失敗與重試，並核對草稿接受率；別讓換算假設取代真實文字上的量測。

第三張是完整成本單：計入實際占用的計算、儲存、網路與維運資源，再除以合格完成的工作。想設計考題，可以接著讀 AI Evals 入門；資源盤點可先用 模型記憶體規劃理解權重、快取與工作負載的分工，實際容量仍按 DeepInfer 的平台配置另算。

我的結論是：DeepInfer 把一部分大型推論服務的方法變成可檢查、可重用的工程資產。它最值得期待的成果，是別的團隊能在自己的服務門檻內，交付同樣可靠、成本更清楚的工作。先留下一組可對照的基準，再談要不要搬；這會比替開源消息喊一個尚未量過的降本百分比更有用。