从 GShard 到 DeepSeek-V3：回顾 MoE 大模型负载均衡策略演进

作者：小天狼星不来客
原文：https://zhuanlan.zhihu.com/p/19117825360

故事要从 GShard 说起——当时，人们意识到拥有数十亿甚至数万亿参数的模型可以通过某种形式的“稀疏化（sparsified）”来在保持高精度的同时加速训练。自那以后，我们见证了各种让人眼花缭乱的创新。本文将尝试把从 GShard 到 DeepSeek-V3 这一系列关键方案串联起来，看看每一次迭代都给我们带来了什么改进，又踩过哪些坑，还有哪些重要问题尚未解决。

简介

为什么要用稀疏专家（Sparse MoE）？

先说点背景吧。MoE 架构之所以瞬间火起来，是因为人们发现，你可以在不等比例增加计算开销（FLOPs）的前提下，让模型拥有极其庞大的参数量。核心思路在于：对每个 token，只激活少量的专家参与计算，而不是让所有参数统统上场。

但这种“只让部分专家工作”的做法，很快就暴露了一大问题：如果只把 token 分给几个专家，那怎么保证负载是均衡的？要是某个专家被一大堆 token 疯狂轰炸，而其他专家却闲得无聊怎么办？这就是负载均衡的本质，也是 MoE 要大规模应用时必须解决的一道难题。

这篇博文要讨论些什么？

我会带着大家依次走过几个标志性的 MoE 系统，从 GShard（最早把大规模 MoE 推向主流的方案）一直到最新的 DeepSeek-V3。在过程中，我们也会顺带聊聊 Switch Transformer、GLaM 这些经典“选手”，重点剖析它们在负载均衡上遇过的坑和后来的改进思路。

如果你想获得一些实践层面的启发——没问题，我会尽量保持足够的学术严谨，让研究人员或资深从业者也能从中受益。也希望我这篇文章能写得有点意思，让你不会看几段就昏昏欲睡——毕竟这是篇博客，又不是考试题嘛！

我注意到的一些关键主题

1.路由方式：top-2 gating、single-expert gating、top-K gating、correlation-aware gating……我们对 gating 的花式名词似乎永远都不嫌多。

2.辅助损失 (Auxiliary Loss)：用来帮助专家均衡使用，但如果过于强势，也会让模型的性能受限。

3.容量约束（Capacity Constraints）：所谓“capacity factor”，其实就是“每个专家最多能接收多少 token，超了就丢”。

4.实现细节：从“随机分配”到分层的 all-to-all 传输，高性能计算（HPC）的那一套在这里特别重要。

5.可扩展性：有时候我们要上千个专家，因此分布式计算的开销非常值得关注。

历史脉络：从 GShard 到 Switch

GShard：先锋之作

GShard（谷歌提出）通常被视为最早实现大规模超稀疏 MoE 的框架之一。它让人们真正意识到，只要把层和 token 智能拆分并均衡地分配给各个专家，训练几百亿甚至上千亿参数的模型是可以做到的。

GShard 的路由通常采用 top-2 的 gating 方式，即：

其中  是 token 的嵌入向量， 是路由器（router）的权重矩阵。只有排名前两名的专家会被激活。不过，为了防止某些专家超负荷，训练时一般会引入以下概念：

1.专家容量 (Expert Capacity)，约为 （如果共有  个 token， 个专家）。一旦某个专家被分配的 token 超过了这个容量，就可能丢弃一些 token（或者在下一层再处理）。

2.辅助负载均衡损失 (Auxiliary Loss)，形式通常如下：

其中  表示实际路由到专家  的 token 比例， 是专家  的平均 gating 概率。这个损失会“鼓励”各专家负载更加均衡。

3.本地分组 (Local Groups)：不是所有 token 都在全局竞争，而是先进行分组后再分配给专家。这样能缩小混乱程度。

痛点：没错，token 被丢弃肯定不是什么好事——如果超容量了，就只好忍痛割爱。而且 top-2 gating 在规模很大时会带来不小的通信和计算开销，再加上依赖辅助损失有时会让路由分布变得“人为”偏均匀，反而牺牲了一定的性能。不过，GShard 为后续所有的 MoE 研究铺好了路：它证明了稀疏专家是有价值的，还为后来的方案指明了“容量因子”这些关键概念的重要性。

Switch Transformer：当“少就是多”

Switch Transformer 的思路很直接：“我们干脆只给每个 token 选一个专家得了。