DeepSeek的AI為什麼這麼便宜？這次，它把一部分省錢的門道公開了，同行也能拿去用。
10月20日，DeepSeek開源了自研推理框架DeepInfer。這套軟體支撐著V4.1 Flash的大規模運行，負責給晶片派活，讓一批批提問盡快得到回答。開發者可以免費使用、修改這些程式碼，也可以將其用於商業服務。
此前，開發者已經能下載DeepSeek的模型，但把同一個模型搬回自己的機房，不代表就能跑出官方那樣的效率。一段反覆出現的提示詞，要不要每次從頭算？大量使用者同時提問，怎麼安排任務，才能少讓晶片空等？這些環節處理得好不好，最後都會體現在算力和電費帳單上。DeepSeek這次公開的程式碼和部署文件，就介紹了它如何省下這些開銷。
這套框架同時支援輝達SM100和華為昇騰950晶片，最先用得上的是自己部署模型的企業和雲廠商。不過，支撐完整線上服務的快取管理、流量分配等元件，目前尚未完整開源。想把模型跑得像官方一樣又快又省，外部團隊還得補齊這些配套系統。
模型是菜譜，還要有個忙得過來的後廚
技術博主寶玉用“菜譜和後廚”來解釋這次開源：模型檔案好比菜譜，推理框架則負責接單、排隊和安排計算。同樣的菜譜，交給不同的後廚，一小時能接多少單、客人要等多久，可能很不一樣。
運行AI也會遇到類似的問題。有人只問一句話，有人上傳一份長文件，還有智能體一輪接一輪地呼叫模型。怎樣把這些請求安排到不同晶片上，既能多處理一些任務，又不讓使用者等得太久，是推理框架要解決的事。
DeepSeek此前已經公開過不少相關工具。2025年2月的開源周，FlashMLA、DeepEP、DeepGEMM等項目陸續放出，分別處理注意力計算、跨裝置通訊和矩陣運算。此後，TileLang等工具又讓開發者能更方便地編寫適配晶片的計算程序。
這些元件擅長各自的工作，放到一起，還需要軟體把它們組織起來。DeepInfer將多項底層最佳化整合進推理引擎，外部團隊可以看到，它們在V4.1 Flash上如何配合運行。拿到模型權重之後，開發者多了一套來自模型廠商自身的部署實現可供參考。
少算重複的內容，少讓晶片空等
模型上線後，每天的提問、寫程式碼和智能體任務，都會不斷產生計算開銷。對提供服務的公司來說，同樣一批硬體能處理多少請求，會直接影響每次呼叫的成本。
DeepInfer的程式碼和配套部署問答，披露了幾種減少這些開銷的辦法。
先看答案是怎麼生成的。模型通常逐個生成token，前一步完成後，才繼續下一步。DeepInfer支援的投機解碼，會先用輕量的“草稿手”預測後續內容，默認最多生成5個草稿token，再讓主模型批次核對；能接受的留下，不能接受的重新生成。
核對草稿也要花算力。DSpark會預測每個草稿token被接受的機率，優先把核對工作安排給更有希望被採用的內容，減少白忙一場的計算。
按DeepSeek的部署問答，相比每步固定核對5個草稿token，動態核對讓每步檢查的數量減少約30%，平均被接受的長度基本不變。這裡省下的是核對量；按官方基準資料估算，在接近實際生產並行量的配置下，這項調整帶來的吞吐量提升約為4%至7%。
另一筆能省的開銷，來自反覆出現的上下文。比如，一個程式設計智能體連續改同一份程式碼，後一次請求裡往往還帶著前面的指令和對話。已經計算過的部分，可以通過KV快取復用，不必每次重新處理。
DeepSeek在部署問答中介紹，它把這類中間結果存入獨立的記憶體叢集，供不同計算節點讀取。這樣，新的請求可以交給更空閒的機器，而不必追著某一台保存了快取的機器排隊。這是線上系統的設計說明，完整的快取管理程式碼尚未隨引擎一併放出。
這套快取的規模也不小：官方披露，底層3FS檔案系統為其提供約100 PiB的固態硬碟空間，智能體流量的快取保留3天，聊天流量保留7天。聊天快取留得更久，是因為其中少量內容會在較長時間裡被反覆讀取，過早清掉就得重新計算。
多張卡協作時，還要防止有的卡忙不過來、有的卡在等。DeepSeek介紹，在生成答案的階段，它會把混合專家模型中的專家分散到64張或128張卡上，減少每一步單卡需要讀取的資料，並根據負載調整專家的分佈。
CPU與GPU之間也能少一些等待。DeepInfer默認開啟非同步調度：GPU計算當前這一步時，CPU就開始準備後續任務，不必等當前計算全部結束才接著安排。
DeepSeek公佈的性能曲線還展示了一個取捨：一批處理更多輸入，單卡每秒能處理的總量會上升，但完成這一批計算也需要更長時間。實際提供服務時，不能只追求吞吐量最大，還要顧及使用者等待答案的時間。
引擎交出來了，整套服務還得自己搭
上述方法中，有些已能在開放原始碼裡使用，有些目前主要通過部署文件介紹。DeepInfer的公開版本提供離線推理，以及大規模服務所需的核心引擎功能；要讓外部使用者持續接入，還需要配套系統。
官方列出的缺項包括KV快取系統、把讀取輸入和生成輸出分到不同機器上的部署設施，以及不同服務實例之間的負載平衡。其中，分階段部署需要的大部分引擎功能已經實現，但外圍系統並未全部提供。
這些系統決定著快取能否及時取回、長短不同的請求怎麼分流、某台機器忙不過來時任務該交給誰。DeepSeek稱，快取管理和負載平衡與內部基礎設施耦合較深，程式碼尚未完整開源。外部團隊可以參考已公開的設計，但仍要接上自己的記憶體、網路和服務管理系統。
X使用者ReignSwords把它概括為：“他們開源了引擎，不是底盤。”他認可多個底層工具被整合到一起，也在意那些沒有隨之發佈的元件。
ReignSwords還把這次發佈形容為對2025年承諾的反轉。不過，當時DeepSeek並沒有說“永遠不發佈”。在2025年4月的說明中，團隊提到內部引擎經過大量定製，難以直接搬到外部環境，小團隊也缺少維護大型開放原始碼專案的精力，因此選擇先向已有項目貢獻獨立元件和最佳化。這次發佈擴大了程式碼開放的範圍，基礎設施依賴則仍需處理。
硬體同樣限制了誰能馬上用起來。當前支援列表是輝達SM100和華為昇騰950，H100、H800、A100，以及普通消費級顯示卡，都不在其中。
官方還給出了一套“最小高效部署單元”：64張卡處理輸入，另64張卡生成輸出，共128張卡。這不是啟動軟體的硬性下限，文件也說明，一個預填充實例加一個解碼實例可以部署；128張卡對應的是推薦的高效配置。對沒有這類硬體和叢集維運能力的團隊來說，它暫時還不是下載後就能開張的工具。
輝達之外，昇騰也有了配套引擎
DeepInfer從發佈時就同時支援輝達和華為平台。DeepSeek在設計目標中寫明，要支援多家廠商的加速晶片，並儘量發揮各自的性能。
這延續了它最近在昇騰軟體上的投入。9月底，DeepSeek已經公開面向昇騰平台的程式設計工具、計算庫和通訊庫，華為團隊參與了研發支援。底層元件解決具體計算和通訊的問題，DeepInfer則進一步將它們用於模型推理。
按The New Stack援引彭博社9月報導的說法，DeepSeek計畫在內蒙古的新資料中心部署至少16萬張昇騰950DT晶片，用於運行模型。這仍是一項報導中的部署計畫，不能算作已經投入使用的規模。
對於準備使用昇騰部署V4.1 Flash的企業，模型廠商公開相應實現，可以減少自行摸索適配方法的工作。但兩種晶片同時進入支援列表，還不能證明它們已經跑出了相同的性能或成本。
目前，DeepSeek公開的性能測試使用輝達SM100：處理輸入的測試用了4張卡，生成輸出的測試用了64張卡。部分幫助穩定復現輸出的功能，也僅在輝達實現中提供。昇騰使用者仍需要在自己的硬體和負載下測試速度、穩定性及每次請求的開銷。
企業能省多少，還得算整套帳
有叢集的企業和雲廠商，是最先有條件嘗試DeepInfer的一批使用者。它們可以對照官方程式碼，檢查自己現有的模型服務在那些環節浪費了算力，再決定是整體接入，還是先採用其中的最佳化。
配套元件deepseek-recipe解決的則是另一個問題：同一個模型，換一家平台呼叫，介面行為可能對不上。使用者消息怎麼拼成提示詞，模型輸出怎麼還原成回覆，工具呼叫怎麼解析，都可能影響最終使用體驗。
deepseek-recipe將Messages、Chat Completions和Responses等格式的請求轉成統一的對話格式，再按DeepSeek模型的要求編碼，並把生成結果轉回相應介面。按官方介紹，這部分處理邏輯與DeepSeek官方API對齊，第三方不必各自重寫一遍。但模型推理、工具執行和HTTP服務，仍由接入方提供。
算力能省下來多少，已經引起了社區的興趣。X帳號Tradenometry引用一套第三方測算：假設每小時GPU租金為3至6美元，處理的10億token中有97%是可復用的快取輸入，另外2%為非快取輸入、1%為輸出，那麼GPU租金約為0.73至1.46美元，對應非高峰時段收入約11.91美元。
在這組假設下，GPU租金只佔收入的約6%至12%。不過，這張帳單沒有覆蓋記憶體、網路、維運、研發等全部開銷，也高度依賴快取命中和流量構成，不能直接換算成DeepSeek的利潤率或硬體回本周期。
圖：第三方測算，非DeepSeek財務披露；其中的成本估算主要針對GPU租金。
Tradenometry看好的是另一種可能：呼叫更便宜之後，使用者願意讓模型處理更多工，服務商也更有動力增加算力。能否出現這種增長，要看新增用量是否足以抵消每項任務減少的計算開銷。
對第三方服務商來說，最佳化程式碼提供了壓低成本的機會，最終帳單還受採購價格、硬體配置和實際負載影響。對使用DeepSeek App或官方API的人來說，這次開源本身並不是一份降價通知；更值得留意的是，其他平台接入後，能否提供價格更低、等待更短的同款模型服務。
沒有大叢集，也能先學它怎麼省
不是每個開發者都有條件部署DeepInfer，但投機解碼、減少重複計算和非同步調度的方法，可以拆開研究，再嘗試用於其他推理框架。
DeepInfer本身也受益於這樣的程式碼交流。項目說明寫明，它最初主要基於vLLM建構，還借鑑了SGLang、TensorRT-LLM等項目。如今這些針對DeepSeek模型的改動被公開，社區可以進一步檢查，那些最佳化依賴特定模型和硬體，那些能被其他項目採用。
X使用者Nick對這次開放頗為樂觀。他認為，更多團隊能夠學習DeepSeek的推理最佳化，會帶來更多競爭；但軟體方法公開之後，硬體供應仍是限制。他還後悔，沒趁GPU和固態硬碟有貨時多買一些。
(網易科技)