樊玉偉，鄭靈超，李勇鋒，區(qū)曉峰，李君，KenZhang，韓偉，李億杜霄鵬，王鵬程，劉杰，董谷音，梁泓，柳伊揚(yáng)，廖崎臣，高雪健王鵬宇，趙毅，王翔，林棟，練韻文，林清揚(yáng)，陳衎，龐西豹呂俊龍，蘭龍文，張維熹，丁益斌，高宇，陶壯，張弓，謝冬輝范港華，范峻逸，胡琤球，李寶，鄭樂(lè)文，陳付愷，申智好，金穎華為技術(shù)有限公司摘要本報(bào)告旨在探討華為昇騰服務(wù)器上部署DeepSeekV3/R1推理的最佳實(shí)踐。為滿(mǎn)足不同推理場(chǎng)景的需求，本文提供兩種不同的部署形態(tài)。第一種是基于華為CloudMatrix384超節(jié)點(diǎn)的大規(guī)模EP部署策略：為充分發(fā)揮CloudMatrix384的獨(dú)特組網(wǎng)優(yōu)勢(shì)，使用其中的144張卡作為一個(gè)Decode實(shí)例，以實(shí)現(xiàn)較低時(shí)延下的高并發(fā)，當(dāng)前已達(dá)到了50ms時(shí)延約束下每卡輸出1920Tokens/s。第二種是基于Atlas800IA2服務(wù)器的小規(guī)模EP部署策略：使用4節(jié)點(diǎn)A2服務(wù)器作為一個(gè)Decode實(shí)例，以實(shí)現(xiàn)較優(yōu)吞吐下的靈活部署，當(dāng)前達(dá)到了100ms時(shí)延約束下每卡輸出723~808Tokens/s。我們采用基于vLLM的部署框架，并面向昇騰服務(wù)器進(jìn)行修改以適配EP/DP/TP混合并行策略，同時(shí)滿(mǎn)足靈活調(diào)度和極致性能的需求。模型層面，采用A8W8(INT8)的動(dòng)態(tài)量化方式，并使用Multi-TokenPrediction技術(shù)進(jìn)行加速。針對(duì)昇騰芯片和昇騰服務(wù)器組網(wǎng)特征，從數(shù)學(xué)上重新審視模型的推理過(guò)程，選用了合適的并行方式和計(jì)算邏輯，同時(shí)還充分利用了昇騰硬件支持多種多流并發(fā)的能力以最大化實(shí)現(xiàn)通信/計(jì)算/數(shù)據(jù)搬運(yùn)的相互掩蓋，實(shí)現(xiàn)模型層面的性能極致。算子層面，提出了多種結(jié)合數(shù)學(xué)等價(jià)變換、融合算子、緩存復(fù)用和流水掩蓋等技術(shù)的計(jì)算和通信算子的優(yōu)化方案，使MLA、MoE和通信算子達(dá)到預(yù)期的算力利用率、訪存帶寬和通信帶寬。本報(bào)告將詳細(xì)介紹上述兩套部署方案，并列出關(guān)鍵的特性和優(yōu)化技術(shù)，更詳細(xì)的技術(shù)細(xì)節(jié)之后會(huì)陸續(xù)公開(kāi)。11引言32昇騰服務(wù)器和組網(wǎng)52.1昇騰芯片 52.2Atlas800IA2服務(wù)器 52.3CloudMatrix384超節(jié)點(diǎn) 63DeepSeekV3/R1模型部署方案63.1模型與框架配置 63.2Atlas800IA2部署方案 83.3CloudMatrix384超節(jié)點(diǎn)部署方案 4框架側(cè)性能優(yōu)化144.1APIServer擴(kuò)展技術(shù) 4.2MoE模型負(fù)載均衡 5模型側(cè)性能優(yōu)化155.1模型側(cè)通信優(yōu)化 5.2模型側(cè)并發(fā)方案 5.3推理投機(jī)框架FusionSpec 6昇騰算子性能優(yōu)化196.1MLA算子優(yōu)化 6.2MoE通信算子優(yōu)化 7性能分析217.1Altas800IA2性能分析 7.2CloudMatrix384超節(jié)點(diǎn)性能分析 8下一步工作252DeepSeekV3/R1作為業(yè)界領(lǐng)先的開(kāi)源大語(yǔ)言模型，已在自然語(yǔ)言處理、代碼生成、知識(shí)推理等多個(gè)領(lǐng)域展現(xiàn)出卓越的應(yīng)用價(jià)值。DeepSeek團(tuán)隊(duì)于3月份推出了迭代版本DeepSeekDeepSeek-Prover-V2-671B[11]。這兩款新的模型與原始DeepSeekV3架構(gòu)完全兼容，僅需進(jìn)行參數(shù)差異化配置的權(quán)重調(diào)整，便可實(shí)現(xiàn)既有模型部署方案的無(wú)縫遷移。這一設(shè)計(jì)不僅降低了技術(shù)迭代的邊際成本，更有效擴(kuò)大了DeepSeekV3系列模型的使用范圍。本報(bào)告分享當(dāng)前在昇騰服務(wù)器上高性能DeepSeekV3/R1部署方案的最佳實(shí)踐，包括具體的部署方案和關(guān)鍵優(yōu)化特性的簡(jiǎn)單介紹。關(guān)鍵優(yōu)化特性的詳細(xì)報(bào)告將于近期陸續(xù)發(fā)布。昇騰服務(wù)器有多種配置和型號(hào)，我們針對(duì)近期發(fā)布的CloudMatrix384超節(jié)點(diǎn)和Atlas800IA2推理服務(wù)器兩種典型機(jī)型進(jìn)行部署。為了解耦Prefill階段的首token時(shí)延約束和Decode階段的解碼時(shí)延約束，同時(shí)希望針對(duì)不同場(chǎng)景選擇最優(yōu)的部署策略和計(jì)算流程，我們采用PD分離部署的方式。在框架側(cè)，以vLLM為基礎(chǔ)，針對(duì)DP、EP和TP并行策略做了相應(yīng)適配，在KVCache傳輸方面采用了靈衢直聯(lián)的技術(shù)來(lái)降低開(kāi)銷(xiāo)，在請(qǐng)求下發(fā)、調(diào)度策略和框架前后處理等方面做了性能優(yōu)化，以實(shí)現(xiàn)整個(gè)系統(tǒng)的最優(yōu)性能。模型方面，采用A8W8(INT8)的動(dòng)態(tài)量化策略。針對(duì)昇騰芯片和昇騰服務(wù)器組網(wǎng)特征，從數(shù)學(xué)上重新審視模型的推理過(guò)程，并綜合考慮了數(shù)據(jù)搬運(yùn)量、數(shù)據(jù)通信量、計(jì)算量和內(nèi)存占用量，選用了合適的并行方式和計(jì)算邏輯，有效降低了模型推理過(guò)程中的通信和計(jì)算耗時(shí)；我們還充分利用了昇騰硬件的多流并發(fā)能力，實(shí)現(xiàn)通信-計(jì)算并發(fā)、通信-通信并發(fā)和通信-權(quán)重預(yù)取并發(fā)等多種加速技術(shù)，從而做到通信/計(jì)算/數(shù)據(jù)搬運(yùn)的相互掩蓋，實(shí)現(xiàn)模型層面的極致性能。算子方面，我們針對(duì)DeepSeek模型的特點(diǎn)，提出了多種結(jié)合數(shù)學(xué)等價(jià)變換、融合算子、緩存復(fù)用、流水掩蓋等技術(shù)的極致優(yōu)化的計(jì)算算子和通信算子，特別是在MLA、MLA前序計(jì)算、Dispatch/Combine通算融合算子和指令級(jí)底層通信調(diào)度方面做了深入的優(yōu)化，以最大化利用昇騰的算力、訪存帶寬和通信帶寬。詳細(xì)的部署方面，由于兩種機(jī)型定位和配置不同，所以具體部署方案也不盡相同。3針對(duì)CloudMatrix384超節(jié)點(diǎn)，其特殊的組網(wǎng)方式使其具有很高的通信帶寬。按照DeepSeek的論文[16]所述，Decode部分是嚴(yán)重的通信瓶頸，在Micro-batch技術(shù)的加持下，幾乎可以做到通信掩蓋其他所有計(jì)算類(lèi)操作。而CloudMatrix384的獨(dú)特組網(wǎng)使得通信耗時(shí)大幅降低，可以有效釋放昇騰芯片的算力，具體見(jiàn)第7.2節(jié)。因此，針對(duì)超節(jié)點(diǎn)我們采用大規(guī)模EP并行的方式來(lái)部署：Prefill使用16卡，Decode使用144卡。其中Decode部分使用128卡通過(guò)大規(guī)模EP的方式部署路由專(zhuān)家，16卡通過(guò)DP的方式部署共享專(zhuān)家，MLA部分使用DP的方式進(jìn)行部署。按照類(lèi)似于[16]的分析，超節(jié)點(diǎn)可以獲得非常高的理論吞吐。實(shí)際場(chǎng)景下，由于各種因素的影響，包括Decode時(shí)延的約束使得各部分耗時(shí)未能達(dá)到理想的線性度，帶寬搶占帶來(lái)一部分性能劣化，框架的耗時(shí)和調(diào)度開(kāi)銷(xiāo)帶來(lái)了額外的時(shí)延增加，MLA部分的序列負(fù)載均衡和MoE部分的專(zhuān)家負(fù)載均衡帶來(lái)進(jìn)一步的性能惡化；最后多種因素綜合在一起，使得當(dāng)前吞吐如[19]所述，實(shí)現(xiàn)在保證50ms時(shí)延下單卡Decode吞吐達(dá)到1920Tokens/s。針對(duì)Atlas800IA2服務(wù)器，由于每個(gè)節(jié)點(diǎn)包含8張昇騰芯片，我們需要采用多節(jié)點(diǎn)互聯(lián)的方式來(lái)進(jìn)行部署。綜合考慮模型吞吐和部署靈活性，我們選定使用2節(jié)點(diǎn)16卡作為一個(gè)Prefill實(shí)例，4節(jié)點(diǎn)32卡作為一個(gè)Decode實(shí)例。為了部署時(shí)盡可能的靈活，這里選用的卡數(shù)較少，這使得整個(gè)系統(tǒng)采用較小規(guī)模的EP并行策略：每張卡上部署8(Decode)/16(Prefill)個(gè)路由專(zhuān)家和1個(gè)共享專(zhuān)家。在Decode階段，MLA部分采用DP并行策略，通信方式采用AllGather/ReduceScatter方案。這種部署方式可以在卡數(shù)較少情況下依然達(dá)到相當(dāng)可觀的吞吐。值得一提的是，真實(shí)負(fù)載下AllGather/ReduceScatter比Dispatch/Combine的通信方案具有更好的性能表現(xiàn)。綜合上述優(yōu)化方案，我們實(shí)現(xiàn)了在100ms時(shí)延下單卡吞吐達(dá)到723~808Tokens/s。本文結(jié)構(gòu)安排如下：在第2節(jié)簡(jiǎn)單介紹昇騰服務(wù)器相關(guān)的硬件信息，在第3節(jié)詳細(xì)介紹兩種不同機(jī)型下的部署方案，在第4,5,6節(jié)分別介紹框架層、模型層和算子層的優(yōu)化技術(shù)，在第7節(jié)給出兩種部署下的性能分析結(jié)果，最后列舉一些當(dāng)前部署方案后續(xù)要增加的特性和優(yōu)化方案。42昇騰服務(wù)器和組網(wǎng)2.1昇騰芯片昇騰NPU芯片是華為推出的一系列高性能AI處理器，專(zhuān)為大規(guī)模AI訓(xùn)練、高性能AI推理等任務(wù)設(shè)計(jì)。該系列芯片采用達(dá)芬奇架構(gòu)[18]，具備強(qiáng)大的計(jì)算能力和高效的能效表現(xiàn)，能夠滿(mǎn)足深度學(xué)習(xí)模型訓(xùn)練與推理、自然語(yǔ)言處理等多種應(yīng)用場(chǎng)景的需求。該系列芯片分為多種型號(hào)，不同型號(hào)的性能不同，不同服務(wù)器會(huì)根據(jù)定位選用不同型號(hào)的芯片。2.2Atlas800IA2服務(wù)器昇騰Atlas800IA2推理服務(wù)器（下文簡(jiǎn)稱(chēng)為A2服務(wù)器或A2）一個(gè)節(jié)點(diǎn)包含8張NPU芯片，形成多機(jī)組網(wǎng)架構(gòu)(圖1)，具有以下特點(diǎn)：?節(jié)點(diǎn)內(nèi)拓?fù)洌篈2單節(jié)點(diǎn)內(nèi)8卡NPU通過(guò)Fullmesh形成全互聯(lián)結(jié)構(gòu)，通信總帶寬392GB/s。?節(jié)點(diǎn)間拓?fù)洌篈2節(jié)點(diǎn)間通過(guò)網(wǎng)絡(luò)交換機(jī)進(jìn)行互聯(lián)，形成Stars結(jié)構(gòu)，通信總帶寬50GB/s。圖1:Atlas800IA2服務(wù)器節(jié)點(diǎn)內(nèi)和節(jié)點(diǎn)間組網(wǎng)。左圖：A2節(jié)點(diǎn)內(nèi)全互聯(lián)；右圖：多節(jié)點(diǎn)間通過(guò)交換機(jī)實(shí)現(xiàn)互聯(lián)。節(jié)點(diǎn)間通信時(shí)，由于不同卡上的數(shù)據(jù)匯聚到同一個(gè)網(wǎng)絡(luò)通信接口上，共享總帶寬。所以如果模型需要部署在多個(gè)節(jié)點(diǎn)上時(shí)，需關(guān)注節(jié)點(diǎn)間通信量和通信次數(shù)，減少節(jié)點(diǎn)間帶寬對(duì)性能帶來(lái)52.3CloudMatrix384超節(jié)點(diǎn)CloudMatrix384超節(jié)點(diǎn)（下文簡(jiǎn)稱(chēng)為CM384）是基于靈衢高速互聯(lián)總線，滿(mǎn)足AI時(shí)代海量算力需求的大規(guī)模超節(jié)點(diǎn)集群(圖2)。CM384通過(guò)多卡緊耦合互聯(lián)，統(tǒng)一內(nèi)存編址，統(tǒng)一標(biāo)識(shí)，統(tǒng)一通信等技術(shù)，實(shí)現(xiàn)算力、互聯(lián)帶寬、內(nèi)存帶寬的全面領(lǐng)先。因此，在CM384上進(jìn)行網(wǎng)絡(luò)部署時(shí)，子節(jié)點(diǎn)間帶寬不再成為通信瓶頸，可考慮利用全部AI處理器的算力分布式部署，如全域的專(zhuān)家并行，以充分利用超節(jié)點(diǎn)高算力高帶寬的特性。圖2:CloudMatrix384超節(jié)點(diǎn)內(nèi)卡間和多子節(jié)點(diǎn)間高速互聯(lián)。3DeepSeekV3/R1模型部署方案本節(jié)重點(diǎn)介紹DeepSeekV3/R1在昇騰服務(wù)器上的具體部署方案和調(diào)度策略?？紤]到Atlas800IA2和CloudMatrix384超節(jié)點(diǎn)的部署方案比較相似，我們將在第3.2節(jié)中詳細(xì)介紹Atlas800IA2上的部署方案，在第3.3節(jié)中介紹CloudMatrix384超節(jié)點(diǎn)上的部署方案相比Atlas800IA2的差異。3.1模型與框架配置3.1.1模型量化策略為適配昇騰芯片保證推理性能，這里采用SmoothQuant技術(shù)[15]對(duì)模型進(jìn)行A8W8動(dòng)態(tài)量化(權(quán)重激活均采用INT8量化數(shù)據(jù)類(lèi)型)，計(jì)算過(guò)程的中間變量采用BF16。當(dāng)前KVCache采用了BF16的數(shù)據(jù)類(lèi)型進(jìn)行存儲(chǔ)和計(jì)算，后續(xù)該量化策略會(huì)記為A8W8C16，即激活I(lǐng)NT8、權(quán)重INT8和KVCacheBF16。63.1.2Prefill和Decode分離部署大模型推理過(guò)程主要分Prefill和Decode兩個(gè)階段。Prefill階段通常是計(jì)算瓶頸，而Decode階段通常是帶寬瓶頸和通信瓶頸，這導(dǎo)致兩者的最佳部署策略往往不同。此外，由于權(quán)重吸收的技術(shù)，MLA模塊在Prefill和Decode階段的計(jì)算邏輯是不同的，部署在同一實(shí)例上會(huì)導(dǎo)致額外的權(quán)重占用。另一方面，由于實(shí)際服務(wù)時(shí)對(duì)首Token時(shí)延(TTFT)和Decode時(shí)延(TPOT)的要求，如果在同一套硬件上部署Prefill和Decode，導(dǎo)致該系統(tǒng)要同時(shí)滿(mǎn)足TTFT和TPOT兩個(gè)指標(biāo)，這會(huì)導(dǎo)致整體吞吐難以達(dá)到最優(yōu)。綜合上述原因，如果采用Prefill和Decode分離部署的方式，可以更好的獲得兩階段的極致性能，并更好的滿(mǎn)足實(shí)際需求。所以本報(bào)告中我們總是基于Prefill和Decode分離的方式進(jìn)3.1.3服務(wù)框架配置vLLM[8]是當(dāng)前較為流行的開(kāi)源大模型推理框架，我們以此為基礎(chǔ)來(lái)對(duì)大模型進(jìn)行部署。為適配PD分離，并獲得極致的性能，我們?cè)诳蚣軅?cè)做了相應(yīng)的適配：圖3:基于PD分離部署的vLLM框架調(diào)度示意圖。7?Prefill調(diào)度分桶：基于vLLM框架，結(jié)合請(qǐng)求長(zhǎng)度與KV親和性調(diào)度策略，根據(jù)任務(wù)特性動(dòng)態(tài)優(yōu)化資源分配，顯著提升了在高并發(fā)場(chǎng)景下的推理性能；?靈衢互聯(lián)與分層傳輸：在KVCache傳輸上，我們采用了靈衢互聯(lián)與分層傳輸?shù)男问?，?lái)降低KVCache傳輸時(shí)延。為了支撐大規(guī)模EP、小規(guī)模EP、DP和TP等并行策略，我們對(duì)框架做了相應(yīng)的修改和適配。同時(shí)為了支持超高并發(fā)（10K以上需要較為極致的性能優(yōu)化，這部分在第4節(jié)框架優(yōu)化部分會(huì)詳細(xì)介紹。3.2Atlas800IA2部署方案在Atlas800IA2的部署上，綜合考慮模型吞吐和部署靈活性，我們?cè)贒ecode階段僅使用32卡進(jìn)行部署，Prefill階段僅使用16卡部署。如果Decode要達(dá)到高吞吐，或Prefill要支持長(zhǎng)序列，則意味著高內(nèi)存占用，這導(dǎo)致內(nèi)存可能會(huì)成為關(guān)鍵瓶頸，所以具體的部署策略上要特別注圖4:圖4:DeepSeekV3/R1主體網(wǎng)絡(luò)架構(gòu)。PrefillDecodeMLATP16DP32DenseFFNDP16DP4+TP8路由專(zhuān)家EP16EP32共享專(zhuān)家DP16DP4+TP8EmbeddingTP16DP4+TP8LMHeadTP16DP4+TP8表1:Altas800IA2的PD分離部署。DeepSeekV3/R1模型共有61層（圖4）和額外的一層MTP層，每層包括MLA模塊和DenseFFN/MoE模塊。整體部署策略如表1所示?？傮w來(lái)說(shuō)，MoE部分均采用EP部署策略，其中共享專(zhuān)家部分采用DP4+TP8并行，MLA部分在Prefill和Decode部分因其核心邏輯的差異導(dǎo)致采用不同的部署策略。此外，稠密層FFN、Embeding和LMHead部分均為了節(jié)省內(nèi)存采用DP4+TP8的部署策略。下面詳細(xì)介紹各模塊的部署方案。83.2.1多頭潛在注意力（MLA）DeepSeekV3/R1使用了獨(dú)特的MLA進(jìn)行KVCache壓縮。不同于傳統(tǒng)的MHA[14]，MLA的多個(gè)頭共用壓縮后的KVCache。在Decode階段，對(duì)MLA用TP無(wú)法節(jié)省內(nèi)存,反而會(huì)導(dǎo)致KVCache的大量重復(fù)搬運(yùn)；而在Prefill階段，矩陣乘計(jì)算取代數(shù)據(jù)搬運(yùn)成為主要性能瓶頸，DP與TP的計(jì)算量相同，但TP可以獲得一定的內(nèi)存收益。內(nèi)存分析單張卡上MLA部分的內(nèi)存占用可以描述為：Memory=++Memory激活,其中W是模型MLA部分的權(quán)重大小。在Decode階段,KVCache會(huì)占據(jù)大量?jī)?nèi)存(卡均72并發(fā)，序列長(zhǎng)度為4K時(shí)，KVCache內(nèi)存占用接近20GB)。由于MLA的多頭共享KVCache機(jī)制，傳統(tǒng)的TP（head軸切分）部署并不能降低單卡KVCache占用，因此全DP部署是最節(jié)省內(nèi)存的并行部署方式。而在Prefill階段，并發(fā)數(shù)較小，序列長(zhǎng)度較大，權(quán)重（約11.6GB)和激活內(nèi)存（總token數(shù)為16384場(chǎng)景下，約1GB）占據(jù)了大部分內(nèi)存，更適合采用TP的方式進(jìn)行部署。因此，我們對(duì)Prefill和Decode采取不同的部署策略。Prefill我們采用Attention前序計(jì)算DP16，AttentionTP16,Attention后序計(jì)算DP8+TP2的混合部署策略，流程圖示見(jiàn)圖5b。具體而言：?在Q、K、V降維階段采用DP16部署，這部分模型權(quán)重?cái)?shù)量較少，使用DP不會(huì)占用過(guò)多內(nèi)存，且降維后的Q、K、V可以最大程度降低切換到TP所引入的通信開(kāi)銷(xiāo);?在Q、K、V升維以及Attention計(jì)算階段采用TP16部署，顯著降低算子激活內(nèi)存;?Output投影矩陣采用DP8+TP2,能顯著降低TP轉(zhuǎn)換為DP的通信量,具體技術(shù)見(jiàn)Decode此時(shí)MLA的性能瓶頸主要在權(quán)重和KVCache搬運(yùn)，其中KVCache搬運(yùn)為主要耗時(shí)。因此，我們采用業(yè)界主流的DP32與權(quán)重吸收[5]的部署方式，避免KVCache重復(fù)搬運(yùn)，降低Attention算子的耗時(shí)。9(a)Prefill稠密層(b)PrefillMLA圖5:左：Prefill稠密層使用DPDenseFFN提升Prefill性能，避免引入額外通信。右：Prefill的MLA部分使用DP-TP16-TP2的方式部署。其中，我們選擇在Q、K、V降維之后進(jìn)行DP-TP轉(zhuǎn)換，最大程度降低通信量。Attention采用TP16，最后對(duì)Output投影矩陣計(jì)算(圖中的OProj)使用DP8+TP2。注：簡(jiǎn)潔起見(jiàn)，圖中忽略了RoPE和RMSNorm部分的計(jì)算。3.2.2DenseFFNPrefill此時(shí)性能瓶頸是矩陣乘的計(jì)算量。注意到無(wú)論使用DP或者TP，計(jì)算量都保持不變,但是使用TP會(huì)引入額外的通信，且全TP在長(zhǎng)序列場(chǎng)景下的矩陣乘法的維度對(duì)計(jì)算硬件不親和，影響矩陣乘計(jì)算性能。因此，我們對(duì)DenseFFN采用全DP的部署方式。Prefill階段稠密層的計(jì)算流程見(jiàn)圖5a。Decode此時(shí)性能瓶頸是權(quán)重搬運(yùn)。綜合考慮FFN性能和通信耗時(shí)，以及權(quán)重所需內(nèi)存（總共約1.1GB)，我們采取DP4+TP8的部署策略。Decode階段稠密層的計(jì)算流程見(jiàn)圖6。3.2.3混合專(zhuān)家（MoE）路由專(zhuān)家DeepSeekV3/R1龐大的專(zhuān)家數(shù)量對(duì)內(nèi)存提出了巨大挑戰(zhàn)。每個(gè)專(zhuān)家在總共58層共占權(quán)重約2.5GB，而每張Atlas800IA2昇騰卡的內(nèi)存大小是64GB。因此，我們?cè)赑refill和Decode階段都采用了業(yè)界主流的EP并行部署策略，即將256個(gè)路由專(zhuān)家平均地部署到所有昇騰卡上。對(duì)于Prefill節(jié)點(diǎn)而言，每張卡上需要部署16個(gè)路由專(zhuān)家；Decode節(jié)點(diǎn)上每張卡部圖6:Decode階段稠密層采取DP32MLA+節(jié)點(diǎn)內(nèi)TP8DenseFFN的部署方式。MLA使用DP32可以避免KVCache的重復(fù)搬運(yùn)，且有效降低了單卡的內(nèi)存壓力。DenseFFN采用了節(jié)點(diǎn)內(nèi)TP8，避免過(guò)高的通信代價(jià)，同時(shí)能夠部分降低單卡載入的權(quán)重（約1GB）。注：簡(jiǎn)潔起見(jiàn)，圖中已忽略各處的RMSNorm計(jì)算。署8個(gè)路由專(zhuān)家。這種部署方式很大程度上減輕了單卡的內(nèi)存壓力和計(jì)算量，但同時(shí)也引入了別的挑戰(zhàn)如MoE前后的通信開(kāi)銷(xiāo)（見(jiàn)第5.2節(jié)）和專(zhuān)家負(fù)載不均衡（見(jiàn)第4.2節(jié)）。共享專(zhuān)家通常場(chǎng)景下，我們選擇對(duì)共享專(zhuān)家應(yīng)用全DP的并行策略。在長(zhǎng)序列的場(chǎng)景下，內(nèi)存成為提升吞吐的瓶頸之一，我們可以選擇對(duì)共享專(zhuān)家應(yīng)用節(jié)點(diǎn)內(nèi)TP8的并行策略，這能節(jié)省約2.1GB內(nèi)存。兩種場(chǎng)景下，共享專(zhuān)家的計(jì)算都與路由專(zhuān)家的通信操作并發(fā)掩蓋?？傮w流程Decode節(jié)點(diǎn)MoE層的具體計(jì)算流程請(qǐng)見(jiàn)圖7。由于Prefill的流程與Decode高度相似（共享專(zhuān)家部署略有不同），這里不另展示Prefill的流程圖。3.2.4Embedding和LMHeadDeepSeekV3/R1模型一開(kāi)始的Embedding和模型最后的LanguageModel(LM)Head都涉及對(duì)一個(gè)巨大的形狀為(129280,7168)的BF16數(shù)據(jù)格式的字典映射/矩陣乘，權(quán)重大小均為1.7GB，共約3.5GB。在Prefill節(jié)點(diǎn)上，我們采取TP16的部署方式；而在Decode節(jié)點(diǎn)上，我們采取類(lèi)似DenseFFN的DP4+TP8的部署方式。這部分減少內(nèi)存占用約3GB，但需要引入額外的節(jié)點(diǎn)內(nèi)通信操作。圖7:Decode節(jié)點(diǎn)稀疏層的計(jì)算流程。MLA部分和稠密層一樣采取DP32的方式，降低KVCache搬運(yùn)量。MoE部分使用EP32的部署策略。首先對(duì)MLA的輸出使用AllGather通信，所有路由專(zhuān)家計(jì)算完畢后，使用ReduceScatter分發(fā)結(jié)果給下一3.3CloudMatrix384超節(jié)點(diǎn)部署方案本節(jié)介紹我們?cè)贑M384上設(shè)計(jì)的部署策略。PrefillCM384在Prefill階段的部署方案與Atlas800IA2基本相同，主要差異是，在CM384上MoE模塊的通信方式為All2All。CM384的子節(jié)點(diǎn)間通過(guò)交換設(shè)備形成無(wú)收斂高速互聯(lián)（第2.3節(jié)因此在CM384上采用All2All方案，比AllGather+ReduceScatter的方案（圖6）性能更優(yōu)。Decode由于DeepSeekV3/R1模型的路由專(zhuān)家數(shù)量多，在Decode階段，MoE模塊的主要性能瓶頸為權(quán)重搬運(yùn)。EP的規(guī)模越大，意味著每個(gè)子節(jié)點(diǎn)需要搬運(yùn)的專(zhuān)家權(quán)重越少，但代價(jià)是通信時(shí)延的增加。在CM384上，子節(jié)點(diǎn)間的互聯(lián)帶寬相比Atlas800IA2大大提高，這使得大規(guī)模的EP部署成為可能。在Decode階段，我們用18個(gè)CM384子節(jié)點(diǎn)（共144卡）進(jìn)行部署。具體部署方案與Atlas800IA2的對(duì)比如下：1.MLA模塊的部署方案與Atlas800IA2基本相同，采用DP。但在Output投影矩陣部分，CM384Decode稠密層子節(jié)點(diǎn)1~18NPU1&2NPU3&4NPU5&6NPU7&8DPMLADPMLADPMLADPMLADPMLADPMLADPMLADPMLAAllGatherAllGatherAllGatherAllGatherAllGatherAllGatherAllGatherTP2DenseFFNTP2TP2DenseFFNTP2DenseFFNTP2DenseFFNReduceScatterReduceScatterReduceScatterReduceScatterReduceScatterReduceScatterReduceScatter圖8:CM384Decode階段稠密層部署方式為全DPMLA和TP2DenseFFN。在CM384Decode子節(jié)點(diǎn)上，稠密層的MLA整體上采取全DP的部署方式，最后的Output投影矩陣采用TP2（圖中的O-proj）。不同于Atlas800IA2上的TP8，基于CM384的組網(wǎng)特點(diǎn)（第2.3節(jié)我們?cè)贔FN層采取了TP2的部署方式。CM384Decode稀疏層子節(jié)點(diǎn)2子節(jié)點(diǎn)3子節(jié)點(diǎn)子節(jié)點(diǎn)2子節(jié)點(diǎn)3子節(jié)點(diǎn)18…………………DispatchAll2All路由專(zhuān)家路由專(zhuān)家路由專(zhuān)家共享專(zhuān)家路由專(zhuān)家路由專(zhuān)家路由專(zhuān)家共享專(zhuān)家共享專(zhuān)家共享專(zhuān)家共享專(zhuān)家…………CombineAll2All圖9:CM384Decode階段稀疏層部署方式為DPMLA和EP144MoE。在CM384Decode子節(jié)點(diǎn)上，稀疏層的MLA整體上采取DP的部署方式，最后的Output投影矩陣采用TP2（圖中的O-proj）。MoE采取EP144的部署方式，共享專(zhuān)家也被當(dāng)做路由專(zhuān)家處理[6]。在18個(gè)CM384子節(jié)點(diǎn)中，2個(gè)子節(jié)點(diǎn)以DP的方式部署共享專(zhuān)家；其余16個(gè)子節(jié)點(diǎn)用于部署路由專(zhuān)家，每張卡部署兩個(gè)專(zhuān)家。由于通信性能更高，CM384采用了TP2。2.Atlas800IA2上節(jié)點(diǎn)內(nèi)是Fullmesh組網(wǎng)，TP2/TP4無(wú)法充分利用帶寬，但CM384上子節(jié)點(diǎn)內(nèi)是通過(guò)交換設(shè)備互聯(lián)，不存在這一問(wèn)題。因此，不同于Atlas800IA2的TP8，CM384上稠密層FFN的并行策略采取TP2（見(jiàn)圖8）。3.與Prefill相同，CM384上MoE模塊采用了All2All的通信方式（見(jiàn)圖9并且將共享專(zhuān)家看做一個(gè)必選的路由專(zhuān)家[6]，部署到單獨(dú)的NPU上。由于每個(gè)Token會(huì)選擇8個(gè)路由專(zhuān)家和1個(gè)共享專(zhuān)家，因此單獨(dú)部署時(shí)，共享專(zhuān)家的數(shù)量應(yīng)為路由專(zhuān)家的8分之1。在18個(gè)CM384子節(jié)點(diǎn)的144張NPU中，128張用于部署路由專(zhuān)家，其余16張卡用于4.對(duì)于Embedding模塊，由于CM384上采用了EP144，內(nèi)存壓力小，沒(méi)有使用TP；而在LMHead部分，由于TP切分可以減小每張卡上的權(quán)重搬運(yùn)，帶來(lái)性能收益，我們最終采用了TP8。4框架側(cè)性能優(yōu)化為了實(shí)現(xiàn)DeepSeekV3/R1的高吞吐，需要框架支持10K甚至更高的并發(fā)度。為此我們需要對(duì)框架進(jìn)行增強(qiáng)，通過(guò)性能優(yōu)化和多Server并發(fā)等來(lái)降低框架側(cè)耗時(shí)。我們?cè)趘LLM的以下關(guān)鍵環(huán)節(jié)進(jìn)行了深度優(yōu)化：1.請(qǐng)求下發(fā)：支持下發(fā)水平擴(kuò)展，結(jié)合負(fù)載均衡機(jī)制，降低轉(zhuǎn)發(fā)時(shí)延。2.調(diào)度策略：采用請(qǐng)求長(zhǎng)度感知與KVCache親和等高級(jí)調(diào)度策略，實(shí)現(xiàn)負(fù)載均衡與資源高3.系統(tǒng)建鏈：簡(jiǎn)化系統(tǒng)通訊鏈路，在保證穩(wěn)定性的前提下去除所有非必要鏈路。4.前后處理：多核全并行、全異步的高效前后處理，降低NPU閑置率，確保推理結(jié)果快速返回，降低端到端延遲。4.1APIServer擴(kuò)展技術(shù)當(dāng)前單節(jié)點(diǎn)APIServer部署存在故障風(fēng)險(xiǎn)。在昇騰服務(wù)器高性能架構(gòu)下，高并發(fā)請(qǐng)求易使單點(diǎn)APIServer成為性能瓶頸，導(dǎo)致響應(yīng)延遲增加，NPU算力資源浪費(fèi)。因此我們做了如下優(yōu)化：?APIServer水平擴(kuò)容策略：通過(guò)GlobalProxy組件插件化實(shí)現(xiàn)KVCache親和、負(fù)載均衡及序列長(zhǎng)度調(diào)度優(yōu)化，提升請(qǐng)求處理能力和系統(tǒng)吞吐量（QPS降低用戶(hù)請(qǐng)求延遲。?組網(wǎng)方案優(yōu)化：從APIServer與DP全連接簡(jiǎn)化為1:1組網(wǎng)，減少通訊開(kāi)銷(xiāo)，增強(qiáng)系統(tǒng)魯棒性。整體方案顯著提升TTFT提高推理服務(wù)可用性與效率，充分發(fā)揮昇騰算力，為高并發(fā)場(chǎng)景下的大模型推理服務(wù)提供可靠支持。?全并行、全異步前后處理，并結(jié)合Multi-Step技術(shù)進(jìn)一步降低Decode前后處理耗時(shí)；Prefill部分支持動(dòng)態(tài)進(jìn)程前后處理降低TTFT。4.2MoE模型負(fù)載均衡針對(duì)混合專(zhuān)家（MoE）模型推理中的“冷熱專(zhuān)家”問(wèn)題，我們提出高效負(fù)載均衡策略，解決負(fù)載不均、推理延遲高及吞吐量低等痛點(diǎn)。通過(guò)專(zhuān)家重排、分層冗余部署和近實(shí)時(shí)調(diào)度，顯著提升推理性能，具體包括：?動(dòng)態(tài)負(fù)載均衡：基于激活數(shù)據(jù)與計(jì)算均衡，動(dòng)態(tài)調(diào)整專(zhuān)家部署，縮小通信域，優(yōu)化后結(jié)果靜態(tài)負(fù)載均衡的收斂性與負(fù)載均勻性。?熱專(zhuān)家冗余部署：為高頻專(zhuān)家分配冗余實(shí)例，結(jié)合實(shí)時(shí)資源預(yù)測(cè)，降低通訊開(kāi)銷(xiāo)，從而提?實(shí)時(shí)調(diào)度：動(dòng)態(tài)調(diào)整專(zhuān)家分配，實(shí)現(xiàn)快速收斂、適應(yīng)輸入變化的同時(shí)，保持低延遲。?動(dòng)態(tài)監(jiān)控：獨(dú)立流監(jiān)控激活數(shù)據(jù)，不干擾推理，確保高魯棒性。5模型側(cè)性能優(yōu)化5.1模型側(cè)通信優(yōu)化大模型多卡部署時(shí)，卡間并行方式包括數(shù)據(jù)并行（DP）、張量并行（TP）、專(zhuān)家并行（EP）等。不同的卡間并行方式對(duì)多卡間通信方式和通信算子有著不同的需求，從而影響模型部署時(shí)的通MoE層整體通信策略針對(duì)Altas800IA2的組網(wǎng)架構(gòu)，我們采用AllGather和ReduceScatter來(lái)進(jìn)行MoE層前后的數(shù)據(jù)通信，而非經(jīng)典的EP部署下的All2All。這是因?yàn)楣?jié)點(diǎn)間通信帶寬相較節(jié)點(diǎn)內(nèi)的較低。當(dāng)單卡的并發(fā)數(shù)為BS時(shí)，若采用AllGather通信，單卡需要進(jìn)行節(jié)點(diǎn)間通信的數(shù)據(jù)量為BS×3×hidden__size。作為對(duì)比，若采用All2All方案，單卡平均需要進(jìn)行節(jié)點(diǎn)間通信的數(shù)據(jù)量為BS×6×hidden__size。同時(shí)All2All方案的通信數(shù)據(jù)量會(huì)受到專(zhuān)家負(fù)載不均的影響，不如AllGather/ReduceScatter方案穩(wěn)定。結(jié)合細(xì)粒度分級(jí)流水算法(第6.2節(jié))，AllGather/ReduceScatter方案可以做到節(jié)點(diǎn)間通信耗時(shí)幾乎被節(jié)點(diǎn)內(nèi)通信耗時(shí)掩蓋。另一方面，采用AllGather的分發(fā)模式，AllGather通信可以和Gating函數(shù)的計(jì)算解耦，實(shí)現(xiàn)計(jì)算通信并發(fā)，詳見(jiàn)第5.2節(jié)。綜上所述，在Altas800IA2的32卡部署方案中，我們采用了AllGather/ReduceScatter來(lái)進(jìn)行MoE層前后的數(shù)據(jù)通信。FlashComm主流張量并行（TP）[12]中使用AllReduce進(jìn)行通信的方案存在通信次數(shù)多、通信數(shù)據(jù)量大等問(wèn)題，且AllReduce之后的殘差連接和歸一化計(jì)算存在計(jì)算冗余，沒(méi)有充分利用多卡并行能力。為此，我們提出FlashComm網(wǎng)絡(luò)通信方案：在Prefill階段針對(duì)DeepSeekV3/R1網(wǎng)絡(luò)MLA層前后的AllReduce通信，基于相同的集合通信邏輯將張量并行中的AllReduce通信算子進(jìn)行替換，并對(duì)通信算子在網(wǎng)絡(luò)中的位置進(jìn)行編排，實(shí)現(xiàn)了低比特和低維度數(shù)據(jù)通信，從而有效降低了通信數(shù)據(jù)量和通信時(shí)延，并消除了網(wǎng)絡(luò)中存在的冗余計(jì)算。FlashComm技術(shù)應(yīng)用于DeepSeekV3/R1模型Prefill階段，降低25%的通信量，提升10%的推理性能。層內(nèi)并行轉(zhuǎn)換技術(shù)在FlashComm的基礎(chǔ)上，為進(jìn)一步優(yōu)化通信算子的時(shí)延，我們提出層內(nèi)并行轉(zhuǎn)換的優(yōu)化技術(shù)：針對(duì)Prefill階段網(wǎng)絡(luò)MLA層的節(jié)點(diǎn)內(nèi)通信，我們重新設(shè)計(jì)了MLA層內(nèi)的多卡并行策略，實(shí)現(xiàn)張量并行（TP）與數(shù)據(jù)并行（DP）[9]的靈活轉(zhuǎn)換，消除了節(jié)點(diǎn)內(nèi)卡間求和的需求，且充分利用網(wǎng)絡(luò)中低維度數(shù)據(jù)和量化特性實(shí)現(xiàn)節(jié)點(diǎn)內(nèi)通信量的大幅降低，從而顯著優(yōu)化了通信時(shí)延。層內(nèi)并行轉(zhuǎn)換技術(shù)應(yīng)用于DeepSeekV3/R1模型Prefill階段，降低71%的節(jié)點(diǎn)內(nèi)通信量，提升10%以上的推理性能。5.2模型側(cè)并發(fā)方案昇騰芯片支持多種計(jì)算資源如張量計(jì)算單元、向量計(jì)算單元，以及通信資源的并發(fā)使用，這為盡可能發(fā)揮昇騰硬件的算力和帶寬提供了支持。我們針對(duì)DeepSeekV3/R1模型的架構(gòu)進(jìn)行了細(xì)致的流水編排，從而盡可能利用硬件資源，實(shí)現(xiàn)極致的性能。具體來(lái)講，包含如下幾項(xiàng)技術(shù)：通信通信并發(fā)昇騰芯片提供了通信和通信并發(fā)的機(jī)制。當(dāng)通信帶寬利用率比較低的時(shí)候，可以把兩個(gè)通信算子并發(fā)起來(lái)以掩蓋通信算子的啟動(dòng)開(kāi)銷(xiāo)，同時(shí)提高通信帶寬的利用率。在DeepSeekV3/R1模型中，我們將Norm算子和量化算子移到AllGather通信前，從而降低通信的數(shù)據(jù)量，進(jìn)而提高通信的效率。由于量化算子的前移，需分別通信量化后的激活值和量化Scale，進(jìn)而增大了通信算子啟動(dòng)開(kāi)銷(xiāo)。由于量化Scale的數(shù)據(jù)量較小，對(duì)帶寬的占用較低，因此我們采用通信通信并發(fā)的機(jī)制，將通信激活值和通信量化Scale并發(fā)起來(lái)，在不增加激活值通信開(kāi)銷(xiāo)的前提下，掩蓋掉量化Scale的通信開(kāi)銷(xiāo)。計(jì)算通信并發(fā)昇騰芯片也提供了計(jì)算和通信的并發(fā)機(jī)制。MoE層的計(jì)算過(guò)程需要使用AllGather匯聚各張卡上token的特征，以進(jìn)行激活專(zhuān)家的篩選和計(jì)算。但Gating函數(shù)無(wú)須依賴(lài)AllGather匯聚的結(jié)果。因此，對(duì)Gating函數(shù)使用先計(jì)算后通信的方法，對(duì)共享專(zhuān)家使用DP部署，從而保證Gating函數(shù)的計(jì)算和通信、共享專(zhuān)家的計(jì)算，以及特征匯聚的AllGather通信之間解耦。我們利用昇騰的多流機(jī)制，將這三部分進(jìn)行并發(fā)處理，從而最大化推理模型的性能。結(jié)合通信通信并發(fā)技術(shù)可以實(shí)現(xiàn)極致的流水編排（參見(jiàn)圖10）。此技術(shù)在DeepSeekV3/R1模型在大并發(fā)下可以實(shí)現(xiàn)Decode性能提升15%。通信和權(quán)重預(yù)取的并發(fā)昇騰芯片提供了緩存機(jī)制，算子在進(jìn)行計(jì)算時(shí)，會(huì)優(yōu)先從緩存中尋找數(shù)據(jù)，如果命中，則直接從緩存中讀取數(shù)據(jù)，否則從HBM中讀取數(shù)據(jù)，而緩存的帶寬是HBM帶寬的數(shù)倍。由于通信算子進(jìn)行過(guò)程中HBM帶寬占用率較低，我們?cè)谕ㄐ潘阕拥倪M(jìn)行過(guò)程中可以將后續(xù)算子需要的權(quán)重提前預(yù)取到緩存中，從而降低后續(xù)算子計(jì)算過(guò)程中的權(quán)重搬運(yùn)開(kāi)銷(xiāo)。同時(shí)昇騰芯片支持限定預(yù)取帶寬，因此在通信過(guò)程中預(yù)取對(duì)通信性能影響很小。對(duì)于DeepSeekV3/R1模型，我們?cè)贛oE模塊末尾的ReduceScatter預(yù)取下一層MLA模塊中的權(quán)重和KVCache，提升了MLA約10%的性能。圖10:DecodeMoE層計(jì)算通信并發(fā)和通信通信并發(fā)。利用昇騰多流機(jī)制，使能Gating函數(shù)計(jì)算和通信，激活值的AllGather通信，共享專(zhuān)家計(jì)算進(jìn)行通信計(jì)算并發(fā)。量化后激活值和Scale的通信，路由專(zhuān)家門(mén)控系數(shù)和Index的通信進(jìn)行通信和通信并發(fā)5.3推理投機(jī)框架FusionSpec在大模型推理優(yōu)化領(lǐng)域，投機(jī)推理是一種極具潛力的技術(shù)路徑：其通過(guò)引入輕量模型或外部知識(shí)數(shù)據(jù)，為大模型生成推理草稿，從而在解碼階段一次推理多個(gè)token，提升了計(jì)算密度。以DeepSeekV3/R1模型[6]為例，其創(chuàng)新性地引入MTP（Multi-TokenPrediction）投機(jī)層，實(shí)現(xiàn)了投機(jī)推理技術(shù)的落地。投機(jī)推理在模型解碼階段的高計(jì)算密度天然匹配昇騰高算力帶寬比的特點(diǎn)。為了充分發(fā)揮這一優(yōu)勢(shì)，在低時(shí)延大并發(fā)場(chǎng)景下實(shí)現(xiàn)高吞吐，我們提出了投機(jī)推理框架FusionSpec，包括投機(jī)流程及投機(jī)算子性能的優(yōu)化技術(shù)，持續(xù)提升MTP在昇騰上的推理性能，使得MTP部分框?流程拼接：在推理流程上，將投機(jī)模型置于主體模型之后，直接使用主體模型的輸出，并復(fù)用主體模型的控制參數(shù)，大幅減少了框架耗時(shí)，適配PD分離的部署場(chǎng)景。?輕量步間準(zhǔn)備：在投機(jī)場(chǎng)景中針對(duì)框架與算子優(yōu)化，實(shí)現(xiàn)了輕量步間準(zhǔn)備，適配多核并行全異步框架，降低端到端時(shí)延。6昇騰算子性能優(yōu)化6.1MLA算子優(yōu)化Attention算子MLA相較于傳統(tǒng)的Attention（如MHA,GQA類(lèi)在Decode階段顯著帶寬瓶頸的算子由于其中間變量膨脹且計(jì)算量顯著增加，為算子優(yōu)化帶來(lái)了新的挑戰(zhàn)。針對(duì)昇騰處理器的架構(gòu)特性，我們借鑒了Flash-Attention的思想[2,3]，對(duì)MLA場(chǎng)景的Attention算子[5,6]進(jìn)行了計(jì)算過(guò)程的優(yōu)化，以及硬件親和的性能優(yōu)化。主要包括以下幾點(diǎn)：?提出AMLA（AscendMLA）算法，通過(guò)浮點(diǎn)二進(jìn)制編碼解析及存內(nèi)計(jì)算能力實(shí)現(xiàn)乘性計(jì)算的加性等價(jià)轉(zhuǎn)換，從而實(shí)現(xiàn)直接在內(nèi)存上更新輸出矩陣O的步驟，無(wú)須進(jìn)入向量計(jì)算單元，大幅降低中間變量的重復(fù)搬運(yùn)。?根據(jù)[2,3]的思想，對(duì)L1緩存進(jìn)行了細(xì)致規(guī)劃，盡可能地減少數(shù)據(jù)重復(fù)搬入搬出的過(guò)程。?在工程實(shí)現(xiàn)方面，通過(guò)優(yōu)化計(jì)算流程提高L2緩存命中率及數(shù)據(jù)復(fù)用率，并且利用K-buffer流水排布等策略，實(shí)現(xiàn)張量計(jì)算和向量計(jì)算互相掩蓋；使能昇騰硬件親和的數(shù)據(jù)排布，提高了算子整體性能。上述優(yōu)化方案提升Attention算子性能接近1倍，非MTP場(chǎng)景算力利用率達(dá)到55%，使用一個(gè)MTP模塊場(chǎng)景算力利用率達(dá)到60%。MLA前序算子針對(duì)復(fù)雜的MLA前序算子，我們分別在Prefill階段和Decode階段采取了?在Prefill階段，我們通過(guò)雙流并發(fā)等技術(shù)實(shí)現(xiàn)了流水掩蓋，同時(shí)增加了Attention算子對(duì)多種輸入輸出模式的支持以消除純?cè)L存類(lèi)冗余算子。?在Decode階段，我們采用權(quán)重吸收，同時(shí)將前序算子深度融合為MLAProlog算子，并且針對(duì)昇騰硬件架構(gòu)進(jìn)行了全方位的深度優(yōu)化。具體優(yōu)化措施包括：采用權(quán)重預(yù)取減少流水線空泡；基于最小化搬運(yùn)以及最大化帶寬的Tiling策略；通過(guò)計(jì)算解耦減少依賴(lài)；利用局部計(jì)算融合消除全核同步開(kāi)銷(xiāo)等。基于上述優(yōu)化方案，MLAProlog算子性能提升30%6.2MoE通信算子優(yōu)化Dispatch/Combine通算融合算子在EP部署模式中，MoE中的專(zhuān)家分布在通信域的各個(gè)卡上，每個(gè)token需要分發(fā)到對(duì)應(yīng)的卡上進(jìn)行計(jì)算。原始的方案使用InitialRouting根據(jù)專(zhuān)家排序?qū)λ衪oken進(jìn)行重排，再利用兩次通信算子（All2All以及All2Allv）完成token分發(fā)。該方案在通信域比較大的場(chǎng)景下，存在通信次數(shù)多，卡間同步開(kāi)銷(xiāo)大等問(wèn)題，導(dǎo)致端到端時(shí)延增加。針對(duì)此問(wèn)題，我們提出MoEDistributeDispatch和MoEDistributeCombine兩個(gè)通算融合算子：將計(jì)算和通信拆解為token粒度，通過(guò)流水排布實(shí)現(xiàn)兩者的并行執(zhí)行；利用內(nèi)存語(yǔ)義的通信技術(shù)直接向不同卡上的內(nèi)存?zhèn)鬏敂?shù)據(jù)，從而減少了本地拷貝和等待數(shù)據(jù)的開(kāi)銷(xiāo)；通過(guò)本地內(nèi)存篩選和拷貝的機(jī)制，減少了數(shù)據(jù)傳輸次數(shù)和卡間同步開(kāi)銷(xiāo)。SMTurbo-CPP針對(duì)MoE層大通信域場(chǎng)景下，小數(shù)據(jù)量傳輸效率低的問(wèn)題，我們提出SMTurbo-ConcurrentPushandPull（SMTurbo-CPP）技術(shù)：在內(nèi)存語(yǔ)義級(jí)別對(duì)通信算子All2All(v)進(jìn)行優(yōu)化，充分利用硬件并發(fā)能力，使用讀寫(xiě)混合、聚合流水、批量檢測(cè)等技術(shù)，提升了線程的訪存效率與吞吐，顯著降低Dispatch和Combine場(chǎng)景通信算子的時(shí)延。實(shí)測(cè)可降低Dispatch/Combine算子8%-20%的推理時(shí)延。細(xì)粒度分級(jí)流水算法Atlas800IA2服務(wù)器通信協(xié)議支持細(xì)粒度的分級(jí)流水算法，可大幅提升AllGather、ReduceScatter、All2All等集合通信算子的執(zhí)行效率[17]。該算法利用A2組網(wǎng)的特性，實(shí)現(xiàn)了節(jié)點(diǎn)內(nèi)/節(jié)點(diǎn)間通信的并發(fā)執(zhí)行以提高帶寬利用率。采用細(xì)粒度分級(jí)流水算法后的AllGather和ReduceScatter,在4節(jié)點(diǎn)時(shí)，可以達(dá)到節(jié)點(diǎn)間通信耗時(shí)被節(jié)點(diǎn)內(nèi)通信耗時(shí)幾乎完全掩蓋。在Decode4節(jié)點(diǎn)部署/Prefill2節(jié)點(diǎn)部署場(chǎng)景中，其性能相較All2Allv具有更大優(yōu)圖11:細(xì)粒度分級(jí)流水算法[17]，每次Server間傳輸過(guò)來(lái)的數(shù)據(jù)，在下一個(gè)步驟將此數(shù)據(jù)用于Server內(nèi)傳輸，同時(shí)獲得下一份Server間的數(shù)據(jù)，以此類(lèi)推。7性能分析7.1Altas800IA2性能分析7.1.1Decode性能A2Decode的測(cè)試方式為：?序列長(zhǎng)度為2K輸入+2K輸出/1K輸入+2K輸出。?在使能MTP進(jìn)行推理加速的情況下，由于不同測(cè)試數(shù)據(jù)集和業(yè)務(wù)場(chǎng)景的MTP接受率不同，性能測(cè)試結(jié)果會(huì)有比較大的偏差。因此在計(jì)算時(shí)延和吞吐的時(shí)候默認(rèn)按照70%接受?TPOT（Decode平均每token時(shí)延）不超過(guò)100ms。對(duì)于序列長(zhǎng)度是2K輸入+2K輸出的情形，每卡平均并發(fā)數(shù)為72，此時(shí)端到端耗時(shí)為99.6ms，卡均吞吐為723Tokens/s。具體數(shù)據(jù)詳見(jiàn)表2。圖12中詳細(xì)拆解了每個(gè)模塊的耗時(shí)，可以看出：?由于MLA的Attention算子，尤其在使能MTP時(shí)，計(jì)算密度遠(yuǎn)高于GQA和MHA，與MQA相當(dāng)，此時(shí)MLA的計(jì)算不再是完全帶寬瓶頸。我們通過(guò)第6.1節(jié)中的優(yōu)化方案，當(dāng)前的算子實(shí)現(xiàn)可以達(dá)到55%的算力利用率。輸入長(zhǎng)度輸出長(zhǎng)度單卡并發(fā)數(shù)不同接受率吞吐(Tokens/s)70%80%90%2K2K7237658081K2K784830876表2:Altas800IA2的Decode性能：在不同MTP接受率和不同序列下的單卡吞吐。圖12:Atlas800IA2的Decode在序列長(zhǎng)度2K+2K，卡均72并發(fā)的各模塊耗時(shí)拆解。?卡均72并發(fā)，且使用一個(gè)MTP模塊時(shí)，MoE中的全連接層中，每個(gè)專(zhuān)家激活的token數(shù)是72×2×8×32/256=144，對(duì)于昇騰硬件而言，這還是一個(gè)相對(duì)帶寬瓶頸的場(chǎng)景，算力利用率不高。未來(lái)使用更大規(guī)模的EP部署方案，可以進(jìn)一步提高單卡并發(fā)數(shù)，提高M(jìn)oE模塊的算力利用率。?由于采用了AllGather和ReduceScatter來(lái)作為通信方式，而非All2All方案，所以通信數(shù)據(jù)量不隨著真實(shí)的專(zhuān)家負(fù)載變化，負(fù)載不均僅通過(guò)MoE路由專(zhuān)家計(jì)算不均來(lái)影響性能，對(duì)整體性能的影響相對(duì)較小。?根據(jù)DeepSeek披露的數(shù)據(jù)[16]，MTP接受率可達(dá)80%~90%。如果按照90%的MTP接受率來(lái)估算，2K輸入+2K輸出的Decode單卡吞吐可達(dá)808Tokens/s。7.1.2Prefill性能A2Prefill的測(cè)試方式為：?jiǎn)蝏atch輸入序列長(zhǎng)度為2K/1K，通過(guò)拼batch的方式拼成一共16K序列。對(duì)于序列長(zhǎng)度是2K，共8batch拼成一共16K序列的場(chǎng)景，端到端耗時(shí)為631ms，卡均吞吐為1622Tokens/s。具體的數(shù)據(jù)見(jiàn)表3，具體的拆解數(shù)據(jù)見(jiàn)圖13。分析如下：輸入長(zhǎng)度總并發(fā)數(shù)單卡吞吐2K81K表3:Altas800IA2的Prefill性能。圖13:序列長(zhǎng)度8×2K,Prefill階段各組件的耗時(shí)占比。?Prefill階段除了MoE層前后的AllGather和ReduceScatter之外，由于我們MLA部分采用了TP16的部署策略，所以這里也存在AllGather和ReduceScatter通信過(guò)程。?由于在Output投影矩陣部分采用了第5.1節(jié)中提到的層內(nèi)并行轉(zhuǎn)換技術(shù)，我們?cè)赑refill階段也存在All2All通信過(guò)程。?雖然采用了AllGather和ReduceScatter通信方式，在負(fù)載不均時(shí)MoE部分的通信數(shù)據(jù)量是不受MoE負(fù)載不均影響的。不過(guò)負(fù)載不均會(huì)導(dǎo)致不同卡的MoE部分計(jì)算時(shí)間不同，不同卡間等待的過(guò)程在當(dāng)前的統(tǒng)計(jì)方式里會(huì)表現(xiàn)在通信的耗時(shí)上。?當(dāng)前為了部署的靈活性，同時(shí)考慮到實(shí)際場(chǎng)景Prefill難以拼到足夠的并發(fā)數(shù)，我們采用了16卡部署，MLA選擇TP16，所有卡的序列長(zhǎng)度之和為16K的一種方案。如果采用DPMLA的部署方式，則可以減少M(fèi)LA前后的通信，同時(shí)如果采用更大的并發(fā)數(shù)，可以進(jìn)一步提高M(jìn)oE部分的算力利用率。同時(shí)根據(jù)[13]，大并發(fā)的Prefill階段采用Micro-batch(Two-batchOverlap)技術(shù)可以得到相當(dāng)大的吞吐收益，甚至可以完全掩蓋通信。據(jù)此計(jì)算，Altas800IA2在Prefill階段可達(dá)到卡均3095Tokens/s的吞吐。7.2CloudMatrix384超節(jié)點(diǎn)性能分析DeepSeek團(tuán)隊(duì)基于H800的算力、帶寬和網(wǎng)絡(luò)互聯(lián)帶寬，給出了DeepSeekV3/R1模型的理論分析[16]。由于H800高單卡算力帶寬，而低網(wǎng)絡(luò)帶寬的特性，作者使用Micro-batch技術(shù)，提出利用Dispatch/Combine掩蓋其余所有計(jì)算的方案，并給出了理論的耗時(shí)估計(jì)。昇騰CloudMatrix384超節(jié)點(diǎn)由于其獨(dú)特的網(wǎng)絡(luò)互聯(lián)使得其通信方面具有顯著優(yōu)勢(shì)，這使得在CM384上我們不再是通信瓶頸。基于此，可以設(shè)計(jì)不同的Micro-batch掩蓋策略：使用MLA中Attention計(jì)算掩蓋其他部分，包括其他計(jì)算部分。根據(jù)當(dāng)前MLA的實(shí)現(xiàn)（當(dāng)前MTP的MLA算子接近60%的算力利用率并考慮到使用MLA計(jì)算掩蓋其余部分會(huì)帶來(lái)35%左右的性能劣化，以3K序列長(zhǎng)度為例，估算單層MTP的MLA的耗時(shí)大約為這里BS表示單卡的并發(fā)數(shù)，從而按照70%的MTP接受率來(lái)算的話，整個(gè)網(wǎng)絡(luò)的耗時(shí)接近如果不限制Decode時(shí)延，理論吞吐可以達(dá)到在實(shí)際部署的時(shí)候，由于多種因素的影響，實(shí)際可達(dá)吞吐會(huì)大幅打折。一個(gè)關(guān)鍵原因是Decode時(shí)延的約束限制了實(shí)際使用的并發(fā)數(shù)，使得各部分耗時(shí)未能達(dá)到理想的線性度，導(dǎo)致可達(dá)吞吐的大幅下降。另一方面，帶寬搶占帶來(lái)的惡化不可忽略，實(shí)際上上述評(píng)估中需要使用MLA來(lái)掩蓋MoE等其他計(jì)算部分，這里會(huì)發(fā)生嚴(yán)重的HBM帶寬搶占導(dǎo)致整體帶寬利用率下降。框分的序列負(fù)載均衡和MoE部分的專(zhuān)家負(fù)載會(huì)分別使得MLA和MoE部分耗時(shí)增加，導(dǎo)致進(jìn)一步的性能惡化。這些因素結(jié)合在一起，使得當(dāng)前吞吐明顯低于理論值。2025年4月，硅基流動(dòng)聯(lián)合華為云基于CloudMatrix384超節(jié)點(diǎn)昇騰云服務(wù)，采用與本報(bào)告完全相同的大規(guī)模專(zhuān)家并行方案正式上線DeepSeek-R1。該服務(wù)在保證單用戶(hù)20TPS（等效50ms時(shí)延約束）水平前提下，單卡Decode吞吐突破1920Tokens/s。[19]圖14:2025年4月，硅基流動(dòng)聯(lián)合華為云基于CloudMatrix384超節(jié)點(diǎn)上線DeepSeek-R1，單卡Decode吞吐突破1920Tokens/s.8下一步工作當(dāng)前已經(jīng)完成了在昇騰服務(wù)器上部署DeepSeek-V3/R1模型的方案，后續(xù)還有一些工作需要完善，以進(jìn)一步提升性能和支撐更多場(chǎng)景：?低時(shí)延場(chǎng)景的極致優(yōu)化：本報(bào)告中的部署方案主要瞄準(zhǔn)高吞吐場(chǎng)景，暫未針對(duì)低時(shí)延場(chǎng)景進(jìn)行極致優(yōu)化。基于當(dāng)前的部署方案，CloudMatrix384超節(jié)點(diǎn)在卡均8并發(fā)下時(shí)延為15ms，Atlas800IA2服務(wù)器上的方案在卡均4并發(fā)下時(shí)延為30ms。實(shí)際上當(dāng)前的整體部署方案、算子優(yōu)化和模型并行優(yōu)化策略均未針對(duì)低時(shí)延下做優(yōu)化，也并未使能多層MTP，還有很大的優(yōu)化空間。?Micro-batch優(yōu)化方案：在DeepSeek公布的DeepEP方案[1,13]中，提出通過(guò)將數(shù)據(jù)拆分為兩個(gè)Micro-batch的思路，實(shí)現(xiàn)了通信和計(jì)算的相互掩蓋。該技術(shù)可以預(yù)見(jiàn)地會(huì)有較大的性能收益，尤其在高并發(fā)的Decode和Prefill場(chǎng)景。當(dāng)前在CloudMatrix384超節(jié)點(diǎn)的部署上已經(jīng)采用了該技術(shù)，但在Altas800IA2上還未有效使用。接下來(lái)我們會(huì)基于Altas800IA2進(jìn)行適配以及更極致地優(yōu)化。?低比特量化方案：當(dāng)前模型采用的是A8W8C16的量化模式。對(duì)于MLA而言，其計(jì)算密度遠(yuǎn)大于經(jīng)典的GQA方案，所以傳統(tǒng)的KVCache量化[7,10]只能保證較大的內(nèi)存收益，能帶來(lái)的性能收益有限。因此我們也在探索一些將Q/K/V全部量化的計(jì)算方案，如果可以給出滿(mǎn)足精度要求的量化方案，會(huì)給Attention計(jì)算帶來(lái)可觀的加速效果。另外，針對(duì)低時(shí)延場(chǎng)景，Decode部分是強(qiáng)訪存帶寬瓶頸，如果對(duì)MoE部分使用A8W4或A4W4的量化方案，可有效降低訪存帶寬需求量，從而大幅提升性能。因此我們需要探索針對(duì)MoE部分INT4的量化技術(shù)。?MLA層算子量化支持：在長(zhǎng)序列下KVCache量化可以大幅減少推理過(guò)程中的內(nèi)存占用，我們將同步進(jìn)行Attention及MLAProlog算子針對(duì)僅KVCache的INT8量化和Q/K/V全I(xiàn)NT8量化場(chǎng)景的適配，通過(guò)深度的算子重構(gòu)與極致流水優(yōu)化保證性能。?Altas800IA2的更大EP部署方案：對(duì)于Altas800IA2，當(dāng)前采用的是32卡的部署策略，每張卡的路由專(zhuān)家個(gè)數(shù)是8個(gè)，這帶來(lái)了不小的FFN層的開(kāi)銷(xiāo)。單卡72并發(fā)，使用一個(gè)MTP模塊時(shí)，MoE的每個(gè)專(zhuān)家激活token個(gè)數(shù)是144個(gè)。而對(duì)于昇騰硬件來(lái)言，其算力帶寬比較高，因此行數(shù)為144的GEMM還不足以實(shí)現(xiàn)較高的算力利用率。我們可以進(jìn)一步地采用更大EP的部署策略，例如64卡或128卡部署?？梢灶A(yù)見(jiàn)更大EP的部署方案可以進(jìn)一步地提高M(jìn)oE部分的算力利用率，提高單卡吞吐。?序列負(fù)載均衡優(yōu)化方案：實(shí)際部署的Decode階段，每個(gè)請(qǐng)求由于其輸入序列長(zhǎng)度不同和Decode開(kāi)始時(shí)間不同，使得整個(gè)實(shí)例中不同請(qǐng)求的序列長(zhǎng)度相差很大，進(jìn)而導(dǎo)致不同卡上MLA耗時(shí)相差很大，這時(shí)MLA階段會(huì)出現(xiàn)嚴(yán)重序列負(fù)載不均的問(wèn)題。針對(duì)該問(wèn)題，可以按照不同的請(qǐng)求的處理時(shí)間對(duì)請(qǐng)求序列進(jìn)行處理優(yōu)先級(jí)劃分，從而減少整體的等待時(shí)間。具體來(lái)說(shuō)，可以通過(guò)某種簡(jiǎn)單的預(yù)測(cè)手段快速預(yù)測(cè)請(qǐng)求輸出長(zhǎng)度。在獲得輸出長(zhǎng)度之后結(jié)合輸入長(zhǎng)度來(lái)做卡間負(fù)載均衡調(diào)度，最小化不同卡間的序列負(fù)載不均。References[2]TriDao.FlashAttention-2:Fasterattentionwithbetterparallelismandworkpartitioning.InternationalConferenceonLearningRepresentations,2024.[3]TriDao,DanFu,StefanoErmon,AtriRudra,andChristopherRé.FlashAttention:Fastandmemory-e?icientexactattentionwithIO-awareness.Advancesinneuralinformationprocessingsystems,35:16344–16359,2022.[5]DeepSeek-AI,AixinLiu,BeiFeng,andBinWangetal.DeepSeek-V2:Astrong,econom-ical,ande?icientmixture-of-expertslanguagemodel,2024.URL/[6]DeepSeek-AI,AixinLiu,BeiFeng,andBingXueetal.DeepSeek-V3technicalreport,[7]ColemanHooperandetal.Kim.KVQuant:Towards10MillionContextLengthLLMInferencewithKVCacheQuantization.InA.Globerson,L.Mackey,D.Belgrave,A.Fan,U.Paquet,J.Tomczak,andC.Zhang,editors,AdvancesinNeuralInformationProcessingSystems,volume37,pages1270–1303.CurranAssociates,Inc.,2024.[8]WoosukKwon,ZhuohanLi,SiyuanZhuang,YingSheng,LianminZheng,CodyHaoYu,JosephE.Gonzalez,HaoZhang,andIonStoica.E?icientMemoryManagementforLargeLanguageModelServingwithPagedAttention.InProceedingsoftheACMSIGOPS29thSymposiumonOperatingSystemsPrinciples,2023.[9]ShenLi,YanliZhao,RohanVarma,OmkarSalpekar,PieterNoordhuis,TengLi,AdamPaszke,JeffSmith,BrianVaughan,Pr