MoE模型在生产环境莫名掉智？检查下Capacity Factor

很多MoE架构的模型在离线评测时表现完美，但一上线面对高并发流量，输出质量就莫名下滑。最诡异的是，这种退化跟输入问题的难度无关，反而跟并发量正相关，而且日志里一个报错都没有。这种“静默失效”大概率是因为 MoE Capacity Factor（容量因子）设低了，导致大量 Token 被悄悄丢弃。

简单来说，MoE 的每个专家（Expert）都有一个固定大小的缓冲区。如果路由（Router）把太多的 Token 分配给同一个专家，超过缓冲区上限的部分会被直接丢弃。被丢弃的 Token 不会触发报错，而是直接跳过该层的前馈网络（FFN），只靠残差连接传递。这意味着你的模型在某些层实际上变成了“空跑”，导致表达能力骤降。

这里的核心计算逻辑是：

capacity = capacity_factor * tokens * top_k / num_experts

如果 capacity_factor 是 1.0，专家只能接收刚好平均分配的 Token 量。一旦路由出现不均衡（而 MoE 的天性就是“强者恒强”），超出部分就被扔掉。

这种设计是为了在 TPU/XLA 等硬件上保证静态形状（Static Shape），方便进行批处理矩阵乘法。但代价就是：Token 的命运取决于它在 Batch 里的位置。同一个句子，放在 Batch 前面可能被处理，放在后面可能就被丢弃，这解释了为什么 MoE 推理时会出现随 Batch Size 变化而结果不同的玄学现象。

针对这个问题，实操中的优化路径通常是：

• 最简单的方案： 直接调高 capacity_factor。虽然会增加显存占用，但能有效降低丢弃率。
• 进阶方案： 切换到 Dropless 的块稀疏内核（比如 MegaBlocks 风格的 Grouped GEMM），彻底消除固定缓冲区的限制。
• 架构方案： 采用像 DeepSeek-V3 那样的无辅助损失平衡机制（per-expert routing bias），在不牺牲质量的前提下维持负载均衡。

建议在部署 MoE 模型时，必须在监控中加入每层、每个专家的 Token 丢弃率（Drop Rate）。如果你不记录这个指标，你永远无法感知模型是否在悄悄“偷懒”。