混合专家模型每次只激活少量专家，全部专家权重仍要有地方存。单张 GPU 放不下时，专家并行会把不同专家安排到不同设备。路由器为 Token 选中专家后，系统把它送到对应 GPU，算完再送回原来的序列位置。
我查看了 Switch Transformer 论文和 Megatron Core 的并行、MoE、Token dispatcher 文档。专家并行省的是每张卡保存的专家权重，新增成本主要来自两件事，跨设备搬 Token，以及不同专家收到的工作量不一样。
一次路由会带来两段交换
假设一层有八个专家，分布在四张卡上。当前 GPU 上的 Token 可能被路由到另外三张卡。常见的 all-to-all dispatcher 会先按照目标专家重排 Token，再让各设备互相发送。专家算完后，系统反向交换结果，并恢复原顺序。一次 MoE 层因此既有专家矩阵运算，也有分发和合并。
Megatron Core 还提供 all-gather 与 flex 等 dispatcher。all-gather 会让参与设备取得更完整的 Token 集合，逻辑直接，传输量也可能更大。all-to-all 只把需要的 Token 发给目标设备，对跨卡交换和排列实现提出更高要求。框架把选择留给模型规模、并行组合与硬件拓扑。
专家并行还能和张量并行一起用。Megatron Core 明确要求这组组合开启序列并行，因为同一批激活还要在两个并行维度间保持正确布局。少开一个选项，问题可能表现为内存变大、通信重复，或者配置直接被框架拒绝。
当前 Megatron Core 文档称，未经优化的专家并行 all-to-all 可能占训练时间的 30% 至 40%。它还提供通信与计算重叠、融合排列、Grouped GEMM 等办法。这个比例来自其支持场景，换成别的模型和网络仍应重新剖析，尤其要分清设备在算专家还是等数据。
热门专家会让其他设备空等
路由器不会保证每个批次平均分配。有些专家收到很多 Token，所在 GPU 继续计算，其他卡已经空下来。Switch Transformer 论文把通信成本、实现复杂度与训练不稳定列为稀疏模型扩展的主要困难，并用每个 Token 只选一个专家等设计减少负担。
训练框架通常加入负载平衡损失，也可以设置专家容量。容量不足时，超出的 Token 可能被丢弃；为了让张量形状规整，也可能把每个专家填充到固定长度。前者会影响模型学习，后者会算一批没有内容的位置。参数表里一个 capacity factor，背后对应的是质量、显存和吞吐三笔账。
部署专家模型时，我会记录每层各专家接收的 Token 数、设备间传输时间和最慢 GPU 的结束时刻。然后分别用短请求、长请求与真实并发压测。总参数能分开放下，只证明机器够装。专家是否均衡、互连是否够快，才决定这些卡能不能一起把请求及时算完。