AWS在EKS上用EFA和DeepEP跑MoE强化学习，吞吐量提升 40%
在一套 48 台P5en实例（16 台训练、32 台推理）的测试中，启用DeepEP over EFA后，MoE模型强化学习rollout总吞吐量提升 40%。
AI解读：这条新闻的核心数字是 40%：在 48 台P5en实例上，把DeepEP跑在EFA上之后，MoE模型的强化学习rollout总吞吐量比不启用时高了四成。AWS把原因归结为专家并行通信开销的下降。
为什么MoE的RL后训练容易被通信卡住？因为模型越稀疏，计算省了，令牌在设备之间的全对全路由却变多了。专家并行把这种稀疏、细粒度、不均衡的流量从单机NVLink推到跨机EFA上，跨机带宽更低，同步开销更大，通信就成了主瓶颈。
AWS的解法是把DeepEP的通信原语从CUDA专用RDMA后端迁到libfabric，让传输层可以跑在EFA上，并用dispatch和combine两个专用内核替代通用全对全集合通信。配套版本包括DeepEP 2.0.0、NCCL 2.31.2、SGLang 0.5.17、PyTorch 2.12.1（CUDA 13.0）。
对跑大规模RLHF或GRPO的团队来说，这套架构把rollout生成和策略训练拆到不同节点组：rollout可以跑在Spot实例上，因为单个worker被中断不需要整个任务停下；策略训练则留在稳定容量上，避免被Spot中断或NCCL超时拖垮。这是省钱的部分，但AWS没有给出具体的成本下降数字。
40% 是在特定配置下测出来的，不是通用承诺。架构还要求通信节点在同一个可用区、集群版本EKS 1.31或更高、EFA installer 1.49配AWS OFI NCCL插件，并且只在p5.48xlarge、p5e.48xlarge、p6-b200.48xlarge等受支持的GPU实例上成立。换环境之前，这些条件得先对上。
AWS在一篇技术文章中给出了一套在Amazon EKS上扩展MoE强化学习后训练的架构，组合Amazon EKS、Elastic Fabric Adapter（EFA）和DeepEP。文章称，在 48 台P5en实例（16 台用于训练、32 台用于推理）上运行一个super-sparse MoE模型时，启用DeepEP over EFA使强化学习rollout的总吞吐量提升了 40%。
MoE的强化学习后训练为什么卡在通信上
文章指出，用RLHF或GRPO对MoE模型做大规模后训练时会同时出现三类挑战：协调rollout生成与策略训练的异构算力；在数百个加速器之间维持高吞吐通信；以及动态编排各子系统保持平衡。
MoE已成为把大语言模型扩展到数千亿甚至万亿参数的标准架构，靠稀疏性维持推理效率。但稀疏并不消除训练侧的基础设施复杂度。后训练流程通常包括预训练、中期训练、监督微调（SFT）和强化学习（RL），其中大规模RL训练对基础设施的要求格外特殊：它把弹性推理工作和需要高带宽通信的紧耦合模型训练放在一起，奖励模型、验证器和检查点更新还会进一步增加内存、网络和编排压力。
与稠密模型相比，MoE后训练引入的新问题是：新架构为了降低推理成本越来越稀疏，训练就越受通信而非计算约束。通信开销的一个关键来源是专家并行（EP）。EP在张量并行、数据并行、流水线并行这些结构化通信模式之外，增加了跨设备的动态全对全令牌路由。EP度越大，这种流量越会从节点内走向节点间。
文章把问题归结为两类工作负载的速率匹配：rollout生成追求聚合吞吐而非首令牌时间或令牌间延迟，策略训练则要求worker齐步前进，任何延迟尖峰或掉队worker都可能让整个任务停摆或触发NCCL超时。训练步太慢会让推理worker空转，推理吞吐不够又会让训练加速器闲置。
架构：EKS分节点组，EFA负责跨机，S3存检查点
架构把编排、高性能通信和持久存储拆成可独立扩展的三层。Amazon EKS管理异构worker的生命周期和调度，EFA提供计算密集型GPU工作负载的节点间数据路径，Amazon S3存储数据集、模型检查点和训练产物（包括模型权重）。
EKS集群按RL流程的不同阶段划分节点组：GPU加速实例跑rollout生成、奖励模型推理和策略训练；CPU实例跑环境和预处理；内存优化实例承载经验缓冲区和检查点缓存，让生产者和消费者交换数据时不必把持久存储放在关键路径上。
在GPU实例内部，NVLink和NVSwitch承载节点内高带宽通信；EFA支撑对延迟敏感的节点间通信，用于分布式策略训练等紧耦合GPU操作。文章称，在受支持的配置上，EFA配合NVIDIA GPUDirect RDMA和OS bypass，可以在实例之间的GPU内存缓冲区直接传输数据，减少通信路径中的CPU和操作系统参与。
文章给出的前提条件包括：具备相应IAM权限的AWS账户；Amazon EKS 1.31或更高版本；EFA installer 1.49及AWS OFI NCCL插件；DeepEP 2.0.0、NCCL 2.31.2、SGLang 0.5.17、PyTorch 2.12.1（CUDA 13.0）；受支持的GPU实例，例如p5.48xlarge、p5e.48xlarge或p6-b200.48xlarge；以及熟悉Kubernetes和分布式训练概念。文章还提到通信节点必须位于同一可用区，并需要安装EFA Kubernetes设备插件。
DeepEP如何改走EFA，以及 40% 从哪来
DeepEP替换了标准NCCL全对全集合通信，改用两个专用GPU内核：dispatch内核把令牌从本地GPU路由到远端专家，combine内核把处理后的令牌收回来。节点内传输走NVSwitch上的NVLink，节点间传输由DeepEP通过libfabric在EFA上发送。
AWS向上游贡献了把DeepEP通信原语从CUDA专用RDMA后端迁移到libfabric的多项特性，使传输层可以移植到libfabric支持的网络架构上，并针对EFA优化MoE训练。文章称，这些改动让DeepEP v2获得原生EFA支持；同时NCCL 2.31纳入了面向稠密集合通信的最新EFA优化。
支撑 40% 这一数字的测试配置是 48 台P5en实例，其中 16 台专用于训练、32 台用于推理，运行一个super-sparse MoE模型。文章没有说明该吞吐量提升在其他模型规模、实例组合或并行配置下是否成立。
rollout用Spot实例省钱，但文章没给成本数字
文章建议把rollout生成放在Amazon EC2 Spot实例上，理由是它是分布式推理任务，可以拆分到独立worker上。与策略训练不同，rollout worker被中断不需要整个RL任务停止，未完成的任务可以退回队列重新分配，其余worker继续生成经验。
具体做法是：在Amazon EKS上按rollout需求和队列深度扩展基于Spot的rollout节点组，同时为策略训练保留稳定容量；rollout worker处理有界的工作单元并频繁发布已完成样本；收到Spot中断通知时，worker排空进行中的请求，把未完成任务退回队列。文章称这种分离可以降低rollout生成成本，策略训练worker则不受Spot中断、延迟或NCCL超时影响。
文章没有给出这套方案具体节省了多少成本，只说明这一分离“有助于降低”rollout生成成本。