235B 的 MoE 模型，训练算力怎么估算？

先这样答

估算 235B MoE 模型训练算力的第一步是确认激活参数量。这是美团二面的压轴题。MoE 架构在每次推理时只激活部分专家网络。模型的总参数量不等于实际参与计算的参数量。直接用 235B 去乘 token 数会导致这道题直接归零。你必须先向面试官明确该模型每次路由激活的具体参数规模。

拿到激活参数量后，你可以开始估算总计算量。单 token 经过模型的前向传播计算量，等于激活参数量乘以对应的常数系数。反向传播的计算量大约是前向传播的两倍。前向与反向加起来的总系数约等于三倍。你用总训练 token 数乘激活参数量，再乘这个三倍系数，就能得出训练所需的总 FLOPs。

最后一步是把总 FLOPs 换算成训练时间。你需要把总计算量除以集群的有效算力。你不能直接使用 GPU 的理论峰值算力。集群在分布式训练时存在节点间的通信开销。MoE 模型在路由时还会遇到专家负载不均的情况。这些因素都会让实际算力打折扣。你必须向面试官说明算力折损情况。你用总计算量除以折损后的有效算力，得出最终的训练耗时。

面试官会怎么追问

• 「为什么说直接用 235B 算 FLOPs 这道题就归零了？」 因为 MoE 模型采用稀疏激活机制。每次前向传播时网络只会把数据路由给部分专家。235B 是所有专家参数的总和。实际参与单次计算的参数量远小于这个数字。

• 「计算总 FLOPs 时，前向和反向的比例关系是怎么来的？」 模型训练包含前向传播和反向传播两个阶段。前向传播对应一个基础计算系数。反向传播的计算量大约是前向的两倍。两者相加得出总计算量约为前向的三倍。

• 「在评估集群有效算力时，为什么要特意强调打折扣？」 理论算力无法在实际训练中完全跑满。多节点协同训练必然产生网络通信开销。MoE 模型特有的路由机制还会引发专家负载不均。这些因素都会让实际可用算力低于标称算力。

回答的坑

• 混淆总参数量与激活参数量，直接用 235B 作为基数去估算总计算量。
• 忽略通信开销和 MoE 负载不均问题，直接用 GPU 标称算力除总 FLOPs。