IT之家 3 月 1 日消息，DeepSeek 官方今日在知乎發(fā)布《DeepSeek-V3 / R1 推理系統(tǒng)概覽》一文，詳細(xì)介紹如何使用大規(guī)?？绻?jié)點(diǎn)專家并行（Expert Parallelism / EP）來增大 batch size，如何隱藏傳輸?shù)暮臅r，如何進(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 個專家中僅激活其中 8 個。模型的高度稀疏性決定了 DeepSeek 必須采用很大的 overall batch size，才能給每個專家提供足夠的 expert batch size，從而實現(xiàn)更大的吞吐、更低的延時。需要大規(guī)?？绻?jié)點(diǎn)專家并行（Expert Parallelism / EP）。
DeepSeek 采用多機(jī)多卡間的專家并行策略來達(dá)到以下目的：
Prefill：路由專家 EP32、MLA 和共享專家 DP32，一個部署單元是 4 節(jié)點(diǎn)，32 個冗余路由專家，每張卡 9 個路由專家和 1 個共享專家
Decode：路由專家 EP144、MLA 和共享專家 DP144，一個部署單元是 18 節(jié)點(diǎn)，32 個冗余路由專家，每張卡 2 個路由專家和 1 個共享專家
計算通信重疊
多機(jī)多卡的專家并行會引入比較大的通信開銷，因此使用雙 batch 重疊來掩蓋通信開銷，提高整體吞吐。
對于 prefill 階段，兩個 batch 的計算和通信交錯進(jìn)行，一個 batch 在進(jìn)行計算的時候可以去掩蓋另一個 batch 的通信開銷；
Prefill 階段的雙 batch 重疊 對于 decode 階段，不同階段的執(zhí)行時間有所差別，因此將 attention 部分拆成了兩個 stage，共計 5 個 stage 的流水線來實現(xiàn)計算和通信的重疊。
Decode 階段的雙 batch 重疊 關(guān)于更多雙 batch 重疊的細(xì)節(jié)，可參考 profiling 數(shù)據(jù) GitHub 倉庫：https://github.com/deepseek-ai/profile-data。
盡可能地負(fù)載均衡
由于采用了很大規(guī)模的并行（包括數(shù)據(jù)并行和專家并行），如果某個 GPU 的計算或通信負(fù)載過重，將成為性能瓶頸，拖慢整個系統(tǒng)；同時其他 GPU 因為等待而空轉(zhuǎn)，造成整體利用率下降。因此需盡可能為每個 GPU 分配均衡的計算負(fù)載、通信負(fù)載。
Prefill Load Balancer
核心問題：不同數(shù)據(jù)并行（DP）實例上的請求個數(shù)、長度不同，導(dǎo)致 core-attention 計算量、dispatch 發(fā)送量也不同
優(yōu)化目標(biāo)：各 GPU 的計算量盡量相同（core-attention 計算負(fù)載均衡）、輸入的 token 數(shù)量也盡量相同（dispatch 發(fā)送量負(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 計算負(fù)載均衡）、請求數(shù)量盡量相同（dispatch 發(fā)送量負(fù)載均衡）
Expert-Parallel Load Balancer
核心問題：對于給定 MoE 模型，存在一些天然的高負(fù)載專家（expert），導(dǎo)致不同 GPU 的專家計算負(fù)載不均衡
優(yōu)化目標(biāo)：每個 GPU 上的專家計算量均衡（即最小化所有 GPU 的 dispatch 接收量的最大值）
參考架構(gòu)圖
線上系統(tǒng)的實際統(tǒng)計數(shù)據(jù)
DeepSeek V3 和 R1 的所有服務(wù)均使用 H800 GPU，使用和訓(xùn)練一致的精度，即矩陣計算和 dispatch 傳輸采用和訓(xùn)練一致的 FP8 格式，core-attention 計算和 combine 傳輸采用和訓(xùn)練一致的 BF16，最大程度保證了服務(wù)效果。另外，由于白天的服務(wù)負(fù)荷高，晚上的服務(wù)負(fù)荷低，因此 DeepSeek 實現(xiàn)了一套機(jī)制：
白天負(fù)荷高時用所有節(jié)點(diǎn)部署推理服務(wù)。
晚上負(fù)荷低時，減少推理節(jié)點(diǎn)，以用來做研究和訓(xùn)練。、
在最近的 24 小時里（北京時間 2025/02/27 12:00 至 2025/02/28 12:00），DeepSeek V3 和 R1 推理服務(wù)占用節(jié)點(diǎn)總和，峰值占用為 278 個節(jié)點(diǎn)，平均占用 226.75 個節(jié)點(diǎn)（每個節(jié)點(diǎn)為 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 任務(wù)，輸入吞吐約 73.7k tokens / s（含緩存命中）；對于 decode 任務(wù)，輸出吞吐約 14.8k tokens / s。以上統(tǒng)計包括了網(wǎng)頁、APP 和 API 的所有負(fù)載。如果所有 tokens 全部按照 DeepSeek R1 的定價計算，理論上一天的總收入為 $562,027，成本利潤率 545%。
“當(dāng)然我們實際上沒有這么多收入，因為 V3 的定價更低，同時收費(fèi)服務(wù)只占了一部分，另外夜間還會有折扣。”
DeepSeek R1 的定價：$0.14 / 百萬輸入 tokens (緩存命中)，$0.55 / 百萬輸入 tokens (緩存未命中)，$2.19 / 百萬輸出 tokens。
廣告聲明：文內(nèi)含有的對外跳轉(zhuǎn)鏈接（包括不限于超鏈接、二維碼、口令等形式），用于傳遞更多信息，節(jié)省甄選時間，結(jié)果僅供參考，IT之家所有文章均包含本聲明。