基于 AWS EKS 与 DeepEP 的 MoE 强化学习架构实现 40% 吞吐量提升

一句话结论

在亚马逊云科技（AWS）上结合弹性容器服务（Amazon EKS）、Elastic Fabric Adapter（EFA）及 DeepEP 通信库，可将混合专家（MoE）强化学习吞吐量提升 40%。

关键要点

• 通过 DeepEP v2 原生支持 EFA，结合 NVIDIA GPUDirect RDMA 及操作系统旁路技术，解决了 MoE 模型训练中的通信瓶颈，使端到端策略迭代时间显著缩短。
• 在由 48 台 P5en 实例（含 16 台训练节点和 32 台推理节点）组成的集群中，启用 DeepEP 经 EFA 优化后，强化学习（RL）Rollout 总吞吐量提升 40%。
• 架构采用混合节点组设计：GPU 实例负责生成、奖励推理及策略训练，CPU 实例处理预处理，内存实例托管缓冲区，并利用 EC2 Spot 实例降低生成阶段成本。
• 支持 p4d/p4de、p5/p5e 及 p6-b200/p6-b300（.48xlarge 规格）等多种实例类型，要求通信节点位于同一可用区并配置 EFA 插件，架构可扩展至约 1000 个加速器。
• 改进配置软件栈包括 CUDA 13.0、PyTorch 2.12、NCCL 2.31、EFA 1.49、DeepEP 2.0、SGLang 0.5.17 及 Miles 0.1.0，相较于基线配置实现了性能突破。

背景与事实

混合专家（Mixture-of-Experts, MoE）架构利用稀疏激活机制将大语言模型扩展至万亿参数规模，其训练流程涵盖预训练、监督微调（SFT）及强化学习（RL）阶段。与传统密集模型不同，MoE 的后训练过程受通信约束显著大于计算约束。专家并行（Expert Parallelism, EP）引入跨设备的动态令牌路由，导致通信模式叠加了张量并行（TP）、数据并行（DP）及流水线并行（PP）的复杂度。在大规模异步强化学习场景中，系统需平衡侧重聚合吞吐量的滚动生成（Rollout）与紧耦合的策略训练，以防止硬件闲置或 NCCL 超时错误。

为解决上述挑战，亚马逊云科技在基于 Amazon EKS 的环境中构建了一套优化架构。该架构在节点间采用 EFA 技术，支持 NVIDIA GPUDirect RDMA 及操作系统旁路，利用节点内的 NVLink/NVSwitch 加速互联。Amazon 将 DeepEP 通信原语迁移至 libfabric，使 DeepEP v2 原生支持 EFA，且 NCCL 2.31 集成了最新的 EFA 优化。DeepEP 通过专用的分发（dispatch）与合并（combine）内核替代传统的 NCCL All-to-All 操作，结合 NVLink 与 RDMA 有效降低了 EP 通信开销。在集群编排层面，Amazon EKS 划分了独立节点组：GPU 实例执行生成、奖励推理及策略训练，CPU 实例运行预处理任务，内存实例托管缓冲区。此外，使用 EC2 Spot 实例可显著降低生成阶段成本，Spot 节点组支持按需扩展，并能在中断后重分配资源而不影响策略训练的连续性。

测试环境基于 48 个 P5en 实例构建，其中 16 个用于训练，32 个用于推理，运行对象为超稀疏 MoE 模型。基线配置采用 Slime 栈（CUDA 12.9, PyTorch 2.9.1, NCCL 2.27, SGLang 0.5.9, Slime 0.2.4），未启用 EFA 加速 EP。改进配置则采用 DeepEP-over-EFA 栈（CUDA 13.0, PyTorch 2.12, NCCL 2.31, EFA 1.49, DeepEP 2.0, SGLang 0.5.17, Miles 0.1.0）。数据显示，启用 DeepEP 经 EFA 使 RL Rollout 总吞吐量提升 40%，端到端策略迭代时间缩短，且架构可平滑扩展至约 1000 个加速器。该方案支持 p4d/p4de、p5/p5e 及 p6-b200/p6-b300（.48xlarge 规格）实例，前提条件是通信节点位于同一可用区并正确配置 EFA 插件。作业提交由 TorchX 负责，Miles 仓库中的 train_rl.py 脚本协调 Rollout 与策略训练，参考镜像为 763104351884.dkr.ecr。任务结束后，需删除作业、节点组、集群及 Spot 容量、EFA 网卡、S3 存储以停止计费。

影响分析

对于中文开发者与从业者而言，这一架构优化提供了在大模型后训练领域降低成本与提升效率的可行路径。分析判断显示，由于 MoE 模型训练对通信带宽极度敏感，传统的基于以太网或标准 RDMA 的集群在专家并行阶段往往成为瓶颈，导致昂贵的 GPU 资源闲置。引入 DeepEP 与 EFA 组合后，通信开销大幅降低，使得单位算力能够处理更多的 RL 迭代，直接降低了单次模型迭代的硬件成本。

此外，该方案中关于 Spot 实例的使用策略对国内云环境具有参考意义。分析判断认为，在强化学习这种对延迟敏感度相对较低（针对生成阶段）且任务具备重分配能力的场景中，利用竞价实例处理非核心路径任务，可以在保证核心策略训练稳定性的同时，将生成阶段的成本压缩至传统预留实例的较低水平。对于正在构建大规模 RLHF 或 GRPO 后训练流水线的团队，这一架构证明了在 Kubernetes 环境下通过细粒度网络优化和异构节点分组，可以突破传统单一节点组模式的扩展性限制。

适用边界

该结论的适用存在明确限制。首先，所有通信节点必须位于同一可用区（Availability Zone）内，若集群跨可用区部署，EFA 的高吞吐特性可能因网络延迟而失效，导致性能提升幅度下降甚至出现通信错误。其次，支持实例类型限定为 p4d/p4de、p5/p5e 及 p6-b200/p6-b300 系列，其他 GPU 实例或非 NVIDIA 架构可能无法完全兼容该 DeepEP 与 EFA 的优化路径。

第三，软件栈版本要求严格，必须使用 DeepEP 2.0、NCCL 2.31 及特定版本的 PyTorch 和 CUDA，低版本栈无法复现 40% 的吞吐量提升。第四，该优化主要针对 MoE 模型的专家并行通信瓶颈，对于密集模型或主要受计算约束而非通信约束的训练场景，采用此架构可能无法获得显著收益。最后，Spot 实例的使用依赖于市场实例库存的稳定性，在算力高峰期可能导致实例中断频率增加，需具备完善的中断处理逻辑才能发挥其成本优势。

孤本观察

编辑判断认为，AWS 此次通过底层通信库（DeepEP 迁移至 libfabric）与集群网络（EFA）的深度耦合，实际上重新定义了 MoE 训练在云原生环境下的网络基准线，这表明未来大规模后训练的竞争焦点将从单纯的算力堆叠转向网络拓扑与通信原语的精细化协同。

来源：AWS Machine Learning Blog