MLNLP

社群是國內外知名的機器學習與自然語言處理社群，受眾覆蓋國內外NLP碩博生、高校老師以及企業研究人員。

社群的願景是促進國內外自然語言處理，機器學習學術界、產業界和廣大愛好者之間的交流和進步，特別是初學者同學們的進步。

來源 | 量子位

編輯 | 魚羊

五連開源後，DeepSeek還有One More Thing！

就在剛剛，DeepSeek官方親自揭秘了DeepSeek-V3/R1推理系統。

重點包括，最佳化吞吐量和延遲的方法：

跨節點EP驅動的批次擴充套件
計算與通訊重疊
負載均衡

還公佈了DeepSeek的線上服務資料統計：

每個H800節點每秒有73.7k/14.8k個輸入/輸出token
成本利潤率545%

更多細節，一起來看官方原文↓

更大的吞吐，更低的延遲

DeepSeek-V3/R1推理系統的最佳化目標是：更大的吞吐，更低的延遲。

為了實現這兩個目標，我們的方案是使用大規模跨節點專家並行（ExpertParallelism/EP）。

首先EP使得batch size大大增加，從而提高GPU矩陣乘法的效率，提高吞吐。其次EP使得專家分散在不同的GPU上，每個GPU只需要計算很少的專家（因此更少的訪存需求），從而降低延遲。

但EP同時也增加了系統的複雜性。複雜性主要體現在兩個方面：

EP引入跨節點的傳輸。為了最佳化吞吐，需要設計合適的計算流程使得傳輸和計算可以同步進行。
EP涉及多個節點，因此天然需要Data Parallelism（DP），不同的DP之間需要進行負載均衡。

因此，本文的主要內容是如何使用EP增大batch size，如何隱藏傳輸的耗時，如何進行負載均衡。

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

由於DeepSeek-V3/R1的專家數量眾多，並且每層256個專家中僅啟用其中8個。模型的高度稀疏性決定了我們必須採用很大的overall batch size，才能給每個專家提供足夠的expert batch size，從而實現更大的吞吐、更低的延時。需要大規模跨節點專家並行（Expert Parallelism/EP）。

我們採用多機多卡間的專家並行策略來達到以下目的：

Prefill：路由專家EP32、MLA和共享專家DP32，一個部署單元是4節點，32個冗餘路由專家，每張卡9個路由專家和1個共享專家
Decode：路由專家EP144、MLA和共享專家DP144，一個部署單元是18節點，32個冗餘路由專家，每張卡2個路由專家和1個共享專家

計算通訊重疊

多機多卡的專家並行會引入比較大的通訊開銷，所以我們使用了雙batch重疊來掩蓋通訊開銷，提高整體吞吐。

對於prefill階段，兩個batch的計算和通訊交錯進行，一個batch在進行計算的時候可以去掩蓋另一個batch的通訊開銷；

△Prefill階段的雙batch重疊

對於decode階段，不同階段的執行時間有所差別，所以我們把attention部分拆成了兩個stage，共計5個stage的流水線來實現計算和通訊的重疊。

△Decode階段的雙batch重疊

關於更多雙batch重疊的細節，可以參考我們的profiling資料的GitHub倉庫：https://github.com/deepseek-ai/profile-data。

儘可能地負載均衡

由於採用了很大規模的並行（包括資料並行和專家並行），如果某個GPU的計算或通訊負載過重，將成為效能瓶頸，拖慢整個系統；同時其他GPU因為等待而空轉，造成整體利用率下降。因此我們需要儘可能地為每個GPU分配均衡的計算負載、通訊負載。

Prefill Load Balancer

核心問題：不同資料並行（DP）例項上的請求個數、長度不同，導致core-attention計算量、dispatch傳送量也不同
最佳化目標：各GPU的計算量儘量相同（core-attention計算負載均衡）、輸入的token數量也儘量相同（dispatch傳送量負載均衡），避免部分GPU處理時間過長

Decode Load Balancer

核心問題：不同資料並行（DP）例項上的請求數量、長度不同，導致core-attention計算量（與KVCache佔用量相關）、dispatch傳送量不同
最佳化目標：各GPU的KVCache佔用量儘量相同（core-attention計算負載均衡）、請求數量儘量相同（dispatch傳送量負載均衡）

Expert-Parallel Load Balancer

核心問題：對於給定MoE模型，存在一些天然的高負載專家（expert），導致不同GPU的專家計算負載不均衡
最佳化目標：每個GPU上的專家計算量均衡（即最小化所有GPU的dispatch接收量的最大值）

參考架構圖

線上系統的實際統計資料

DeepSeekV3和R1的所有服務均使用H800 GPU，使用和訓練一致的精度，即矩陣計算和dispatch傳輸採用和訓練一致的FP8格式，core-attention計算和combine傳輸採用和訓練一致的BF16，最大程度保證了服務效果。

另外，由於白天的服務負荷高，晚上的服務負荷低，因此我們實現了一套機制，在白天負荷高的時候，用所有節點部署推理服務。晚上負荷低的時候，減少推理節點，以用來做研究和訓練。在最近的24小時裡（北京時間2025/02/27 12:00至2025/02/28 12:00），DeepSeekV3和R1推理服務佔用節點總和，峰值佔用為278個節點，平均佔用226.75個節點（每個節點為8個H800 GPU）。假定GPU租賃成本為2美金/小時，總成本為$87,072/天。