隨著DeepSeek火爆全網(wǎng)，混合專(zhuān)家（Mixture of Experts, MoE）技術(shù)也成功出圈。憑借優(yōu)秀的性能，MoE成為大語(yǔ)言模型（LLM）界的頂流。在各行各業(yè)加速接入國(guó)產(chǎn)開(kāi)源大模型DeepSeek的同時(shí)，人工智能領(lǐng)域大范圍落地應(yīng)用也帶來(lái)了龐大的算力需求，業(yè)界的大模型推理系統(tǒng)開(kāi)始采用大規(guī)模專(zhuān)家并行方案，大規(guī)模專(zhuān)家并行集群推理能夠提升吞吐和降低時(shí)延，也在推理過(guò)程中帶來(lái)了通信時(shí)延長(zhǎng)、負(fù)載不均衡、算力浪費(fèi)等新挑戰(zhàn)。優(yōu)化負(fù)載均衡、縮減通信開(kāi)銷(xiāo)以及高效利用資源，是當(dāng)前亟待解決的技術(shù)難題。針對(duì)這些難題，昇騰推出大規(guī)模專(zhuān)家并行集群推理解決方案，通過(guò)多專(zhuān)家負(fù)載均衡和極致通信優(yōu)化，實(shí)現(xiàn)極致吞吐，單卡性能提升到3倍，Decode時(shí)延降低50%+，實(shí)現(xiàn)更高性能，提升客戶(hù)體驗(yàn)。
本期，將為大家重點(diǎn)介紹昇騰大規(guī)模專(zhuān)家并行（EP）針對(duì)All-to-All通信、計(jì)算瓶頸的優(yōu)化：通過(guò)動(dòng)態(tài)EP（Prefill階段）、算子融合（Decode階段）的策略?xún)?yōu)化分配專(zhuān)家計(jì)算節(jié)點(diǎn)，提升集群利用率。
傳統(tǒng)專(zhuān)家并行架構(gòu)的挑戰(zhàn)：
All-to-All 的不足
許多企業(yè)用戶(hù)接入DeepSeek后，業(yè)務(wù)量激增，推理集群需要從 16 卡擴(kuò)展到千卡。然而，擴(kuò)容并非簡(jiǎn)單堆疊硬件，就像普通公路單純拓寬車(chē)道，若行駛車(chē)輛頻繁變換車(chē)道、上下乘客，仍會(huì)導(dǎo)致交通擁塞。而大規(guī)模專(zhuān)家并行方案，如同將普通公路升級(jí)為智能公路：通過(guò)一種動(dòng)態(tài)路由算法（智能分流系統(tǒng)），給不同特性的數(shù)據(jù)流（乘客）分配卡（車(chē)輛）并匹配專(zhuān)屬的專(zhuān)家模型（路徑）——讓需要極速響應(yīng)的數(shù)據(jù)駛?cè)?quot;超算快車(chē)道"，讓復(fù)雜計(jì)算任務(wù)進(jìn)入"重載專(zhuān)用道“。
也就是說(shuō)，專(zhuān)家并行架構(gòu)中，需要解決的關(guān)鍵問(wèn)題之一就是如何高效調(diào)度數(shù)據(jù)流動(dòng)。常用的數(shù)據(jù)傳輸通信策略All-to-All：
每個(gè)節(jié)點(diǎn)發(fā)送N 份不同數(shù)據(jù)（每個(gè)目標(biāo)節(jié)點(diǎn)對(duì)應(yīng) 1 份），同時(shí)每個(gè)節(jié)點(diǎn)接收每個(gè)節(jié)點(diǎn)發(fā)送給自己的數(shù)據(jù)，數(shù)據(jù)可能與其他節(jié)點(diǎn)不同，最終每個(gè)節(jié)點(diǎn)擁有專(zhuān)屬的接收數(shù)據(jù)集合。這就像所有車(chē)廂互相交換全部乘客數(shù)據(jù)（全量交互）。分發(fā)精準(zhǔn)，但也存在通信復(fù)雜，帶寬敏感的問(wèn)題。
●通信復(fù)雜度高：數(shù)據(jù)塊頻繁交換，通信耗時(shí)占端到端推理30%以上，算力利用率不足5%。
●帶寬敏感：在大規(guī)模分布式系統(tǒng)中，尤其是當(dāng)節(jié)點(diǎn)數(shù)量眾多且通信數(shù)據(jù)量較大時(shí)，所有節(jié)點(diǎn)之間同時(shí)進(jìn)行數(shù)據(jù)交換會(huì)對(duì)網(wǎng)絡(luò)帶寬造成巨大壓力。
●適用場(chǎng)景：4機(jī)及以上有一定收益，但大規(guī)模集群下效率仍不理想。
昇騰MoE分階段All-to-All優(yōu)化
昇騰針對(duì)All-to-All算法的不足，結(jié)合LLM推理兩階段的不同特點(diǎn)，提出了相適應(yīng)的優(yōu)化方案。
我們知道，LLM 推理包含Prefill和Decode這兩個(gè)階段，Prefill階段處理用戶(hù)輸入的提示詞，構(gòu)建KVcache，生成首個(gè)輸出詞，為計(jì)算密集型；Decode階段針對(duì)已有KVcache，頻繁讀取繼續(xù)生成輸出Token，形成完整回復(fù)，為訪(fǎng)存密集型。接下來(lái)我們將具體介紹昇騰大規(guī)模專(zhuān)家并行方案是如何利用階段特點(diǎn)和All-to-All特點(diǎn)，因勢(shì)利導(dǎo)，實(shí)現(xiàn)通信范式的優(yōu)化：
1.MindIE 動(dòng)態(tài)EP（Prefill階段）實(shí)測(cè)顯存節(jié)省約50%
動(dòng)態(tài)EP通過(guò)動(dòng)態(tài)路由調(diào)度機(jī)制，采用專(zhuān)家歸屬識(shí)別，All-to-All精準(zhǔn)分發(fā)的技術(shù)路徑，以車(chē)廂和乘客的例子來(lái)說(shuō)：就像按目的地等條件，僅在必要車(chē)廂間交換特定乘客（按需交互）。單一的All-to-All策略，在Prefill階段，面臨單一請(qǐng)求對(duì)應(yīng)多個(gè)輸入token的計(jì)算密集型場(chǎng)景時(shí)，通信效率低。動(dòng)態(tài)EP的核心優(yōu)勢(shì)就此凸顯，采用稀疏通信策略，傳輸必要數(shù)據(jù)降低通信量，同時(shí)通過(guò)預(yù)分配通信緩沖區(qū)消除動(dòng)態(tài)內(nèi)存管理的運(yùn)行時(shí)開(kāi)銷(xiāo)。
2.CANN Dispatch/Combine融合算子（Decode階段）實(shí)測(cè)吞吐性能提升約20%
a.Dispatch模塊：不同專(zhuān)家接收的Token數(shù)據(jù)長(zhǎng)度不一致，Dispatch模塊智能打包不同長(zhǎng)度的數(shù)據(jù)塊，實(shí)現(xiàn)動(dòng)態(tài)Shape的All-to-All通信。
b.Combine模塊：實(shí)時(shí)重組分散數(shù)據(jù)，直接輸出計(jì)算結(jié)果。
c.通過(guò)通信-計(jì)算深度融合，減少數(shù)據(jù)搬運(yùn)次數(shù)，支持流式生成。
Dispatch模塊如同精準(zhǔn)的快遞分揀系統(tǒng)，在識(shí)別Token歸屬專(zhuān)家的同時(shí)，動(dòng)態(tài)打包不同長(zhǎng)度的數(shù)據(jù)塊，通過(guò)優(yōu)化后的All-to-All通信實(shí)時(shí)發(fā)往目標(biāo)設(shè)備；Combine模塊則像高效的裝配流水線(xiàn)，在接收端直接將分散的數(shù)據(jù)還原為完整計(jì)算結(jié)果。
針對(duì)Decode階段一個(gè)請(qǐng)求對(duì)應(yīng)一個(gè)token的訪(fǎng)存密集型場(chǎng)景，Dispatch/Combine算子通過(guò)融合集成，提升響應(yīng)速度。
MoE分階段并行優(yōu)化策略通過(guò)兩大創(chuàng)新點(diǎn)重塑了解碼流程：一是將原本分離的通信計(jì)算步驟深度融合，通過(guò)底層指針實(shí)現(xiàn)，減少數(shù)據(jù)搬運(yùn)次數(shù)，并減少排序計(jì)算次數(shù)；二是支持動(dòng)態(tài)Shape的All-to-All通信，實(shí)現(xiàn)不等長(zhǎng)的數(shù)據(jù)分發(fā)，適配每個(gè)Token生成時(shí)不斷變化的計(jì)算需求。在聊天對(duì)話(huà)等需要逐字生成的場(chǎng)景中，Dispatch/Combine通算融合方案真正實(shí)現(xiàn)了流式生成場(chǎng)景的毫秒級(jí)響應(yīng)，實(shí)驗(yàn)室基于DeepSeek V3驗(yàn)證，性能提升最高可達(dá)25%。
使用方法
昇騰大模型專(zhuān)家并行方案支持 ALL to ALL 優(yōu)化策略。集群規(guī)模大于或等于64張卡時(shí)，部署DeepSeekV3類(lèi)MoE模型，即可啟用動(dòng)態(tài)EP和Dispatch/Combine融合算子。DeepSeek V3模型部署過(guò)程可參考：http://m.digitalhealthexpert.com/uploadfile/pic2020/2025/0409/20250409212011218G>
開(kāi)發(fā)者若有二次開(kāi)發(fā)需求，CANN Dispatch/Combine融合算子接口調(diào)用方法如下：
每個(gè)算子分為兩段式接口，必須先調(diào)用“aclnnMoeDistributeDispatchGetWorkspaceSize”接口獲取計(jì)算所需workspace大小以及包含了算子計(jì)算流程的執(zhí)行器，再調(diào)用“aclnnMOEDistributeCombine”和“aclnnMOEDistributeDispatch”接口執(zhí)行計(jì)算。
1 aclnnStatusaclnnMOEDistributeCombineGetWorkspaceSize(constaclTensor *expandX,constaclTensor *expertIds,
2constaclTensor* expandIdx,constaclTensor* epSendCounts,constaclTensor* expertScales,
3 constaclTensor* tpSendCountsOptional,constaclTensor* xActiveMaskOptional,
4 constaclTensor* activationScaleOptional,constaclTensor* weightScale,
5 constaclTensor* groupListOptional,constaclTensor* expandScales,constchar* groupEp,
6 int64_tepWorldSize,int64_tepRankId,int64_tmoeExpertNum,constchar* groupTp,
7 int64_ttpWorldSize,int64_ttpRankId,int64_texpertShardType,int64_tsharedExpertRankNum,
8 int64_tglobalBS,int64_toutDtype,int64_tcommQuantMode,int64_tgroupListType, aclTensor* out,
9 uint64_t*workspaceSize, aclOpExecutor **executor);
10 aclnnStatusaclnnMOEDistributeCombine(void*workspace,uint64_tworkspaceSize, aclOpExecutor *executor,
11 aclrtStream stream)
12 aclnnStatusaclnnMoeDistributeDispatch(void*workspace,uint64_tworkspaceSize, aclOpExecutor *executor,
13 aclrtStream stream)
總結(jié)
在大規(guī)模專(zhuān)家并行方案中，昇騰通過(guò)MoE分階段并行優(yōu)化技術(shù)，針對(duì)All-to-All算法重點(diǎn)創(chuàng)新，在Prefill階段啟用All-to-All動(dòng)態(tài)EP壓縮通信，Decode階段切換為Dispatch/Combine實(shí)現(xiàn)超低延遲，兼顧吞吐量與實(shí)時(shí)性。
結(jié)語(yǔ)
本期為大家介紹了昇騰針對(duì)大規(guī)模專(zhuān)家并行場(chǎng)景的MoE分階段并行優(yōu)化技術(shù)，下期內(nèi)容，我們將解析大規(guī)模專(zhuān)家并行場(chǎng)景下，昇騰如何實(shí)現(xiàn)技術(shù)突圍，降低時(shí)延通信，敬請(qǐng)關(guān)注！
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。 ）
