亚马逊云科技 2026 年 9 月 25 日公开 MoE 强化学习训练配方：48 台 P5en 启用 DeepEP over EFA，吞吐提升 40%。 ## 为什么这条配方值得 FDE 逐字读 前置部署 Forward Deployed Engineer（FDE）在企业里做大规模训练交付时，最难的不是把作业跑起来，而是把「十几个组件版本对齐」这件事变成可核对、可回滚的工程流程。这条配方给的正是一份带版本矩阵与构建期断言的训练栈，而不是架构图加概念解释。 前置部署 Forward Deployed Engineer（FDE）能直接拿走四样东西：一份 EKS 与 EFA 的节点组划分方式、一条必须满足的同一可用区约束、一个带收尾断言的 DeepEP over EFA 镜像构建脚本，以及一条 TorchX 提交命令与配套的清理命令。 前置部署 Forward Deployed Engineer（FDE）还要先记住题材边界：原文反复使用 in our internal workloads 的措辞，这是亚马逊云科技内部训练团队的负载，不是客户现场交付项目。把它当作训练基础设施工程的一手样本，而不是客户案例。 ## 一、问题定义：MoE 强化学习训练同时压三个约束 原文把大规模 MoE 强化学习 Reinforcement Learning 的困难拆成三条同时成立的约束：协同异构算力以同时承载 rollout 生成与策略训练；在数百个加速器之间维持高吞吐通信；以及动态编排每个子系统使它们保持平衡。 rollout 生成是分布式推断，优化目标是聚合吞吐而不是首 token 延迟或 token 间延迟；策略训练 policy training 则是紧耦合的锁步作业，任何延迟尖峰或掉队 worker 都会拖住整个作业，甚至触发 NVIDIA 集合通信库 NCCL 的超时。两者的速率不匹配，就会一边空转一边排队。 专家并行 Expert Parallelism 是通信开销的主要来源：MoE 模型按 token 动态路由到不同专家，产生稀疏、细粒度且不均衡的 all-to-all 流量，这与张量并行 Tensor Parallelism、数据并行 Data Parallelism、流水线并行 Pipeline Parallelism 的结构化通信模式完全不同。 作业规模超过单机后，并行组跨节点，通信从机内高带宽的 NVLink 结构转到带宽更低的跨机链路。专家并行度越高，跨机流量占比越大，跨机通信遂成为主导瓶颈。 ## 二、架构分层：三类节点组加一个对象存储数据层 EKS 集群里按职责切成三类节点组：GPU 加速实例跑 rollout 生成、奖励模型推断和策略训练；CPU 实例跑环境和预处理；内存优化型实例托管经验缓冲与检查点缓存，使生产者和消费者交换数据时不必把持久存储放进关键路径。 作业数据流是一个闭环：rollout 阶段模型与 CPU 环境 pod 交互生成样本，经验写入内存优化型缓冲；策略训练步骤消费批次、更新权重、发布新检查点；新检查点回流到下一轮 rollout，同时与训练产物一起持久化到 Amazon S3，用于恢复与下游使用。 通信域分成两层：机内由 NVLink 与 NVSwitch 承担高带宽流量；跨机由弹性网络适配器 Elastic Fabric Adapter（EFA）承担延迟敏感的紧耦合 GPU 通信。在受支持的机型上，EFA 与 NVIDIA GPUDirect RDMA 配合，数据直接在跨实例的 GPU 显存缓冲之间搬运，绕过 CPU 与操作系统。 ## 三、前置条件：六个必须同时满足的版本口径 前置部署 Forward Deployed Engineer（FDE）落地前要逐项核对前置条件，任何一项不满足都建议先停手，因为后面的性能收益依赖于整条链路一致。 六项要求是：具备相应 IAM 权限的账号；Amazon EKS 1.31 或更高版本（下文 ClusterConfig 里写的是 1.33）；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 与分布式训练的熟悉度。 原文给出的可用机型清单更长：p4d.24xlarge、p4de.24xlarge、p5.48xlarge、p5e.48xlarge、p6-b200.48xlarge 与 p6-b300.48xlarge 都支持大规模强化学习训练，可以承担 rollout 或训练任一角色。 衡量收益用的两套栈必须记清楚，否则 40% 这个数字会被误读。基线栈是 Slime-based 且没有启用 EFA 加速的专家并行：CUDA 12.9、PyTorch 2.9.1、NCCL 2.27、SGLang 0.5.9、Slime 0.2.4。改进栈是本文描述的组合：CUDA 13.0、PyTorch 2.12、NCCL 2.31、EFA 1.49、DeepEP 2.0、SGLang 0.5.17、Miles 0.1.0。 ## 四、第一步：用 eksctl 划分节点组 集群用 eksctl 的 ClusterConfig 声明，通用 CPU 节点组与 GPU 加速节点组的容量口径完全一致，都是 minSize 3、desiredCapacity 3、maxSize 6、capacityType 为 ON_DEMAND、privateNetworking 为 true，滚动更新的 maxUnavailable 都取 1。 两个节点组的关键差别在标签与污点：加速节点组打 workload-type 为 accelerator 与 accelerator 为 nvidia-b300 两个标签，并加一条键为 nvidia.com/gpu、值为 true、效果 effect 为 NoSchedule 的污点；启动模板分别用两个 launchTemplate id 引用。 这段 YAML 在原文里是可直接复制的，集群名 my-eks-cluster、区域 us-west-2、版本 1.33。托管节点组的价值在于策略训练 worker 可以留在稳定按需容量上，而 rollout 容量独立伸缩，必要时混入 Spot 实例。 ## 五、第二步：装 EFA device plugin，并先确认节点在同一可用区 原文把一条容易被忽略的硬约束写在前置说明里：需要通信的节点必须位于同一可用区 Availability Zone。跨可用区部署会先丢掉 EFA 的带宽优势，再去调其他参数是白费力气。 EFA 的 Kubernetes device plugin 以 DaemonSet 形式应用，name 与 label 都是 aws-efa-k8s-device-plugin，命名空间 kube-system，只有加速节点组会被调度到：nodeSelector 写 eks.amazonaws.com/nodegroup 等于 accelerator-ng。 这份 DaemonSet 的几个取值值得逐条抄：priorityClassName 为 system-node-critical；hostNetwork 为 true；容器以 privileged 运行且 allowPrivilegeEscalation 为 true；资源请求只有 cpu 10m 与 memory 20Mi；挂载两个 hostPath，分别是 /var/lib/kubelet/device-plugins 与 /dev/infiniband。 镜像版本是 aws-efa-k8s-device-plugin:v0.5.20，路径形如 602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/aws-efa-k8s-device-plugin:v0.5.20。原文同时提醒，device plugin 只是让设备可见，性能测试与更细的 EFA 配置要另看 EKS 的 EFA 设置指引。 ## 六、第三步：构建 DeepEP over EFA 的镜像，关键是安装顺序 前置部署 Forward Deployed Engineer（FDE）如果要复现这套栈，最值得抄的是构建顺序而不是 Dockerfile 的目录结构。原文的基础镜像是 763104351884.dkr.ecr.<region>.amazonaws.com/sglang 的 0.5.17-gpu-py312-cu130-ubuntu24.04-ec2 标签，来自 SGLang 深度学习容器目录。 版本矩阵在 Dockerfile 里全部参数化：PYTORCH_VERSION 为 2.12.1、EFA_INSTALLER_VERSION 为 1.49.0、NCCL_VERSION 为 2.31.2、NVSHMEM_VERSION 为 3.7.2、SGLANG_VERSION 为 0.5.17、DEEPEP_VERSION 为 2.0.0、MILES_VERSION 为 0.1.0，两个源码提交分别钉在 DEEPEP_COMMIT 为 b306af06afd412c88e51e71802951606e40b7358 与 DEEPGEMM_COMMIT 为 731e7c7a97d269e4b9f482ea18d0e709a948f293。 第一个顺序约束是 EFA 的安装方式：先执行 apt-get remove 卸掉 libnccl-ofi 并删除 /etc/ld.so.conf.d/aws-ofi-nccl.conf，再用 efa_installer.sh 加 -y、--skip-kmod、--no-verify、--build-ngc、--skip-mpi 参数安装。加 --skip-kmod 的理由原文写得很清楚：EFA 内核模块由 EKS 与 EC2 宿主机提供，不由容器提供。 第二个顺序约束是 NCCL 必须先于 DeepEP：DeepEP V2 使用 NCCL Gin，所以要在编译 DeepEP 之前先装好 nvidia-nccl-cu13 的 2.31.2 与 nvidia-nvshmem-cu13 的 3.7.2，让构建期头文件与运行期库保持一致。 第三个顺序约束是用 --no-deps 保护版本：Miles 0.1.0 以 pip install --no-deps -e 的方式安装，避免它的依赖解析把上面那几个基准版本顶掉；原文在装完 Miles 之后又强制重装了一次 NCCL 与 NVSHMEM，并解释了理由——每次源码或包安装之后都要重新断言 NCCL。 收尾有两条硬断言，可以直接当作构建是否成功的判定条件：grep -Fx 校验 /opt/amazon/efa_installed_packages 里存在 EFA installer version 为 1.49.0 那一行；再用 test -f 确认 /opt/amazon/efa/lib/libfabric.so.1 与 /opt/amazon/ofi-nccl/lib/libnccl-net-ofi.so 两个文件存在。同时构建时把 TORCH_CUDA_ARCH_LIST 设为 9.0 10.0 10.3 12.0，覆盖 Hopper 与 Blackwell。 ## 七、第四步：用 TorchX 提交作业，把应用配置与集群配置分开 作业提交不进 kubectl，而走 TorchX：命令是 torchx run 加 -s kubernetes、-cfg queue=default，再调用 dist.ddp，其中 -j 4x8 表示 4 个节点乘 8 张 GPU，脚本是 train_rl.py，模型配置取 deepseek_v3_moe，rollout worker 数取 32，检查点参数 checkpoint_dir 指向 S3。 TorchX 的作用是把作业需求翻译成 Kubernetes 资源，包括算力请求、存储挂载与运行期配置。原文给出的价值是把模型参数、worker 数量与并行策略的调整，和集群级别的资源改动解耦，这样换模型或改并行度时不必动集群。 参考实现把 rollout worker 与策略训练 worker 作为不同的 Kubernetes pod 分别拉起，编排 rollout 与训练的循环。原文也点明保持组件对齐是关键，因为 GPU 内核、集合通信库与底层 EFA 传输各自都会影响端到端性能。 ## 八、第五步：把 rollout 放到 Spot 上，但训练不要放 原文对 Spot 的适用范围给了明确判据：rollout 生成是分布式推断任务、可以切分到互相独立的 worker 上，某个 worker 被中断不需要整个作业停下；未完成的 rollout 任务可以退回队列重新分配，其余 worker 继续产出。策略训练反过来，紧耦合 worker 必须一起推进，不能容忍中断。 前置部署 Forward Deployed Engineer（FDE）判断能不能用 Spot，看的是任务单元是否有界、中断后能不能交回队列。这条判据可以同时用在客户现场的批处理作业与数据回填作业上，而不限于强化学习。 可执行的写法有两条：rollout worker 处理有界的工作单元并频繁发布已完成的样本；Spot 中断通知到达时，worker 先排空drain 活跃请求，再把未完成任务退回队列。策略训练 worker 全程留在按需容量，从而与 Spot 中断、延迟和 NCCL 超时隔离。 在 EKS 层面，Spot 节点组按 rollout 需求与队列深度伸缩，同时为策略训练保留稳定容量。注意原文只给了这套方法，没有给具体的成本节省比例，任何「用 Spot 省了多少」的说法都不在这篇官方原文里。 ## 九、DeepEP over EFA 做了什么：从 CUDA 专用后端迁到 libfabric DeepEP 的做法是替换掉通用的 all-to-all 集合通信，改用两个专用 GPU 内核：dispatch 内核把 token 从本地 GPU 路由到远端专家，combine 内核把处理完成的 token 收回来。机内传输走经 NVSwitch 的 NVLink，跨机传输走 libfabric 发到 EFA。 亚马逊为 DeepEP 贡献的改动是把通信原语从 CUDA 专用 RDMA 后端迁移到 libfabric，这让传输层可移植到 libfabric 支持的网络结构上，并降低专家并行那种稀疏、细粒度流量的单消息开销。原文的结论是 DeepEP v2 由此获得原生 EFA 支持，同时 NCCL 2.31 纳入了面向稠密集合通信的最新 EFA 优化。 之所以要专用内核而不是通用集合通信，原文的解释是：标准 all-to-all 对稠密、规整的通信最有效，而 MoE 因为 token 动态路由产生稀疏、细粒度且不均衡的流量；专家并行跨多节点后，同步与单消息开销上升，跨机通信成为主导瓶颈。 ## 十、实测结果与必须一起读的口径 前置部署 Forward Deployed Engineer（FDE）引用这组数字前，要先看清楚它是怎么测出来的，否则很容易把内部基准当成对外承诺。 实验规模是 48 台 P5en 实例，其中 16 台专用于训练、32 台专用于推断，运行同一个超稀疏 MoE 模型；在启用 DeepEP over EFA 之后，聚合的强化学习 rollout 吞吐提升 40%。对照组与实验组跑在同样的 48 台 P5en 上、同一个模型，差别只在软件栈。 原文额外的结果是：这套架构同时缩短了端到端策略迭代时间，并可扩展到大约一千个加速器。原文没有给出策略迭代时间的具体秒数，也没有给出成本金额，这两个数字在本条里刻意留空，不做推算。 ## 十一、原文没有覆盖的部分 第一条局限是主体：原文说的是 in our internal workloads，即亚马逊云科技内部训练负载，不是客户现场交付。把它迁移到客户环境时，镜像仓库、网络出口与合规约束都会不同，原文没有涉及。 第二条局限是口径：40% 是同机型、同模型下的两套软件栈对比，不是跨机型对比，也不是不同 MoE 结构之间的对比。换机型、换专家并行度或换模型稀疏度之后，这个数字不能直接沿用。 第三条局限是缺口：原文没有给出策略迭代时间的具体数值，没有给出 Spot 的成本节省比例，没有给出 Karpenter 或其他自动扩缩组件的配置示例（只说按 rollout 需求与队列深度伸缩），也没有覆盖 air-gapped 隔离环境下如何搬运这些容器与 EFA 安装包。p6-b300.48xlarge 只出现在机型清单里，没有对应的实测数据。 第四条局限是版本敏感：整套收益建立在版本相互对齐之上，原文自己用「保持这些组件对齐至关重要」来强调这一点，因此任何一项版本漂移都需要重新验证，不能沿用本文的数字。 ## 十二、可以照抄的做法清单与退出方式 前置部署 Forward Deployed Engineer（FDE）按以下顺序执行，每一步都有原文里可核对的取值。 第一步，核对六项前置条件，重点确认 EKS 版本不低于 1.31、EFA installer 为 1.49、并准备好支持 EFA 的机型。不满足就先不要往下走。 第二步，用 eksctl 建集群，按 CPU 与加速两类节点组划分，容量口径统一为最小 3、期望 3、最大 6，加速组加 nvidia.com/gpu 污点，避免非 GPU 负载占用加速节点。 第三步，确认所有需要通信的节点落在同一可用区，再以 DaemonSet 方式部署 aws-efa-k8s-device-plugin:v0.5.20，用 nodeSelector 限定到加速节点组。 第四步，按固定顺序构建镜像：先卸 libnccl-ofi，再装 EFA 1.49（带 --skip-kmod），然后装 NCCL 2.31.2 与 NVSHMEM 3.7.2，再编译 DeepEP 2.0.0（提交 b306af06），最后用 --no-deps 装 Miles 0.1.0 并重装一次 NCCL；镜像构建完成必须通过 libfabric.so.1 与 libnccl-net-ofi.so 两条文件断言。 第五步，用 TorchX 提交作业，把 -j 设为 4x8、rollout worker 数设为 32，检查点目录指向 S3；然后单独拿一组 48 台 P5en 的对照实验确认自己的 40% 是否复现，不要直接引用别人的数字当验收线。 第六步，只在 rollout 节点组上引入 Spot，并实现「有界工作单元 + 频繁发布样本 + 中断时排空并退回队列」三条规则；策略训练节点组保持按需容量。 退出方式在原文里是完整的四步清理：先删运行中的训练作业及其 pod，再删三类节点组，然后删集群，最后确认 Spot 容量、用于 EFA 的弹性网卡以及存检查点的 S3 桶都已释放或清空。命令是 kubectl delete jobs --all -n rl-training、eksctl delete nodegroup 两次（general-purpose-ng 与 accelerator-ng）、eksctl delete cluster --name my-eks-cluster。 ## 十三、与本站既有 EKS 稿件的差异说明 新条目与既有条目的差异是明确的三点：既有 EKS 稿件分别讲自管 Kubernetes 迁 EKS 的共享服务架构、EKS 按 Pod 级控制 ECR 镜像拉取权限、以及 SageMaker HyperPod Inference Gateway 的推断路由；本条讲的是训练侧，主体是 DeepEP over EFA 的专家并行通信与训练栈版本矩阵。 本条与它们不是同一事件、不是同一版本、不是同一技术面：前三条的落点在迁移、权限与推断，本条落在分布式训练的跨机通信与镜像构建顺序。读者如果已经在做 EKS 上的推断服务，这条是训练方向的另一套配置面。 ## 原始来源 原始来源： https://aws.amazon.com/blogs/machine-learning/scaling-moe-reinforcement-learning-on-amazon-eks-with-efa-and-deepep-with-40-more-throughput/