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