专家并行（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模型的内在特性：
- 参数稀疏性：MoE模型的绝大部分计算（FFN层）由多个并行的专家网络完成，但每个Token仅激活其中少数（如1-2个）。这使得模型总参数大，但单个Token的计算量（FLOPs）远低于同参数规模的密集模型。
- 内存墙挑战：尽管计算稀疏，但所有专家网络的完整参数必须驻留在内存中，以便路由器动态选择。一个拥有64个专家、每个专家参数量等同于一个密集模型FFN的MoE模型，其总参数是密集版的数十倍。
- 计算不规则性：路由器动态选择专家，导致每个设备上的计算负载可能不均衡（负载不均衡问题），给系统调度带来挑战。
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` 通信的操作。