DeepInfer 是什麼？DeepSeek 的推論引擎，以及它未一併發布的部分

DeepInfer 是 DeepSeek 於 2026 年 10 月 16 日以 Apache-2.0 授權發布的推論框架，且僅服務一個模型：DeepSeek-V4.1-Flash，並以DeepSeek-V4.1-Flash-1017作為預設檢查點。這種單一模型範圍是首先要理解的事，因為它幾乎解釋了該儲存庫的其他一切。這不是一個恰巧包含 DeepSeek 設定的通用服務框架。它是 DeepSeek 在生產環境執行的程式碼路徑，精簡到可通用化的部分，並且對這項裁剪相當坦誠：README 自己列出完整推論服務所需具備的項目，以及此版本未包含的內容，當中點名了 KV 快取系統、VE/Prefill/Decode 分離，以及跨資料平行副本的負載平衡。你得到的是運算路徑——核心、平行化、推測解碼、排程、結構化輸出。你得不到的是儲存與路由層，而這層能讓運算路徑在大規模運作時成本低廉。DeepSeek 說明了原因：這些元件與內部基礎設施緊密耦合，因此設計會以已公開的技術文章描述，而程式碼仍留在內部。

儲存庫裡實際上有什麼？

已發布的功能清單讀起來，像是對服務大型混合專家模型時各項瓶頸的一場導覽。其中包括 DeepSeek 先前釋出的核心函式庫：用於注意力機制的 FlashMLA、用於矩陣乘法的 DeepGEMM、用於專家平行通訊的 DeepEP，以及 TileKernels 和 DeepSelect。還有平行化方案：注意力部分以資料平行執行，並搭配平衡的上下文平行；MoE 那一半則以專家平行執行，並搭配專家平行負載平衡器。還有推測解碼堆疊 DSpark，其驗證長度由排程決定，而非固定不變。還有 SWA 有界重放，這是一種機制，可避免滑動視窗注意力快取在每次快取未命中時都強制進行完整重算。還有非同步批次排程、具確定性取樣的批次不變推論，以及受正規表達式、JSON schema 或 EBNF 約束的結構化輸出。

進入點刻意保持精簡。設定 DEEPINFER_ACCELERATOR 為 nvidia或 Ascend 對應值，並執行 build.sh之後，儲存庫隨附 examples/offline_inference.py，可端到端執行預設檢查點。 DEEPINFER_HF_MODEL_DIR 則可指向不同的權重目錄。已公布的基準測試是在四張 SM100 GPU 上量測 prefill、在 64 張 SM100 GPU 上量測 decode，這正是此引擎撰寫時所針對的部署規模，而非筆記型電腦等級的示範。

README 也說明了程式碼的來源，這點在閱讀前值得先知道。這個引擎最初主要建構於 vLLM 之上，並從 SGLang 與 TensorRT-LLM 汲取設計靈感。這樣的傳承反映在結構上——排程器、分頁注意力介面與取樣路徑，對讀過那些專案的人來說都會很熟悉——這也解釋了為何這個發布版本是某個服務堆疊的分支，而非從零撰寫的架構。DeepSeek 新增的部分，則是專屬於其自身模型的內容：分離式部署、搭配其平衡器的寬專家平行、滑動視窗重播，以及 DSpark。

它不包含什麼，以及為何那更重要

這三塊缺失的部分並不是小疏漏。每一塊都是引擎在正式承擔生產流量之前就必須存在的系統，而且各自以不同的方式代價高昂。

• KV 快取系統。 前綴重用是聊天工作負載中大部分成本節省所在，因為快取命中會取代一次預填。沒有快取儲存，每個請求都會重新計算其提示。DeepSeek 自己的文章描述了它使用的儲存方式：專用的 3FS 叢集，而非本機主機記憶體，正是為了讓任何預填機器都能命中任何前綴，且快取容量可以獨立於運算資源進行擴展。

• VE/Prefill/Decode 解耦。 README 指出，大部分引擎端功能已存在於發行版中；缺的是部署。將視覺編碼器、prefill 與 decode 解耦，可讓你依各階段自身的瓶頸調整規模，並將首 token 時間與 token 間時間分開控制。這是基礎架構決策，而非某個旗標。

• 跨資料平行副本的負載平衡。 DeepSeek 執行四個平衡器——預填充、解碼、視覺編碼器與專家平行——並在文章中描述這四個平衡器。這些路由邏輯都未隨附發布。少了它，副本叢集的表現只能取決於你放在前面的路由器，而樸素的輪詢路由器會破壞這個儲存系統原本旨在保護的快取命中率。

兩者合起來看，這項省略說明了這是哪一種產物。DeepInfer 是運算路徑的參考實作，其公開發布是為了讓核心與排程方面的工作成果能被檢視與重用，而不是讓你安裝後把流量導向的發行版。

硬體閘門才是真正的過濾器

DeepInfer 的目標平台是 NVIDIA SM100 與 Huawei Ascend 950。它沒有 Ampere 路徑，也沒有 Hopper 路徑，因此排除了現今大多數叢集裡的大多數 GPU。其餘工具鏈也同樣特定：僅支援 Linux、GCC 13 或更新版本、Python 3.12、NVIDIA 用 CUDA 13，Ascend 用 CANN 9.2。而且完全沒有發行版本——在 2026 年 10 月 21 日讀取時，該儲存庫沒有任何已發布的發行版本，所以沒有東西可下載，也沒有東西可鎖定版本。你得自行複製它，並針對自己的工具鏈進行建置。

這種組合對於一個受到如此多關注的開源發佈來說並不尋常，最好將其理解為對範圍的準確陳述，而不是疏漏。儲存庫中的核心是為特定指令集和特定互連而寫的；README 中的數字來自該硬體。將運算路徑移植到上一代，正是社群能迅速完成、工程組織卻無法承諾的工作。發佈後幾天內，GitHub 上就出現了針對較舊 NVIDIA 元件的第三方移植，這對需求是有用的訊號，但對於已公佈的吞吐量數字能否在移植後成立，則完全沒有訊號。

DeepSeek 實際採用的部署形態

架構說明能讓此儲存庫的假設變得清晰易懂。系統被拆解為視覺編碼器、預填充（prefill）與解碼（decode），以及專用儲存節點。預填充使用 2 到 8 的專家平行度，並搭配相應的資料平行度，選擇 HBM 允許的最小配置。解碼則相反：專家平行度與資料平行度為 64 到 128，DeepSeek 稱之為 Wide-EP，並使用可用 GPU 允許的最大配置。完全未使用張量平行與上下文平行。視覺編碼器每個執行個體使用一張 GPU，建議採用較便宜的 GPU，因為編碼器不是花錢的重點。

從這些數字可以推得合理的最小部署規模。一個 prefill GPU 和一個 decode GPU 就能運行，而實務上這兩個資源池的比例大約是一比一。但由於 decode 需要 64 個以上的 GPU 才能獲得專家並行（expert-parallel）的好處，所以最小有效單位是 64 個 prefill GPU 加 64 個 decode GPU。閱讀任何關於 DeepInfer 效率的說法時，要記住的就是這個數字：這些數字描述的是 128 GPU 的部署，而其中一半就是一個階段。

將預填充（prefill）與解碼（decode）拆分到不同資料中心，在技術上是可行的，因為 DeepSeek-V4.1-Flash 大幅壓縮了其 KV 快取，而 DeepSeek 自身的部署確實把推論節點放在不同但相鄰的資料中心。預算大約是每八張 GPU 需要 400 Gbps 的互連頻寬，而這份報告也坦率指出了可靠性方面的代價——建築物之間的光纖很容易被挖斷。

為什麼 decode 會分佈得這麼廣？

廣泛的專家平行化是設計中影響最深遠的單一選擇，而且很容易被誤解為一種擴展技巧。在混合專家層中，每個 token 只會接觸少數幾個專家，因此解碼步驟的成本主要取決於搬運專家權重與活化值，而非算術強度。將專家分散到 64 或 128 顆 GPU 上，可降低每顆 GPU 在每一步所貢獻的記憶體流量，從而提高每秒 token 數——前提是，這就是條件——各專家之間的負載保持平均。這正是專家平行負載平衡器的用途所在。

DeepSeek 的設定具體到可以直接照抄。就預填充（prefill）而言，每張 GPU 除了自己擁有的專家之外，還額外持有四個備援專家；統計資料以 100 步為窗口收集，且每 1,000 步重新分配專家，權重則透過 NVLink 共享記憶體在同一組內重新洗牌。測得的不平衡度——以最慢的 rank 除以平均值——在 EP4/DP4 配置下為 1.074，在 EP2/DP2 配置下為 1.045。就解碼（decode）而言，設定則拉長：每張 GPU 一個備援專家、1,000 步的統計窗口、每 10,000 步重新分配，測得的不平衡度為 1.090。兩者之間的差異正是重點。預填充面對的是突發且異質的工作負載，需要快速重新平衡；解碼面對的是穩定的工作流，可以承受較長的窗口，因此很少重新平衡，而且幾乎不為此付出代價。

路由端也具有相同的特性。預填請求會依總上下文長度分成四個層級——低於 16K、16 至 64K、64 至 256K，以及 256K 及以上——並根據各層級在前一輪運算需求中所占的比例，將引擎指派到對應層級。在單一 GPU 內，每個預填步驟的分塊大小並非固定：擬合出的二次成本模型會根據序列 token 數與已計算的前綴，預測一個步驟需要多久，而排程器則求解在剩餘時間內能容納 32,768 個 token 預算的最大分塊。解碼平衡器同時平衡兩個維度——請求數量和 KV 快取總長度——將短請求送往並行度低且快取長的 GPU，並將長請求送往快取小的 GPU。DeepSeek 自己對這一切能帶來多少效益的總結：大約可達到完美平衡的離線基準的 80%。

快取，以及那個三日之問

KV 快取位於專用的 3FS 叢集上，而不是本機主機記憶體中，而這項決定主導了其餘的儲存設計。資料以 10+2 糾刪碼儲存，因此每個編碼群組可承受兩個節點同時故障；讀取時會向群組內全部 11 個節點發出請求，只要收到任意 10 個回應就足以解碼。每個儲存節點上都執行垃圾回收 worker，並在超過水位後依 LRU 淘汰。建議的伺服器配備 20 顆各 30.73 TB 的固態硬碟，至少可維持 40 GB/s 的讀取與 5 GB/s 的寫入，容量設計為每台伺服器約可保留 24 小時的資料。實務上，叢集每張線上 GPU 約可提供 14.4 TB 的邏輯快取，實體容量則更大。

駐留策略正是取捨顯現之處。快取端沒有到期邏輯；TTL 設在儲存端，代理流量為三天、聊天機器人流量為七天，而叢集擁有約 100 PB 的固態儲存。之所以有這種區分，是因為聊天機器人流量的命中分布有重得多的長尾——少量快取會被反覆讀取許多次，因此失去它對整體命中率造成的代價，比其容量占比所暗示的更高。DeepSeek 測得，將聊天機器人保留期縮短至三天的代價，是快取命中率的 0.5% 到 1%。這個數字雖小，卻恰好代表大量被重新計算的預填充。

滑動視窗注意力會取得一個採用不同規則的獨立快取。SWA 快取不會進入分頁區塊；每個序列在主機記憶體中佔用一個固定大小的槽位，而對 DeepSeek-V4.1-Flash 而言，所儲存的層是前 20 層。只有該區域會持久化——20 層 × 134 個 token × 528 位元組，以 MXFP8 格式計算，每個序列為 1,415,040 位元組。不會有任何資料送到儲存叢集；它會留在產生它的機器記憶體中，並由記憶體內目錄記錄哪台機器持有哪些資料，而跨機器命中時則透過 400 Gbps VLAN 將其拉回。

產生頭條數字的兩項機制

有界重放是兩者中較有趣的一種，因為它把無界成本變成固定成本。通常，滑動視窗快取未命中意味著要從頭重新計算整個視窗，而成本會隨上下文長度與層數增長。DeepSeek 則只重新計算最近的 128 個 token，並將注意力視窗截斷到該區段，以固定代價產生近似的 SWA 快取。在編碼器端，這使前綴快取命中長度與 SWA 快取完全解耦：若 SWA 快取缺失，則重放命中前綴的最後 128 個 token，而區塊快取則原封不動地重複使用。

解碼器端才是節省幅度最大的地方。在這個架構中，解碼器各層的區塊快取是由最後一層編碼器的隱藏狀態投影而來，因此只有解碼器的 SWA 快取需要逐層計算——而若要精確重建它，就代表每次 prefill 都得把最後 2,560 個 token 送進 20 層解碼器。改成重放 128 個 token，並只將結果用於解碼、不讓它進入前綴快取，總 prefill 計算量幾乎減半。這單一改動的價值勝過大多數 kernel 最佳化，而且這是只有擁有模型架構的團隊才做得到的事。

DSpark 的貢獻較小，也較為常規。草稿 token 的接受機率會因請求和位置而異，因此每一步都固定驗證五個草稿，會把運算浪費在終將被拒絕的 token 上。置信度頭會預測每個草稿 token 的接受率，而排程器會依預期回報對草稿排序，只驗證能讓吞吐量最大化的前綴。在生產環境中，草稿模型仍會每一步產生五個 token；驗證數量會從 5.00 降到 3.2 到 4.4 之間，約減少 30%，而接受長度幾乎不變——3.29 對上 3.20。根據 EP64/DP64 基準測試資料，在每個 rank 約 60 個並行序列時，這相當於吞吐量提升 4% 到 7%。正好在 60 時，每個 rank 的吞吐量會從每秒 13,730 個 token 增加到 14,466 個 token。低於約 16 個並行序列時，這項技術會造成小幅淨損失，這點在低流量部署採用前值得知道。

155兆這個數字意味著什麼

這次發布最常被引用的數字，是單一叢集每天服務 155 兆個 token，並在谷底定價下達到每 GPU 小時 38 美元的整體營收。這兩個部分都是廠商自行報告，且都不是你能重現的基準測試；但這並不代表它們不有趣——每 GPU 小時的營收數字，與吞吐量數字是截然不同的一類主張，因為它把使用率、定價與快取命中率壓縮進同一行。它也是最可能被引用時省略限定條件的數字，所以這些限定條件值得寫下來：單一叢集、谷底定價、是營收而非成本，以及涵蓋 prefill、decode 與 vision encoder 的彙總。

有兩項較小的揭露更直接有用。公開儲存庫中的 FlashMLA 解碼核心缺少內部版本所具備的一項手工調校組合語言最佳化，這使其單獨執行時慢 5% 到 10%；DeepSeek 表示端到端效能最多相差 5%。此外，用於推測解碼的內部草稿模型比已發布的版本更新，效能差異被描述為很小。這兩項陳述都對第三方透過複製程式碼能達到多少已發布效能設定了預期，而答案是：大部分都能達到，前提是硬體相符。

該儲存庫目前的情況

上方截圖拍攝於 2026 年 10 月 21 日，顯示頁面讀數為 1.63 萬顆星。同日查詢 GitHub API，傳回 16,590 顆星、1,649 個分支與 176 個開啟中的問題，且問題功能已停用，討論則改導向 GitHub Discussions。此後星數持續攀升，因此請把這裡的每個數字都視為時間戳記，而非程式碼本身的屬性。不到一週就出現如此規模的流量，更能說明人們對 DeepSeek 服務堆疊的興趣，而非程式碼已準備就緒；而零次發布的計數則說明了其餘的一切。

如果你正考慮自己運行它

誠實的總結是，DeepInfer 值得仔細閱讀，卻難以操作。四個問題能告訴你它是否適合。

• 您是否擁有 SM100 或 Ascend 950？工具鏈中其餘的一切都取決於這一點。沒有正確的加速器，已公布的數字無法轉移，而社群移植版本在生產規模下尚未經過驗證。

• 你能在單一通訊網域中執行 64 張解碼 GPU 嗎？ 寬專家平行不是可以略過的最佳化；它是解碼路徑在設計時所依據的組態。低於那個規模，你執行的是名稱相同、實則不同的系統。

• 您是否已經擁有前綴快取？ 若沒有，您就是把 DeepInfer 的運算路徑，拿來與一個內建前綴快取的競爭堆疊相比；這樣的比較結果會比其設計應有的表現更差。

• 你有餘力自己撰寫路由層嗎？ 預填充分桶、解碼負載平衡與專家重新指派都已有足夠清楚的描述可供重新實作，而重新實作需要數週的工作，儲存庫並不會代你完成。

如果您不想擁有上述任何項目

對多數團隊而言，實際的問題不是如何部署 DeepSeek-V4.1-Flash，而是要在哪裡呼叫它。這款模型可透過相容的 API 使用，無須建置 128-GPU 叢集，也不必重新實作負載平衡器；而它就是本文一直在描述其架構的同一款模型——相同的上下文處理、相同的結構化輸出行為，且無須進行拆分式部署的工作。

要做的比較，不是抽象地判斷哪個引擎比較快，因為已公布的數字是廠商自行回報、在大多數讀者沒有的硬體上測得的數據。而是要判斷：這個工作負載是屬於「3 天快取 TTL 與 64 GPU 解碼集區會改變價格」的那一類，還是屬於「每隔幾秒透過 API 送出一個請求，就比上述任何操作都更便宜」的那一類。對於第二種情況——也就是大多數情況——該用的 DeepInfer 用量是零，該讀的 DeepInfer 資料則是全部。若你想要的是端點，請從 DeepSeek V4.1 Flash 模型頁面 開始；若你想知道端點在做什麼，請從儲存庫的 README 開始。