大家好，歡迎來到最佳夥伴，我是大飛。
DeepSeek 開源推理框架與生態工具
10 月 20 日，DeepSeek 開源了其推理框架 DeepInf（為其線上服務提供支援）及其配套的編碼組件 DeepSeek-Recipe。這一次，DeepSeek 既沒有發布新型號，也沒有登上排行榜榜首；相反，他們交出了該車型背後的引擎藍圖。
今天，我們來談談這個框架。要理解它，我們首先需要明確推理框架究竟是什麼。許多人認為開源模型僅僅意味著下載權重，僅此而已。但重量只是一堆數字；他們既不能說話也不能回答問題。其間隱藏著一整套工程技術棧，負責對請求進行排隊、將請求輸入晶片並檢索結果。科技部落客寶宇曾用食譜和廚房工作人員作比喻。如果把模型文件比喻成食譜，那麼推理框架就是廚房工作人員。如果將同一食譜交給不同的廚房團隊，他們每小時可以處理的訂單數量以及顧客的等待時間可能會有很大差異。這就是為什麼開源引擎比開源引擎重要罕見得多的原因。公開重量現在已是常規操作，但開源引擎意味著向所有人展示你的廚房人員配備方式以及如何擴展營運規模。
2025 年 4 月，DeepSeek 解釋了他們為什麼不開放其內部引擎，基本上是說該引擎是為他們的環境進行了高度定制，難以遷移，而且團隊沒有資源來維護一個大型公共項目。然而，到了今年十月，他們改變了立場。他們發布了不只一個程式碼庫；除了 DeepInf 之外，還有 DeepSeek-Recipe。
就在幾天前，DeepSeek 推出了專門針對模型的搜尋和取得工具。這三件事看似毫不相干，但其實是相互連結的。Search 和 Fetch 負責採購食材，DeepInf 是廚房團隊，Recipe 則提供多語言菜單，允許將各種格式的訂單翻譯成廚房能夠理解的語言。
讓我們先簡單了解搜尋和獲取功能，它們背後有一個人們很少考慮的層。我們都知道搜尋引擎是為人類設計的，其中充滿了廣告、推薦和彈出窗口，我們可以輕易忽略它們。但模型做不到；每多一個字都會消耗上下文，佔用詞元，並且會花費金錢。這兩個 API 都會傳回原始 JSON 資料。除了提供標題、網址、摘要、全文和時間戳外，它們還包括相關性和權威性評分。很簡單：你提供一個 URL，它就會傳回清理後的 Markdown 資料。這兩個 API 的定價為每 1000 次成功請求 5 元人民幣，用戶可以使用 depsharnessCodecodex 中的伺服器端工具來呼叫它們。2026 年 11 月 1 日北京時間 0 時之前不收取任何費用。它也不需要綁定特定的模型；您只需要一個 Depsik API 即可呼叫其他提供者的模型。
當然，真正的明星是 DeepInf，它採用了 Apache 2.0 授權。它支援 NVIDIA 的 SM100 和華為的 Ascend 950，需要 Linux 環境，以及 Python 3.12 和 GCC 13 或更高版本。NVIDIA 需要 CUDA 13，而 Ascend 需要 CANN 9.2。目前，它僅支援一種模型：depsicv 4.1 flash，拉取權重程式碼為 depsicv 4.1 flash 1017。稍後我們將詳細介紹具體的日誌記錄細節。
接下來是 deepsicrecipe，它可以解決格式問題。目前有三種主流 API：OpenAI 聊天補全和回复，以及 Anthropic 訊息。最終，它們都會向模型尋求答案，但格式各不相同，因此不能直接移植相同的對話。如果你想在自己的伺服器上執行 deepsake，但客戶端是基於 OpenAI 標準編寫的，那麼模型將無法理解。因此，需要一名翻譯人員在中間進行溝通。RP 負責處理此翻譯；它的核心是用 Rust 編寫的，並提供了一個 Python 介面。它將三種類型的請求統一為內部對話格式，根據模型版本建立提示，並使用其內建的分詞器將它們編碼為標記。模型輸出後，會依照對應的協定將令牌還原到回應中，並將其串流回使用者。
它還維護一個跨資料塊解析狀態機。由於一個漢字在 UTF-8 編碼中佔用三個位元組，因此它可以被分成兩個相鄰的區塊，工具參數也可以被分成兩個相鄰的區塊。因此，它會在解析之前等待數據，確保用戶永遠不會看到半個字元。它也恰好修復了一個安全漏洞。Deps 模型依賴一組特殊的標記來標記對話結構，例如使用者語句的起始位置或工具的呼叫時間。如果有人手動在輸入中輸入完全相同的使用者或圖像標籤，就可以冒充系統並發出命令。Recipe 的方法是只將提示建置過程中明確插入的標籤對應到特殊標記；使用者輸入的相同字串將被視為普通文字。此外，當思維模式被停用時，輸出限制預設為 8,192 個標記。啟用思考模式後，數值為 65,536；如果將推理強度設定為最大值，則數值可達 131,072。
PD 分離與架構設計
現在，讓我們來看一個例子，了解請求是如何經過整個流程的。
首先，請求必須經過分詞器才能變成令牌，然後它分成兩個階段。第一階段稱為預填充，模型會同時讀取系統提示、聊天記錄和文件問題；每個令牌在每一層都會產生一組中間結果，稱為 KV 快取。第二階段是解碼，它一次產生一個標記；產生的每個新令牌都需要使用先前的所有 KV 快取。這兩個階段消耗的資源完全不同：預先填充一次處理數萬個令牌，需要純粹的運算能力，解碼一次產生一個令牌，大部分時間都花在從 VRAM 讀取參數和快取。因此，DeepSeek 將它們分配到不同的機器上，這就是通常所說的 PD 分離。
在設計該系統時，設定了三個目標：與不同供應商的晶片相容，使通用硬體能夠進行預填充和解碼，以及將 KV 快取保持至少一個小時。在部署中，預先填充使用 8 個 GPU 伺服器，解碼使用 64 到 128 個 GPU 集群，視覺編碼器是單獨拉出來的；三個階段各自獲得自己的資源，分別優化首令牌延遲和令牌間延遲。官方文件中有條有趣的說明：視覺編碼器通常只需要一張卡，他們建議使用最便宜的卡。實際部署中，兩個階段的卡片比例接近 1:1；雖然只需一個預填充單元和一個解碼單元即可運行，但要獲得高效的性能，需要遵循官方的起始規格。
KV 快取機制與 3FS 分散式儲存
接下來是整個系統中成本最低的部分。在代理場景中，每次呼叫工具時，客戶端都必須重新傳送完整的歷史記錄——系統提示、工具定義以及之前的所有回應和工具結果——一個字都不能漏掉。然而，其中絕大多數實際上已經在上一輪計算中得出。DeepSeek 的方法是快取計算出的 KV 值，這樣在下一輪計算中，它就只計算新加入的標記。要求是前綴必須完全匹配才能命中緩存，因此必須從第一個標記開始對齊；從中間開始重複的內容不能使用。
這種快取機制的效果有多顯著？在同一張卡上，如果沒有快取命中，預填充每秒可以處理 60,000 個令牌；如果算上快取命中次數，那就是 150 萬——相差 25 倍。Deps 線上請求的平均輸入量為 77K，平均首次令牌延遲時間為 400 毫秒，P99 為 1000 毫秒。快取命中時的輸入成本僅為快取未命中時的 1/50；命中率每提高一點，鈔票就會變薄。
這些快取不是儲存在電腦器本身的記憶體中，而是儲存在一個獨立的儲存叢集中，該叢集使用 DeepSeg 之前開源的分散式檔案系統 3FS，在 SSD 上的容量約為 100PB，以 128 個令牌為一組寫入 KV 快取。ENT 流量的快取保留三天，而聊天流量的快取則保留七天。由於聊天流量具有長尾命中特性，少量快取資料會被重複讀取，因此聊天流量的保留時間更長，丟失快取會對整體命中率產生更大的影響。根據 Deck 的估計，如果他們只保留三天，聊天流量命中率將下降 0.5% 至 1%。從產業角度來看，OpenAI 和 Google 的快取保留時間僅為 5 分鐘到 24 小時，因此三到七天算是相當長的了。
將它們儲存在獨立的叢集中有兩個好處：任何電腦都可以讀取任何快取片段，因此使用者不再受限於先前的機器。計算機器的故障率也比儲存設備高幾個數量級，因此即使機器崩潰，快取仍然存在。但是，讀取快取不應該降低首次令牌延遲時間，因此 DPS 將命中分為三個階段：第一階段在入口服務處，使用雜湊鏈對本地 KV 儲存執行前綴匹配以取得元資料。為了達到所需的長度，第二階段必須在路由之前獲取數據，使用一個獨立的進程將快取從 3FS 移動到主機共享內存，而第三階段（引擎層）則將其從共享內存移動到 VRAM，將逐層傳輸與前向計算重疊。
他們本可以使用大型複製引擎，但細粒度塊的複製性能並不理想，因此 DPS 轉而使用 GDR，使 RDMA NIC 能夠在不佔用計算單元的情況下充分利用 PCIe 頻寬。底層儲存也針對大約 112KB 區塊的隨機讀取/寫入進行了最佳化，總讀取峰值達到每秒 10TB。
V4.1 的滑動視窗注意力改進
當然，總會有失手的時候，而這正是 V 4.1 版本變化最明顯的地方。在 V 4.1 中，一些層使用滑動視窗注意力 (SWA)，其中每個標記只專注於與其最近的 128 個標記。活動塊 KV 快取和狀態 KV 快取儲存在推理卡的 VRAM 中。資料塊每 128 個令牌進行分頁，持久部分寫入檔案系統。前 20 層是單獨維護的，每一層都有一個 128 個標記的循環緩衝區，另外還有 6 個標記保留用於推測性解碼。它不會同步，只會保存在生成它的機器的記憶體中，大約三分鐘後就會被清除。命中率超過 98%；對於跨機器命中，它透過 400G 網路獲取數據。
那麼，那 2% 失手的人怎麼辦？V 4 的方法是精確地重新計算，逐層恢復視窗狀態。需要重新計算的標記數等於層數乘以視窗長度。為了減少這種情況，V4 還將快取的這一部分寫入磁碟，結果消耗了近一半的磁碟快取容量。問題是它只對幾分鐘的對話有用，所以使用可以儲存幾天資料的磁碟顯然不划算。因此，V 4.1 採用了一種不同的方法，稱為“SWAB”，即“滑動視窗近似邊界”。它會重新計算最後 128 個標記，計算過程中的注意力也僅限於這 128 個標記，從而實現近似視窗快取。這樣，重新計算的成本就變成了一個常數，與上下文長度或模型層數無關。
同樣的方法也應用於解碼器的 20 層。每次預先填充時，這 20 層的視窗快取都必須重建；更改後，不再需要處理最後 2560 個令牌，而只需要處理 128 個令牌。預填充計算總量減少了近一半。
動態投機解碼與零開銷批次調度
然而，雖然快取解決了讀取速度的問題，但解碼速度也需要更快。此模型的每個計算步驟最初只能產生一個標記。推測性解碼背後的想法是讓一個輕量級的草稿模型產生五個連續的令牌，然後將它們傳遞給大型模型進行一次性驗證。正確猜測會被直接接受，對於第一個錯誤位置，大型模型會給出正確答案。
這樣，一次計算步驟可以產生多個令牌，但驗證過程本身也會消耗運算能力。如果所有五個草稿都要進行驗證，那麼大量的計算資源將浪費在被否決的猜測上。DSI 自主研發的系統 DISBK 會先估計每個猜測被接受的機率，從而將驗證預算引導到更有希望的領域。與每一步驗證五個令牌相比，動態驗證每一步的檢查次數減少了約 30%，而接受的令牌的平均長度基本上保持不變。就吞吐量而言，實際線上測試顯示提高了 6%。另一組更詳細的數據顯示，隨著序列數從 16 增加到 96，收益從 -1.5% 上升到 11%，因此該數字是有條件的；並非所有工作負載都能加快運行速度。
CPU 和 GPU 之間隱藏著一些開銷；通常情況下，GPU 在完成一個步驟後必須停止，等待 CPU 更新上一輪的狀態，然後才能調度下一輪，這會導致生成數千個令牌的請求反覆等待。DeepInfra 的方法稱為零開銷批次調度；雖然名稱暗示沒有調度成本，但實際上它將 CPU 工作隱藏在 GPU 的計算時間中。當 GPU 處理步驟 N 的前向傳播和採樣時，CPU 已經在準備步驟 N + 1 的預填充，同時處理早期的採樣結果，從而允許一些任務提前提交到 GPU 執行佇列，依賴關係由流和事件管理。
這種提前調度帶來了新的問題：當 CPU 調度下一輪時，先前的結果可能不確定。標準自回歸解碼一次推進一個標記，但推測性解碼一次可以接受多個候選標記；如果已經緩存了 1000 個令牌，並且本輪接受了 3 個令牌，則 CPU 將不知道最終計數，如果使用舊長度，則會導致查詢長度、鍵長度和旋轉位置編碼等計算出現偏差。DeepInfra 維護一個已分發但尚未提交的代幣計數器，透過考慮正在進行的計算來預先預留快取空間。
由於請求位置在連續的輪次之間會發生變化——有些請求結束，新的請求加入，還有一些請求被搶佔——它使用映射層將當前輪次的請求與上一輪的執行狀態對齊，並使用設備端內核來糾正長度。
內存回收也被推遲。在同步執行過程中，CPU 可以在請求完成後釋放引用，但這在這個管道中行不通。即使請求已完成 CPU 後處理，GPU 可能仍有操作正在使用它，因此 DeepInfra 會將元資料、輸出物件和快取區塊排隊等待回收，並在稍後的同步點進行處理，使用 CUDA 事件驗證與 GPU 相關的資源。
MoE 專家負載平衡與叢集擴展
多張卡片之間也存在同步問題；V 4.1 的部署規模預填使用 2 到 8，解碼使用 64 到 128。由於專家並行性如此之高，同一通訊域中的卡片必須保持同步。否則，如果一些用戶正在運行預填程序，而另一些用戶仍在解碼，則集體通訊將會失敗。DPIN 為調度器添加了群組內投票功能，有兩種模式：一種模式要求所有卡片都滿足條件才能切換，另一種模式允許部分卡片觸發，以避免小請求等待時間過長。之後，還有第二輪驗證，因為佇列中的請求並不能保證它們能在這一輪中被安排執行；在實際應用中，您可能會遇到卡片缺少快取容量或序列插槽的情況。確認後，如果只有部分卡片被分配了任務，則其他卡片執行空的預填充步驟；因此，專家負載是拖慢整個回合計算速度的另一個因素。
V 4.1 是典型的 MoE 模型，共有 384 位路由專家；每個代幣只使用其中六個，外加一個共享專家。當擴展到 EP64 時，這些專家分佈在 64 張卡片上，每張卡片上有 6 位專家，外加一位熱門專家的副本；這七位專家檔中不包括共同專家。每張卡片上的專家越少，每一步需要從 VRAM 載入的參數就越少，從而使相同數量的卡片可以處理更多的請求。知名專家的文稿也不是固定的；每 1000 步收集一次負載統計信息，每 10000 步進行一次重新分配。實際測試結果顯示，最繁忙的卡片只比平均值高出 9%，因此雖然仍然存在一些不平衡，但已經保持在相當低的水平。
請求本身也必須均勻分配。對於預填充，輸入長度分為四個等級：小於 16K、16K 到 64K、64K 到 256K 以及大於 256K。分配給每個層級的機器數量會根據上一輪的需求動態調整。解碼時，它會考慮每張卡的請求次數和總快取長度；短請求分配給請求較少、快取時間較長的卡片，而長請求分配給快取時間較短的卡片。採用這種調度系統，效能可以達到離線測試中完美平衡狀態的約 80%。
負載平衡器也分為四種類型，包括預填充型、解碼型、視覺化編碼型和專家並行型；擴展是在叢集層級處理的。預填充監控快取未命中令牌的數量，解碼查看目前正在處理的請求數量，擴展使用上限和下限以及計數限制。
在專業的並行部署中，最大的擔憂是浪費長尾請求。因此，當解碼實例收到關閉通知時，它不會立即退出；它允許有一分鐘的寬限期。然後，任何未完成的任務都會連同請求和 KV 快取一起傳遞給另一個實例繼續處理。此外，DeepSeek 還維護著一批預先準備好但尚未分配的機器，作為突發庫存池。當利用率超過 0.8 時，就會觸發禁令。
在容錯性方面，DeepSeek 並不追求極短的重啟時間；實際上，它們的傳輸時間在分鐘級，依靠容量配額和請求重新路由來提供覆蓋範圍。例如，所有 GPU 共用同一個通訊域。如果一張卡片發生故障，整個執行個體就會停止運作，因此在重新啟動時，他們會重新統計健康的卡片，並根據實際可用數量重新確定 TP 度。
至於跨資料中心操作，官方表示技術上是可行的。V 4.1 大幅壓縮了 KV 緩存，每 8 張卡片需要約 400Gbps 的互連頻寬，但這犧牲了可靠性，因為資料中心之間的光纖電纜可能會被切斷。這就是為什麼 DeepSeek 將自己的推理節點放置在不同但相鄰的資料中心的原因。
商業考量與單位經濟效益
技術方面的問題解決了，現在是時候分析數據了。DeepSeek 很少公開其單位經濟效益。他們有一個集群，每天可以處理 1.55 兆個代幣。根據股價計算，每張卡平均每小時可賺取 38 美元。將此乘以 24，再乘以 30，每張卡每月大約能賺 27,000 美元——同行很少透露這個數字。梁文峰曾在私人投資者會議上提到，他們的 API 定價是基於合理的利潤，目標是在大約十個月內收回一批設備的成本。他表示，他們只追求合理的利潤，而不是利潤最大化。
然而，DeepSeek 顯然打算實現商業化，並且最終必須生存下去。從本質上講，它仍然是一家公司，只不過這家公司正在考慮追求哪些利潤、何時賺錢、如何賺錢以及需要做出哪些權衡。
如果我們把這些聲明與可口可樂的故事結合起來看，會發現很多事情都吻合。2011 年可口可樂配方外流時，幾乎沒有引起任何迴響。該公司聲稱這只是早期草稿，生產版本已經多次改進，因此股價保持平穩，而銷售額實際上卻有所增長。因為可口可樂的護城河從來都不是糖漿配方，而是它的裝瓶和分銷網絡、品牌認知和成本控制。DeepSeek 這次的做法很像可口可樂；他們已經公開了配方，但真正賺錢的地方並不在於配方。
那麼，他們究竟想要什麼？答案就在於切入點和形式。隨著旗艦機型之間的差距縮小，僅憑參數和排行榜很難脫穎而出，競爭的重點正在從「誰的機型更強」轉移到「誰控制了入口點、資料流和格式」。他們爭奪的是搜尋和資訊流：這些入口點。每次代理搜尋資訊時，都需要呼叫一個工具；預設使用者佔據該位置，任何型號的使用者都可以通過該入口。每一次查詢、抓取、引用和選擇都可以轉換為訓練訊號，從而形成一個由入口點、資料、模型以及更強大的入口點組成的飛輪。
至於食譜，關鍵在於掌握格式；他們將官方處理邏輯變成了一個公共庫，第三方只需遵循它，他們的行為自然也會保持一致。這對開發者來說當然是件好事，因為針對官方行為進行調整的代理在切換到其他服務提供者時不會輕易遇到問題。對於 DeepSeek 來說，情況就更好了；隨著越來越多的第三方服務採用這些規則，提示格式、工具調用格式和串流輸出規則將成為事實上的行業標準。
業界迴響與硬體門檻
業界的反應非常直接。Llama 官方帳號發布了一條訊息，感謝 DeepSeek 根據 Apache 2.0 許可證回饋社區，該許可證最初是基於 Llama 構建的。研究員陳德利在 X 上表示，這是開源與閉源之間的決鬥，對方可以一直打下去，想打多久就打多久。DeepSeek-Harness 的負責人崔天義則更務實地表示：開源的目的是希望世界各地的公司能夠部署 DeepSeek 模型並從中獲得真正的收入。
除此之外，其他人還在計算另一組數據。一位部落客根據 GB200 NV72 的極端利用率推斷，1 吉瓦的運算能力每年可產生 1,000 億至 1,490 億美元的收入——幾乎是先前機構預測的十倍。其他人則根據每 GPU 每小時 3 美元的租金來計算毛利率，假設 API 使用率足夠高。如果以每平方英尺 3 美元到 6 美元的租金計算，租金僅佔收入的 6% 到 12%。
雖然這些數字聽起來很驚人，但實際上需要謹慎看待。前兩個模型都是基於樂觀的假設，而第三個模型只扣除了 GPU 租金，沒有考慮儲存、網路、推理和研發成本，並且高度依賴緩存命中率和流量結構。因此，將這些視為 DeepSeek 的利潤率或投資回收期是站不住腳的。這 38 美元指的是收入，而不是利潤，也不是 DeepInf 專案單獨產生的收益。
還有一個更大的限制：這次開源的是引擎，而不是底盤。開源的 DeepInf 在官方 README 文件中有詳細的說明。建立完整的推理服務仍然需要三件事：獨立的 KV 快取系統、視覺編碼器、預填充和解碼設施以及資料並行副本之間的負載平衡。文件也承認，生產環境中的快取管理和負載平衡與內部基礎設施耦合太深，目前尚未完全開源。因此，雖然外部團隊在獲得程式碼後可以看到請求如何通過調度程序、快取通訊和採樣，並可以提取特定的最佳化供自己使用，但要複製一個既快速又高效的線上服務，仍然需要他們自己解決儲存、網路、服務管理和故障轉移等問題。但是，如果你能夠讓離線推理運作起來，那麼你離生產系統可能就不遠了。
當然，硬體也是一大難題。目前支援的顯示卡清單僅包括 NVIDIA SM100 和華為 Ascend 910；H100、H800、A100 和標準消費級顯示卡不包含在內。官方建議預填卡片 64 張，解碼卡片 64 張。這是效率的起始標準，而不是運作的基準線。對大多數團隊來說，這套工具包目前還不是下載後就能立即使用的工具。
我們先單獨討論硬體部分。總而言之，DeepSeek 為 Ascend 平台發布了程式設計工具、計算庫和通訊庫，華為團隊提供了研發支援。關於規模，彭博社報道稱，DeepSeek 計劃在其位於內蒙古的新資料中心部署至少 16 萬顆 Ascend 910 晶片。這是一個計劃數字，不能計入目前實際運作的規模。此外，README 中的效能測試是在 NVIDIA SM100 上進行的。兩款晶片都在支援列表中，並不意味著它們的性能和成本完全相同。
總結與展望
那麼，我們該如何評估這一點呢？
我認為真正值得注意的是，DeepSeek 很少將所有這些組件組合在一起。過去幾年，外界只看到了各個組成部分：FlashAttention 用於注意力機制，GEMM 用於矩陣操作，EP 用於專家通信，EPLB 用於專家部署。每個元件都有自己的文件和基礎，但請求如何遍歷它們，以及中間資料契約是什麼樣子，一直都是一個黑盒子。DPO 將這些內容放入同一個公共專案中；雖然無法完全控制，但現在可以看到整體組裝圖。
這也顯示模型架構決定了運行時結構。MLA、滑動視窗、生產者-消費者層優化、超連接 MoE 和多標記預測都不是通用引擎可以自動推斷的配置；它們直接改變快取佈局、調度器狀態機、計算圖形形狀和檢索邏輯。這就是為什麼 DeepSeek 必須編寫自己的引擎，而不是修補通用框架的原因。
至於開源本身，我認為它既不像理想主義者所說的那麼天真，也不像陰謀論所說的那麼黑暗。正如文子所說，“與眾人行善，共享技藝，使眾人皆知”，意思是做好事應該一起做，能力應該人人皆可獲得。當然，其中也涉及商業考量，但這兩者並不衝突。透過上市，他們獲得了切入點、標準、資料流和規模——所有這些實際上都比配方本身更有價值。
剩下的問題是，一旦推理引擎和 API 格式成為公共產品，模型供應商還能依靠什麼來真正脫穎而出？是數據、用例，還是像可口可樂那樣，只是擁有冰箱？