近日,當(dāng)大家以為開源周已經(jīng)結(jié)束的時(shí)候,真「Open AI」DeepSeek帶來了壓軸大戲——DeepSeek-V3/R1推理系統(tǒng),全面揭秘! 吞吐量和延遲優(yōu)化: 跨節(jié)點(diǎn)高效并行(EP)驅(qū)動(dòng)的批處理擴(kuò)展 計(jì)算與通信并行處理 智能負(fù)載均衡 在線服務(wù)性能數(shù)據(jù): 每個(gè)H800節(jié)點(diǎn)每秒處理73,700/14,800輸入/輸出token 成本利潤(rùn)率高達(dá)545% DeepSeek表示,希望本周分享的技術(shù)見解能為開源社區(qū)帶來價(jià)值,共同推進(jìn)通用人工智能的發(fā)展目標(biāo)。 看到這里,網(wǎng)友都驚了! 所以,基本免費(fèi)的DeepSeek成本利潤(rùn)率高達(dá)545%,而堪稱世界最貴的OpenAI卻在虧損? 系統(tǒng)設(shè)計(jì)原則 簡(jiǎn)單來說,DeepSeek-V3/R1推理服務(wù)的優(yōu)化目標(biāo)是:提高吞吐量和降低延遲。 為了實(shí)現(xiàn)這兩個(gè)目標(biāo),團(tuán)隊(duì)采用了跨節(jié)點(diǎn)專家并行(Expert Parallelism,EP)技術(shù)。 首先,EP顯著擴(kuò)大了批處理規(guī)模,提高了GPU矩陣計(jì)算效率,從而提升吞吐量。 其次,EP將專家模塊分布在不同GPU上,每個(gè)GPU僅處理少量專家模塊(減少內(nèi)存訪問需求),從而降低延遲。 然而,EP也增加了系統(tǒng)復(fù)雜度,主要體現(xiàn)在兩個(gè)方面: EP引入了跨節(jié)點(diǎn)通信。為了優(yōu)化吞吐量,需要設(shè)計(jì)合理的計(jì)算工作流,使通信過程與計(jì)算過程能夠并行進(jìn)行。 EP涉及多個(gè)節(jié)點(diǎn),因此必然需要數(shù)據(jù)并行(Data Parallelism,DP),并要求在不同DP實(shí)例之間進(jìn)行負(fù)載均衡。 為此,DeepSeek通過以下方式應(yīng)對(duì)這些挑戰(zhàn): 利用EP技術(shù)擴(kuò)展批處理規(guī)模 將通信延遲與計(jì)算過程重疊處理 實(shí)現(xiàn)有效的負(fù)載均衡 大規(guī)?绻(jié)點(diǎn)專家并行(EP)DeepSeek-V3/R1中包含大量專家模塊:每層256個(gè)專家中僅激活8個(gè),所以模型的高稀疏性特點(diǎn)要求采用極大的整體批處理規(guī)模。 這樣才能確保每個(gè)專家模塊獲得足夠的批處理量,從而實(shí)現(xiàn)更高的吞吐量和更低的延遲。因此,大規(guī)模跨節(jié)點(diǎn)EP技術(shù)成為必不可少的選擇。 DeepSeek采用了預(yù)填充-解碼解耦架構(gòu)(prefill-decode disaggregation architecture),在預(yù)填充和解碼階段分別采用不同程度的并行策略: 預(yù)填充階段「路由專家EP32,MLA/共享專家DP32」:每個(gè)部署單元跨越4個(gè)節(jié)點(diǎn),配置32個(gè)冗余路由專家,每個(gè)GPU負(fù)責(zé)處理9個(gè)路由專家和1個(gè)共享專家。 解碼階段「路由專家EP144,MLA/共享專家DP144」:每個(gè)部署單元跨越18個(gè)節(jié)點(diǎn),配置32個(gè)冗余路由專家,每個(gè)GPU管理2個(gè)路由專家和1個(gè)共享專家。 計(jì)算-通信重疊處理大規(guī)模跨節(jié)點(diǎn)EP技術(shù)引入了顯著的通信開銷。 為了緩解這一問題,采用dual-batch重疊策略,將同一批請(qǐng)求分割為兩個(gè)microbatch,以隱藏通信成本并提高整體吞吐量。 在預(yù)填充階段,兩個(gè)microbatch交替執(zhí)行,一個(gè)microbatch的通信開銷被另一個(gè)microbatch的計(jì)算過程所掩蓋。 在解碼階段,各執(zhí)行階段的時(shí)長(zhǎng)存在不平衡現(xiàn)象。 為此,需要將注意力層細(xì)分為兩個(gè)步驟,并采用五階段流水線(5-stage pipeline)技術(shù),實(shí)現(xiàn)計(jì)算與通信的無縫重疊。 實(shí)現(xiàn)最優(yōu)負(fù)載均衡大規(guī)模并行(包括數(shù)據(jù)并行DP和專家并行EP)帶來了一個(gè)關(guān)鍵挑戰(zhàn):如果單個(gè)GPU在計(jì)算或通信方面過載,它將成為整個(gè)系統(tǒng)的性能瓶頸,導(dǎo)致系統(tǒng)速度下降,同時(shí)造成其他GPU資源閑置。 為了最大限度地提高資源利用率,DeepSeek的目標(biāo)是在所有GPU上實(shí)現(xiàn)計(jì)算和通信負(fù)載的平衡。 1. 預(yù)填充階段負(fù)載平衡器 關(guān)鍵問題:不同數(shù)據(jù)并行實(shí)例之間的請(qǐng)求數(shù)量和序列長(zhǎng)度差異導(dǎo)致核心注意力計(jì)算和分發(fā)發(fā)送負(fù)載不平衡。 優(yōu)化目標(biāo): 平衡各GPU之間的核心注意力計(jì)算(核心注意力計(jì)算負(fù)載均衡); 均衡每個(gè)GPU處理的輸入token數(shù)量(分發(fā)發(fā)送負(fù)載均衡),避免特定GPU出現(xiàn)處理延遲。 2. 解碼階段負(fù)載平衡器 關(guān)鍵問題:數(shù)據(jù)并行實(shí)例之間請(qǐng)求數(shù)量和序列長(zhǎng)度不均導(dǎo)致核心注意力計(jì)算(與KV緩存使用相關(guān))和分發(fā)發(fā)送負(fù)載的差異。 優(yōu)化目標(biāo): 平衡各GPU之間的KV緩存(KVCache)使用(核心注意力計(jì)算負(fù)載均衡); 均衡每個(gè)GPU的請(qǐng)求處理數(shù)量(分發(fā)發(fā)送負(fù)載均衡)。 3. 專家并行負(fù)載平衡器 關(guān)鍵問題:在混合專家模型(Mixture of Experts,MoE)中,存在天然的高負(fù)載專家,導(dǎo)致不同GPU上的專家計(jì)算工作負(fù)載不平衡。 優(yōu)化目標(biāo): 平衡每個(gè)GPU上的專家計(jì)算工作量(即最小化所有GPU中的最大分發(fā)接收負(fù)載)。 DeepSeek在線推理系統(tǒng)圖示DeepSeek在線服務(wù)統(tǒng)計(jì)數(shù)據(jù) 所有DeepSeek-V3/R1推理服務(wù)均在H800 GPU上運(yùn)行,精度與訓(xùn)練保持一致。 具體而言,矩陣乘法和分發(fā)傳輸采用與訓(xùn)練一致的FP8格式,而核心MLA計(jì)算和組合傳輸使用BF16格式,確保最佳的服務(wù)性能。 此外,由于白天服務(wù)負(fù)載高而夜間負(fù)載低,團(tuán)隊(duì)采取了一種創(chuàng)新的機(jī)制:
在過去24小時(shí)內(nèi)(02月27日中午12:00至02月28日中午12:00),V3和R1推理服務(wù)的合計(jì)峰值節(jié)點(diǎn)占用達(dá)到278個(gè),平均占用226.75個(gè)節(jié)點(diǎn)(每個(gè)節(jié)點(diǎn)包含8個(gè)H800 GPU)。 假設(shè)租賃一個(gè)H800 GPU的成本為每小時(shí)2美元,每日總成本為87,072美元。 在24小時(shí)統(tǒng)計(jì)期內(nèi),V3和R1: 總輸入token:6080億,其中3420億token(56.3%)命中磁盤上的KV緩存。 總輸出token:1680億。平均輸出速度為每秒20-22個(gè)token,每個(gè)輸出token的平均KV緩存長(zhǎng)度為4,989個(gè)token。 每個(gè)H800節(jié)點(diǎn)在預(yù)填充階段提供平均約7.37萬token/秒的輸入吞吐量(包括緩存命中),或在解碼階段提供約1.48萬token/秒的輸出吞吐量。 上述統(tǒng)計(jì)數(shù)據(jù)包括來自網(wǎng)頁、APP和API的所有用戶請(qǐng)求。 如果所有token都按照下列DeepSeek-R1的定價(jià)計(jì)費(fèi),每日總收入將達(dá)到562,027美元,利潤(rùn)率為545%。
然而,實(shí)際收入大幅低于此數(shù)字,原因如下: DeepSeek-V3的定價(jià)顯著低于R1 只有部分服務(wù)實(shí)現(xiàn)了商業(yè)化(網(wǎng)頁和APP訪問仍然免費(fèi)) 在非高峰時(shí)段自動(dòng)應(yīng)用夜間折扣 本文來源:新智元 |
原創(chuàng)欄目
IT百科
網(wǎng)友評(píng)論
聚超值•精選