混合专家模型（Mixture of Experts, MoE）训练到中后期，路由器（router）开始只愿意把任务派给少数几个专家，其余专家几乎收不到数据、参数基本不再更新——名义上有几十个专家，真正在工作的可能只有三五个。这个现象叫专家坍塌（Routing Collapse）。
一个呼叫中心的比方
想象一家有 64 个客服的呼叫中心，派单规则是“谁上一单处理得快，下一单就优先派给谁”。起初只是某人手快了半秒，于是他拿到更多单子；单子多，练得多，他更快；系统更愿意派给他。几个月后，64 个人里只有 3 个在接电话，另外 61 个坐在工位上无事可做，工资照发。
MoE 的结构就是这样一家呼叫中心。每个 MoE 层都有一个门控网络（gating network），它给每个 token 对每个专家打分，然后取分数最高的前 k 个（top-k）专家来计算。早期初始化的差异，加上一点数据噪声，总有几个专家略微占优；它们被选中的概率高一点，拿到的梯度就多一点，学得更快，下一轮就更占优。这是一个自我强化的正反馈，也就是富者愈富。而 top-k 是硬选择，没被选中的专家在这一轮梯度几乎为零，即便想追赶也拿不到样本。
代价是什么
- 算力白花：MoE 的卖点是“总参数量大、单次激活少”，靠专家分工把容量堆上去。坍塌之后，参数照样占显存、专家间的通信开销照付，有效容量却缩水了。
- 分工没发生：专家本该各自擅长不同模式（代码、多语言、罕见标点……），坍塌后少数几个专家要覆盖全部输入，等于一个稠密模型外加一堆摆设。
- 负载倾斜：分布式训练时，专家分散在不同设备上，路由一偏，有的卡忙不过来，有的卡闲置；超出容量（capacity）的 token 还会被直接丢弃。
容易混淆的几个说法
| 说法 | 出问题的层面 | 典型表现 |
|---|---|---|
| 路由坍塌 | 门控分配 | 少数专家处理绝大多数 token，其余基本不工作 |
| 负载不均衡（load imbalance） | 同上，程度较轻 | 分配明显偏斜，但每个专家仍有份额 |
| 表示坍塌（representation collapse） | 特征空间 | 不同输入被压成几乎相同的向量，模型分不清 |
| 神经元死亡（dying ReLU） | 单个单元 | 某单元输出恒为 0，梯度不再回流 |
前两者的关系常被描述为：负载不均衡是预警信号，路由坍塌是它的极端形态。表示坍塌是另一个层面的问题，两者可能同时出现，但机制不同。还有一个名字很像的“模型坍塌（model collapse）”，讲的是用 AI 生成内容反复训练 AI 导致退化，跟路由无关。
对策与启示
常见干预手段：在损失里加负载均衡辅助项（auxiliary load-balancing loss），给每个专家设容量上限并处理溢出 token，在路由打分里加噪声鼓励探索，或者用可调偏置项纠偏而不是直接压梯度。哪种更合适取决于任务，具体实现以官方文档和论文为准。
对从业者：评估一个 MoE 模型，别只看“总专家数”，要看专家利用率（expert utilization）和各层的负载分布——训练时把这些直方图打出来，坍塌往往在早期就有苗头。
对普通职场人，这面镜子也算好用：只要派单规则是“谁快给谁”，又不给别人练手的机会，团队最后就只剩几个熟练专家和一群闲置的人。并不是那些专家不行，而是分配机制没给他们被训练的机会。