Expert Parallel

EP 把不同专家放到不同设备。专家内部 TP 则让多张卡共同计算同一个专家的矩阵。两者可以组合，但会改变每次 GEMM 的形状和通信路径。

当专家的 token 很少时，再切小矩阵可能降低计算效率。EP 可以把多个来源的 token 聚到同一个专家，也引入 dispatch、combine 和动态负载。Attention 与专家层因此常需要不同的并行布局。

Dispatch 把 token 送到持有所选专家的设备。专家算完后，输出仍在专家所在设备，需要回到 token 原来的位置。Combine 再按路由权重合并各专家的贡献。

同一个 token 选了多个专家时，可能对应多份专家输出。通信实现可以融合重排、去重或加权，但逻辑上仍要完成分发和结果归并。

在每个 token-expert 分配都单独发送、没有 padding 和压缩的模型里，专家输入载荷与 $k$ 成正比。跨节点字节数还取决于这些专家位于哪些设备和节点。

多个专家位于同一目的设备时，分发可以复用同一份 token。节点内转发、节点受限路由、数据精度和通信协议也会改变网卡上的实际流量。因此要分别统计 token-expert 分配数、目的设备数和跨节点传输。

设整个 EP 组一轮共有 $T$ 个 token，每个 token 选择 $k$ 个专家，隐藏维为 $H$。先假设每份分配都独立携带完整向量，输入和输出各元素均占 $b$ 字节，且都需要远程传输。一次前向 dispatch 加 combine 的载荷为 $2TkHb$。

例如 $T=4096,k=2,H=4096$、BF16，整个组的逻辑载荷为 128 MiB。这个数把每份发送只算一次，没有再加接收。

实际远程流量应扣除本地专家，按目的地复用、量化和 padding 调整，并单独计入路由元数据。训练反向还会增加对应的梯度交换。

计算负载要看每个 rank 的总工作量及最慢专家。网络负载还要看 token 从哪里来、跨过哪些链路、集中发往哪些节点。专家计数接近，并不保证链路流量接近。

训练中的负载均衡策略会影响学习到的路由。推理还可以通过专家副本和放置策略调整服务负载，需要同时观察尾延迟与路由分布。

Dropless 保留所有被路由的 token，但各专家收到的 token 数仍然会变化。计算形状、缓冲区需求和各 rank 完成时间也会随之变化。

MegaBlocks 用块稀疏计算处理不均匀的专家输入，减少为固定容量填充或丢弃 token 的需要。它解决了这部分计算组织问题，仍需要配合路由和通信上的负载管理。

训练通常有更多 token，也要传递反向梯度。吞吐、激活显存和通信重叠会共同影响每步时间。Decode 的单步 token 数较少，专家 GEMM 更碎，通信启动和最慢 rank 的等待更容易影响每个输出 token 的延迟。

同一模型在 prefill、decode 和训练中可以使用不同的专家布局。比较时应固定工作负载，并分别看 token 分布、通信时间和端到端指标。

需要把路由频率、源节点分布、专家副本和网络拓扑一起考虑。副本更新与重新放置的开销应怎样计入收益？