專家並行（Expert Parallelism, EP）

3 秒看懂

專家並行（EP）是為混合專家模型（MoE） 設計的一種分散式計算策略。其核心思想是將MoE模型中的多個“專家”網路（Expert）分散到不同的計算裝置（如GPU/TPU）上，每個裝置只負責處理被路由器選中的那一小部分專家的計算。EP旨在解決MoE模型引數量巨大、單卡無法容納的難題，是實現萬億引數模型訓練和推論的關鍵使能技術。

3 分鐘產業解釋

當前，前沿AI大型模型正從密集（Dense）架構向混合專家（MoE） 架構快速演進。MoE模型通過啟用總引數中的一小部分（專家）來處理每個輸入，以極低的計算成本實現巨大的模型容量。然而，這帶來了一個新挑戰：模型的總引數量可能達到萬億級別，遠超任何單一加速器的記憶體容量。

專家並行（EP）正是為了解決這一“存不下”和“算不動”的矛盾而誕生的核心系統技術。它與資料並行、張量並行、流水線並行等技術共同構成現代AI分散式訓練/推論的“並行工具箱”。在產業實踐中，EP是連線超大MoE模型演算法與大規模GPU叢集硬體的關鍵橋樑。沒有高效可靠的EP實現，如DeepSeek-V2、Mixtral、Grok-1等明星MoE模型就無法被訓練和部署。因此，掌握EP技術棧，意味著掌握了下一代AI基礎設施的核心能力，直接影響著大型模型公司的研發效率與成本。

15 分鐘專家深入

專家並行的必要性源於MoE模型的內在特性：

1. 引數稀疏性：MoE模型的絕大部分計算（FFN層）由多個並行的專家網路完成，但每個Token僅啟用其中少數（如1-2個）。這使得模型總引數大，但單個Token的計算量（FLOPs）遠低於同參數規模的密集模型。
2. 記憶體牆挑戰：儘管計算稀疏，但所有專家網路的完整引數必須駐留在記憶體中，以便路由器動態選擇。一個擁有64個專家、每個專家引數量等同於一個密集模型FFN的MoE模型，其總引數是密集版的數十倍。
3. 計算不規則性：路由器動態選擇專家，導致每個裝置上的計算負載可能不均衡（負載不均衡問題），給系統排程帶來挑戰。

EP的戰略價值在於：

• 記憶體效率：將專家分佈到多個裝置，使每個裝置只需儲存部分專家的引數和對應最佳化器狀態，突破單裝置記憶體極限。
• 計算解耦：EP可以與資料並行（DP）、張量並行（TP）、流水線並行（PP）等正交組合。例如，在典型的超大規模訓練中，採用 DP + EP + TP 的混合並行策略。DP處理資料批次，TP切分單個專家的計算（如切分FFN的權重矩陣），EP將不同的專家分配到不同的TP組。
• 通訊模式特化：EP引入了一種獨特的通訊模式。在MoE層的前向和反向傳播中，需要將每個Token的資料路由到其被選定的專家所在的裝置，計算完成後再聚合結果。這通常通過 All-to-All通訊 實現，其通訊模式與DP的AllReduce或TP的AllReduce/ReduceScatter有本質區別，對網路拓撲（如高速互聯如NVLink、NVSwitch、InfiniBand）提出特定要求。

技術原理

EP的核心機制圍繞著路由和通訊展開。以一個簡化的兩裝置（GPU0, GPU1）EP系統為例，假設模型有4個專家（E0-E3），GPU0負責E0, E1；GPU1負責E2, E3。

# 前向傳播EP通訊示意（程式碼塊內ASCII圖）
                  裝置0 (GPU0)                  裝置1 (GPU1)
                +----------------+              +----------------+
 Token A: [路由 -> E1]           |              |                |
 Token B: [路由 -> E0]           |              |                |
                |  E0, E1 引數  |  -- All-to-All通訊(A-E1, B->E0) -->  |  E2, E3 引數  |
                | 計算GEMM/啟用 |              | 計算GEMM/啟用 |
                +----------------+              +----------------+
                     |                                  |
                     |    -- All-to-All通訊(結果回傳) --   |
                     v                                  v
                Token A 的輸出 (來自E1)      Token B 的輸出 (來自E0)

# 關鍵通訊與計算步驟分解：
1.  **路由計算**：每個裝置對其本地微批次（micro-batch）中的所有Token，使用路由器（Router）計算每個專家的權重/機率，並決定啟用哪些專家（Top-K）。此步驟在每個裝置上獨立完成。
2.  **Token分發（Dispatch）**：這是EP的核心通訊。每個裝置需要將屬於其他裝置上專家的Token傳送出去，同時接收屬於本裝置專家的Token。通訊模式是 **All-to-All**。設總Token數為N，總專家數為E，啟用專家數為K，則每個裝置平均接收的Token數約為 (N * K) / (裝置數)，通訊量與總Token數和啟用專家數成正比。
3.  **專家計算**：在每個裝置上，對分發到本地的所有Token，執行其被路由到的專家的前向計算（通常是FFN）。此步驟是**計算密集型**。
4.  **結果聚合（Combine）**：與分發過程相反，將計算結果All-to-All通訊回Token的原始裝置，並根據路由權重進行加權求和，得到MoE層的最終輸出。

**關鍵引數與考量**：
- **負載均衡損失**：為防止路由器將所有Token都發送到少數專家（導致計算和通訊熱點），通常會引入輔助損失函式（如Switch Transformer中的負載均衡損失）。
- **容量因子**：限制每個專家在一個微批次中最多能處理的Token數量，以防止記憶體溢位和降低通訊不規則性。
- **通訊-計算重疊**：高階EP實現會試圖將All-to-All通訊與專家計算進行流水線化重疊，以隱藏通訊延遲。

技術演進史

• 早期探索（~2017）：Google的Shazeer等人在《Outrageously Large Neural Networks》中提出MoE模型，主要在單裝置內用門控網路啟用少量專家，EP概念尚未顯性化。
• 系統化實踐（2020-2021）：隨著Switch Transformer (Google) 和 GShard (Google) 等工作的發表，MoE擴充套件到數千億引數。這些工作明確提出了將專家分散在不同裝置上的並行策略，並系統討論了All-to-All通訊、負載均衡等挑戰。此時EP開始作為大規模分散式訓練的一個獨立元件被設計。
• 工程最佳化與普及（2022-至今）：以Megablocks (Databricks)、Tutel (Microsoft)、DeepSpeed-MoE (Microsoft)、FastMoE (社群) 等開源架構為代表，EP的工程實現得到極大最佳化。重點包括：高效All-to-All通訊原語、與其它並行模式的靈活組合、處理不規則計算（稀疏計算）的專用運算元、以及在推論場景下的EP最佳化。DeepSeek-V2等模型的成功，標誌著EP技術棧已趨於成熟，成為訓練超大MoE模型的標準配置。

技術路線對比

以下表格對比了EP與其它主流並行技術的關鍵特徵。需要注意的是，在實際超大規模訓練中，這些技術通常是混合使用的。

並行策略	切分物件	主要目的	核心通訊模式	對互聯的要求	適用模型型別
資料並行 (DP)	資料批次 (Batch)	提升吞吐量，擴充套件訓練規模	AllReduce (梯度同步)	較低（引數伺服器或環狀拓撲）	所有模型
張量並行 (TP)	單層內的權重矩陣/運算元	解決單層過大無法放入單裝置，降低延遲	AllReduce/ReduceScatter (層內啟用同步)	極高（需要裝置間低延遲高頻寬互聯，如NVLink/NVSwitch）	密集模型的FFN/Attention層
流水線並行 (PP)	模型的層 (Stage)	將模型層順序切分到不同裝置	點對點通訊（前後微批次啟用）	中等（Stage間需穩定連線）	所有模型（尤其是層級明顯的）
專家並行 (EP)	MoE模型中的專家網路	解決MoE模型總引數量超大，單裝置無法容納的問題	All-to-All (Token路由)	極高（需支援不規則All-to-All模式的互聯）	混合專家模型 (MoE)
序列並行 (SP)	序列長度維度	處理長序列，降低單裝置序列維度的記憶體消耗	AllGather/ReduceScatter	中等至高	所有模型（處理長文本/影片等）

說明：上表為定性比較。具體效能受模型結構、叢集拓撲、實現最佳化等因素影響。TP和EP都對高速互聯有嚴苛要求，但通訊模式不同（TP是規則的、層內的集合通訊；EP是不規則的、層間的All-to-All通訊）。

上下游

上游（依賴項）：

1. MoE演算法與模型架構：EP是MoE模型的系統層實現，其設計直接受MoE路由機制（Top-1, Top-2, Choice）、專家數量、啟用專家數、負載均衡策略等影響。
2. 硬體基礎設施：需要具備高頻寬、低延遲、支援All-to-All模式的網際網路絡。典型代表：
   • 節點內：NVIDIA NVLink、NVSwitch（提供GPU間超高頻寬直連）。
   • 節點間：InfiniBand、高速RoCE網路。
   • 計算卡本身需具備足夠大的HBM記憶體以存放分片後的專家引數及通訊緩衝區。
3. 通訊庫與執行時：依賴如NVIDIA NCCL（支援All-to-All）、MPI等底層通訊庫。

下游（使能項）：

1. 大規模MoE模型訓練：是訓練萬億引數MoE模型的必備元件，直接影響訓練速度、穩定性和成本。
2. MoE模型推論與部署：在推論階段，EP同樣用於將大型MoE模型分佈到多個裝置上，以滿足低延遲和高吞吐的服務要求。
3. AI架構與編譯器：PyTorch、JAX、TensorFlow等架構，以及專用AI編譯器（如XLA）都需要整合EP運算元和排程策略。

關鍵指標

評估EP系統性能與效率的核心指標包括：

1. All-to-All通訊開銷佔比：在訓練/推論的總時間中，EP引入的All-to-All通訊所消耗的時間比例。最佳化目標是最小化此比例。
2. 負載均衡度：衡量各裝置（專家）上實際處理的Token數量與理想均勻分佈的偏差。常用方差或最大最小負載比表示。負載不均衡會導致計算資源閒置和通訊熱點。
3. EP計算效率 (MFU)：在EP模式下，模型實際達到的浮點運算利用率。需考慮因稀疏計算、不規則通訊帶來的效率損失。
4. 最大可擴充套件模型引數：在給定叢集規模下，通過EP所能支援的MoE模型最大總引數量。
5. 每裝置記憶體佔用：部署EP後，單個裝置需要承載的專家引數、最佳化器狀態、啟用值和通訊緩衝區的總大小。

供需與市場資料

注：以下為基於公開資訊的估算，具體資料[廠商財報/行業報告未充分揭露]。

• 需求端驅動力：
  1. MoE模型成為主流：主要AI實驗室（Google, OpenAI, Meta, DeepSeek, xAI等）釋出的前沿大型模型中，MoE架構比例顯著上升。
  2. 模型規模指數增長：模型引數從千億向萬億邁進，單卡記憶體增長速度（如NVIDIA H100 80GB -> B200 192GB）遠跟不上。
  3. 推論成本壓力：EP允許用更少的裝置數（相比全引數部署）服務大型模型，是降低推論成本的關鍵。
• 供給端能力：
  1. 硬體：以NVIDIA的GPU和高速互聯（NVLink, NVSwitch, InfiniBand）生態為核心主導。AMD的MI系列GPU及其Instinct平台也在建置類似能力。
  2. 軟體：開源架構（DeepSpeed-MoE, Megablocks）與廠商自研架構（Google的GShard, Meta的內部架構）並存。軟體棧的成熟度是主要瓶頸。
• 市場規模：EP本身不是一個獨立市場，而是大型模型訓練與推論基礎設施的核心組成部分。其價值蘊含在AI伺服器、高效能網路裝置和AI軟體平台的整體市場中。全球AI伺服器市場（包含EP所需配置）預計在未來幾年保持高速增長，達到[未充分揭露，估算數百億至千億美元級別]規模。

代表公司與資本對映

環節	代表公司/機構	與EP的關聯
模型層	Google (GShard, Switch Transformer), DeepSeek, xAI (Grok-1), Mistral AI (Mixtral)	需求方與核心推動者。其MoE模型架構定義了EP的演算法需求。
硬體層	NVIDIA (GPU, NVLink, NVSwitch, NCCL), AMD (GPU, ROCm), Intel (Gaudi), Broadcom (網路晶片)	基礎設施提供者。提供執行EP所需的算力卡和高速互聯硬體。
軟體/架構層	Microsoft (DeepSpeed-MoE), Databricks (Megablocks), 社群 (FastMoE), PyTorch/TensorFlow社群	系統實現者。提供將EP工程化、易用化的軟體棧。
雲端運算服務商	雲端廠商 (AWS, Azure, GCP, 阿里雲端, 騰訊雲端等)	服務提供者。在其雲端上提供支援EP的AI訓練/推論例項，降低使用者使用門檻。
系統整合/最佳化	各AI大廠內部基礎設施團隊	終極實現者。在超萬卡叢集上，EP的實現需要深度的軟硬體協同定製和最佳化。

資本對映邏輯：投資於具備 “MoE模型研發能力” 或 “支撐EP的高速互聯硬體及軟體棧” 的公司，是捕獲EP技術紅利的兩條路徑。前者體現為領先的AI模型公司，後者體現為“賣鏟人”的AI基礎設施公司（NVIDIA是當前最直接受益者）。

投資邏輯

1. 架構演進確定性：MoE被公認為是平衡模型能力與計算/推論成本的有效路徑，是下一代主流大型模型架構。EP作為其“引擎”，需求確定性高。
2. 硬體壁壘加深：EP對節點內高速互聯（如NVLink）和節點間網路的要求極高，這正是NVIDIA等領先晶片廠商建置硬體生態壁壘的關鍵環節。擁有強大互聯技術的公司將持續受益。
3. 軟體定義價值：EP的實現複雜，軟體棧的最佳化程度直接決定叢集的有效算力。擁有高效、易用EP軟體架構的公司（如微軟、Databricks）能提供顯著的生產力優勢。
4. 系統複雜性溢價：部署和最佳化EP叢集是一項高門檻的系統工程，這為提供一站式大型模型訓練/推論雲端服務的廠商創造了高附加值空間。
5. 風險點：MoE架構本身可能存在訓練不穩定、微調困難等問題；若未來出現更優的替代架構（如全新的稀疏化方法），可能影響EP的演進路徑。此外，對超高速網路的依賴也增加了基礎設施成本和供應商鎖定風險。

常見誤讀糾偏

誤讀一：“EP就是把MoE模型的專家放到不同卡上，很簡單。”

• 糾偏：EP的工程複雜性遠不止於此。核心難點在於：1）All-to-All通訊是不規則且動態的，對網路和通訊庫最佳化要求極高；2）需要與負載均衡演算法深度耦合，防止計算和通訊熱點；3）必須與DP、TP、PP等正交併行策略無縫融合，形成高效的混合並行方案；4）需要處理稀疏、不規則的計算模式，傳統針對密集GEMM最佳化的庫可能效率低下。一個未經最佳化的EP實現可能導致系統效率極低。

誤讀二：“EP中All-to-All的通訊量很大，所以EP的效率一定很低。”

• 糾偏：需要具體分析。EP的All-to-All通訊量與活躍Token數和啟用專家數成正比，而非與總引數量直接相關。在Top-1或Top-2路由下，通訊量是可控的。EP的效率（MFU）取決於 “有效計算量” 與 “通訊及系統開銷” 的比值。雖然通訊是瓶頸，但通過：1）通訊-計算重疊；2）最佳化網路拓撲和路由策略；3）使用容量因子等限制技術；4）專用高效能通訊硬體，可以顯著提升EP的總體效率。在成熟的系統實現下，EP的MFU可以達到較高水平。

學習路徑

1. 基礎奠基：理解基礎的分散式並行概念：資料並行、模型並行（張量並行、流水線並行）。推薦閱讀：PyTorch分散式教程、李沐《動手學深度學習》分散式章節。
2. 演算法入門：精讀混合專家模型（MoE）的經典論文，如**《Outrageously Large Neural Networks》、《Switch Transformer》、《GShard》**。理解門控網路、稀疏啟用、負載均衡的核心思想。
3. 系統聚焦：深入學習專家並行（EP）的系統實現。推薦閱讀：
   • 工程實踐論文：《MegaBlocks: Efficient Sparse Training with Mixture-of-Experts》 (Databricks)，瞭解EP的高效核心實現。
   • 綜合架構論文：《DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale》 (Microsoft)，瞭解EP與其它並行技術的混合及最佳化。
4. 動手實踐：在支援MoE和EP的架構上進行實驗，如使用Hugging Face Transformers執行Mixtral模型，或嘗試用DeepSpeed架構配置一個簡單的MoE訓練任務，觀察EP的配置和通訊模式。
5. 追蹤前沿：關注頂級會議（ICML, NeurIPS, ICLR, OSDI, SOSP）中關於大規模模型訓練系統、MoE架構最佳化的最新論文。

一句話總結

專家並行（EP）是駕馭混合專家模型（MoE）萬億引數時代的分散式系統引擎，它通過將專家網路分散到多個計算裝置並以All-to-All通訊動態路由資料，巧妙地解決了MoE模型“存不下”與“算不動”的根本矛盾，是連線前沿AI演算法與下一代大規模計算基礎設施的核心樞紐。

延伸閱讀與來源

1. 奠基論文：
   • Shazeer, N., et al. (2017). Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer.
   • Fedus, W., Zoph, B., & Shazeer, N. (2021). Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity.
2. 系統實現論文：
   • Gale, T., et al. (2022). MegaBlocks: Efficient Sparse Training with Mixture-of-Experts.
   • Hwang, C., et al. (2023). Tutel: Adaptive Mixture-of-Experts at Scale.
   • Rajbhandari, S., et al. (2022). DeepSpeed-MoE: Advancing Mixture-of-Experts Inference and Training to Power Next-Generation AI Scale.
3. 模型案例研究：
   • DeepSeek-AI. (2024). DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model. （尤其關注其系統部分）
   • Jiang, A. Q., et al. (2024). Mixtral of Experts.
4. 技術部落格與文件：
   • NVIDIA Developer Blog: 關於Megatron-Core中MoE和EP的實現細節。
   • Microsoft DeepSpeed Documentation: DeepSpeed-MoE 指南。
   • PyTorch Documentation: torch.distributed 中關於 all_to_all 通訊的操作。