轉載：機器之心

【寫在開頭】

最近微信推薦機制調整了，可能有些朋友會收不到我們的推送，大家別忘了給海角春藤加上星標，以免錯過更多精彩！

直播預告

正文

DeepSeek 官方：如果所有 tokens 全部按照 DeepSeek R1 的定價計算，理論上一天的總收入為 $562,027，成本利潤率 545%。但實際上沒有這麼多收入，因為 V3 的定價更低，同時收費服務只佔了一部分，另外夜間還會有折扣。

太突然了！原來 DeepSeek 也有 One More Thing。

就在所有人以為 DeepSeek 預告的 5 天開源告一段落時，今天中午 12 點 11 分，官方 𝕏 帳號再次更新，宣告「開源周」還在繼續。不過這第六天 DeepSeek 並沒有開源新的軟體庫，而是介紹了 DeepSeek-V3/R1 的推理系統。

概述地址：

https://github.com/deepseek-ai/open-infra-index/blob/main/202502OpenSourceWeek/day_6_one_more_thing_deepseekV3R1_inference_system_overview.md

DeepSeek 的推文中寫到，DeepSeek-V3/R1 的推理系統採用了跨節點 EP 驅動的批次擴充套件、計算 – 通訊重疊、負載平衡來實現對吞吐量和延遲的最佳化。同時，DeepSeek 還給出了其線上服務的統計資料：

每個 H800 節點實現了 73.7k/14.8k 個每秒輸入 / 輸出 token；
（理論）成本利潤率高達 545%。

DeepSeek 還表示：「我們希望本週的洞見能夠為社群帶來價值，併為我們共同的 AGI 目標做出貢獻。」

一時之間，社群再次沸騰，不僅僅是因為明明說的 5 天開源卻來到了第 6 天以及 73.7k、14.8k、545% 這三個驚人的數字，大家尤其期待明天 —— 開源周的最後一天，DeepSeek 將用什麼來壓軸。

系統設計原則

為了實現更高的吞吐量和更低的延遲，DeepSeek 採用了跨節點專家並行（EP，Expert Parallelism）策略。

首先，EP 顯著擴充套件了 batch 大小，提高了 GPU 矩陣計算效率並增加了吞吐量。

其次，EP 將專家分佈到各個 GPU 上，每個 GPU 只處理一小部分專家（減少記憶體訪問需求），從而降低延遲。

然而 EP 增加了系統的複雜性，主要表現在兩個方面：

EP 引入了跨節點通訊。為了最佳化吞吐量，必須設計適當的計算工作流，shi 通訊與計算重疊。
EP 涉及多個節點，因此本質上需要資料並行 (DP)，並且需要在不同的 DP 例項之間進行負載平衡。

為此，該專案重點介紹如何透過以下方式應對這些挑戰：

利用 EP 擴充套件 batch 大小；
隱藏計算背後的通訊延遲；
執行負載平衡。

大規模跨節點專家並行（EP）

由於 DeepSeek-V3/R1 中專家數量龐大 —— 每層 256 個專家中只有 8 個被啟用 —— 模型的高度稀疏性導致需要極大的總 batch 大小。這樣才能確保每個專家有足夠的 batch 大小，從而實現更高的吞吐量和更低的延遲。大規模跨節點 EP（專家並行）是至關重要的。

由於 DeepSeek 採用了預填充 – 解碼分解架構，因此他們在預填充和解碼階段採用不同程度的並行性：

預填充階段 [路由專家 EP32、MLA / 共享專家 DP32]：每個部署單元跨越 4 個節點，擁有 32 個冗餘路由專家，其中每個 GPU 處理 9 個路由專家和 1 個共享專家。
解碼階段 [路由專家 EP144、MLA / 共享專家 DP144]：每個部署單元跨越 18 個節點，擁有 32 個冗餘路由專家，其中每個 GPU 管理 2 個路由專家和 1 個共享專家。

計算 – 通訊重疊

大規模跨節點 EP 會引入顯著的通訊開銷。為了緩解這一問題，DeepSeek 採用了「dual-batch」重疊策略，透過將一個 batch 請求拆分為兩個 microbatch 來隱藏通訊成本並提高整體吞吐量。在預填充階段，這兩個 microbatch 交替執行，一個 microbatch 的通訊成本被隱藏在另一個 microbatch 的計算過程中。

預填充階段通訊 – 計算重疊

在解碼階段，不同階段的執行時間是不平衡的。因此，DeepSeek 將注意力層細分為兩個 step，並使用一個 5 階段的 pipeline 來實現無縫的通訊 – 計算重疊。

解碼階段的通訊 – 計算重疊

關於通訊 – 計算重疊機制的更多細節可以參考：

https://github.com/deepseek-ai/profile-data

實現最優負載平衡

大規模並行化（包括 DP 和 EP）存在一個關鍵難題：如果單臺 GPU 的計算或通訊負荷過重，它就會成為效能瓶頸，導致整個系統變慢，同時還讓其他 GPU 處於閒置狀態。為了最大限度地提高資源利用率，DeepSeek 努力實現了所有 GPU 上的計算和通訊負載平衡。

1. 預填充負載平衡器

關鍵問題：DP 例項之間的請求數量和序列長度不同，導致核心注意力（core-attention）計算和排程傳送負載不平衡。

最佳化目標：

平衡 GPU 之間的核心注意力計算（核心注意力計算負載平衡）。
均衡每個 GPU 的輸入 token 數量（排程傳送負載平衡），防止特定 GPU 上的處理時間過長。

2. 解碼負載平衡器

關鍵問題：DP 例項之間的請求數量和序列長度不均勻導致核心注意力計算（與 KV 快取使用量相關）和排程傳送負載不均。

最佳化目標：

平衡 GPU 之間的 KV 快取使用率（核心注意力計算負載平衡）。
均衡每個 GPU 的請求數（排程傳送負載平衡）。

3. 專家並行負載平衡器

關鍵問題：對於給定的 MoE 模型，存在固有的高負載專家，導致不同 GPU 之間的專家計算工作負載不平衡。

最佳化目標：平衡每個 GPU 上的專家計算（即，最小化所有 GPU 上的最大排程接收負載）。

DeepSeek 線上推理系統示意圖

DeepSeek 線上推理系統示意圖

DeepSeek 線上服務統計

所有 DeepSeek-V3/R1 推理服務均在 H800 GPU 上執行，精度與訓練一致。具體而言，矩陣乘法和分發傳輸採用與訓練一致的 FP8 格式，而核心 MLA 計算和組合傳輸使用 BF16 格式，確保最佳服務效能。

此外，由於白天服務負載高而夜間負載低，DeepSeek 實施了一種機制，於白天高峰時段在所有節點上部署推理服務。在夜間低負載期間，他們減少推理節點並將資源分配給研究和訓練。在過去 24 小時內（北京時間 2025 年 2 月 27 日中午 12:00 至 2025 年 2 月 28 日中午 12:00），V3 和 R1 推理業務的合併峰值節點佔用達到 278，平均佔用 226.75 個節點（每個節點包含 8 個 H800 GPU）。假設租賃一個 H800 GPU 的成本為每小時 2 美元，每日總成本為 87,072 美元（約合人民幣 63.4 萬）。

H800 推理服務節點數量。

在 24 小時統計期間（北京時間 2025 年 2 月 27 日中午 12:00 至 2025 年 2 月 28 日中午 12:00），V3 和 R1：

總輸入 token：608B，其中 342B token（56.3%）命中磁碟 KV 快取。
總輸出 token：168B。平均輸出速度為每秒 20-22 個 token，每個輸出 token 的平均 kvcache 長度為 4,989 個 token。
每個 H800 節點在預填充期間平均吞吐量約為 73.7k tokens/s 輸入（包括快取命中）或在解碼期間約為 14.8k tokens/s 輸出。

以上統計資料包括來自網頁、APP 和 API 的所有使用者請求。如果所有 token 都按照 DeepSeek-R1 的定價 (*) 計費，每日總收入將為 562,027 美元，成本利潤率為 545%。

(*) R1 定價：0.14 美元 / 百萬輸入 token（快取命中），0.55 美元 / 百萬輸入 token（快取未命中），2.19 美元 / 百萬輸出 token。

然而，DeepSeek 表示實際收入大幅低於此數字，原因如下：