3 月 1 日消息，DeepSeek 官方今日在知乎發(fā)布《DeepSeek-V3 / R1 推理系統(tǒng)概覽》一文，詳細介紹如何使用大規(guī)模跨節(jié)點專家并行(Expert Parallelism / EP)來增大 batch size，如何隱藏傳輸?shù)暮臅r，如何進行負載均衡。

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

IT之家附 DeepSeek 提出的方案如下：

大規(guī)模跨節(jié)點專家并行(Expert Parallelism / EP)

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

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

• 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

• 核心問題：不同數(shù)據(jù)并行(DP)實例上的請求個數(shù)、長度不同，導致 core-attention 計算量、dispatch 發(fā)送量也不同
• 優(yōu)化目標：各 GPU 的計算量盡量相同(core-attention 計算負載均衡)、輸入的 token 數(shù)量也盡量相同(dispatch 發(fā)送量負載均衡)，避免部分 GPU 處理時間過長

Decode Load Balancer

• 核心問題：不同數(shù)據(jù)并行(DP)實例上的請求數(shù)量、長度不同，導致 core-attention 計算量(與 KVCache 占用量相關(guān))、dispatch 發(fā)送量不同
• 優(yōu)化目標：各 GPU 的 KVCache 占用量盡量相同(core-attention 計算負載均衡)、請求數(shù)量盡量相同(dispatch 發(fā)送量負載均衡)

Expert-Parallel Load Balancer

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

參考架構(gòu)圖

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

DeepSeek V3 和 R1 的所有服務均使用 H800 GPU，使用和訓練一致的精度，即矩陣計算和 dispatch 傳輸采用和訓練一致的 FP8 格式，core-attention 計算和 combine 傳輸采用和訓練一致的 BF16，最大程度保證了服務效果。另外，由于白天的服務負荷高，晚上的服務負荷低，因此 DeepSeek 實現(xiàn)了一套機制：

• 白天負荷高時用所有節(jié)點部署推理服務。
• 晚上負荷低時，減少推理節(jié)點，以用來做研究和訓練。、

在最近的 24 小時里(北京時間 2025/02/27 12:00 至 2025/02/28 12:00)，DeepSeek V3 和 R1 推理服務占用節(jié)點總和，峰值占用為 278 個節(jié)點，平均占用 226.75 個節(jié)點(每個節(jié)點為 8 個 H800 GPU)。假定 GPU 租賃成本為 2 美金 / 小時，總成本為 $87,072 / 天。

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

• 輸入 token 總數(shù)為 608B，其中 342B tokens(56.3%)命中 KVCache 硬盤緩存。
• 輸出 token 總數(shù)為 168B。平均輸出速率為 20~22 tps，平均每輸出一個 token 的 KVCache 長度是 4989。
• 平均每臺 H800 的吞吐量為：對于 prefill 任務，輸入吞吐約 73.7k tokens / s(含緩存命中);對于 decode 任務，輸出吞吐約 14.8k tokens / s。以上統(tǒng)計包括了網(wǎng)頁、APP 和 API 的所有負載。如果所有 tokens 全部按照 DeepSeek R1 的定價計算，理論上一天的總收入為 $562,027，成本利潤率 545%。

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

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