MoE训练怎么评测：按顺序验证通信与吞吐

一、为什么MoE要单独评测

混合专家模型（Mixture of Experts，下文简称MoE）把部分网络层拆成多个专家子网络。每个token只交给少数几个专家计算，所以模型总参数量可以远大于每个token实际经过的参数量。这种结构能扩大模型容量，但会引入通信和负载问题，稠密模型的评测方法无法直接套用。

评测MoE时，团队通常会遇到三类问题：

• 另一套集群上跑不出同样的吞吐，原因是网络，还是配置？
• 训练变慢，是通信瓶颈，还是某几个专家所在的设备过热？
• 增加专家数量后，模型质量是否真的提高？

本文给出一套按顺序进行的评测方法。前一步不通过，就不进入下一步。方法基于自测，不引用外部材料的具体数字。文中出现的数字都是占位符或示例，需要替换为自己的测量值。

本文适合训练平台开发者、大模型训练工程师、集群运维人员和负责算力预算的技术负责人。

二、先弄清MoE的成本结构

评测前要统计三个数字：

1. 总参数量：包括全部专家、共享层和嵌入层。
2. 激活参数量：每个token实际经过的参数，通常包括共享层和被选中的专家。
3. 专家数量与top-k：每层有多少个专家，每个token选几个。例如每层64个专家、每个token选8个。此处数字仅为示例，应以自己的配置文件为准。

忽略路由和通信开销时，MoE的单次前向计算量接近激活参数量相当的稠密模型，参数容量则接近总参数量对应的稠密模型。两者之间的差距，就是MoE用通信、存储和负载换来的容量。

容量增加带来三类额外成本。

• 存储成本：所有专家参数都要放在显存或内存中，优化器状态也随之增长。专家越多，越依赖模型并行切分，管理复杂度随之上升。
• 通信成本：token按路由结果发送到持有对应专家的设备，计算完成后再返回原设备。这一过程通常由all-to-all通信完成，耗时取决于带宽、延迟和每条消息的大小。
• 负载不均成本：路由器可能把大量token分给少数专家。最忙的设备决定每一步的完成时间，其他设备只能在同步点等待。

路由参数会放大后两类成本。容量因子（capacity factor）限制每个专家每步最多接收的token数。超过上限的token如何处理，取决于具体实现。有些实现直接丢弃，有些实现转交给其他专家，还有些实现让这些token跳过该层、经残差路径直通。不同实现的行为差异很大，评测报告必须写明实际采用的策略，不能只写”使用了MoE”。

drop策略的通信量有上限，但会损失部分token的梯度信号。dropless策略保留全部token，但负载不均时，最忙的专家会拖慢整步。因此，top-k、容量因子和丢弃策略必须和吞吐数字一起记录，否则两组结果无法比较。

三、评测前的配置记录

每次实验都要填写下列字段。缺少任何一项，结果都不能用于横向比较。

• 节点数、每节点加速卡数量、网络类型与拓扑。
• 专家数量、top-k、容量因子、丢弃策略（drop或dropless）。
• 并行切分方式：数据并行、张量并行、流水线并行、专家并行各自的规模。
• 每步的全局batch大小（以token计）与序列长度。
• 吞吐统计口径：是否包含数据加载，是否去掉前若干步的预热。

四、实验顺序与停止条件

实验分四步。每一步都写明产出物和停止条件，前一步不通过，就不进入下一步。

第1步：通信基线

在目标节点数下测量纯all-to-all通信。只跑通信内核，不跑模型。

• 消息大小：从小到大取若干档，覆盖训练中每个token的隐藏维度对应的字节数，以及打包后的典型消息大小。
• 并发：与训练时的专家并行规模一致。
• 指标：有效带宽（发送字节数除以耗时）、单次耗时的中位数，以及P99尾延迟。
• 重复：每个配置重复多次，报告均值和方差。
• 产出物：一张”消息大小、有效带宽、尾延迟”对照表，以及不同节点数下的对比图。
• 停止条件：同一配置多次运行的波动超过团队设定的阈值，或尾延迟明显高于中位数。此时先排查网络和拓扑，不进入第2步。阈值由团队根据第一轮测量结果确定。

第2步：稠密对照

选一个激活参数量与MoE相近的稠密模型作为基线。两者必须同口径对比：

• batch大小（以token计）、序列长度、优化器和学习率调度相同。
• 训练token数相同，才能比较loss。
• 吞吐使用同一套统计口径，记录tokens/s/GPU。
• 使用同一份验证集，记录验证loss。

产出物：MoE与稠密模型在吞吐、训练loss、验证loss上的对比表。

停止条件：若MoE吞吐低于稠密模型，且验证loss没有改善，说明该MoE配置的收益不成立。此时应先调整配置，不要扩大专家数量。

第3步：专家负载与训练损失

在第2步的基础上，记录每层、每个专家在每步接收的token数，并计算以下指标：

• 负载比：最忙专家的token数除以平均值（max/mean）。数值越接近1，负载越均匀。
• 丢token率：被丢弃的token数除以总token数。只在drop策略下有意义。
• 最忙设备耗时占比：最忙设备的计算加通信时间，除以整步时间。

训练loss曲线也要和第2步的结果一起看，不能只看吞吐。

产出物：负载比随训练步数变化的曲线，以及丢token率与loss的关系图。

停止条件：负载比长期偏高，或丢token率超过团队设定的上限，应先调整路由或负载均衡方法，再进入第4步。改动负载均衡方法后，需要重跑第2步，确认吞吐与loss的变化。

第4步：迁移边界验证

若要把结论用到另一套集群，必须在目标集群上重跑第1步到第3步。原集群的吞吐数字不能直接套用。

产出物：一份适用条件说明，写明结论在哪些节点数、网络拓扑、专家数量和并行方式下成立。

停止条件：目标集群的通信基线与原集群差异超过阈值。此时结论只能作为参考，不能用于预算决策。

五、常见误判与纠正

误判一：把另一套集群的吞吐直接当作本集群的预期。纠正方法是先做第1步，用通信基线判断差距来自哪里。

误判二：比较两组吞吐时忽略容量因子和丢弃策略。纠正方法是把这两项写入配置记录，不同配置的结果分开列表。

误判三：只看平均负载。平均值接近1，仍可能有少数专家长期过载，拖慢尾部步骤。纠正方法是同时报告max/mean和最忙设备耗时占比。

误判四：吞吐提升就认为配置更好。若loss变差，吞吐提升可能来自丢弃了更多token。纠正方法是吞吐和loss同时看，并记录丢token率。

误判五：把单节点小规模实验的结果直接外推到多节点。节点内与跨节点的通信延迟和带宽差异很大，单节点结果只能反映计算侧的情况。纠正方法是至少在目标节点数下完成第1步。

误判六：吞吐统计包含预热步。前几步的编译和缓存开销会压低均值。纠正方法是去掉预热步，只报告稳定阶段的统计值。

六、适用范围

本文方法适用于MoE模型的训练评测。非MoE模型不适用，因为它们没有all-to-all通信和专家负载问题。单节点小规模实验可以沿用本文步骤，但数字需要在目标规模重新测量。网络拓扑与参考环境不同的集群也是如此。

所有步骤都可以在自己的集群上复现。具体数字需要用自己的训练代码、模型配置和硬件实测得出。