Nous Research 通过 DeepEP 扩展专家并行：MoE 预训练的现场记录

Nous Research 发布了一份详细的技术报告，介绍如何使用 DeepEP（一个用于高效专家通信的开源库）为大规模预训练扩展混合专家（MoE）专家并行。该报告基于该团队运营一个多太瓦月集群来预训练一个未命名的 1 万亿参数 MoE 模型的经验。该文档超越了基准测试数据，深入探讨了实施现实：哪些配置有效，出现了哪些瓶颈，以及团队如何解决这些问题。

大规模 MoE 的核心挑战是专家负载不平衡。当路由器将不成比例的流量发送给某些专家时，一些 GPU 会空闲，而其他 GPU 则排队。DeepEP 通过两层并行解决这一问题：跨专家的数据并行、跨共享专家的全规约，结合在训练期间重新平衡负载的动态路由。Nous 报告证实，DeepEP 在跨 1024 个 GPU 分布的 64 个专家上实现了 2% 偏差内的近乎完美负载平衡。

报告中的关键数据：在 H100 上，对于具有 64 个专家的 1T MoE 模型，吞吐量为 380 t/s/gpu；经过 DeepEP 优化后，专家通信开销占总训练时间的 3%；未使用 DeepEP 时，最差 GPU 的负载失衡导致 34% 的空闲时间；使用 DeepEP 后，负载失衡导致空闲时间低于 2%。

该报告将 DeepEP 与传统的all-to-all专家通信进行了对比，后者在大规模部署中会成为带宽瓶颈。DeepEP 使用一种定制的通信方案，将专家计算与数据交换重叠，从而将通信延迟隐藏在计算背后。Nous 团队还描述了他们的生产集群拓扑：一个由 Slurm 管理的 1024 节点集群，配备通过 NVLink 和 InfiniBand 连接的 H100 GPU。

对其他实验室的实践启示：DeepEP 并非即插即用的解决方案。Nous 报告警告说，专家并行的收益对模型架构因素很敏感，例如专家数量、容量因子和 top-k 值。理想配置必须针对每个模型系列通过经验确定。该团队发布了他们的配置文件和监控脚本作为参考模板。

在更广泛的格局中，Nous Research 的 MoE 工作加入了 Google 的 GLaM、Meta 的 V-MoE 和 Mistral 的 Mixtral 等贡献。但是，那些实验室发布的是最终架构论文，而 Nous 的现场记录则强调运营层面：集群管理员需要了解什么才能保持训练在数月内稳定运行。这种视角在开放研究中很少见，并且对于任何构建大规模 MoE 集群的实验室来说都直接有用。