DeepInfer 的限制：KV Cache、PD 與誰能跑
發佈標題說 DeepSeek 開源了它的推理引擎。DeepInfer README 裡真正關鍵的一句是：完整的 V4.1-Flash 推理服務還需要三樣本次發佈沒有的東西。以下說明它們是什麼、為何重要，以及打造它們的代價。
DeepInfer 是離線推理引擎，不是託管 API，也不是模型；本次發佈不包含完整線上服務所需的 KV cache 系統、prefill/decode 分離，或資料平行副本之間的負載平衡。它服務的是 DeepSeek-V4.1-Flash，而這道缺口正是 README 自己列出來的。
三個缺席的元件
1. KV cache 系統
每個請求都會建立 KV cache：模型已為 prompt 算好的 key 與 value。若相同的 prefix 再次出現——很長的系統提示、多輪 agent 歷史、共用文件——重用快取就能省下重算。在大規模下，prefix 快取命中率是影響成本與 time-to-first-token 最大的槓桿之一。
真正的 KV cache 系統不是 GPU 記憶體裡的一個字典。它需要：
- 具備淘汰與 TTL 的儲存階層（HBM、主機記憶體、SSD）；
- 能跨機器尋找 prefix，而不只是本機；
- 與運算重疊的傳輸路徑；
- 容錯，因為運算節點比儲存節點更常故障；
- 不與負載平衡器互相拉扯的路由策略。
DeepSeek 的生產設計可以讓人感受規模：專用 3FS 叢集、約 100 PiB SSD、10+2 erasure coding、agent 流量 3 天 TTL 與 chatbot 流量 7 天 TTL、每張 GPU 約 14.4 TB 邏輯 KV，以及每 8 張 GPU 約 400 Gbps 互連。這些都不在本次發佈中。
2. VE / Prefill / Decode 分離
本次發佈說「多數必要的引擎功能已實作」，但完整的分離方案並未包含。在生產環境中，視覺編碼器、prefill 資源池與 decode 資源池跑在各自獨立的機器上，各有擴縮策略。難處在交接：在資源池之間搬移 KV cache、把請求路由到正確的 prefill 引擎，並讓 decode 的佔用率保持平衡。
少了這些，你仍可跑離線批次。但你無法重現 DeepSeek 線上服務的形態。
3. 資料平行副本之間的負載平衡
DeepSeek 為 prefill、decode、視覺編碼器與專家平行各用一個平衡器。prefill 平衡器依上下文長度把請求分級，再依剩餘運算配額路由；decode 平衡器同時考慮請求數與 KV 總長度；專家平衡器則在 GPU 之間搬移熱門專家。Q&A 說，結果大約達到完美平衡的離線 benchmark 的 80%。
最後這個數字是很好的現實檢驗：即使是 DeepSeek 的生產系統，也只達到離線 benchmark 吞吐量的約 80%。簡單的輪詢路由器不太可能做得更好。
如果你下載 DeepInfer 並執行 examples/offline_inference.py，你跑的是一個帶有 DeepSeek kernel 與排程的批次引擎，而不是 DeepSeek 的服務。差別就是上面那三塊——再加上任何服務都需要的 API 層、驗證、配額、計費與可觀測性。
界線為何畫在這裡
2025 年 4 月，DeepSeek 解釋過為何不開源完整推理引擎：程式碼是舊版 vLLM 大幅修改後的分支，與內部叢集管理耦合，團隊也沒有餘力維護大型開源項目。當時的計畫是抽出獨立函式庫，並把優化回饋上游。
DeepInfer 是下一步，不是政策大轉彎。它開放了運算與排程路徑——kernel、平行、推測、快取復原、結構化輸出——並保留與內部基礎設施綁得最緊的部分：儲存系統、跨機器分離，以及生產負載平衡器。
這是一條連貫的界線。它也意味著「開源的生產引擎」這個說法需要加個限定：引擎是開放的，圍繞它的服務不是。
誰真的能跑
DeepInfer 支援 NVIDIA SM100 GPU 與華為 Ascend 950 NPU，但 DeepSeek 公布的效能圖只涵蓋 NVIDIA 硬件。這不代表 Ascend 不受支援，而是 Ascend 在公開資料中沒有被量測。
| 你是… | 能用嗎？ | 需要什麼 |
|---|---|---|
| 有 SM100 GPU 的雲端供應商或實驗室 | 可以，用於離線推理與自訂服務 | SM100 叢集、Linux/CUDA 13/Python 3.12 建置，加上自建的 KV cache 與負載平衡層 |
| 擁有 Ascend 950 NPU 的維運者 | 原則上可以 | CANN 9.2 建置；效能與穩定性請自行驗證——DeepSeek 沒有公布 Ascend 吞吐量數據 |
| 能取得上述任一硬件的效能工程師 | 可以，當作參考實作 | 讀 kernel 與排程器；跑小型離線實驗 |
| 今天就要 OpenAI 兼容 API 的團隊 | 不能直接用 | 改用已提供 API 層的服務框架，或在 DeepInfer 之上自行打造 |
| 要服務其他模型的團隊 | 不行 | 只支援 V4.1-Flash |
| 只有消費級 GPU 的愛好者 | 不行 | 列出的目標是 SM100 / Ascend 950；本機 V4.1 實驗用的是獨立的量化項目 |
你得自己建什麼
若想把 DeepInfer 變成服務，請為以下項目編預算：
- KV cache 服務： prefix 比對、分層儲存、跨機器傳輸、TTL/淘汰、容錯。
- Prefill/decode 路由： 分離的資源池、KV 交接、容量規劃、自動擴縮。
- 負載平衡： prefill 依運算配額與上下文長度；decode 依請求數與 KV 長度；專家重新平衡。
- API 層： Chat Completions / Responses / Messages、串流、工具呼叫、結構化輸出、錯誤處理。
- 多租戶與維運： 驗證、配額、計費、速率限制、追蹤、指標、日誌、金絲雀部署。
- 評測： 在你真實工作負載下的品質、延遲與成本回歸測試。
DeepSeek 的 deepseek-recipe 對 API 層的協定／分詞部分有幫助。它不提供伺服器、驗證、計費或 KV cache。
替代方案，不選邊
如果你的目標是服務 V4.1-Flash，DeepInfer 不是唯一的路。正確選擇取決於你已經在維運什麼，以及你需要控制什麼。
| 選項 | 它給你什麼 | 要確認什麼 |
|---|---|---|
| vLLM | 成熟的服務堆疊，模型支援廣，具 OpenAI 兼容 API；其部落格描述了 V4.1-Flash 優化 | 公布的優化是否對得上你的硬件與工作負載 |
| SGLang | 高效能執行環境，有自己的 V4.1-Flash kernel 工作；項目回報在 4×GB300 上、BS=1 搭配 DSpark 可達 873.63 tokens/s | Benchmark 條件；這不是與 DeepInfer 的比較 |
| TensorRT-LLM | NVIDIA 的服務堆疊，在 NVIDIA 硬件上表現強 | 模型支援與引擎建置複雜度 |
| LMDeploy | InternLM 的服務工具組；有 DeepSeek V3/R1 與 PD 分離的文件；透過 PyTorch 引擎提供 OpenAI API 與 Ascend | V4.1-Flash 支援、引擎選擇（TurboMind 或 PyTorch）與硬件 |
| TGI | Hugging Face 的服務工具組，具 OpenAI 兼容 Messages API | 已進入維護模式；不要假設會有新的 V4.1-Flash 支援 |
| Xinference | 多模型平台，具 OpenAI API、function calling、分散式 worker 與多種後端 | 哪個後端能服務 V4.1-Flash，以及是否支援該架構 |
| NVIDIA Dynamo | 位於 vLLM/SGLang/TensorRT-LLM 之上的編排層：PD 服務、KV 感知路由、KVBM | 它不是引擎；V4.1 支援取決於後端 |
| llama.cpp / Ollama | 量化模型的本機與邊緣執行環境；適合桌面與原型開發 | 不是 V4.1-Flash 的資料中心引擎；模型支援與記憶體是不同問題 |
| MLC-LLM | 基於編譯器的執行環境，涵蓋 NVIDIA、AMD、Apple、Intel 與行動裝置 | 要支援 V4.1 需要兼容的編譯模型 |
| DeepInfer | DeepSeek 源自生產環境的 kernel 與排程，專為 V4.1-Flash | 缺席的服務層；SM100/Ascend 950 硬件 |
我們不對這些方案排名。vLLM 與 SGLang 已有 API 層與廣泛採用；DeepInfer 有 DeepSeek 的生產調校與更窄的範圍。下週就要 API 的團隊，不該從建 KV cache 服務開始。
決策指南
- 用 DeepInfer，如果你有 SM100 或 Ascend 950 硬件、想研究或重現 DeepSeek 的服務優化，並且準備好自己建服務層。
- 用 vLLM/SGLang，如果你現在就要能服務的 API、需要廣泛的模型支援，或不想自己維護 KV cache 與路由堆疊。
- 再等等，如果你需要 Ascend 效能數據、與生產環境一致，或 DeepSeek 官方支援的線上服務路徑。
- 別用，如果你只有消費級 GPU、需要其他模型，或期待一個開箱即用的 OpenAI 兼容端點。
DeepInfer 是一次紮實的引擎發佈，界線也畫得誠實。價值在程式碼與生產筆記；風險在於把引擎當成服務。先讀 README 的「不包含」清單，再讀 benchmark 圖表。