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

一、分析團隊背景簡介

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

二、分析目的

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

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

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

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

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

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

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

MoE

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

Prefill與Decode分離，計算更高效

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

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

醫(yī)院

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

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

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

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

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

備注：圖片來自知乎

關(guān)鍵概念描述

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

APP：DeepSeek Web/APP端的C端用戶請求

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

DAU：日均活躍用戶

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

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

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

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

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

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

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

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與單機吞吐數(shù)據(jù)

運營側(cè)

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

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

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

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

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

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

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

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

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

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

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

對V3 API/網(wǎng)頁進行全天24h采樣測試，全天測試成功率100%，表明V3請求峰值未超過集群容量

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

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

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

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

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

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

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

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

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

原文中提到每個Prefill部署單元4個節(jié)點，Decode部署單元18個節(jié)點，總集群278個節(jié)點，我們需要計算出Prefill和Decode部署單元的配比，以便后續(xù)進一步分析吞吐數(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)

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

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

Y1=2，意味著最低谷期時保留了一個V3部署單元，一個R1部署單元

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

輸入608B*（1-56.3%）≈ 266B = 32.2k *24*3600*4*N，N≈23.9，考慮到機器占用率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

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

假設(shè)平均每個請求的輸入長度為Avg_In = 608X tokens，非緩存計算的輸入長度為Avg_In_P = 266X tokens，平均輸出長度為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的輸入/輸出平均長度不一樣，PD的配比也會不一樣，但總的來說，公布的數(shù)據(jù)峰谷圖、吞吐、集群配比上能高度吻合，公開數(shù)據(jù)合理。其中Prefill部署單元29個共116個節(jié)點，Decode部署單元9個共162個節(jié)點。

單機吞吐峰值與理論值估算驗證

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

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

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

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

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

考慮R1/V3集群為隔離部署，且V3請求峰值未超過集群容量，故高峰期間實際單機吞吐峰值還會略高于上述吞吐值

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

用戶請求行為粗略估算

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

平均輸出，相比輸入的長度受用戶使用次數(shù)和連續(xù)會話輪次影響，模型的輸出平均值一般比較穩(wěn)定。我們參考星辰MaaS上 V3和R1的輸出均值，分別為300和1000 tokens。分布比例，結(jié)合上文中提到V3在容量上比R1空閑大，我們認為用戶使用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)。平均輪次，輪次越大，平均輸入因疊加歷史輸出會越長，假設(shè)V3的平均輪次為n，R1的平均輪次為m，平均輪次一定是小于等于平均次數(shù)，即n ≤ 23.33*r；m ≤ 7*(1-r)。平均輸入，平均輸入通常與用戶平均使用上下文輪次有關(guān)，除此之外，由幾個部分組成。

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

上輪輸出，R1的思維鏈約占輸出的50%，不會作為下一輪的輸入，V3不存在該截斷，故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)計，通常請求觸發(fā)聯(lián)網(wǎng)比例在15~25%之間，此處取20%。每次搜索網(wǎng)頁全文按照5K tokens保守估計，均攤到每次的平均輸入取整為1000 tokens，這部分tokens不會作為上下文歷史累加

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

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

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

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

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

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

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

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

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

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

Prefill階段并發(fā)：

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

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

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

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

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

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

上述趨勢可以從zarbot的分析中得到論證：單機Prefill吞吐在DP8并行策略下達到33741，在DP4并行策略下僅為28693，提高并行度一定程度可以提升單機吞吐。MaaS廠商如果期望得到更低的TTFT，可能需要以更低的單機吞吐為代價，來獲得用戶體驗的平衡。

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

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

低成本組合方案估算

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

方案2，通過訓(xùn)推一體、彈性調(diào)度等技術(shù)實現(xiàn)夜間波谷期資源回收填谷后，可有效降低服務(wù)成本，集群單日成本利潤率約為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ǔ)上再進一步，可以在日間波峰期間將訓(xùn)練資源彈性擴容以應(yīng)對流量峰值，進一步降低服務(wù)成本，單日成本利潤率約為234.16%。

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

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

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

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

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

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

規(guī)模化推廣，MoE超低成本依賴規(guī)?；脩粽埱笾С?，冷啟動成本較高，選擇合適的部署方案應(yīng)對用戶需求

六、大模型成本-性能對照速算表

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

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

設(shè)X=3

七、結(jié)語及展望

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