科大訊飛深度解析DeepSeek-V3/R1推理系統(tǒng)成本

本篇分析來(lái)自科大訊飛技術(shù)團(tuán)隊(duì)，深度解析了DeepSeek-V3 / R1 推理系統(tǒng)成本，旨在助力開(kāi)發(fā)者實(shí)現(xiàn)高性價(jià)比的MoE集群部署方案。感謝訊飛研究院副院長(zhǎng)&AI工程院常務(wù)副院長(zhǎng)龍明康、AI工程院AI云平臺(tái)研發(fā)部總監(jiān)李珍松、訊飛星辰MaaS團(tuán)隊(duì)的研究對(duì)本文的貢獻(xiàn)。

一、分析團(tuán)隊(duì)背景簡(jiǎn)介

分析團(tuán)隊(duì)來(lái)自科大訊飛星辰MaaS團(tuán)隊(duì)，從語(yǔ)音小模型時(shí)代到認(rèn)知大模型時(shí)代，積累了豐富的大規(guī)模AI推理服務(wù)集群優(yōu)化及運(yùn)營(yíng)經(jīng)驗(yàn)，也支撐了國(guó)內(nèi)首個(gè)全國(guó)產(chǎn)萬(wàn)卡算力訓(xùn)推集群的上線。

二、分析目的

在MaaS賽道中，大家受益于DeepSeek-V3/R1開(kāi)源的壯舉，但也面臨著成本方面的壓力

由于DeepSeek未開(kāi)源推理服務(wù)器的整體集群方案以及公開(kāi)運(yùn)營(yíng)的更多細(xì)節(jié)，大部分MaaS產(chǎn)商的性能/成本優(yōu)化可能遠(yuǎn)不及DeepSeek當(dāng)前優(yōu)化的水平，我們希望通過(guò)更細(xì)節(jié)的過(guò)程分析，使得性能/成本綜合優(yōu)化方向更加清晰，結(jié)合DeepSeek開(kāi)源的高性能庫(kù)，更快實(shí)現(xiàn)高性價(jià)比的MoE集群部署方案

本文力求從應(yīng)用視角計(jì)算估算相關(guān)數(shù)據(jù)，方便大家參考，由于存在大量估算，難免存在錯(cuò)誤，請(qǐng)大家指正

DeepSeek原文鏈接，本文中的“原文”特指該鏈接內(nèi)容

三、影響成本的關(guān)鍵因素

快速理解DeepSeek MoE推理邏輯架構(gòu)

我們將DeepSeek MoE系統(tǒng)工程架構(gòu)類比成醫(yī)院就醫(yī)問(wèn)診流程架構(gòu)，方便大家理解。

MoE

依靠“專家”機(jī)制激活參數(shù)更小，更便宜

Prefill與Decode分離，計(jì)算更高效

KVCache緩存降低重復(fù)上下文計(jì)算

從單機(jī)到幾十機(jī)，負(fù)載均衡調(diào)度復(fù)雜性上升，既要降低用戶響應(yīng)時(shí)間，又要提升系統(tǒng)吞吐率，實(shí)現(xiàn)低成本，還要保障系統(tǒng)的可靠性（大專家EP并行工程關(guān)鍵難點(diǎn)）

醫(yī)院

不用花錢看更貴的“全科醫(yī)生”，看個(gè)別“?？漆t(yī)生”

問(wèn)診和醫(yī)技流程分離，流程更高效

歷史電子病歷、檢查報(bào)告，減少重復(fù)檢查

從全科室到多?？剖?，預(yù)約導(dǎo)診分流復(fù)雜度上升，既要縮短病人看病時(shí)間，也要提升各科室的問(wèn)診效率，實(shí)現(xiàn)醫(yī)院的效益，還要保障關(guān)鍵流程有效運(yùn)轉(zhuǎn)

MoE推理集群部署架構(gòu)概覽

備注：圖片來(lái)自知乎

關(guān)鍵概念描述

應(yīng)用側(cè)

APP：DeepSeek Web/APP端的C端用戶請(qǐng)求

API：DeepSeek API側(cè)的B端用戶請(qǐng)求

DAU：日均活躍用戶

total_usage：日均總使用次數(shù)

max_con：日峰值并發(fā)用戶請(qǐng)求數(shù)

TTFT：首token響應(yīng)時(shí)間

TPOT：平均每token輸出的時(shí)延，從原文中得知約為50ms（平均輸出速率為 20~22 tps）

系統(tǒng)側(cè)

API：指為API開(kāi)放所搭建的平臺(tái)服務(wù)器集群，由于具有較好的邊際成本遞減效應(yīng)，故不納入成本關(guān)鍵因素分析

Prefill 與 Decode：分別對(duì)應(yīng)原文中PD分離架構(gòu)中的兩個(gè)集群

N:M：由于我們并不清楚P與D的單元化集群配比是不是1:1，所以先假設(shè)是N:M，基于原文得知4*N+18*M=278

total_in/kvcache_rate/total_out/throughput_p/throughput_d：分別映射到原文中的總token與單機(jī)吞吐數(shù)據(jù)

運(yùn)營(yíng)側(cè)

SR_Cost：原文中提到的服務(wù)器平均占用率，由原文可知SR_Cost=226.75/278≈82%

SR_Use：指服務(wù)器集群利用率，通?？梢曰诜?wù)水位采樣監(jiān)控值曲線求面積，反算后得到利用率

SR_Available：指服務(wù)高峰期容量超限時(shí)，可用容量水位占實(shí)際用戶請(qǐng)求水位的比例

四、關(guān)鍵數(shù)據(jù)項(xiàng)分析過(guò)程

服務(wù)器集群利用率估算

原文中提到的服務(wù)器占用率，我們首先要將這個(gè)概念轉(zhuǎn)化為服務(wù)峰值容量、服務(wù)集群利用率這兩個(gè)概念。

DeepSeek-V3 和 R1 推理服務(wù)占用節(jié)點(diǎn)總和，峰值占用為 278 個(gè)節(jié)點(diǎn)，平均占用 226.75 個(gè)節(jié)點(diǎn)（每個(gè)節(jié)點(diǎn)為 8 個(gè) H800 GPU）

傳統(tǒng)互聯(lián)網(wǎng)應(yīng)用中通常會(huì)用并發(fā)用戶請(qǐng)求數(shù)或者QPS每秒請(qǐng)求任務(wù)數(shù)來(lái)量化系統(tǒng)的容量水位，由于AI類計(jì)算任務(wù)（如語(yǔ)音識(shí)別、語(yǔ)音合成、大模型交互）單次請(qǐng)求的計(jì)算時(shí)長(zhǎng)并不固定，因此通常使用并發(fā)用戶請(qǐng)求數(shù)來(lái)衡量系統(tǒng)容量水位。使用這種方式統(tǒng)計(jì)并實(shí)現(xiàn)相應(yīng)的負(fù)載調(diào)度能更好的保障SLA中的關(guān)鍵SLO（如成功率、TTFT、TPOT等）。

通常AI計(jì)算是一個(gè)分布式集群，所以需要采樣集群中所有節(jié)點(diǎn)的實(shí)時(shí)容量水位情況，max_con就是系統(tǒng)的并發(fā)峰值，也就是服務(wù)峰值容量（不考慮少量的容量冗余）。有了這個(gè)容量圖，就可以計(jì)算服務(wù)集群利用率。我們以訊飛星辰MaaS平臺(tái)上工作日24小時(shí)區(qū)間內(nèi)常見(jiàn)的C端大模型應(yīng)用請(qǐng)求并發(fā)趨勢(shì)為例（縱軸為并發(fā)容量%比例），通過(guò)計(jì)算采樣陰影部分的面積求和后與整體面積的比例估算后，得到服務(wù)集群利用率SR_Use ≈ 33%，即整個(gè)集群如果按照并發(fā)峰值水位一直計(jì)算，有效計(jì)算時(shí)間SR_Use_Time = 8小時(shí)。

我們將這個(gè)趨勢(shì)圖與原文中的服務(wù)器占用圖進(jìn)行對(duì)比，在波谷階段基本是一致的。根據(jù)原文信息可以測(cè)算出服務(wù)器平均占用率SR_Cost≈82%，這個(gè)值并不是我們提到的集群利用率，結(jié)合集群利用率估算后，可能會(huì)使得單機(jī)吞吐峰值大幅上漲。我們希望結(jié)合高峰期系統(tǒng)拒絕請(qǐng)求及恢復(fù)的時(shí)間點(diǎn)，估算出服務(wù)可用率的水位線SR_Available的值。

備注：圖片來(lái)自知乎 我們分別對(duì)DeepSeek API和網(wǎng)頁(yè)進(jìn)行了V3/R1采樣測(cè)試，時(shí)間在工作日3月13日~14日，得到如下數(shù)據(jù)：

對(duì)V3 API/網(wǎng)頁(yè)進(jìn)行全天24h采樣測(cè)試，全天測(cè)試成功率100%，表明V3請(qǐng)求峰值未超過(guò)集群容量

對(duì)R1 API/網(wǎng)頁(yè)進(jìn)行全天24h采樣測(cè)試，全天測(cè)試存在3個(gè)時(shí)間段成功率下滑、且對(duì)應(yīng)時(shí)間段的請(qǐng)求TTFT顯著增長(zhǎng)，分別為13:36~17:22，21:02~23:02，09:26~11:34，表明在該時(shí)間段內(nèi)請(qǐng)求峰值超過(guò)集群容量

由此可見(jiàn)，V3/R1存在集群隔離情況，且V3容量正常，推測(cè)V3使用量相比而言不高

在測(cè)試過(guò)程中，順便統(tǒng)計(jì)了低峰期首token的響應(yīng)時(shí)間均值TTFT≈9秒

以上測(cè)試時(shí)間是在原文發(fā)出之后，選擇的工作日時(shí)間測(cè)試，流量特征相對(duì)吻合

將R1成功率下滑時(shí)間段與C端并發(fā)趨勢(shì)圖進(jìn)行對(duì)比，可以看到除了晚上的峰值時(shí)間不完全一樣，其他兩個(gè)峰值基本吻合，由此可以大概估算出R1集群服務(wù)可用率水位線SR_Available≈60%。

從夜間H800節(jié)點(diǎn)圖可以看出最小集群時(shí)預(yù)留了60~70個(gè)節(jié)點(diǎn)，約2~3個(gè)部署單元。假設(shè)該集群中存在大量API24小時(shí)跑特定數(shù)據(jù)處理任務(wù)，那API對(duì)高利用率的貢獻(xiàn)應(yīng)該局限在這70個(gè)節(jié)點(diǎn)內(nèi)。小結(jié)一下，DeepSeek公開(kāi)的利用率相關(guān)的幾個(gè)數(shù)據(jù)整體合理，從集群整體層面提高利用率的可能性方法如下：

削峰，犧牲一定的SLA成功率，節(jié)省了峰值時(shí)需要額外增加但低谷時(shí)利用率偏低的服務(wù)器，預(yù)計(jì)削峰的可用率水位在60%以上。MaaS產(chǎn)商可以根據(jù)SLA做分級(jí)API產(chǎn)品

填谷，將實(shí)時(shí)任務(wù)與離線任務(wù)形成一體化集群，使用潮汐調(diào)度技術(shù)實(shí)現(xiàn)集群的利用率提升，降低實(shí)時(shí)任務(wù)服務(wù)器低谷期的占用攤銷18%，需要足夠的離線業(yè)務(wù)體量。MaaS產(chǎn)商可以發(fā)力離線產(chǎn)品的業(yè)務(wù)體量

服務(wù)器集群部署單元PD配比估算驗(yàn)證

原文中提到每個(gè)Prefill部署單元4個(gè)節(jié)點(diǎn)，Decode部署單元18個(gè)節(jié)點(diǎn)，總集群278個(gè)節(jié)點(diǎn)，我們需要計(jì)算出Prefill和Decode部署單元的配比，以便后續(xù)進(jìn)一步分析吞吐數(shù)據(jù)。估算步驟如下：

首先4*N+18*M=278，(N,M)=(65,1),=(56,3),=(47,5),=(38,7),=(29,9),=(20,11),=(11,13),=(2,15)

通過(guò)低谷期的節(jié)點(diǎn)數(shù)可以看出，L1水位約4*X1+18*Y1 在 60~70 (只能是偶數(shù))，L2擴(kuò)容小于2個(gè)Decode單元36臺(tái)，即4*X2+18*（Y1+1）在 90~100(只能是偶數(shù))

我們估計(jì)N=29，M=9，N:M ≈ 3.2。在L1水位時(shí)，X1=7，Y1=2，X1:Y1 ≈ 3.5，節(jié)點(diǎn)數(shù)為64。在L2水位時(shí)，X2= 10，Y1+1=3, X2:(Y1+1)≈ 3.3，節(jié)點(diǎn)數(shù)為40+54=94。整體與低谷水位圖吻合

Y1=2，意味著最低谷期時(shí)保留了一個(gè)V3部署單元，一個(gè)R1部署單元

備注：圖片來(lái)自知乎文章《DeepSeek-V3 / R1 推理系統(tǒng)概覽》 我們從原文中的吞吐的視角來(lái)計(jì)算一下這兩個(gè)值，基本吻合：

輸入608B*（1-56.3%）≈ 266B = 32.2k *24*3600*4*N，N≈23.9，考慮到機(jī)器占用率SR_Cost 82%，N≈23.9/82%≈29.15

輸出168B=14.8k*24*3600*18*M，M≈7.3，M≈23.9/82%≈8.9

基于這樣的配比，我們需要驗(yàn)證Prefill/Decode集群的處理能力是否一致。我們依舊以簡(jiǎn)化后的并發(fā)請(qǐng)求模式來(lái)計(jì)算相關(guān)值。在并發(fā)量一定的請(qǐng)求下，如果想保持Prefill/Decode兩個(gè)階段不積壓，需要在平均單位時(shí)間內(nèi)，兩階段完成的計(jì)算請(qǐng)求數(shù)一樣，如果再簡(jiǎn)化一下，就是每秒處理請(qǐng)求數(shù)QPS一樣。通過(guò)計(jì)算，兩階段的QPS十分接近，符合預(yù)期。

假設(shè)平均每個(gè)請(qǐng)求的輸入長(zhǎng)度為Avg_In = 608X tokens，非緩存計(jì)算的輸入長(zhǎng)度為Avg_In_P = 266X tokens，平均輸出長(zhǎng)度為Avg_Out = 168X tokens

Prefill階段的QPS_P = 73.7k *(1 - 56.3%)*4*29 tps /Avg_In_P ≈ 14045/X

Decode階段的QPS_D = 14.8k*18*9 tps/Avg_Out ≈ 14271/X

小結(jié)一下，考慮到V3和R1的輸入/輸出平均長(zhǎng)度不一樣，PD的配比也會(huì)不一樣，但總的來(lái)說(shuō)，公布的數(shù)據(jù)峰谷圖、吞吐、集群配比上能高度吻合，公開(kāi)數(shù)據(jù)合理。其中Prefill部署單元29個(gè)共116個(gè)節(jié)點(diǎn)，Decode部署單元9個(gè)共162個(gè)節(jié)點(diǎn)。

單機(jī)吞吐峰值與理論值估算驗(yàn)證

前面估算集群利用率，是為了將單機(jī)吞吐的平均值按照利用率換算為單機(jī)吞吐的峰值，這樣能更好的對(duì)比與理論值的差異，為工程優(yōu)化提供參考?？紤]到原文中集群存在削峰的情況，我們直接選取峰值階段1小時(shí)的吞吐數(shù)據(jù)來(lái)估算單機(jī)吞吐峰值。我們以峰值區(qū)間15:00~16:00為例：

該時(shí)間段服務(wù)器節(jié)點(diǎn)278，其中Prefill節(jié)點(diǎn)116個(gè)，Decode節(jié)點(diǎn) 162個(gè)，從下圖可以估算出該小時(shí)內(nèi)理論收入為$31k

DeepSeek R1 的定價(jià)：$0.14 / 百萬(wàn)輸入 tokens (緩存命中)，$0.55 / 百萬(wàn)輸入 tokens (緩存未命中)，$2.19 / 百萬(wàn)輸出 tokens 輸入 token 總數(shù)為 608B，其中 342B tokens（56.3%）命中 KVCache 硬盤緩存。輸出 token 總數(shù)為 168B 平均每臺(tái) H800 的吞吐量為：對(duì)于 Prefill 任務(wù)，輸入吞吐約 73.7k tokens/s（含緩存命中）；對(duì)于 Decode 任務(wù)，輸出吞吐約 14.8k tokens/s

假設(shè)該峰值區(qū)間的總輸出token為X 百萬(wàn)，按輸入/輸出平均比例估計(jì)，則實(shí)際計(jì)算的總輸入token數(shù)為1.583X，命中Cache 的總輸入token數(shù)為2.036X， 結(jié)合該時(shí)段理論收入$31k與各部分單價(jià)，可得X=9.265B，累計(jì)總輸入token為33.531B（其中14.67B 未命中Cache）

該區(qū)間時(shí)間為3600秒，與Prefill的總節(jié)點(diǎn)數(shù)116計(jì)算，得到單節(jié)點(diǎn)平均輸入吞吐約為35.13k tokens/s（未含緩存命中），與Decode的總節(jié)點(diǎn)數(shù)162計(jì)算，得到單節(jié)點(diǎn)平均輸出吞吐約為15.89k token/s，與公布的數(shù)據(jù)增長(zhǎng)了8%，整體在合理的增長(zhǎng)范圍

考慮R1/V3集群為隔離部署，且V3請(qǐng)求峰值未超過(guò)集群容量，故高峰期間實(shí)際單機(jī)吞吐峰值還會(huì)略高于上述吞吐值

社區(qū)關(guān)于原文中公開(kāi)的單機(jī)吞吐的理論值的分析，已經(jīng)做的比較深入和全面了，其中zarbot與Han Shen的分析比較有代表性，此處引用了Han Shen其中一篇分析 https://zhuanlan.zhihu.com/p/29540042383。

H800 （BF16 kvcache）最佳離線吞吐為單卡2844 tokens/s，由two-mircobatch overlapping的 DP288-EP288 - bmla64 方案得到

H800 （FP8 kvcache）最佳離線吞吐為單卡3121 tokens/s，由two-mircobatch overlapping的 DP288-EP288- bmla128 方案，或者DP48-EP48- bmla128 方案得到

H800 （FP8 kvcache）最佳線上吞吐（滿足20 tokens/s 左右用戶延遲）為2909 tokens/s， 由single-batch compute-communication overlapping的DP24-EP24- bmla128 方案得到。

H800 （BF16 kvcache）最佳線上吞吐（滿足20 tokens/s 左右用戶延遲）為2844 tokens/s，由two-mircobatch overlapping的DP288-EP288- bmla64 方案得到

在8卡H800上，單機(jī)吞吐的理論值在22.75k tokens/s以上。本節(jié)中計(jì)算值15.89k token/s在理論值的70%，故數(shù)據(jù)在合理區(qū)間。小結(jié)一下，在服務(wù)容量高峰時(shí)段，經(jīng)過(guò)估算，單節(jié)點(diǎn)平均輸入吞吐約為35.13k token/s，單節(jié)點(diǎn)平均輸出吞吐約為15.89k token/s，較官方公布平均吞吐約增長(zhǎng)8%，公開(kāi)數(shù)據(jù)合理，大家關(guān)注的輸出吞吐部分，在理論值22.75k tokens/s范圍內(nèi)。

用戶請(qǐng)求行為粗略估算

本節(jié)我們將用一些相對(duì)粗略的公開(kāi)數(shù)據(jù)，大致估算一下用戶的平均輸入/輸出。由于缺乏的數(shù)據(jù)輸入項(xiàng)過(guò)多，預(yù)估與實(shí)際值會(huì)存在很大的誤差，請(qǐng)側(cè)重參考輸入/輸出等用戶行為因素如何影響集群的配比。用戶規(guī)模，在原文發(fā)出來(lái)的一周，我們咨詢了相關(guān)C端運(yùn)營(yíng)，通過(guò)擬合各類數(shù)據(jù)，預(yù)估對(duì)應(yīng)時(shí)間段在2400W左右。通過(guò)DeepSeek網(wǎng)頁(yè)端提問(wèn)，大概也得到了2000~3000W日活的范圍，所以我們以DAU=24M為準(zhǔn)。假設(shè)該用戶數(shù)也包含了API側(cè)toB toC的日活用戶，整體而言DeepSeek自有流量的日活占絕大頭。

平均輸出，相比輸入的長(zhǎng)度受用戶使用次數(shù)和連續(xù)會(huì)話輪次影響，模型的輸出平均值一般比較穩(wěn)定。我們參考星辰MaaS上 V3和R1的輸出均值，分別為300和1000 tokens。分布比例，結(jié)合上文中提到V3在容量上比R1空閑大，我們認(rèn)為用戶使用V3的總次數(shù)低于R1，假設(shè)V3占比為r：

V3的每日總使用次數(shù)為168B*r/300=560M*r

R1的每日總使用次數(shù)為168B*(1-r)/1000=168M*(1-r)

平均次數(shù)，V3的平均用戶使用次數(shù)為560M*r/24M=23.33*r，R1為168M*(1-r)/24M=7*(1-r)。平均輪次，輪次越大，平均輸入因疊加歷史輸出會(huì)越長(zhǎng)，假設(shè)V3的平均輪次為n，R1的平均輪次為m，平均輪次一定是小于等于平均次數(shù)，即n ≤ 23.33*r；m ≤ 7*(1-r)。平均輸入，平均輸入通常與用戶平均使用上下文輪次有關(guān)，除此之外，由幾個(gè)部分組成。

用戶的直接輸入，一般20 tokens左右，在平均輸出中的成分為20*(n+1)/2=10n+10

上輪輸出，R1的思維鏈約占輸出的50%，不會(huì)作為下一輪的輸入，V3不存在該截?cái)?，故V3為300*(n-1)/2=150n-150，R1為1000*50%*(m-1)/2=250m-250

聯(lián)網(wǎng)搜索，聯(lián)網(wǎng)搜索按照星辰MaaS統(tǒng)計(jì)，通常請(qǐng)求觸發(fā)聯(lián)網(wǎng)比例在15~25%之間，此處取20%。每次搜索網(wǎng)頁(yè)全文按照5K tokens保守估計(jì)，均攤到每次的平均輸入取整為1000 tokens，這部分tokens不會(huì)作為上下文歷史累加

在粗估數(shù)據(jù)下，V3 token占比在35%時(shí)，用戶行為相對(duì)符合直覺(jué)，V3的平均輸入在2000 tokens左右，R1的平均輸入在1800左右，日均總請(qǐng)求次數(shù)total_usage=560M*r+168M*(1-r)=3.05億次。

結(jié)合上一節(jié)中高峰期時(shí)段的數(shù)據(jù)，來(lái)粗略估算計(jì)算節(jié)點(diǎn)的分布情況，可得知下表V3的PD配比為20:3，共135個(gè)節(jié)點(diǎn)，R1的為9:6，共143個(gè)節(jié)點(diǎn)。整體來(lái)說(shuō)Decode階段的計(jì)算單元R1比V3多符合預(yù)期，Prefill階段V3占用過(guò)多計(jì)算單元略顯意外，按照利用率估算過(guò)程中的值來(lái)看，V3的峰值是未觸發(fā)容量上限的，這可能與我們的平均輸出預(yù)估以及DAU的誤差有關(guān)，但也可能是為了在高峰期將預(yù)期使用R1的用戶請(qǐng)求引導(dǎo)到性價(jià)比更高的V3。

可得X=9.265B，累計(jì)總輸入token為33.531B（其中14.67B 未命中Cache）

該區(qū)間時(shí)間為3600秒，與Prefill的總節(jié)點(diǎn)數(shù)116計(jì)算，得到單節(jié)點(diǎn)平均輸入吞吐約為35.13k tokens/s（未含緩存命中），與Decode的總節(jié)點(diǎn)數(shù)162計(jì)算，得到單節(jié)點(diǎn)平均輸出吞吐約為15.89k token/s

小結(jié)一下，經(jīng)過(guò)粗略的估算，當(dāng)V3的輸出流量占比在35%時(shí)，V3平均輸入為2000 tokens，輸出300tokens，R1平均輸入為1800 tokens，輸出為1000 tokens，V3計(jì)算單元的PD配比為20:3，R1為9:6。

集群高并發(fā)高吞吐策略分析

大專家EP并行計(jì)算的特點(diǎn)是需要高并發(fā)的請(qǐng)求量，來(lái)激活集群各個(gè)維度的性能上限，獲得高吞吐率。首先分析原文中集群的并發(fā)情況。Decode階段并發(fā)：

結(jié)合H800的單機(jī)token吞吐、平均輸出速率可以知悉Decode節(jié)點(diǎn)單機(jī)并發(fā)≈14.8k/21* ≈ 705

按官方公開(kāi)信息1個(gè)Decode部署單元為18個(gè)節(jié)點(diǎn)，故Decode最小部署單元并發(fā)≈705*18 = 12.69k

根據(jù)上文分析Decode節(jié)點(diǎn)總數(shù)為162，則集群整體并發(fā)數(shù)max_con≈705*162=114.21k

Prefill階段并發(fā)：

根據(jù)上節(jié)中的粗略估算的數(shù)據(jù)，R1平均輸入長(zhǎng)度為1800 tokens，R1的TTFT=9s

R1單機(jī)并發(fā)=73.7k/1.8k * 9=368.5

R1Prefill最小部署單元并發(fā)=368.5*4 =1474

通常在推理計(jì)算過(guò)程中，在高并發(fā)、高并行計(jì)算獲得高吞吐的同時(shí)，也需要權(quán)衡延遲因素TTFT、TPOT，其關(guān)系如下：

并發(fā)提升初期，單機(jī)吞吐值、TTFT隨著并行度提升呈現(xiàn)非線性增長(zhǎng)趨勢(shì)；

當(dāng)并發(fā)超過(guò)一定閾值后，并行度提升帶來(lái)的計(jì)算量達(dá)到服務(wù)器計(jì)算瓶頸，吞吐不再隨之提升，但TTFT因并行排隊(duì)、通信延遲等因素而持續(xù)增加；

上述趨勢(shì)可以從zarbot的分析中得到論證：?jiǎn)螜C(jī)Prefill吞吐在DP8并行策略下達(dá)到33741，在DP4并行策略下僅為28693，提高并行度一定程度可以提升單機(jī)吞吐。MaaS廠商如果期望得到更低的TTFT，可能需要以更低的單機(jī)吞吐為代價(jià)，來(lái)獲得用戶體驗(yàn)的平衡。

文章鏈接 在TP=4，DP=8的部署方式下，H800單機(jī)Prefill TPS=33741.0；TPS(overlap)=52240.1 在TP=8，DP=4的部署方式下，H800單機(jī)Prefill TPS=28693.1；TPS(overlap)=41057.0

小結(jié)一下，原文中最小部署單元可支撐12.69k路并發(fā)，整個(gè)集群支撐114.21k路并發(fā)，要達(dá)到超低成本，需要有規(guī)模化的用戶請(qǐng)求才能支撐，MaaS廠商需要權(quán)衡好冷啟動(dòng)階段的成本問(wèn)題。若要達(dá)成更小的TTFT達(dá)到更優(yōu)的用戶體驗(yàn)，MaaS廠商需要考慮吞吐和首響平衡帶來(lái)的Prefill階段額外成本開(kāi)銷。

低成本組合方案估算

最后，我們結(jié)合上述性能分析的各類影響因素，梳理了幾種典型場(chǎng)景下的成本方案，供參考。方案1，假設(shè)MaaS產(chǎn)商在白日不削峰、夜間無(wú)填谷的情況下，集群?jiǎn)稳粘杀纠麧?rùn)率約為112%。

方案2，通過(guò)訓(xùn)推一體、彈性調(diào)度等技術(shù)實(shí)現(xiàn)夜間波谷期資源回收填谷后，可有效降低服務(wù)成本，集群?jiǎn)稳粘杀纠麧?rùn)率約為183.37%。

以夜間縮容區(qū)間00:00~08:00為例，55%水位線以下填谷收益約為(278-226.75)/278= 18.4%；55%水位線以上填谷收益為1/3；全天降本收益55%*18.4%+45%*1/3=25%

方案3，在方案2的基礎(chǔ)上再進(jìn)一步，可以在日間波峰期間將訓(xùn)練資源彈性擴(kuò)容以應(yīng)對(duì)流量峰值，進(jìn)一步降低服務(wù)成本，單日成本利潤(rùn)率約為234.16%。

五、MoE大模型成本優(yōu)化方向總結(jié)

綜合上述分析，我們可以看到除了極致的推理性能及吞吐優(yōu)化外，大模型成本與算力資源有效利用率、首響用戶體驗(yàn)等體系化的綜合策略也息息相關(guān)。基于以上成本數(shù)據(jù)分析，MaaS產(chǎn)商的成本優(yōu)化方向主要集中在以下幾點(diǎn)：

大專家EP并行方案優(yōu)化，優(yōu)化指標(biāo)在H800上需要達(dá)到，Prefill單機(jī)達(dá)35.13k tokens/s（未含緩存命中），Decode單機(jī)吞吐達(dá)15.89k token/s，其他卡型可以參考性價(jià)比換算

集群潮汐調(diào)度，基于夜間波谷期算力潮汐調(diào)度，對(duì)MaaS業(yè)務(wù)低峰期資源回收填谷，有效降低推理算力成本25%?；谌臻g波峰期算力的彈性調(diào)度擴(kuò)容，將75%水位線以上容量的增量資源成本由全天24h降低至5h，在夜間基礎(chǔ)上再降本11.4%

離線計(jì)算產(chǎn)品設(shè)計(jì)，通過(guò)離線產(chǎn)品補(bǔ)充峰谷期的計(jì)算空閑，提升集群利用率

差異化SLA產(chǎn)品，面向不同SLO及用戶體驗(yàn)需求提供差異化MaaS服務(wù)，通過(guò)適當(dāng)增加首token響應(yīng)TTFT、降低平均每token輸出的時(shí)延TPOT、適當(dāng)放棄峰值期間成功率，確保集群高利用率

規(guī)?；茝V，MoE超低成本依賴規(guī)?；脩粽?qǐng)求支持，冷啟動(dòng)成本較高，選擇合適的部署方案應(yīng)對(duì)用戶需求

六、大模型成本-性能對(duì)照速算表

為了方便技術(shù)團(tuán)隊(duì)設(shè)置技術(shù)優(yōu)化目標(biāo)及運(yùn)營(yíng)團(tuán)隊(duì)設(shè)計(jì)產(chǎn)品價(jià)格，我們進(jìn)一步提供了一個(gè)速算表，可以根據(jù)目標(biāo)價(jià)格，結(jié)合不同的SLA/SLO、用戶場(chǎng)景輸入/輸出長(zhǎng)度，以及服務(wù)器選型成本、集群利用率運(yùn)營(yíng)水平，來(lái)設(shè)置優(yōu)化目標(biāo)。（白色數(shù)值項(xiàng)可代入，黃色為公式計(jì)算）

假設(shè)平均每個(gè)請(qǐng)求的輸入長(zhǎng)度為Avg_In = 608X tokens，非緩存計(jì)算的輸入長(zhǎng)度為Avg_In_P = 266X tokens，平均輸出長(zhǎng)度為Avg_Out = 168X tokens

設(shè)X=3

七、結(jié)語(yǔ)及展望

DeepSeek-V3/R1自開(kāi)源后迅速轟動(dòng)全球，以其領(lǐng)先的算法架構(gòu)創(chuàng)新以及極致的系統(tǒng)性工程優(yōu)化，贏得了全球從業(yè)者及用戶的尊重，這也讓無(wú)數(shù)研究員、工程師熱血澎湃！我們也看到在NVIDIA GTC 2025上，黃教主發(fā)布了性能超強(qiáng)的新一代Blackwell芯片。在條件受限以及硬件存在差距的情況下，我們唯有繼續(xù)從系統(tǒng)性角度進(jìn)行極致的工程創(chuàng)新，方能補(bǔ)齊硬件上的短板，以極致的性價(jià)比迎接AI大模型應(yīng)用的指數(shù)級(jí)增長(zhǎng)！