虎嗅注：

“大模型江湖，落地為王。”這句話的含金量還在提升。隨著DeepSeek V3/R1在春節期間一夜爆火，基于超大規模MoE（Mixture of Experts）架構的大模型正在從訓練開發轉向推理應用的落地。

對于MoE推理部署來說，效率一直是一個痛點。誰能將部署計算效率提升至最高，才能真正獲得大模型商業成功。但受限于龐大的模型容量與計算需求，傳統部署方案通常依賴于多張數據中心級GPU（如H20）。你我都知道，英偉達不僅貴，而且不斷受到地緣政治摩擦的影響，不斷降低自己的性能來滿足監管需求。

而在最近，華為全面揭秘超大規模MoE模型推理部署技術，不僅實現了國產的進一步突破，更全面超越了基于英偉達Hopper架構的推理部署性能。

他們是怎么做到的？

數學補物理，極致提升計算效率

“數學補物理”，這種通過數學理論、工具、算法和建模等方式，來彌補硬件和工藝的局限性，實現最大化發揮芯片和系統能力效果。華為輪值董事長孟晚舟曾在2025年新年致辭中提到：

“華為十多個實驗室與伙伴們的工程師組成“大雜燴”團隊，面對天成AI集群系統和單芯片性能的嚴峻工程挑戰，他們創造性應用數學補物理、非摩爾補摩爾、系統補單點等思想，在散熱、供電、高速、高密及大芯片在板可靠性等工程領域突破極限。”

華為技術團隊面向超大規模MoE模型的推理技術優化也是圍繞著數學補物理這一思路，充分發揮等價數學變換，也就是在保持數學對象本質屬性不變的前提下，通過數學變形、邏輯轉換或結構重構等方式提升計算效率的方法，極致的提升了硬件集群的算力利用率，包括從點到面的推理框架側優化技術，把數學最優實現變為物理最優的FlashComm通算優化技術，把串行計算變成四流并發的通算極致掩蓋技術，以加法代乘法昇騰MLA最優實現，硬件感知親和的大量創新算子等一系列核心技術孕育而生，并將通過一連串的技術報告首次全面披露這些寶貴的技術細節。

這次昇騰超大規模MoE模型推理部署技術的揭秘，除了通過技術報告分享昇騰在超大規模MoE模型的推理部署技術之外，在近一個月的時間內，這些核心技術的相關代碼也都會陸續開源出來。在與業界分享技術思路的同時，也通過開源的方式共同打造長期持續的開放協作生態環境，讓昇騰親和的技術能力通過這些開源項目真正的活躍起來，這體現出華為堅定建設開放生態的決心，讓所有愿意嘗試使用昇騰能力的專家有信心長期投入，也讓所有積極參與貢獻的開發者有信心持續耕耘，一起努力讓昇騰生態在中國茁壯成長。

超大MoE大模型推理的挑戰

擁有6710億參數，采用混合專家架構，在各種榜單表現出色的DeepSeek V3某種程度上代表了大模型發展的一個新趨勢，即基于軟硬件協同優化的模型架構，能夠最大性能的發揮硬件平臺的能力，在多種任務中表現出色，包括自然語言理解、代碼生成和數學推理。我們暫且把DeepSeek V3為代表的大模型統稱為超大MoE類模型。

盡管在性能上表現出色，并且有著大量開源的模型權重以及很多的包括DeepEP等在內的工具類項目，但對于想使用這類大模型的企業來說，能夠高效部署完整版本的超大MoE類模型目前依舊面臨多重挑戰：

首先，硬件部署規模要求更高。現在我們在和大模型進行交互聊天的時候，無時無刻不在使用大模型的推理。而由于其自身的尺寸規模，這不再是此前小尺寸模型在單機多卡甚至單機單卡就可以運行能夠相比的。硬件集群逐漸成為“滿血版”超大MoE類模型的標配。

其次，模型規模龐大對推理效率提出了高要求。龐大的專家數量給硬件內存使用效率提出了很大挑戰，每個專家權重約44MB，而共有58個MoE層14906個專家的超大MoE類模型，對于一般的AI硬件來說，需要合理的分布式并行和通信策略設計，才能將如此大量的專家有效的跑在硬件集群上。

再次，超大MoE類模型的諸多架構創新，也帶來了很多實際部署上的困難。比如其多頭隱式注意力機制(MLA - Multi Head Latent Attention)，雖然可以通過將原有的注意力機制的鍵值對通過一個投影矩陣壓縮到一個較小的隱式向量空間中，但這種創新也為算子優化帶來了新的挑戰，比如其帶來了中間變量膨脹且向量計算占比顯著增加，這樣給硬件對計算的加速提出了新的要求

華為的解法

為了解決如上提到的實際部署中遇到的問題，從模型和算子兩個方面入手，基于昇騰硬件和組網方式，團隊提出了多個親和的優化策略，開發出了一整套面向集群的大規模專家并行的解決方案。

昇騰服務器有多種配置和型號，團隊針對：

? CloudMatrix 384超節點 ? Atlas 800I A2推理服務器

兩種典型機型進行部署。為了解耦prefill階段的首token時延約束和decode階段的解碼時延約束，采用了PD分離部署的方式。在框架側，團隊基于vLLM框架，為了適配昇騰服務器，針對DP和EP并行策略做了相應適配，在調度和KV傳輸方面分別采用了Prefill調度分桶和靈衢互聯與分層傳輸的技術來降低調度開銷，在請求下發、調度策略、系統建鏈和框架前后處理方面做了性能優化，以實現整個系統的最優性能。模型方面，采用了A8W8C16的量化策略，其中A8W8采用INT8的數據類型，C16采用BF16的數據類型進行量化。在具體部署方面，由于兩種機型的定位和配置（尤其是網絡配置）存在較大差異，所以具體部署方案也不盡相同。

針對 CloudMatrix 384 超節點，其特殊的組網方式使其具有很高的通信帶寬。按照 DeepSeek的論文所述，Decode 部分是嚴重的通信瓶頸，在 Micro-batch 技術的加持下，幾乎可以做到通信掩蓋其他所有計算類操作。而 CloudMatrix 384 的獨特組網使得通信耗時大幅降低，可以有效釋放昇騰芯片的算力。因此，針對超節點我們采用大規模 EP 并行的方式來部署：Prefill 使用 16 卡，Decode 使用 144 卡。其中 Decode 部分使用 128 卡通過大規模 EP 的方式部署路由專家，16 卡通過 DP 的方式部署共享專家，MLA 部分使用 DP 的方式進行部署。按照理論分析，超節點可以獲得非常高的理論吞吐。實際場景下，由于各種因素的影響，包括 Decode 時延的約束使得各部分耗時未能達到理想的線性度，帶寬搶占帶來一部分性能劣化，框架的耗時和調度開銷帶來了額外的時延增加，MLA 部分的序列負載均衡和 MoE 部分的專家負載均衡帶來進一步的性能惡化；最后多種因素綜合在一起，華為團隊實現在保證 50ms 時延下單卡 Decode 吞吐達到 1920 Tokens/s。

針對 Atlas 800I A2 服務器，由于每個節點包含 8 張昇騰芯片，我們需要采用多節點互聯的方式來進行部署。綜合考慮模型吞吐和部署靈活性，我們選定使用 2 節點 16 卡作為一個Prefill 實例，4 節點 32 卡作為一個 Decode 實例。為了部署時盡可能靈活，這里選用的卡數較少，這使得整個系統采用較小規模的 EP 并行策略：每張卡上部署 8(Decode)/16(Prefill)個路由專家和 1 個共享專家。在 Decode 階段，MLA 部分采用 DP 并行策略，通信方式采用AllGather/ReduceScatter 方案。這種部署方式可以在卡數較少的情況下依然達到相當可觀的吞吐。值得一提的是，在真實負載下， AllGather/ReduceScatter 通信方案比 Dispatch/Combine 通信方案具有更好的性能表現。綜合上述優化方案，我們實現了在 100ms 時延下單卡吞吐達到 723～808Tokens/s。

推理框架側優化技術

1. API Server擴展技術

團隊提出了API Server擴展技術，通過支持API Server水平擴容策略，可以有效提升框架請求處理能力，降低用戶請求延遲，提高系統吞吐量（QPS）。結合包括組網方案優化和全并行、全異步前后處理，可進一步實現最佳TTFT，提升推理服務的可用性與處理效率

2. MoE模型負載均衡

團隊提出了一種高效的負載均衡策略，通過動態負載均衡，熱專家冗余部署，實時調度和動態監控等核心技術，顯著提升MoE模型推理性能。

FusionSpec推理投機加速技術

在實際應用中，投機推理技術更多聚焦于小批量（batch）低時延場景，如何將其高效應用于高吞吐量場景并實現性能收益最大化，成為當前亟待攻克的技術難題。

投機推理在模型解碼階段的高計算密度，天然匹配昇騰高計算帶寬比的特點。為了能夠充分發揮昇騰算力大的優勢，在低時延大并發場景下實現高吞吐，團隊提出了投機推理引擎FusionSpec深度優化MTP在昇騰上的推理性能：

●流程拼接：在推理流程上，將投機模型置于主體模型之后，直接使用主體模型的輸出，并復用主體的控制參數，大幅減少了框架耗時，適配PD分離的部署場景。 ●輕量步間準備：在投機場景中針對框架與算子優化，實現了輕量步間準備，適配多核并行全異步框架，降低端到端時延。

模型側性能優化技術

1. 模型側通信優化

●FlashComm：主流張量并行（TP） 中使用AllReduce進行通信的方案存在通信次數多，通信數據量大等問題，且AllReduce之后的殘差連接和歸一化計算存在計算冗余，沒有充分利用多卡并行能力。為此團隊提出了FlashComm網絡通信方案：在 Prefill 階段針對DeepSeek V3 網絡 MLA 層前后的 AllReduce 通信，基于相同的集合通信邏輯將張量并行中的AllReduce通信算子進行替換，并對通信算子在網絡中位置進行編排，實現了低比特和低維度數據通信，從而有效降低了通信數據量和通信時延，并消除了網絡中存在的冗余計算。FlashComm 技術應用于 DeepSeek V3 模型 Prefill 階段，降低 25% 的通信量，提升 10%的推理性能。 ●層內并行轉換技術：在FlashComm的基礎上，為進一步優化通信算子的時延，團隊提出層內并行轉換的優化方案：針對Prefill階段網絡MLA層的節點內通信重新設計了單層內使用的并行策略，靈活做到張量并行（TP）與數據并行（DP）的轉化，消除節點內卡間求和的需求，且充分利用網絡中低數據維度和量化特性實現節點間通信量的大幅降低，從而顯著優化了通信時延。這一技術術應用于 DeepSeek V3/R1 模型 Prefill 階段，降低 71%的節點內通信量，提升 10% 以上的推理性能。

2. 模型側并發優化

●計算通信并發：昇騰芯片提供了計算和通信的并發機制。MoE層的計算過程中需要使用AllGather匯聚各張卡上的Token的特征進行激活專家的篩選和計算。方案中，對于Gating函數使用先計算后通信的方法，對共享專家使用DP部署，從而保證了Gate函數的計算和通信、共享專家的計算，以及特征匯聚的AllGather 函數之間沒有依賴關系。團隊利用昇騰的多流機制，將這三部分進行并發處理，從而最大化推理模型的性能。此技術在 DeepSeekV3模型的大并發場景下可以實現 Decode 性能提升 15%。 ●通信通信并發：昇騰芯片也提供了通信和通信并發的機制。當通信帶寬利用率比較低的時候，可以把兩個通信算子并發起來以掩蓋通信算子的啟動開銷，同時提高通信帶寬的利用率。DeepSeekV3模型在進行AllGather等通信時，可以將Norm算子和量化算子移到AllGather通信的前面，從而降低通信的數據量，進而提高通信的效率。但是由于量化算子的前移，需分別通信量化后的激活值和scale，進而增大了通信算子啟動開銷。由于量化scale的數據量較小，對帶寬的占用較低，因此團隊采用通信通信并發的機制，將通信激活值和通信量化scale并發起來，在不增加激活值通信開銷的前提下，掩蓋掉量化scale的通信代價。 ● 通信和權重預取的并發：昇騰芯片提供了緩存機制，算子在進行計算時，會優先從緩存中尋找數據，如果命中，則直接從緩存中讀取數據，否則從HBM中讀取數據，而緩存的帶寬是HBM帶寬的數倍。由于通信算子進行過程中HBM帶寬占用率較低，在通信算子進行過程中可以將后續算子需要的權重提前預取到緩存中，從而降低后續算子計算過程中的權重搬運開銷。同時昇騰芯片支持靈活限定預取帶寬，因此在通信過程中預取對通信性能影響很小。對于DeepSeek模型，在MoE模塊末尾的ReduceScatter預取MLA中權重矩陣和KV cache，可以提升MLA部分約10%計算性能。

昇騰親和的創新算子

1. MLA算子優化

Attention算子：MLA相較于傳統的Attention算子（如MHA, GQA類顯著帶寬瓶頸的算子），由于其中間變量膨脹且計算量顯著增加，為算子優化帶來了新的挑戰。針對昇騰處理器的架構特性，團隊對MLA場景的FA算子進行了算法重構以及硬件親和的性能優化。

?提出AMLA（Ascend MLA）算法，通過二進制編碼解析及存內計算，實現乘性計算的加性等價轉換，從而實現直接在Global Memory上更新O的步驟，無須進入Vector core，大幅降低中間變量的重復搬運。 ?對L1緩存進行了細致規劃，盡可能地減少數據重復搬入搬出的過程。 ?在工程實現方面，通過優化計算流程提高L2 cache命中率，并且利用K-buffer流水排布等策略，實現Cube計算和Vector計算互相掩蓋，提高了算子整體性能。

上述優化方案提升 Attention 算子性能接近 1 倍，非 MTP 場景算力利用率達到 55%，使用一個 MTP 模塊場景算力利用率達到 60%。

MLA前序算子：針對復雜的MLA前序算子，分別在Prefill階段和Decode階段采取了不同的優化策略：

?在Prefill階段，通過雙流并發等技術實現了流水掩蓋，同時增加了FA算子對多種輸入輸出模式的支持以消除純訪存類冗余算子。 ?在Decode階段，團隊采用權重吸收，同時將前序算子深度融合為MLAProlog算子，并且針對昇騰硬件架構進行了全方位的深度優化。

具體優化措施包括：采用權重預取減少流水線空泡；基于最小化搬運以及最大化帶寬的tiling策略；通過計算解耦降低指令依賴與等待；利用局部計算融合消除全核同步開銷；運用昇騰定制指令集實現ICache壓縮，規避issue queue阻塞風險等。

通過上述優化方案，MLAProlog 算子性能提升 30%以上。

2. MOE算子優化

Dispatch/Combine通算融合算子：在EP部署模式中，MoE中的專家分布在較大的通信域的各個卡上，每個Token需要分發到對應的卡上進行計算，原始的實現方式使用InitialRouting根據專家排序對所有Token進行重排，再用AllToAll以及AllToAllv通信算子進行交換token。該實現方式在通信域比較大的場景下，存在通信次數多、卡間同步開銷嚴重等問題，阻礙了整網端到端時延的提升。因此團隊提出MoeDistributeDispatch和MoeDistributeCombine兩個通算融合算子技術：將計算和傳輸拆解為Token粒度的計算單位，通過流水排布實現通信和計算的并行執行；同時利用內存語義的通信技術直接向不同卡上的共享內存傳輸數據，從而減少了本地拷貝和等待數據的開銷；團隊還通過本地內存篩選和拷貝的機制，減少了數據傳輸次數和卡間同步開銷。

SMTurbo-CPP算子：針對MOE層大通信域場景下，小數據量傳輸效率低的問題，團隊提出SMTurbo-Concurrent Push and Pull（SMTurbo-CPP）技術：在內存語義級別對通信算子AllToAll(v)進行優化，充分利用硬件并發能力，使用讀寫混合、聚合流水、批量檢測等技術，提升了線程的訪存效率與吞吐，顯著降低Dispatch和Combine場景通信算子的時延。

細粒度分級流水算法：基于Atlas A2系列產品，HCCL支持細粒度的分級流水算法，可大幅提升集群中Allgather、ReduceScatter、AlltoAll等集合通信算子的執行效率。該算法利用A2組網的特性，實現了節點內/節點間的并發執行，以提高帶寬利用率。

在2025年4月，硅基流動聯合華為云基于CloudMatrix 384超節點昇騰云服務和高性能推理框架SiliconLLM，用大規模專家并行最佳實踐正式上線DeepSeek-R1。該服務在保證單用戶20 TPS水平前提下，單卡Decode吞吐突破1920 Tokens/s，可比肩H100部署性能。同時，經過主流測試集驗證及大規模線上盲測，在昇騰算力部署DeepSeek-R1的模型精度與DeepSeek官方保持一致。

在大模型產業加速落地的關鍵節點，華為玩了波“硬核操作“—— 用“數學補物理的創新思路”硬剛硬件瓶頸，拿通算融合玩轉集群調度，靠算子重構榨干芯片性能。這場全鏈路技術優化不僅實現了超大規模模型在國產硬件上的高效部署，更以開源共享的姿態激活了本土 AI 生態的協同創新活力。

本內容為作者獨立觀點，不代表虎嗅立場。未經允許不得轉載，授權事宜請聯系 hezuo@huxiu.com

本文來自虎嗅，原文鏈接：https://www.huxiu.com/article/4367996.html?f=wyxwapp