作者 | 程茜

編輯 | 心緣

智東西3月1日消息，DeepSeek的開源周竟然還有彩蛋！開源第六天，DeepSeek不僅放出了DeepSeek-V3/R1推理系統技術祕籍，還公開了每日成本和理論收入！

DeepSeek統計了2月27日24點到2月28日24點，計算出其每日總成本爲87072美元（摺合人民幣約63萬元）。如果所有Token都以DeepSeek-R1的價格計費，每日總收入將爲562027美元（摺合人民幣約409萬元），成本利潤率達到545%。也就是說，理論上DeepSeek每日淨賺474955美元（摺合人民幣約346萬元）。

但實際情況是，DeepSeek的收入大幅下降。由於DeepSeek-V3定價低於R1；網頁端和應用程序免費，只有部分服務有收入；非高峯時段還有夜間折扣，使得其實際收入並沒有這麼高。

此外，DeepSeek還公開了DeepSeek-V3/R1推理系統概述：爲了達到推理更高的吞吐量和更低的延遲，研究人員採用了跨節點的專家諮詢（EP），並且利用EP增大batch size、將通信延遲隱藏在計算之後、執行負載均衡，應對EP的系統複雜性挑戰。

發佈一小時，GitHub Star數已超過5600。

評論區的網友頻頻cue OpenAI，直呼“被搶劫”了！

還有網友以OpenAI的定價幫DeepSeek算賬：

一、每日總成本爲87072美元，利潤率理論上最高545%

DeepSeek V3和R1的所有服務均使用H800 GPU，使用和訓練一致的精度，即矩陣計算和dispatch傳輸採用和訓練一致的FP8格式，core-attention計算和combine傳輸採用和訓練一致的BF16，最大程度保證了服務效果。

此外，由於白天的高服務負載和晚上的低負載，DeepSeek在白天高峯時段跨所有節點部署推理服務。在低負載的夜間時段減少了推理節點，並將資源分配給研究和訓練。

在過去的24小時內（2月27日24點到2月28日24點），V3和R1推理服務的合併峯值節點佔用率達到278，平均佔用率爲226.75個節點（每個節點包含8個H800 GPU）。假設一個H800 GPU的租賃成本爲每小時2美元，則每日總成本爲87072美元。

▲推理服務的H800節點計數

在24小時統計週期內（2月27日24點到2月28日24點），V3和R1：

總輸入Token 608B，其中342B Token（56.3%）命中KVCache硬盤緩存。

總輸出Token 168B，平均輸出速度爲每秒20-22 tps，每個輸出Token的平均kvcache長度爲4989個Token。

每個H800節點在prefill期間提供約73.7k token/s輸入（包括緩存命中）的平均吞吐量，或在解碼期間提供約14.8k token/s輸出。

以上統計數據包括所有來自web、APP、API的用戶請求。

如果所有Token都以DeepSeek-R1的價格計費，每日總收入將爲562027美元，成本利潤率爲545%。

*R1的定價：0.14美元輸入Token（緩存命中），0.55美元輸入令牌（緩存未命中），2.19美元輸出令牌。

然而，DeepSeek的實際收入並沒有這麼多，其原因是DeepSeek-V3的定價明顯低於R1；網頁端和應用程序免費，所有隻有一部分服務被貨幣化；夜間折扣在非高峯時段自動適用。

▲成本和理論收入

二、EP增加系統複雜性，三大策略應對

DeepSeek的解決方案採用了跨節點的專家並行（EP）。

首先，EP顯著擴展了批處理大小，增強了GPU矩陣計算效率並提高了吞吐量；其次，EP將專家分佈在不同GPU上，每個GPU只處理專家的一小部分（減少內存訪問需求），從而降低延遲。

然而，EP在兩個方面增加了系統複雜性：EP引入跨節點的傳輸，爲了優化吞吐，需要設計合適的計算流程使得傳輸和計算可以同步進行；EP涉及多個節點，因此天然需要Data Parallelism（DP），不同的DP之間需要進行負載均衡。

DeepSeek通過三種方式應對了這些挑戰：

利用EP增大batch size、將通信延遲隱藏在計算之後、執行負載均衡。

1、大規模跨節點專家並行（EP）

由於DeepSeek-V3/R1的專家數量衆多，並且每層256個專家中僅激活其中8個。模型的高度稀疏性決定了其必須採用很大的overall batch size，才能給每個專家提供足夠的expert batch size，從而實現更大的吞吐、更低的延時。需要大規模跨節點專家並行（Expert Parallelism/EP）。

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

Prefill：路由專家EP32、MLA和共享專家DP32，一個部署單元是4節點，32個冗餘路由專家，每張卡9個路由專家和1個共享專家

Decode：路由專家EP144、MLA和共享專家DP144，一個部署單元是18節點，32個冗餘路由專家，每張卡2個路由專家和1個共享專家

2、計算-通信重疊

多機多卡的專家並行會引入比較大的通信開銷，所以使用了雙batch重疊來掩蓋通信開銷，提高整體吞吐。

對於prefill階段，兩個batch的計算和通信交錯進行，一個batch在進行計算的時候可以去掩蓋另一個batch的通信開銷。

▲預充階段的通信-計算重疊

對於decode階段，不同階段的執行時間有所差別，所以DeepSeek把attention部分拆成了兩個stage，共計5個stage的流水線來實現計算和通信的重疊。

▲解碼階段的通信-計算重疊

3、實現最佳負載均衡

由於採用了很大規模的並行（包括數據並行和專家並行），如果某個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發送量負載均衡）。

專家並行負載均衡器的核心問題：對於給定MoE模型，存在一些天然的高負載專家（expert），導致不同GPU的專家計算負載不均衡。

其優化目標是，每個GPU上的專家計算量均衡（即最小化所有GPU的dispatch接收量的最大值）。

▲DeepSeek在線推理系統圖