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

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

重點包括，優(yōu)化吞吐量和延遲的方法：

• 跨節(jié)點EP驅(qū)動的批量擴展
• 計算與通信重疊
• 負載均衡

還公布了DeepSeek的在線服務(wù)數(shù)據(jù)統(tǒng)計：

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

更多細節(jié)，一起來看官方原文↓

更大的吞吐，更低的延遲

DeepSeek-V3/R1推理系統(tǒng)的優(yōu)化目標(biāo)是：更大的吞吐，更低的延遲。

為了實現(xiàn)這兩個目標(biāo)，我們的方案是使用大規(guī)模跨節(jié)點專家并行（ExpertParallelism/EP）。

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

但EP同時也增加了系統(tǒng)的復(fù)雜性。復(fù)雜性主要體現(xiàn)在兩個方面：

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

因此，本文的主要內(nèi)容是如何使用EP增大batch size，如何隱藏傳輸?shù)暮臅r，如何進行負載均衡。

大規(guī)?？绻?jié)點專家并行（Expert Parallelism/EP）

由于DeepSeek-V3/R1的專家數(shù)量眾多，并且每層256個專家中僅激活其中8個。模型的高度稀疏性決定了我們必須采用很大的overall batch size，才能給每個專家提供足夠的expert batch size，從而實現(xiàn)更大的吞吐、更低的延時。需要大規(guī)?？绻?jié)點專家并行（Expert Parallelism/EP）。

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

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

計算通信重疊

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

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

△Prefill階段的雙batch重疊

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

△Decode階段的雙batch重疊

關(guān)于更多雙batch重疊的細節(jié)，可以參考我們的profiling數(shù)據(jù)的GitHub倉庫：https://github.com/deepseek-ai/profile-data。

盡可能地負載均衡

由于采用了很大規(guī)模的并行（包括數(shù)據(jù)并行和專家并行），如果某個GPU的計算或通信負載過重，將成為性能瓶頸，拖慢整個系統(tǒng)；同時其他GPU因為等待而空轉(zhuǎn)，造成整體利用率下降。因此我們需要盡可能地為每個GPU分配均衡的計算負載、通信負載。

• Prefill Load Balancer

a.核心問題：不同數(shù)據(jù)并行（DP）實例上的請求個數(shù)、長度不同，導(dǎo)致core-attention計算量、dispatch發(fā)送量也不同

b.優(yōu)化目標(biāo)：各GPU的計算量盡量相同（core-attention計算負載均衡）、輸入的token數(shù)量也盡量相同（dispatch發(fā)送量負載均衡），避免部分GPU處理時間過長

• Decode Load Balancer
• 核心問題：不同數(shù)據(jù)并行（DP）實例上的請求數(shù)量、長度不同，導(dǎo)致core-attention計算量（與KVCache占用量相關(guān)）、dispatch發(fā)送量不同
• 優(yōu)化目標(biāo)：各GPU的KVCache占用量盡量相同（core-attention計算負載均衡）、請求數(shù)量盡量相同（dispatch發(fā)送量負載均衡）
• Expert-Parallel Load Balancer
• 核心問題：對于給定MoE模型，存在一些天然的高負載專家（expert），導(dǎo)致不同GPU的專家計算負載不均衡
• 優(yōu)化目標(biāo)：每個GPU上的專家計算量均衡（即最小化所有GPU的dispatch接收量的最大值）

參考架構(gòu)圖

線上系統(tǒng)的實際統(tǒng)計數(shù)據(jù)

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

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

在24小時統(tǒng)計時段內(nèi)，DeepSeekV3和R1：

輸入token總數(shù)為608B，其中342B tokens（56.3%）命中KVCache硬盤緩存。

輸出token總數(shù)為168B。平均輸出速率為20~22tps，平均每輸出一個token的KVCache長度是4989。

平均每臺H800的吞吐量為：對于prefill任務(wù)，輸入吞吐約73.7k tokens/s（含緩存命中）；對于decode任務(wù)，輸出吞吐約14.8k tokens/s。

以上統(tǒng)計包括了網(wǎng)頁、APP和API的所有負載。如果所有tokens全部按照DeepSeek R1的定價*計算，理論上一天的總收入為$562,027，成本利潤率545%。

*DeepSeek R1的定價：$0.14/百萬輸入tokens(緩存命中)，$0.55/百萬輸入tokens(緩存未命中)，$2.19/百萬輸出tokens。

當(dāng)然我們實際上沒有這么多收入，因為V3的定價更低，同時收費服務(wù)只占了一部分，另外夜間還會有折扣。