DeepSeek DeepInfer 開源發布揭示推論引擎，服務元件仍屬內部
DeepSeek 已發布其內部推論框架 DeepInfer，但完整生產服務所需的多個元件仍未納入公開套件。這次 DeepSeek DeepInfer 開源發布支援 DeepSeek-V4.1-Flash，並公開了用於運行該公司模型的軟件。它亦突顯了一項重要分別：取得推論引擎，並不代表能自動重現圍繞它運作的服務。
DeepSeek 隨附的文件描述了一套建基於專用硬件、協調排程及可重用運算的基礎設施。公開發布提供離線推論，意味開發者可在毋須部署完整網上服務的情況下產生輸出。快取基礎設施、分離式服務階段，以及部分負載平衡功能，仍需額外整合。
這條界線的重要性，遠超過簡單的開源與封閉標籤。DeepInfer 借鑑 vLLM、SGLang 及 TensorRT-LLM；這些成熟的推論專案早已處理部署挑戰。DeepSeek 正將自己的實作貢獻至這個共享領域。對基礎設施團隊而言，眼前的問題是哪些工程決策可移植至自身環境，哪些則依賴 DeepSeek 僅作說明的系統。
DeepSeek DeepInfer 開源發布實際包括甚麼
DeepSeek 發布的是經過大量最佳化的模型執行引擎，而非其託管服務的完整複製版本。
inference engine 文件指出，支援的模型為 DeepSeek-V4.1-Flash。其預設 checkpoint，即模型已儲存的版本，為 DeepSeek-V4.1-Flash-1017。發布內容列出 NVIDIA SM100 圖形處理器及 Huawei Ascend 950 神經處理器為支援硬件。
這些細節界定了最初的目標用戶。這是面向使用所列模型及加速器平台團隊的基礎設施軟件。文件並未確立它對每款 DeepSeek 模型、舊款顯示卡或通用運算環境均提供同等支援。
DeepInfer 包括經最佳化的核心程式，即在加速器上執行數值運算的小型程式。它亦包括協調模型執行及輸出選擇的執行階段。這些層次決定模型指令能如何高效地在硬件上轉化為有效工作。
已發布的功能清單不止數值運算程序。它包括分散式執行，即將推論工作分配至不同處理器，以及協調傳入工作與裝置執行的排程功能。它亦包括結構化輸出，可限制生成文字遵循指定格式。
這些能力之所以重要，是因為提供模型服務不只涉及載入其權重，即訓練期間學得的數值。請求會競逐記憶體和運算資源。它們的輸入長度各異，輸出完成時間亦不同。引擎必須管理這些差異，避免昂貴硬件閒置。
DeepSeek 以 Apache 2.0 發布 DeepInfer。該授權條款界定框架程式碼的使用條件；並不免除另行核對模型及相依套件條款的需要。機構仍須評估其計劃部署的完整軟件套件。
未包含的部分同樣明確。README 列出 KV 快取系統、分離的視覺編碼、提示處理及生成服務，以及跨副本的負載平衡。KV 快取會儲存中間注意力運算，讓後續處理重用早前的工作。
據 DeepSeek 所述，這些服務所需的部分引擎功能已經存在。然而，公開套件並未包括其完整部署。這項區別可避免「完全開源」一詞成為對整個營運平台的不準確描述。
因此，這次發布改變了外界可檢視及運行的內容。它公開了 DeepSeek 推論決策的可運作實作，並附有範例及基準測試腳本。然而，這並不表示外部團隊只要建置該儲存庫，便可重現 DeepSeek 的生產服務。
對尋求理解 DeepSeek DeepInfer 的讀者而言，這是最重要的起點。程式碼發布確實存在，範圍亦相當可觀，而其文件所述的界線仍是整個故事的一部分。
基礎設施團隊取得程式碼，同時承接整合決策
眼前壓力落在評估自託管 DeepSeek 的團隊，因為他們現在多了一個實作可對照自身營運要求進行評估。
模型供應商的內部引擎，與通用模型服務框架提供不同的參考點。DeepSeek 可公開圍繞其模型架構及已觀察工作負載設計的最佳化措施。外部營運者可檢視這些選擇，而非從託管服務的行為推測。
這改變了技術評估方式。調查回應緩慢的團隊，可在公開實作中檢視排程、通訊及輸出處理。它能分辨模型執行問題，與周邊應用程式引入的問題。
不過，這個機會也帶來工作。團隊必須判斷已發布的硬件要求是否符合可用容量，亦須決定如何把引擎連接至請求處理、儲存、監察及復原系統。
以一個示例性的企業文件助理為例，它反覆收到一組共用的技術手冊。其提示包含重疊資料，而個別問題及答案長度各異。這是一個部署情境，並非有文件記錄的 DeepInfer 客戶例子。
引擎會影響每個請求的執行效率。周邊快取系統會影響重複的文件內容是否需要重新運算。請求路由則會影響當流量在不同機器之間轉移時，有用的已儲存運算是否仍可存取。
引擎基準測試只涵蓋這類體驗的一部分。員工亦會留意答案開始前的等待時間、生成期間的中斷，以及需求上升時的故障。這些結果取決於數值執行以外的服務元件。
同樣的分別亦適用於採購。考慮自託管的買方，需要有關營運責任、硬件供應及應用程式相容性的證據。公開程式碼的存在擴大了可供評估的選項，但並未解決這些問題。
DeepSeek 的部署說明亦顯示基礎設施擁有權何以重要。其內部設計協調儲存與運算，而非將兩者視為獨立的最佳化目標。重現這種安排，需要就網絡、儲存容量及故障處理作出決策。
對較小團隊而言，採用部分構想或元件，可能比重建整套架構更實際。這是由發布範圍得出的分析性含意，並非由獨立測試確立的部署建議。
因此，相關的競爭比較不應只看原始生成速度。即使另一項實作展示出吸引人的最佳化，能配合現有營運的框架仍可能較合適。工程投入、可靠性及支援的工作負載，都會影響決策。
這亦是技術知識管理變得有用之處。團隊可把基準測試設定、事故發現及部署假設保存在一個可搜尋的知識庫中。這份紀錄有助避免日後的比較混合不相容的測試條件。
DeepSeek DeepInfer 開源發布讓更多實作可供審視。基礎設施團隊仍須自行判斷採用甚麼、整合甚麼，以及其應用程式需要哪些證據。
架構取決於工作如何在系統中流動
DeepInfer 的重要性在於協調執行決策，而其價值取決於硬件組織及工作負載形態。
DeepSeek 的部署架構將提示處理與答案生成分開。Prefill 處理輸入提示；decode 生成後續輸出 token，即模型讀取及產生的單位。這些階段對硬件提出不同要求。
內部架構亦分離視覺編碼，即將影像轉化為語言模型可處理的表示形式。專用儲存支援重用早前的運算。架構圖描述了這個更廣泛的生產系統，包括未納入初始公開服務套件的元件。
分離不同階段，讓營運者能按照不同工作負載分配資源。即使答案保持簡短，長輸入也可帶來大量 prefill 需求。輸入處理完成後，長答案仍可持續產生 decode 需求。
DeepSeek 亦描述專家平行化，即將混合專家模型的專用神經元件分配至不同處理器。其首選生產設定在 prefill 和 decode 之間有所不同，反映每個階段在運算、記憶體存取及通訊上的不同平衡。
該公司的 Wide-EP 討論比較了跨 8 及 64 個處理器的專家平行化。更大的群組會改變專家運算及記憶體流量的分配方式，同時令通訊效率及均衡工作分配成為結果的核心。
這些考量說明，單看裝置數量並不足夠。透過高速本地連結接駁的群組，與經較慢網絡通訊的機器表現不同。硬件拓撲，即裝置及其連接的排列方式，應納入任何有意義的比較。
DeepInfer 亦實作推測式解碼，即提出草擬 token，再由主模型核對。DeepSeek 的 DSpark 機制利用置信度估算，決定多少草擬工作值得驗證。目標是避免將驗證運算花在不太可能的候選項上。
這是一項帶有可量度取捨的排程決策。核對更多草擬 token，並不會自動產生更多獲接納的輸出。有用的結果取決於接納行為，以及硬件處理驗證工作負載的能力。
另一項最佳化會將處理器排程與加速器執行重疊。中央處理器在加速器處理目前運算時準備接下來的工作。DeepSeek 在解釋這種方法時，明確歸功於既有的 SGLang 及 NanoFlow 實作。
這項歸屬十分重要。DeepInfer 是對既有推論工程體系的補充，並承認其影響來源及共用技術。這次發布並未證明每項列出的最佳化均由 DeepSeek 首創。
該引擎亦提供控制項，旨在令不同請求批次下的結果可重現。其文件將批次不變推論及確定性取樣功能限制於 NVIDIA。確定性取樣需要指定設定，包括固定的序列種子。
這些條件對評估團隊在軟件變更後比較輸出十分重要。README 中有某項功能，並不代表兩個受支援的硬件系列均具備完全相同的可用性。因此，從架構角度解釋 DeepSeek DeepInfer，是一個關於協調各項限制的故事，而非通用的效能捷徑。
deepseek-recipe 處理應用程式與模型之間的邊界
deepseek-recipe 處理協定及 token 轉換，這與快速執行模型是另一個問題。
DeepSeek 在公布引擎時，同時推出以 Rust 編寫、提供 Python 綁定的協定轉換程式庫。這些程式庫會將請求轉換為共用的對話表示方式，然後產生模型提示詞，並把生成輸出轉換為受支援的回應格式。
配套專案的 README 早於 DeepInfer README 在 10 月 20 日修改前，已於 10 月 19 日更新。因此，兩者配套出現，不應被理解為兩個儲存庫都在完全相同的時間首次公開。可確認的是，DeepSeek 在其推論部署說明中將兩者一併介紹。
deepseek-recipe 支援轉換 Messages、Chat Completions 和 Responses 請求格式。這些都是應用程式介面格式，即應用程式用來與模型服務交換請求及輸出的慣例。支援這些格式有助將既有應用程式接入推論後端。
兩者的邊界仍然清晰。呼叫方負責模型推論、工具執行及 HTTP 傳輸，即承載請求與回應的網絡機制；deepseek-recipe 則負責轉換及剖析，並不提供完整服務。
這種分隔對要求模型使用工具的應用程式尤其重要。工具呼叫是針對外部操作或函數的結構化請求。轉換其表示方式，並不會執行該操作、授權該操作，或確認其參數是否正確。
同樣地，格式相容性並不代表模型行為等同。應用程式可以收到熟悉的回應結構，卻觀察到不同的回答質素或推理行為。DeepSeek 聲稱可與其官方服務對齊，仍須針對應用程式實際使用的特定功能進行測試。
該專案亦處理串流輸出，即在生成進行期間逐步傳回結果。一段輸出片段可能在一個字元、分隔符號或工具參數的中途結束。正確的剖析必須保留足夠狀態，才能解讀後續片段，同時不損壞先前內容。
DeepSeek 的說明描述了處理這些邊界的機制。這類工作不如加速器效能般顯眼，但應用程式開發者會直接面對其後果。即使推論引擎能正確生成 token，格式錯誤的串流仍可能令整合失效。
token 轉換設計亦將控制標記與一般文字區分開來。控制標記會告訴模型對話中特定部分從何處開始或結束。DeepSeek 表示，使用者提供而看似這些標記的文字，在編碼期間仍會被視為一般內容。
這處理的是一項特定的序列化邊界。不應將其描述為針對提示詞注入——即透過不受信任內容重新導向模型的嘗試——的通用解決方案。模型仍可能遇到以一般語言表達的誤導指令。
deepseek-recipe 的文件亦就結構化輸出作出另一項有用區分。透過請求轉換傳遞格式限制，本身並不會在生成過程中強制執行該限制。推論後端必須套用相關的解碼控制措施。
該專案採用 MIT 授權條款，而 DeepInfer 採用 Apache 2.0。兩者共同呈現部署路徑中互補的層面：一個執行模型；另一個協助應用程式正確地與模型溝通。
生產環境聲稱與基準圖表回答的是不同問題
DeepSeek 的內部營運數字描述其自家系統，而已發表的基準測試則描述特定測試配置。
該公司表示，單一生產集群每日服務 155 萬億個 token。這是供應商自行報告的營運數字，並非基於公開版本而獨立重現的結果。不應將其視為第三方部署所承諾的容量數字。
部署說明描述了該集群周邊的基礎設施，包括快取儲存、請求路由及分離的處理階段。其中多個系統並未包含在公開套件中。若將生產總量視為僅屬引擎的基準測試，便會抹去這些依賴關係。
公開的 prefill 圖表使用 4 個 NVIDIA SM100 處理器。decode 圖表則使用 64 個，而每項測試均維持於單一 scale-up domain，即透過高速本地互連連接的一組系統。討論其結果時，這些配置應一併列出。
圖表所量度的關係亦不同。Prefill 比較未快取輸入吞吐量與延遲，即處理工作的所需時間。Decode 則比較輸出吞吐量與每位使用者的生成速度。某部署可偏重整體容量，同時為每位使用者提供不同的體驗。
這避免了簡單的「更快」結論承載過多意義。有效的比較需要使用相同的模型 checkpoint、工作負載、數值設定、硬件配置及相關服務限制。否則，結果可能反映不同的營運取向，而非更佳的引擎。
相同的謹慎態度亦適用於 Wide-EP 圖表。它考察了在所提供配置下的一項特定並行化比較。它並不能證明每個更大規模的部署均可同樣受益，亦不能證明任意機器之間的通訊都承受相同的開銷。
DeepInfer 的 README 提供透過隨附 sweep script 重現其基準測試的方法，該腳本會跨不同配置執行測試。這改善了可檢視性。本報道並未獨立執行這些測試，因此圖中的效能仍應歸因於 DeepSeek。
中立的競爭比較亦需要納入既有推論專案。DeepSeek 表示，DeepInfer 最初主要建基於 vLLM，並從 SGLang 和 TensorRT-LLM 汲取靈感。這項確認意味著，不應將此發布描述為對周邊生態系統的孤立替代方案。
SGLang serving framework 處理涵蓋更廣泛模型及硬件配置的模型服務。其範圍讓營運者有理由在單一模型的效能圖表以外評估它。相關選擇取決於每個部署的要求。
因此，DeepInfer 與 SGLang 的比較，不能只比對一個標題吞吐量數字。它需要在可比較條件下考慮應用程式行為、整合工作、受支援硬件及故障復原能力。已核實的材料並未確立一個獨立勝方。
引擎內的專家負載平衡，與跨服務副本的請求平衡之間亦有分別。此發布包含專家並行負載平衡功能，同時排除了 README 所列的完整副本層級服務系統。簡單地說「缺少負載平衡」會過於籠統。
DeepSeek DeepInfer 開源發布支援更仔細審視這些邊界。它並不足以將每項內部生產聲稱納入對公開套件的預期。最有力的評估仍應清楚指出：量度了甚麼、發布了甚麼，以及哪些事項仍未獲驗證。
三項發展將顯示此發布能走多遠
下一批有用證據將依次涉及可重現性、服務整合及應用程式行為。
首先，留意具備完整配置的獨立基準測試重現結果。一份有用的報告應列明確切的程式碼修訂版本、模型 checkpoint、硬件連接、工作負載及生成設定，亦應區分引擎量度與完整的線上部署。
此類報告會加強外部團隊能否從已發布實作獲得相近結果的信心。若出現具意義的差異，應進一步調查，而非立即下結論。建置設定、輸入長度及並發量——即同時活躍的請求數目——均可改變觀察到的效能。
最具資訊價值的重現結果會同時公布整體吞吐量及個別回應時間。服務可以處理更多總工作量，同時令特定請求等待更久。同時報告兩者，有助讀者了解某項最佳化是否適合互動式應用程式，還是主要有利於批次處理。
其次，留意周邊服務元件的公開範圍。DeepSeek 的 README 指出，快取基礎設施、分離的服務階段及副本負載平衡，是此發布以外的要求。未來若有程式碼或文件化整合能處理這些缺口，將減少採用者預期需要投入的工作。
這將加強把 DeepInfer 視為較完整部署基礎的理據。若這些元件仍然維持內部使用，引擎對檢視及實驗仍有價值；其採用仍會更高度依賴每位營運者既有的基礎設施。
維護證據亦是該訊號的一部分。能反映實際行為的文件、清晰的相容性要求，以及針對已報告問題的修正，有助判斷外部人士能否營運該軟件。公開可用只是這段關係的開始，而非其最終深度的證據。
第三，留意圍繞 deepseek-recipe 的應用程式層級相容性測試。有用的結果會檢驗串流邊界、工具參數、推理內容及強制輸出格式。這些測試將顯示共用轉換層能否減少不同部署環境之間的實際差異。
成功的測試會加強 DeepSeek 的說法：第三方服務可與其官方處理行為對齊。失敗則會指出轉換支援與後端實作在哪些方面出現分歧。兩種結果均不應被混同為對模型智能的一般判斷。
若要評估 DeepInfer 與 SGLang，這些發展比儲存庫關注度提供更有用的基礎。獨立量度處理效能聲稱；服務整合處理營運工作量；應用程式測試則處理既有軟件能否如預期運作。
未來數月的核心問題，是 DeepSeek 所記錄的生產方法有多少能在公司以外重現。這個問題同時尊重發布的兩面：實質的公開工程，以及清楚說明的基礎設施邊界。
在採用 DeepSeek DeepInfer 開源發布前，請比較其已記錄的範圍與使用者實際所需的服務。閱讀引擎要求時，亦應參閱部署說明，然後識別現有平台已提供哪些缺失元件。讓效能聲稱始終與其硬件及工作負載條件相連。對應用程式團隊而言，應如審視生成速度般仔細檢查協定行為，特別是在串流和工具呼叫支援關鍵工作流程時。記錄哪些結論來自已發布程式碼、公司量度或自家測試；然後隨著獨立重現結果及整合方案出現，再重新檢視這些結論。真正有用的決策，是判斷此發布是否為你的特定部署消除了足夠的不確定性及工程工作，值得作更深入評估。
