MoE 路由不是省钱开关：为什么专家模型最怕负载不均

MoE 模型看起来像一个很直接的优化：一次请求只激活少数几个专家，于是参数规模变大，计算量却不按同样比例上涨。但真正上线时，MoE 的难点通常不在“有多少专家”，而在“谁来决定每个 token 去哪里”。

这个决定由 router 完成。它会给每个 token 计算一个分数，再把 token 分配给一个或多个专家。理想情况下，专家之间的负载接近均匀，GPU 之间的数据移动可控，延迟曲线也比较平滑。现实中，如果某几个专家被反复选中，系统会立刻出现排队、跨卡通信增加、尾延迟抬高等问题。

所以 MoE 路由首先是一个系统工程问题。模型训练时常会加入 load balancing loss，让 router 不要把所有 token 都推向少数专家。推理服务侧还要设置 capacity factor，限制单个专家最多接收多少 token。容量太紧，会丢 token 或退化到备用路径；容量太松，又会浪费显存和调度空间。

第二个问题是 batch 内部的形状变化。普通 dense 模型里，每层计算比较规则；MoE 层则要把 token 按专家重新分组，执行专家计算，再把结果还原到原来的顺序。这个过程带来额外的 all-to-all 通信。模型越大、专家越分散，通信开销越容易吃掉“只激活少数专家”带来的收益。

第三个问题是热点输入。不同业务流量会让 router 呈现不同偏好。代码请求、数学请求、闲聊请求，可能天然偏向不同专家。如果线上流量结构突然变化，原本平衡的专家分布也会变形。因此 MoE 服务不能只看平均 tokens/s，还要看每个专家的 token 分布、溢出率、尾延迟和跨卡通信时间。

对应用团队来说，MoE 的正确使用方式不是把它当作“更便宜的大模型”。更稳妥的做法是把它当作一个需要观测和容量规划的集群系统：先用真实请求重放测路由分布，再决定 batch 策略、专家并行方式和降级路径。

如果没有这些指标，MoE 很容易出现一种误判：离线 benchmark 很漂亮，线上一到高峰就抖。不是模型突然变差，而是 router 把某些专家变成了瓶颈。

MoE 的价值是真实的。它让大参数量模型在可接受成本下运行。但它不是免费的魔法。router、负载均衡、通信拓扑和容量控制，才是 MoE 能不能稳定落地的关键。