10.5 序列并行与专家并行
前面章节讨论的张量并行（TP）沿隐藏维度切分权重矩阵，流水线并行（PP）沿层维度切分模型，数据并行（DP）沿批次维度切分数据。然而，随着上下文长度从数千 token 扩展到数十万甚至百万级别，序列维度本身也成为了显存和计算的瓶颈。与此同时，混合专家模型（MoE）通过条件激活机制在不增加单 token 计算量的前提下大幅扩展模型参数量，但其独特的稀疏激活结构需要专门的并行策略。本节将讨论两种沿"非传统维度"进行并行的技术：序列并行（Sequence Parallelism, SP）与专家并行（Expert Parallelism, EP）。
10.5.1 序列并行的动机
回顾张量并行的工作方式：对于 Transformer 中的线性层（如注意力层的投影矩阵和前馈网络），TP 将权重矩阵按列或按行切分到多个 GPU 上，每个 GPU 只需存储和计算权重的一个分片，因此线性层产生的激活值内存也随并行度线性减少。
然而，Transformer 中并非所有操作都是矩阵乘法。每个子层的前后还包含大量逐点操作（point-wise operations）：
- LayerNorm：对每个 token 的隐藏维度进行归一化。
- Dropout：对激活值进行随机置零。
- 残差连接：将子层输入与输出逐元素相加。
在标准的张量并行方案中，这些逐点操作需要在完整的隐藏维度上执行，因此每个 GPU 都必须持有完整的激活张量副本。换言之，无论张量并行度
10.5.2 Megatron 序列并行原理
Megatron-LM 提出的序列并行基于一个关键观察：上述逐点操作对序列中的每个 token 是完全独立的。 对第
具体地，对于形状为
SP 与 TP 的协作关系。 序列并行并非独立工作，而是与张量并行紧密耦合。在一个完整的 Transformer 层中，计算在两种"数据布局"之间交替切换：
┌──────────────────────────────────────────────────────────────────┐
│ 序列并行区域 │
│ 数据布局：按序列维度分片 [s/T, b, h] │
│ 操作：LayerNorm → Dropout → 残差连接 │
│ │
│ ↓ All-Gather（沿序列维度收集，重建完整序列） │
│ │
│ 张量并行区域 │
│ 数据布局：完整序列 [s, b, h]，权重按隐藏维度分片 │
│ 操作：注意力投影 / FFN 线性层 │
│ │
│ ↓ Reduce-Scatter（规约并沿序列维度分散） │
│ │
│ 序列并行区域 │
│ 数据布局：按序列维度分片 [s/T, b, h] │
│ 操作：LayerNorm → Dropout → 残差连接 │
└──────────────────────────────────────────────────────────────────┘两种布局之间的转换通过集合通信原语完成：
- 进入 TP 区域前执行 All-Gather：将各 GPU 上按序列维度分片的激活值收集拼接，使每个 GPU 都获得完整的序列张量
，以便在隐藏维度上进行张量并行的矩阵乘法。 - 离开 TP 区域后执行 Reduce-Scatter：张量并行的线性层在各 GPU 上产生部分和（partial sum），Reduce-Scatter 在对这些部分和进行规约（求和）的同时，将结果沿序列维度重新分散到各 GPU 上，恢复为
的分片布局。
通信开销分析。 序列并行并没有引入额外的通信量。在不使用序列并行的标准 TP 方案中，TP 区域的出口处需要执行 All-Reduce 来同步各 GPU 的部分和。而 All-Reduce 在数学上等价于 Reduce-Scatter + All-Gather。序列并行所做的，实质上是将原本捆绑在一起的 All-Reduce 拆分为两个独立的操作——Reduce-Scatter 放在 TP 区域的出口，All-Gather 放在 TP 区域的入口——并在这两个操作之间插入序列分片的逐点计算。通信的数据总量保持不变，但换来了逐点操作的激活内存被成功分片。
10.5.3 序列并行 vs 上下文并行
需要区分两个容易混淆的概念。Megatron 序列并行（SP）针对的是 LayerNorm、Dropout 等逐点操作的激活内存，它通过将这些操作沿序列维度切分来节省显存，但在进入注意力计算之前仍需通过 All-Gather 重建完整序列。
另一种称为上下文并行（Context Parallelism, CP） 的技术（典型实现如 Ring Attention）则更进一步：它在注意力计算内部也将序列切分，通过环形传递 Key/Value 分块的方式，避免在任何单个 GPU 上实例化完整的
在实践中，SP 和 CP 往往配合使用：SP 负责分片注意力和 FFN 之外的逐点操作，CP 负责分片注意力计算本身，二者共同实现了 Transformer 层中几乎所有激活内存随并行度线性缩减的目标。
10.5.4 MoE 与专家并行
混合专家模型（Mixture of Experts, MoE） 是一种稀疏激活架构，其核心思想是：将 Transformer 中的前馈网络（FFN）替换为多个并行的"专家网络（Expert FFN）"，并引入一个门控路由器（Gating Router）来决定每个 token 应该被发送到哪些专家进行处理。
以 Mixtral 8×7B 为例，模型包含 8 个专家，每个 token 由路由器选择 Top-2 个专家处理。虽然模型的总参数量达到 46.7B（8 个专家 × 每个专家约 5.6B 参数 + 共享参数），但由于每个 token 只激活 2 个专家，单 token 的实际计算量仅相当于一个约 12.9B 参数的稠密模型。这种"参数多、计算少"的特性使得 MoE 能够在固定计算预算下实现更好的模型质量。
然而，MoE 的大量专家参数给显存带来了巨大压力。一个包含 64 个专家的模型，即使每个专家只有中等规模，总参数量也轻松超过千亿。专家并行（Expert Parallelism, EP） 正是为解决这一问题而设计的并行策略。
10.5.5 专家并行的工作原理
专家并行的核心思想非常直接：将不同的专家网络分布到不同的 GPU 上。如果模型有
专家并行的前向传播流程可以分为三个阶段：
阶段一：路由分发（Dispatch）。 输入 token 经过共享的注意力层后，到达 MoE 层。门控路由器为每个 token 计算一组路由概率，并选出 Top-K 个专家。此时，不同 token 被分配到的专家可能分布在不同的 GPU 上。因此，需要通过一次 All-to-All 通信将 token 发送到其目标专家所在的 GPU：每个 GPU 将本地 token 中需要由远端专家处理的部分发出，同时接收其他 GPU 发来的、需要由本地专家处理的 token。
阶段二：专家计算（Compute）。 各 GPU 在本地独立执行专家 FFN 的前向计算。此阶段无需任何跨 GPU 通信。
阶段三：结果回收（Combine）。 专家计算完成后，需要将结果返回给原始 token 所在的 GPU。这再次通过一次 All-to-All 通信完成，方向与阶段一相反：每个 GPU 将处理完的 token 结果发回其来源 GPU，来源 GPU 收到后按路由权重将多个专家的输出加权合并。
GPU 0 (Expert 0) GPU 1 (Expert 1) GPU 2 (Expert 2) GPU 3 (Expert 3)
│ │ │ │
├── token A,C ├── token B ├── token A,D ├── token C,D
│ (路由到E0) │ (路由到E1) │ (路由到E2) │ (路由到E3)
│ │ │ │
◄════════════════ All-to-All Dispatch ════════════════════►
│ │ │ │
▼ ▼ ▼ ▼
Expert 0 计算 Expert 1 计算 Expert 2 计算 Expert 3 计算
│ │ │ │
◄════════════════ All-to-All Combine ════════════════════►
│ │ │ │
▼ ▼ ▼ ▼
合并输出 合并输出 合并输出 合并输出All-to-All 通信模式。 与 TP 中的 All-Reduce 或 SP 中的 All-Gather/Reduce-Scatter 不同，EP 的核心通信原语是 All-to-All。All-to-All 是一种"全交换"操作：每个 GPU 都向其他所有 GPU 发送不同的数据，同时从所有 GPU 接收不同的数据。这与 All-Gather（每个 GPU 发送相同数据给所有人）或 Reduce-Scatter（数据在传输过程中被规约）有本质区别。All-to-All 的通信模式是不规则的——每个 GPU 发往不同目标的数据量取决于路由结果，因此负载可能不均衡，这也是 EP 实现中最具挑战性的环节之一。
10.5.6 负载均衡问题
专家并行的效率高度依赖于路由的均衡性。如果大量 token 被路由到少数几个"热门专家"，这些专家所在的 GPU 将成为瓶颈，而其余 GPU 则处于空闲状态。这种负载不均衡（Load Imbalance） 会严重降低集群的整体利用率。
业界采用多种策略缓解这一问题：
- 辅助损失（Auxiliary Loss）：在训练目标中加入一个正则化项，惩罚路由概率分布的不均匀性，鼓励 token 被更均匀地分配到各专家。
- 容量因子（Capacity Factor）：为每个专家设定一个容量上限
，其中 是 token 总数， 是专家数， 是 Top-K， 是容量因子。超出容量的 token 将被丢弃或通过残差连接直接传递。 - Expert Choice 路由：反转路由方向——不是 token 选专家，而是专家选 token。每个专家从全局 token 中选取得分最高的固定数量的 token 来处理，从根本上保证了负载均衡。
10.5.7 DeepEP：面向 MoE 的高性能通信库
随着 MoE 模型规模的扩大（如 DeepSeek-V3 使用了 256 个专家），All-to-All 通信的延迟成为训练效率的关键瓶颈。DeepEP 是 DeepSeek 团队开源的专门为 MoE 模型设计的高性能 EP 通信库，针对 All-to-All 通信进行了深度优化。
DeepEP 的核心设计包括以下几个方面：
节点内与节点间分层通信。 GPU 集群的网络拓扑呈现明显的层次结构：节点内 GPU 通过 NVLink 互连（带宽可达 900 GB/s），节点间则依赖 InfiniBand（带宽约 50-400 Gb/s）。DeepEP 将 All-to-All 通信分解为两步：首先在节点内通过 NVLink 进行高速数据重排，然后跨节点通过 RDMA 网络传输。这种分层策略充分利用了不同层级网络的带宽特性。
低精度传输与压缩。 在训练过程中，激活值的跨节点传输可以使用 FP8 等低精度格式，将通信数据量减半，而对模型质量的影响可以忽略不计。推理阶段则进一步利用激活值的稀疏性进行压缩。
计算与通信重叠。 DeepEP 支持将 All-to-All 通信与专家计算进行流水线化重叠：当一部分 token 已经到达目标 GPU 并开始专家计算时，剩余 token 的传输可以同步进行，从而隐藏通信延迟。
针对推理场景的优化。 推理阶段的 MoE 模型面临与训练不同的挑战：批大小通常较小，单次 All-to-All 传输的数据量有限，此时通信的瓶颈从带宽转向延迟。DeepEP 针对这一场景设计了低延迟内核，通过减少通信轮次、使用 RDMA 直写等技术降低端到端延迟。
10.5.8 EP 与其他并行策略的组合
在实际的大规模 MoE 训练中，EP 不会单独使用，而是与 TP、DP、PP 等策略组合形成多维并行。一种常见的配置如下：
- 注意力层使用 TP（节点内）+ DP（节点间），与稠密模型一致。
- MoE 层使用 EP（将专家分布到多个 GPU）+ DP（在 EP 组之间复制专家以处理不同数据分片）。
- 整体模型叠加 PP 进行层间切分。
以 DeepSeek-V3 为例，其 256 个路由专家被分布在多个 EP 组中，每个 EP 组包含足够多的 GPU 来容纳全部专家。EP 组之间则通过 DP 进行数据并行扩展。这种组合使得模型能够在数千张 GPU 上高效训练。
本节小结
序列并行和专家并行分别从序列维度和专家维度扩展了分布式训练的并行空间：
- 序列并行（SP） 是张量并行的自然补充。它利用 LayerNorm、Dropout 等逐点操作在 token 间的独立性，将这些操作的激活值沿序列维度分片，通过 All-Gather 和 Reduce-Scatter 在 SP 区域与 TP 区域之间进行布局转换，在不增加通信开销的前提下实现了全部激活内存的线性缩减。
- 专家并行（EP） 是 MoE 架构的专属并行策略。它将不同专家分布到不同 GPU 上，通过 All-to-All 通信完成 token 的路由分发与结果回收。负载均衡是 EP 高效运行的核心挑战，而 DeepEP 等高性能通信库通过分层通信、低精度传输和计算通信重叠等技术，显著降低了 All-to-All 的延迟瓶颈。
这两种技术与前面章节讨论的 TP、PP、DP、ZeRO 共同构成了现代大模型训练的多维并行体系。实际训练中，工程师需要根据模型架构（稠密 vs 稀疏）、序列长度、硬件拓扑和通信带宽，在这些并行策略之间找到最优的组合配置。