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

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

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

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

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

DeepSeek 采用多機(jī)多卡間的專家并行策略來(lái)達(dá)到以下目的：

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

計(jì)算通信重疊

多機(jī)多卡的專家并行會(huì)引入比較大的通信開(kāi)銷，因此使用雙 batch 重疊來(lái)掩蓋通信開(kāi)銷，提高整體吞吐。

對(duì)于 prefill 階段，兩個(gè) batch 的計(jì)算和通信交錯(cuò)進(jìn)行，一個(gè) batch 在進(jìn)行計(jì)算的時(shí)候可以去掩蓋另一個(gè) batch 的通信開(kāi)銷;

Prefill 階段的雙 batch 重疊

對(duì)于 decode 階段，不同階段的執(zhí)行時(shí)間有所差別，因此將 attention 部分拆成了兩個(gè) stage，共計(jì) 5 個(gè) stage 的流水線來(lái)實(shí)現(xiàn)計(jì)算和通信的重疊。

Decode 階段的雙 batch 重疊

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

盡可能地負(fù)載均衡

由于采用了很大規(guī)模的并行(包括數(shù)據(jù)并行和專家并行)，如果某個(gè) GPU 的計(jì)算或通信負(fù)載過(guò)重，將成為性能瓶頸，拖慢整個(gè)系統(tǒng);同時(shí)其他 GPU 因?yàn)榈却辙D(zhuǎn)，造成整體利用率下降。因此需盡可能為每個(gè) GPU 分配均衡的計(jì)算負(fù)載、通信負(fù)載。

Prefill Load Balancer

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

Decode Load Balancer

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

Expert-Parallel Load Balancer

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

參考架構(gòu)圖

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

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

• 白天負(fù)荷高時(shí)用所有節(jié)點(diǎn)部署推理服務(wù)。
• 晚上負(fù)荷低時(shí)，減少推理節(jié)點(diǎn)，以用來(lái)做研究和訓(xùn)練。、

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

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

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

“當(dāng)然我們實(shí)際上沒(méi)有這么多收入，因?yàn)?V3 的定價(jià)更低，同時(shí)收費(fèi)服務(wù)只占了一部分，另外夜間還會(huì)有折扣?！?/p>

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