01

60 秒回答模板

分布式 MoE 里，Gate 或 Router 通常先在每个 token 的隐藏状态上计算专家分数，选出 top-k 专家和对应权重。因为专家会按 expert parallelism 分布在不同 GPU 或不同节点上，所以路由结果不能只停留在本地：系统要先把 token 按目标专家和目标设备重新分桶、打包，然后通过 all-to-all 把 token activation 发到拥有对应专家的设备；每个设备对自己负责的专家做 batched GEMM 或 grouped GEMM；专家输出再通过一次 all-to-all 或反向排列回到 token 原来的顺序，并按 gate 权重合并后进入后续层。瓶颈主要有四类：第一是通信量随 token 数、hidden size、top-k 和跨节点比例增加；第二是专家负载不均导致某些设备成为 straggler；第三是小 batch、动态路由和 scatter/gather 让通信碎片化，GPU 利用率下降；第四是训练和推理里 dispatch、combine、梯度通信、pipeline 或 tensor parallel 互相叠加。优化思路是让路由、专家放置和通信拓扑一起设计，例如限制跨节点路由比例、做负载均衡损失和 capacity 控制、把 token packing 和 dispatch kernel 融合、用分层 all-to-all、把热门专家分散或复制，并尽量让通信和专家计算重叠。

考点 路由元数据
难度 真实面经题
回答目标 讲清 token 路由通信和瓶颈定位
02

深入解析

01

Gate 的输出不只是专家编号

Gate 网络接收每个 token 的 hidden state，输出每个专家的打分、被选中的 top-k expert id，以及后续合并需要用到的 gate weight。分布式环境下还要把 expert id 映射到具体设备、expert-parallel group 和本地 expert slot。回答时要先把这个元数据说清楚，否则后面的 dispatch 和 combine 没有落点。

02

专家并行让路由变成跨设备数据重排

在 dense FFN 中，token 通常留在当前设备继续做矩阵计算；在 MoE 中，专家参数被切到不同 GPU 上，一个 token 可能要去远端专家计算。因此 MoE 层的核心开销变成先按目标专家对 token activation 做 permutation、计数和打包，再把不同专家的 token 发到对应设备。这一步是分布式 MoE 区别于普通 Transformer 层的关键。

03

典型链路是 dispatch、expert compute、combine

一次 MoE 前向通常可以拆成三段：dispatch 阶段把本地 token 按专家分桶并 all-to-all 到专家所在设备；expert compute 阶段每个设备对本地专家收到的 token 做批量 FFN；combine 阶段把专家输出按原 token 位置发回，再根据 top-k 的 gate weight 加权合并。训练时反向传播还会沿着相同路由产生反向通信和专家参数梯度。

04

通信瓶颈来自带宽、碎片和同步

all-to-all 的数据量大致和 token 数、hidden size、激活专家数 top-k 相关；如果跨节点发送比例高，就会受到网络带宽和延迟限制。动态路由还会造成很多不均匀的小消息，token packing、scatter/gather、排序和反排序本身也消耗 GPU kernel 时间。MoE 层通常要等最慢的专家或最慢的通信分片完成，所以尾部延迟很容易被放大。

05

负载不均会把通信问题变成计算问题

如果 Gate 长期把大量 token 发给少数专家，这些专家所在 GPU 会同时承担更多通信输入、更大的 expert GEMM 和更晚的输出回传，其他 GPU 则空等。capacity factor、token dropping 或 padding 也会影响效率：容量太紧会损失 token 或质量，容量太松会增加 padding 和无效计算。负载均衡不是训练细节，而是通信和吞吐的核心约束。

06

优化要联合路由、放置和通信拓扑

常见优化包括用 auxiliary load-balance loss 或 router regularization 降低专家热点；做 topology-aware expert placement，让高频专家分散在不同设备，尽量减少跨节点路由；使用 grouped all-to-all、分层 all-to-all、融合 permutation/dispatch kernel 和 contiguous buffer；在 serving 侧把多个请求的 token 合批，让每个专家获得更大的 GEMM batch；同时用 profiling 区分 router 计算、token packing、网络通信和 expert compute，避免只优化 Gate 公式而忽略真正瓶颈。

03

易错点

  • 只说 Gate 选择 top-k 专家，没有说明 token activation 需要被发送到专家所在设备。
  • 把 MoE 通信说成普通数据并行的梯度 all-reduce，混淆了 dispatch 的多对多交换语义。
  • 只关注网络带宽，忽略 token packing、scatter/gather、排序回填和小消息碎片的开销。
  • 认为负载均衡只是模型训练指标，没有意识到专家热点会造成 GPU 空等和尾部延迟。
  • 把 capacity factor 讲成越大越好，没有说明 padding、显存和无效计算的代价。
  • 声称某家公司一定使用某种内部通信实现，但来源只支持通用 MoE 通信流程问题。
04

面试官追问

MoE dispatch 为什么常用 all-to-all，而不是 all-reduce？

all-reduce 是把多个设备上的同形张量做归约，适合数据并行梯度同步。MoE dispatch 是把不同 token 发送到不同专家所在设备，数据目的地不同，属于按专家分桶后的多对多交换，因此更接近 all-to-all。

top-k 变大对通信有什么影响？

top-k 越大，每个 token 需要发给更多专家，dispatch 和 combine 的数据量、专家计算量和结果合并成本都会增加。它可能提升模型表达和稳定性，但会直接削弱 sparse activation 的推理效率。

如何判断 MoE 层瓶颈来自通信还是专家计算？

要拆 profiler 指标，看 router/top-k、token packing、all-to-all、expert GEMM、combine 和等待时间分别占比；同时观察每个专家 token count、每张 GPU 利用率、跨节点流量和 p99 延迟。只看总耗时无法定位。

负载均衡损失能完全解决通信热点吗？

不能。它能让训练中专家使用更均匀，但线上输入分布、专家放置、batch 大小和网络拓扑仍会造成热点。工程上还要结合 capacity、expert placement、合批和动态监控。

为什么跨节点路由比同机多卡路由更敏感？

跨节点通常带宽更低、延迟更高，也更容易受到网络拥塞影响。同一节点内 GPU 之间的高速互联更适合频繁 token exchange，所以专家放置和分层通信会尽量减少不必要的跨节点交换。