DeepSeek突襲公布成本利潤率：545%

今天小編分享的科學經驗：DeepSeek突襲公布成本利潤率：545%，歡迎閲讀。

五連開源後，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/ 天。