過去一周，DeepSeek 連續開放了 5 個 Infra 項目的源代碼，正當大家以爲這場開源盛宴已經結束。
剛剛，DeepSeek 的彩蛋來了！開源周 Day6，DeepSeek 官方團隊在 Github 和知乎給出了 DeepSeek-V3 / R1 推理系統的技術解讀。
先說結論：通過優化吞吐和延遲，DeepSeek「理論上一天的總收入爲 $562,027，成本利潤率 545%。」
敏銳的網友——如 MenloVentures 投資人 Deedy 翻譯了這意味着什麽：「理論 ARR 2 億美金、利潤率超過 500%，這樣的商業效率理應是一家值 100 億美金的公司。」
從 2024 年 5 月發布 DeepSeekV2 以來，DeepSeek 模型服務就以「價格屠夫」示衆，總是比行業其他模型便宜 1/10 左右，質疑 DeepSeek 虧本打價格戰的聲音也一直有。
通過這 5 天開放源代碼以及今天的推理系統概述，這一疑慮也被打消，可以預見，模型推理價格越來越負擔得起，且服務提供方也有得賺。這一事件的影響也可以通過 X 平台網友展現出刷屏的驚喜得以一窺，「成本利潤率 545%，等于說你是在告訴我，我被 Open AI 搶劫了？開源周 Day7 的彩蛋是 AGI？」
但更大的信号指向生态夥伴，部署 DeepSeek 有得賺。
一位 AI 領域的投資人向極客公園闡述，「官方技術解讀表明，雲平台和上下遊通過部署 DeepSeek 的服務，理論上收益和利潤率可以達到很高」。無論是對于提供在線推理、還是私有化部署等服務的供應商，都是利好。
在這波 DeepSeek 熱中受益的雲平台矽基流動創始人袁進輝也在第一時間發表了自己的感受，「DeepSeek 官方披露大規模部署成本和收益，又一次颠覆了很多人認知。」
但需要時間适配 DeepSeek V3/R1 模型架構，他表示「現在很多供應商還做不到這個水平，主要是 V3/R1 架構和其它主流模型差别太大了，由大量小 Expert 組成，導緻瞄準其它主流模型結構開發的系統都不再有效，必須按照 DeepSeek 報告描述的方法才能達到最好的效率，而開發這樣的系統難度很高，需要時間」。
他進一步指出現在複現這樣的推理服務的難度以及 DeepSeek 可能的戰略思考，「幸好這周 DeepSeek 五連發已經把主要模塊開源出來了，降低了社區複現的難度。這些成果充分體現了 DeepSeek 團隊第一性原理的思考方式和強悍的意志，他們應該是首先是基于某些原因（？）想到了用這樣的模型結構，然後發現這樣的結構無論是訓練還是推理，要做好都有非常大的工程挑戰，不過這些問題在他們工程團隊來說并不是搞不定的，關鍵是花那麽大力氣做完是否有大的收益呢，在最終結果出來前，誰也說不準，他們還是賭了，結果是賭對了。也可能是反過來的，基于系統的出發點設計了這樣一個全新的模型結構。」
在 DeepSeek 官方報告中也提示了 DeepSeek-V3 / R1 推理系統的優化目标是：更大的吞吐，更低的延遲。配合技術解讀，DeepSeek 開源周放出的 5 個代碼庫帶來的影響力才剛剛開始。
附：《DeepSeek-V3 / R1 推理系統概覽全文
DeepSeek-V3 / R1 推理系統的優化目标是：更大的吞吐，更低的延遲。
爲了實現這兩個目标，我們的方案是使用大規模跨節點專家并行（Expert Parallelism / EP）。首先 EP 使得 batch size 大大增加，從而提高 GPU 矩陣乘法的效率，提高吞吐。其次 EP 使得專家分散在不同的 GPU 上，每個 GPU 隻需要計算很少的專家（因此更少的訪存需求），從而降低延遲。
但 EP 同時也增加了系統的複雜性。複雜性主要體現在兩個方面：
EP 引入跨節點的傳輸。爲了優化吞吐，需要設計合适的計算流程使得傳輸和計算可以同步進行。
EP 涉及多個節點，因此天然需要 Data Parallelism（DP），不同的 DP 之間需要進行負載均衡。
因此，本文的主要内容是如何使用 EP 增大 batch size，如何隐藏傳輸的耗時，如何進行負載均衡。
01 大規模跨節點專家并行（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 個共享專家
02 計算通信重疊
多機多卡的專家并行會引入比較大的通信開銷，所以我們使用了雙 batch 重疊來掩蓋通信開銷，提高整體吞吐。
對于 prefill 階段，兩個 batch 的計算和通信交錯進行，一個 batch 在進行計算的時候可以去掩蓋另一個 batch 的通信開銷；
Prefill 階段的雙 batch 重疊
對于 decode 階段，不同階段的執行時間有所差别，所以我們把 attention 部分拆成了兩個 stage，共計 5 個 stage 的流水線來實現計算和通信的重疊。
Decode 階段的雙 batch 重疊
關于更多雙 batch 重疊的細節，可以參考我們的 profiling 數據的 GitHub 倉庫：https://github.com/deepseek-ai/profile-data。
03 盡可能地負載均衡
由于采用了很大規模的并行（包括數據并行和專家并行），如果某個 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 接收量的最大值）
04 參考架構圖
05 線上系統的實際統計數據
DeepSeek V3 和 R1 的所有服務均使用 H800 GPU，使用和訓練一緻的精度，即矩陣計算和 dispatch 傳輸采用和訓練一緻的 FP8 格式，core-attention 計算和 combine 傳輸采用和訓練一緻的 BF16，最大程度保證了服務效果。
另外，由于白天的服務負荷高，晚上的服務負荷低，因此我們實現了一套機制，在白天負荷高的時候，用所有節點部署推理服務。晚上負荷低的時候，減少推理節點，以用來做研究和訓練。在最近的 24 小時裏（北京時間 2025/02/27 12:00 至 2025/02/28 12:00），DeepSeek V3 和 R1 推理服務占用節點總和，峰值占用爲 278 個節點，平均占用 226.75 個節點（每個節點爲 8 個 H800 GPU）。假定 GPU 租賃成本爲 2 美金 / 小時，總成本爲 $87,072/ 天。
在 24 小時統計時段内，DeepSeek V3 和 R1：
輸入 token 總數爲 608B，其中 342B tokens（56.3%）命中 KVCache 硬盤緩存。
輸出 token 總數爲 168B。平均輸出速率爲 20~22 tps，平均每輸出一個 token 的 KVCache 長度是 4989。
平均每台 H800 的吞吐量爲：對于 prefill 任務，輸入吞吐約 73.7k tokens/s（含緩存命中）；對于 decode 任務，輸出吞吐約 14.8k tokens/s。
以上統計包括了網頁、APP 和 API 的所有負載。如果所有 tokens 全部按照 DeepSeek R1 的定價 ( [ 1 ] ) 計算，理論上一天的總收入爲 $562,027，成本利潤率 545%。
「當然我們實際上沒有這麽多收入，因爲 V3 的定價更低，同時收費服務隻占了一部分，另外夜間還會有折扣。」
參考
^DeepSeek R1 的定價：$0.14 / 百萬輸入 tokens ( 緩存命中 ) ，$0.55 / 百萬輸入 tokens ( 緩存未命中 ) ，$2.19 / 百萬輸出 tokens。
