简介
MoE（混合专家模型）最致命的原生缺陷：路由器马太正反馈引发负载崩塌。训练过程中路由器会持续把 Token 路由到少数表现更好的专家，其余专家长期接收样本不足陷入休眠；显存、参数资源大量浪费，MoE 稀疏加速增益直接消失，性能甚至劣于同规模稠密大模型。 行业主流解法是引入负载均衡辅助损失，在主任务损失之外新增惩罚项，约束路由器不能过度偏向部分专家。 本文拆解负载崩塌发生机理、危害、各类均衡损失公式、工程实现伪代码，最后分析 Kimi‑MoE 落地现状，同时明确整套方案的适用边界。
比喻
把 MoE 想象成一家拥有 8 个技术小组（专家）的外包公司，调度员就是路由器。 调度员考核原本只看交付质量，哪个小组活干得好，就源源不断把新项目派过去。 小组 A 拿到越多项目，实战历练越多，技术越强；小组 B 长期没活，手生能力持续退化。调度员进一步把活全部塞给 A，其余小组摸鱼躺平。
这就是负载崩塌：你花钱养了 8 组人，实际只有 1 组在干活。
公司新增 KPI 约束：调度员考核 = 交付质量 + 人力负载均衡惩罚。哪怕小组 A 能力最强，也必须分配一部分任务给其余小组；如果任务分配差距过大，调度员直接扣分。 对应技术逻辑：总损失 = 主任务损失 + λ× 负载均衡损失，强制路由器兼顾效果与负载分配，打破马太正反馈循环。
公式
路由器路由概率：
(p_i = \\text{softmax}(W_g \\cdot x)_i) x：token 特征向量；(W_g)：路由器可学习参数；(p_i)：token 分配给第i号专家的概率。
总损失函数（核心）
(\\mathcal{L}{total} = \\mathcal{L}{task} + \\lambda \\cdot \\mathcal{L}{balance}) (\\mathcal{L}{task})：主任务交叉熵损失；(\\lambda)：均衡损失权重超参；(\\mathcal{L}_{balance})：负载均衡辅助损失。
(\\mathcal{L}{importance} = N \\cdot \\sum{i=1}^N \\bar p_i^2) N专家总数，(\\bar p_i)专家 i 平均路由概率；分布越不均匀损失数值越大；完全均匀时损失等于 1。
(\\mathcal{L}{load} = N \\cdot \\sum{i=1}^N l_i^2) (l_i)：专家 i 实际接收 token 占比，统计真实调度负载，而非概率期望。
(\\mathcal{L}{entropy} = -\\sum{i=
