正如前面介绍的,在多个设备上分配专家(专家并行)是扩展 MoE 模型的有效策略。然而,这种分配引入了一个重要的通信需求:将令牌从其当前处理设备路由到包含由门控网络选择的专家所在的设备。这种必要的数据交换表现为 All-to-All 通信模式,这是分布式 MoE 训练中的一项基本操作,值得仔细考虑。MoE 中 All-to-All 的特点在标准的数据并行设置中,通信通常涉及 All-Reduce 等操作,其中梯度或参数会在设备间聚合。专家并行需要一种不同的模式。考虑使用数据并行在 $N$ 个设备上分布的一批令牌。模型中的 MoE 层也会将其专家分配到这 $N$ 个设备(或其子集)上。当设备 $i$ 上的令牌 $x$ 经过门控网络 $g(x)$ 时,它可能被分配给专家 $E_j$,而专家 $E_j$ 实际位于设备 $k$ 上,其中 $k$ 可能与 $i$ 不同。由于专家 $E_j$ 需要令牌 $x$ 的表示来进行计算,因此 $x$ 必须从设备 $i$ 发送到设备 $k$。对于所有设备上的微批次中的所有令牌来说,这种情况是同时发生的。每个设备 $i$ 可能需要将其令牌的不同子集发送给所有其他设备 $k$(如果专家位于本地,也可能包括自身)。相应地,每个设备 $k$ 预期会从所有其他设备 $i$ 接收令牌。这种集体交换,即每个参与者向其他所有参与者发送独特数据并从其他所有参与者接收独特数据,是 All-to-All 通信模式的本质。从数学角度看,如果我们在 $N$ 个设备上分布了 $T$ 个令牌(因此每个设备初始有 $T/N$ 个令牌),并且 $E$ 个专家也分布在这 $N$ 个设备上(每个设备 $E/N$ 个专家),门控网络会计算分配结果。设 $S_{ik}$ 为当前在设备 $i$ 上需要路由到设备 $k$ 上任何专家的令牌集合。All-to-All 操作有效地执行所有 $S_{ik}$ 集合的传输,对于所有满足 $1 \le i, k \le N$ 的 $(i, k)$ 对。数据流的可视化我们可以将此过程进行可视化。设想有四个设备(GPU),每个设备都包含一部分输入令牌和特定 MoE 层的一部分专家。digraph G { rankdir=LR; splines=true; node [shape=record, style=filled, color="#495057", fillcolor="#dee2e6"]; edge [color="#495057"]; subgraph cluster_0 { label="设备 1"; bgcolor="#e9ecef"; style=filled; D1_Tokens [label="{<t1> T1 | <t2> T2 | <t3> T3}", fillcolor="#a5d8ff"]; D1_Experts [label="{<e1> E1 | <e2> E2}", fillcolor="#ffec99"]; } subgraph cluster_1 { label="设备 2"; bgcolor="#e9ecef"; style=filled; D2_Tokens [label="{<t4> T4 | <t5> T5 | <t6> T6}", fillcolor="#a5d8ff"]; D2_Experts [label="{<e3> E3 | <e4> E4}", fillcolor="#ffec99"]; } subgraph cluster_2 { label="设备 3"; bgcolor="#e9ecef"; style=filled; D3_Tokens [label="{<t7> T7 | <t8> T8 | <t9> T9}", fillcolor="#a5d8ff"]; D3_Experts [label="{<e5> E5 | <e6> E6}", fillcolor="#ffec99"]; } subgraph cluster_3 { label="设备 4"; bgcolor="#e9ecef"; style=filled; D4_Tokens [label="{<t10> T10 | <t11> T11 | <t12> T12}", fillcolor="#a5d8ff"]; D4_Experts [label="{<e7> E7 | <e8> E8}", fillcolor="#ffec99"]; } D1_Tokens:t1 -> D2_Experts:e3 [label=" g(T1)->E3", fontsize=10, color="#fd7e14"]; D1_Tokens:t2 -> D1_Experts:e2 [label=" g(T2)->E2", fontsize=10, color="#1c7ed6"]; D1_Tokens:t3 -> D4_Experts:e7 [label=" g(T3)->E7", fontsize=10, color="#fd7e14"]; D2_Tokens:t4 -> D1_Experts:e1 [label=" g(T4)->E1", fontsize=10, color="#ae3ec9"]; D2_Tokens:t5 -> D3_Experts:e6 [label=" g(T5)->E6", fontsize=10, color="#ae3ec9"]; D2_Tokens:t6 -> D2_Experts:e4 [label=" g(T6)->E4", fontsize=10, color="#1c7ed6"]; D3_Tokens:t7 -> D4_Experts:e8 [label=" g(T7)->E8", fontsize=10, color="#74b816"]; D3_Tokens:t8 -> D3_Experts:e5 [label=" g(T8)->E5", fontsize=10, color="#1c7ed6"]; D3_Tokens:t9 -> D1_Experts:e1 [label=" g(T9)->E1", fontsize=10, color="#74b816"]; D4_Tokens:t10 -> D2_Experts:e3 [label=" g(T10)->E3", fontsize=10, color="#f76707"]; D4_Tokens:t11 -> D3_Experts:e5 [label=" g(T11)->E5", fontsize=10, color="#f76707"]; D4_Tokens:t12 -> D4_Experts:e7 [label=" g(T12)->E7", fontsize=10, color="#1c7ed6"]; dummy1 [label="", width=0.01, height=0.01, style=invis]; dummy2 [label="", width=0.01, height=0.01, style=invis]; dummy3 [label="", width=0.01, height=0.01, style=invis]; dummy4 [label="", width=0.01, height=0.01, style=invis]; dummy1 -> dummy2 [style=invis]; dummy2 -> dummy3 [style=invis]; dummy3 -> dummy4 [style=invis]; } 基于门控决策(彩色箭头),令牌(蓝色方块)在四个设备之间路由到专家(黄色方块)的流程。每个设备向可能多个其他设备发送令牌,并接收发往其本地专家的令牌。性能考量与瓶颈All-to-All 通信以其高带宽需求而闻名,可能成为分布式训练中的主要瓶颈,特别是对于 MoE 模型而言。原因如下:高通信量: 与 All-Reduce 不同,All-Reduce 的总数据传输量可能根据算法以对数或线性方式随设备数量扩展,而 All-to-All 通常涉及将本地批处理数据的很大一部分发送到其他节点。总通信量大致与设备数量 $N$ 成线性关系,但每链路的带宽需求可能非常高。网络拓扑敏感性: All-to-All 的性能在很大程度上取决于底层网络拓扑和节点之间的带宽。配备高速专用互连(如 NVIDIA 的 NVLink 或 Infiniband)的系统比依赖标准以太网的系统表现好得多,尤其是在设备数量增加时。同步: All-to-All 通常是一种阻塞性集体操作。所有参与设备必须在数据交换有效进行之前到达通信点,如果计算负载不均衡,这可能会导致一些设备空闲。负载均衡影响: 任意一对设备 $(i, k)$ 之间发送的数据量直接取决于门控网络的决策。如果路由器持续将大多数令牌发送到特定设备子集上的专家,就会产生通信热点并加剧负载不均衡问题,从而影响计算和通信效率。这直接与第 3 章中讨论的负载均衡损失相关联。通过集体通信库实现这种通信模式通常使用 MPI(消息传递接口)等标准库或 NCCL(NVIDIA 集体通信库)等 GPU 加速库提供的原语实现。MPI: 使用 MPI_Alltoall 等原语(其中每个进程向/从所有其他进程发送/接收相同数量的数据),或者对于 MoE 更常见的是,使用 MPI_Alltoallv(允许每对进程具有不同的发送/接收计数和位移)。NCCL: NCCL 为 NVIDIA GPU 提供了高度优化的集体操作实现,包括 ncclAllToAll。这些实现旨在最大化 GPU 间带宽(如 NVLink)和网络接口的利用率。使用这些库可以抽象出消息打包、路由和同步的低层细节。然而,理解底层模式对于调试性能问题以及选择合适的硬件和网络配置非常必要。举例来说,了解 MoE 严重依赖 All-to-All 可以为构建训练集群时的节点互连选择提供信息。逆向路径分析需要注意的是,在专家计算其接收到的令牌的输出后,通常还需要另一次 All-to-All 通信。设备 $k$ 上为源自设备 $i$ 的令牌计算的结果必须返回到设备 $i$ 进行组合(通常按门控分数加权),并继续前向传播。这第二次 All-to-All 在通信模式和潜在瓶颈方面与第一次相似。理解 All-to-All 模式的特性和性能影响对于成功扩展 MoE 模型非常重要。后续章节将讨论优化此通信并将其有效整合到更广泛的分布式训练策略中的技术。