官方推文中提到，DeepSeek-V3和R1在線推理系統(tǒng)的優(yōu)化重點(diǎn)有兩個(gè)，就是提高吞吐量和降低延遲。

其中，吞吐量就是每秒能輸入和輸出的Token（也就是文字）數(shù)量，越多越好。延遲就是輸入后得到響應(yīng)的等待時(shí)間，越短越好。

第一個(gè)：大規(guī)模的跨節(jié)點(diǎn)專家并行方案——EP

DeepSeek是MoE模型，MoE（Mixture of Experts，專家混合）的核心思想就是把模型拆分成多個(gè)“專家”（Experts），每個(gè)專家都是一個(gè)獨(dú)立的神經(jīng)網(wǎng)絡(luò)模塊。

所以，它的優(yōu)化主要靠跨節(jié)點(diǎn)的專家并行（Expert Parallelism, 簡稱EP）方案來實(shí)現(xiàn)。EP非常關(guān)鍵，它能讓多個(gè)GPU高效協(xié)作，提高效率和性能。

DeepSeek-V3和R1有256個(gè)專家模型，EP方案讓不同的GPU只處理其中的8個(gè)，于是就減少了單個(gè)GPU的內(nèi)存訪問需求，降低了延遲。

同時(shí)，DeepSeek通過EP來支持更大的Batch Size（一次批量處理的數(shù)據(jù)），讓每個(gè)專家模型能處理更多數(shù)據(jù)，從而提高GPU的矩陣計(jì)算效率，提高吞吐。

推理通常分為兩個(gè)階段，包括預(yù)填充階段和解碼階段。預(yù)填充階段負(fù)責(zé)一次性處理所有輸入（類似于編碼階段），解碼階段負(fù)責(zé)根據(jù)輸入生成輸出（也就是生成階段）。所以，這兩個(gè)階段采用的并行方案也不太一樣。

第二個(gè)，用交替執(zhí)行的策略讓計(jì)算和通訊的執(zhí)行時(shí)間重疊

大規(guī)模并行系統(tǒng)比一體機(jī)負(fù)載，因?yàn)榇笠?guī)模EP需要在多個(gè)GPU之間傳輸數(shù)據(jù)，這會(huì)帶來很大的通信開銷，如果處理不好，就會(huì)導(dǎo)致計(jì)算等待數(shù)據(jù)通信，影響整體效率。

為了解決這個(gè)問題，DeepSeek使用了一種雙批次重疊（Dual-Batch Overlap） 策略，讓計(jì)算和通信盡可能同時(shí)進(jìn)行，減少等待時(shí)間，提高吞吐量。

大致原理上，DeepSeek把一個(gè)批次（batch）拆成兩個(gè)小批次，然后交替執(zhí)行。比如，當(dāng)?shù)谝粋€(gè)小批次在計(jì)算時(shí)，第二個(gè)小批次就可以進(jìn)行通信。當(dāng)?shù)诙€(gè)小批次開始計(jì)算時(shí)，第一個(gè)小批次就可以進(jìn)行通信。

預(yù)填充和解碼階段略有不同，但原理相似。這樣一來，通信的時(shí)間就被“隱藏”在計(jì)算過程中了，而不是讓計(jì)算等著通信完成。效率和延遲情況得到優(yōu)化！

第三個(gè)，在三個(gè)層面上做了負(fù)載均衡

在DeepSeek-V3/R1這種大規(guī)模并行的推理系統(tǒng)中，如果某個(gè)GPU計(jì)算或通信負(fù)擔(dān)過重，其他GPU劃水，就會(huì)造成性能瓶頸，導(dǎo)致整個(gè)系統(tǒng)變慢，無法充分利用資源。

為此，DeepSeek試試了三個(gè)負(fù)載均衡策略：

預(yù)填充階段的負(fù)載均衡：由于不同請求的工作量不同，會(huì)導(dǎo)致某些GPU計(jì)算注意力（Attention）的負(fù)擔(dān)過重，有的GPU可能在劃水。而DeepSeek讓每個(gè)GPU處理輸入的Token數(shù)量盡量相當(dāng)，均衡了各GPU的計(jì)算量，從而讓每個(gè)GPU都高效運(yùn)作。

解碼階段的負(fù)載均衡也會(huì)因?yàn)檎埱笠幚淼墓ぷ髁坎煌?，?dǎo)致負(fù)載不均衡，特別是在 KVCache的使用上。通過讓KVCache的使用在GPU之間均衡分配，避免某些GPU計(jì)算過載，某些空閑，而導(dǎo)致等待，影響效率。

MoE的并行負(fù)載均衡：MoE模型中，不同的專家（experts）計(jì)算任務(wù)不同，某些“熱門”專家可能被調(diào)用得更多，導(dǎo)致某些GPU計(jì)算壓力過大。DeepSeek通過讓所有GPU處理的專家計(jì)算任務(wù)盡量均衡，以此來優(yōu)化專家分配策略，提高整體計(jì)算效率。

最終，通過合理的負(fù)載均衡，讓所有GPU計(jì)算時(shí)間盡可能相近，減少等候時(shí)間，以提高整個(gè)系統(tǒng)的效率和性能。

DeepSeek官方推理服務(wù)的運(yùn)營細(xì)節(jié)，收益率爆表！

介紹完這些技術(shù)細(xì)節(jié)后，DeepSeek還介紹了在線推理服務(wù)的很多個(gè)細(xì)節(jié)，每個(gè)H800 GPU節(jié)點(diǎn)每秒支持73.7K和14.8k的輸入輸出Token，說明吞吐性能很高。

并且，雖然幻方很有錢，但在線服務(wù)的運(yùn)營成本控制的很好，成本利潤率高達(dá)545%，收益遠(yuǎn)超成本。

從介紹中看到，所有DeepSeek-V3/R1推理服務(wù)都在英偉達(dá)H800 GPU 上提供，精度與訓(xùn)練一致。具體來說，矩陣乘法和調(diào)度傳輸采用與訓(xùn)練一致的 FP8 格式，而核心 MLA計(jì)算和組合傳輸則使用 BF16，以確保最佳服務(wù)性能。

此外，由于白天服務(wù)負(fù)載高，夜間負(fù)載低，DeepSeek實(shí)施了一種機(jī)制，在白天高峰時(shí)段跨所有節(jié)點(diǎn)部署推理服務(wù)。在低負(fù)載的夜間時(shí)段，減少推理節(jié)點(diǎn)并分配資源進(jìn)行研究和訓(xùn)練。

在過去 24 小時(shí)期間，V3和R1推理服務(wù)的總峰值節(jié)點(diǎn)占用了 278 個(gè)，平均占用 226.75 個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)包含8個(gè)H800顯卡。假設(shè)一個(gè)H800的租賃成本為每小時(shí)2 美元，則每天總成本為 87072 美元，約合人民幣63萬。

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

輸入的Token總數(shù)為6080億，其中3420億Token命中了磁盤上的 KVCache，命中率56.3%?？傒敵鯰oken為1680億，平均輸出速度為每秒 20-22Token。

每個(gè) H800 節(jié)點(diǎn)在預(yù)填充期間提供約73700個(gè)Token/s的輸入（包括緩存命中）的平均吞吐量，在解碼期間提供每秒14800個(gè)Token的輸出。

以上統(tǒng)計(jì)信息包括來自網(wǎng)頁對話框、手機(jī)APP 和 API 的所有用戶請求。

如果所有Token都按照 DeepSeek-R1 的定價(jià)計(jì)費(fèi)，則每日總收入將為562027美元，約合人民幣409萬，收入是成本的6.4倍，利潤率為545%。

但實(shí)際上，由于DeepSeek-V3 的定價(jià)明顯低于 R1，而且現(xiàn)在網(wǎng)頁對話框和APP都是免費(fèi)提供的，付費(fèi)的API在非高峰時(shí)段還有折扣，所以，實(shí)際收入要遠(yuǎn)低于409萬。

這充分證明，如果采用DeepSeek的各種優(yōu)化技術(shù)來在集群里部署滿血版的服務(wù)，則可以實(shí)現(xiàn)比較大的利潤空間。

另外，目前還不知道與本地單機(jī)8張H800部署滿血版的方案相比，在線集群部署的性價(jià)比差異大致是什么情況。

zhupb