Amazon EKS MoE 强化学习吞吐量提升 40%，但该基准测试仍有局限
Amazon 表示，其 Amazon EKS MoE 强化学习在工程师通过 Elastic Fabric Adapter 启用 DeepEP 后，整体 rollout 吞吐量提升了 40%。该测试覆盖 48 个 P5en 实例，其中 16 个用于策略训练，32 个用于生成推理 rollout。对于大模型后训练中成本高昂的阶段而言，这是一个显著成果。
关键变化并不只是又一种更快的 GPU 配置。Amazon 已将 DeepEP 的专家通信路径适配至 libfabric，使 DeepEP v2 原生支持 AWS 网络。这一集成针对的是 Mixture-of-Experts 模型在不同 GPU 上的专家之间路由 token 时产生的不规则流量模式。
这一结果也需要谨慎看待。AWS 披露的是一个超稀疏 MoE 工作负载的相对吞吐量提升，而非适用于所有模型、集群或强化学习框架的通用基准。独立系统研究已记录了在不同 GPU 与网络架构之间迁移专家并行通信的难度。
Amazon 在其 MoE 强化学习技术栈中做了什么改变
Amazon 报告的提升来自改变路由 token 在专家之间传输的方式，而非为测量集群增加更多机器。
AWS 架构将一项强化学习任务划分为多个工作组。GPU 节点负责策略训练、奖励模型推理和 rollout 生成。CPU 节点运行环境和预处理，而内存优化节点则保存经验缓冲区和检查点缓存。
Amazon EKS 充当编排层。它部署容器、管理独立节点组、协调故障，并让运维人员能够独立扩缩工作负载的各个部分。Amazon S3 在对延迟敏感的执行路径之外，存储数据集、检查点、最终权重和其他持久化产物。
这种分离之所以重要，是因为强化学习并不是一种单一、均匀的计算。在 rollout 生成期间，推理工作节点使用当前策略与环境交互，产生候选响应或轨迹。奖励系统对这些样本进行评估，而策略训练工作节点则消耗由此产生的经验。
更新后的权重随后返回 rollout 集群，开启下一轮策略迭代。这一循环存在于人类反馈强化学习，即 RLHF 中；RLHF 利用偏好信号改进模型。它同样存在于组相对策略优化，即 GRPO 中；GRPO 会相对于同一组中的其他样本评估输出。
每个阶段对基础设施施加的压力不同。rollout 生成类似于分布式推理，通常可以将任务分配给彼此独立的工作节点。策略训练则需要更紧密的同步，因为参与的 GPU 必须完成协调操作，才能进入下一步。
因此，该架构在报告的测试中将 32 个推理实例与 16 个训练实例分开。在这 48 套 P5en 系统中，Amazon 表示，与未使用 DeepEP 的配置相比，通过 EFA 运行 DeepEP 将整体 rollout 吞吐量提升了 40%。
P5en 实例采用 NVIDIA H200 GPU 和高带宽 AWS 网络。一个满配的 48 实例部署意味着数百个加速器，尽管 AWS 表示其更大规模的架构可扩展至约一千个加速器。已公布的百分比描述的是 48 实例的对比，而非所有可能的集群规模。
该模型本身仅被描述为超稀疏 MoE 模型。Mixture-of-Experts 模型包含多个专业化的前馈模块，但每个 token 只会激活其中一部分。稀疏性降低了每个 token 的计算量，但当专家位于不同 GPU 上时，也带来了高要求的路由难题。
当每个 rank 交换大小相近且可预测的数据块时，标准集合操作表现良好。MoE 路由则不同。token 会动态选择专家，因此流量可能稀疏、不均衡，并由大量小规模传输组成。
这一区别解释了基础设施为何如此重要。更高的理论模型容量并不会自动带来更多有效的每秒 token 数。如果专家分发和结果收集压垮网络，昂贵的 GPU 就会等待激活数据，而不是处理它们。
为什么 Amazon EKS MoE 强化学习会遇到网络瓶颈
稀疏计算节省了算力，但专家并行可能将这一成本以通信延迟的形式重新带回来。
专家并行将模型的专家分布在多个 GPU 上。当路由器选择远程专家时，系统必须将每个 token 的激活值分发到正确设备。专家处理完成后，combine 操作会将输出返回其原始执行路径。
这些交换会在整个模型中反复发生。其目的地取决于运行时作出的路由决策，不同专家接收的 token 数量也可能不同。因此，网络必须处理大量细粒度传输，同时避免少数繁忙目的地拖慢所有参与方。
DeepEP 正是为这种模式而创建的。DeepEP 项目为专家并行工作负载提供专用的 dispatch 和 combine 内核。它在服务器内部使用 NVLink 通信，并在服务器之间使用支持 RDMA 的传输方式。
远程直接内存访问，即 RDMA，可让一台机器在较少 CPU 参与的情况下直接向另一台机器的内存传输数据。这一更短的数据路径可以降低软件开销，并让高速网络硬件发挥更大作用。
Elastic Fabric Adapter，即 EFA，是 AWS 面向紧密耦合计算的低延迟网络接口。EFA 文档描述了一条基于 AWS Scalable Reliable Datagram 的操作系统旁路路径。EKS 可以将 EFA 设备暴露给运行分布式机器学习应用的 pod。
在每个 P5en 实例内部，NVLink 和 NVSwitch 在本地加速器互连中承载 GPU 流量。对于跨实例传输，EFA 成为相关路径。Amazon 的集成使用 libfabric，这是一种让应用程序通过统一 API 访问不同高性能网络提供程序的接口。
Amazon 表示，其工程师贡献了相关功能，将 DeepEP 通信原语从 CUDA 专用的 RDMA 后端迁移至 libfabric。借助这项工作，DeepEP v2 可以通过 EFA 发送节点间数据，同时保留用于专家 dispatch 和 combine 的专用内核。
专用专家操作与密集集合操作之间的区别，是这一结果的核心。NCCL 仍适用于 all-reduce、all-gather 和 reduce-scatter 等规则操作。DeepEP 则针对 MoE 层周围的稀疏 all-to-all 交换。
近期研究反映了这一分工。NCCL EP的作者描述了专家通信的低延迟与高吞吐模式。其高吞吐设计会先在 NVLink 域内聚合数据，再通过节点间 RDMA 连接进行传输。
这一层级结构减少了跨越机器间较慢边界的细粒度流量。它也承认集群并非一个均匀的网络：服务器内通信的带宽和延迟特征不同于跨服务器通信。
AWS 的实现遵循同样的总体原则。本地流量保留在 NVLink 上，而 libfabric 通过 EFA 承载跨节点 DeepEP 流量。这条感知拓扑的路径替代了对每次 token 传输进行通用处理的方式。
由此产生的 40% 提升指的是整体 rollout 输出，而不仅仅是通信微基准。这一端到端指标很有价值，因为更快的内核并不总能加速整个强化学习循环。这一提升表明，专家通信的重要性足以影响已完成的 rollout 工作。
不过，rollout 吞吐量仍只是系统的一个层面。策略迭代时间还取决于环境执行、奖励评估、样本缓冲、检查点发布、训练计算和权重同步。优化一个阶段可能会暴露其他瓶颈。
真正的竞争是专用路由与通用集合操作之间的较量
核心竞争在于：为动态专家路由设计的通信，与为规则数据移动设计的集合操作之间的竞争。
通用集合操作之所以具有吸引力，是因为它们成熟、获得广泛支持，也更容易集成。它们可适用于众多训练框架和硬件配置。运维人员还可以用熟悉的工具测试它们，并理解其同步行为。
MoE 流量违背了让这些集合操作高效运行的若干假设。每个 token 都可能选择不同的专家集合。一些专家会暂时变得热门，消息大小保持较小，系统则会在每一层 MoE 层执行 dispatch 和 combine 操作。
传统实现可以将这些流量封装为 all-to-all 操作。这一方法仍然可用，但当专家并行跨越更多节点时，同步与消息处理开销会增长。更多 GPU 随之带来更多通信关系，而不是按比例增加更多有效计算。
DeepEP 通过围绕专家路由语义构建的内核来解决这一问题。dispatch 内核将 token 激活值发送给选定专家。combine 内核返回处理后的激活值，同时避免通用集合操作可能为未使用目的地执行的工作。
该设计还试图将通信与计算重叠。如果 GPU 能够在传输进行时继续执行有用的矩阵操作，部分网络时间就会从关键路径中消失。当通信需要反复进行 CPU 协调或严格的全局同步时，这种重叠会变得更加困难。
Amazon 向 libfabric 的迁移之所以重要，是因为原始优化与 NVIDIA GPU 和 InfiniBand 风格网络紧密相关。在一种网络互连上表现良好的通信库，并不会自动在另一种网络上保持相同行为。排序保证、消息发起方式和设备接口都可能不同。
因此，这一集成并不只是改变一个网络地址。DeepEP 的假设必须映射到 EFA 的传输语义上，且实现必须确保 token 被正确传递。它还必须避免引入足以抵消专用路由优势的软件开销。
Amazon 表示，受支持的 P5 和 P6 系统可以结合 EFA 使用 GPUDirect RDMA。GPUDirect RDMA 允许网络传输直接从 GPU 内存读取和写入，而无需将每个负载都经由普通主机内存暂存。操作系统不再位于主要数据路径上。
这一设计给仅依赖标准集合操作的通用 MoE 部署带来了压力。使用大型专家并行模型的基础设施团队现在已有证据表明，专用路径能够改善一种与生产相关的强化学习工作负载。
这一结果同样给框架维护者带来压力。DeepEP 支持必须覆盖推理引擎、强化学习系统、容器镜像、调度器和可观测性工具。若一种高速传输方式需要脆弱的定制构建，它可能会在部署或恢复期间失去优势。
NCCL 2.31 则补上了另一块拼图。AWS 表示，该版本针对密集型集合通信纳入了更新的 EFA 优化。因此，一个现实的 MoE 训练栈会针对不同流量类别采用不同机制，而不是宣称存在唯一的通用胜者。
DeepEP 负责不规则的专家分发与合并。NCCL 则继续处理注意力层、张量并行、数据并行和优化器状态周围的密集同步。EFA 通过针对各自模式优化的路径，在机器之间承载这两类通信。
这种分工才是更重要的架构启示。MoE 扩展依赖于按通信形态和目的进行识别。若将每次传输都视为可互换的，就会白白损失可获得的性能。
40% DeepEP 吞吐量声明并不能证明什么
该基准测试支持一项特定架构决策，但并不能证明 DeepEP 相比 EFA 具有普遍适用的 40% 增益。
Amazon 明确了实例配置、相对提升幅度以及模型的大致稀疏性特征。但它并未公开模型参数量、专家数量、路由分布、序列长度、批量大小或完整的基线配置。
这些细节会直接影响专家通信。每个 token 激活更多专家的模型可能产生更多流量。更大的批量可更高效地合并消息，而较小的解码批量则可能放大固定延迟。
“汇总 rollout 吞吐量”这一表述也需要结合背景理解。AWS 在公开文章中没有给出每秒输出 token、轨迹或完成请求的绝对数量。读者无法计算集群的总体利用率，也无法将其直接与其他提供商进行比较。
基线同样至关重要。“未使用 DeepEP”可能指采用特定调优选项的标准 NCCL all-to-all 实现。不同的消息聚合、专家部署、并发设置或路由策略，都可能缩小或扩大测得的差距。
Amazon 报告的是其内部工作负载下的受控结果。该公司并未声称该基准经过独立审计，公开材料中也没有包含重复试验的方差。因此，更准确的表述应是 AWS 称吞吐量提升了 40%。
此外还存在可移植性问题。早期的 UCCL-EP research 指出，与 GPU 和网络接口高度绑定的专家通信系统会带来大量集成工作。该论文尤其研究了不同排序语义如何增加对 EFA 及其他非 InfiniBand 网络的支持难度。
这项研究早于 Amazon 最新披露的原生 EFA 工作。它仍具有参考价值，因为它解释了 AWS 表示现已通过对 libfabric 的贡献解决的技术障碍。这两种说法描述了快速变化的实现历史中的不同阶段。
UCCL-EP 采取了另一条路线。它将路由决策保留在 GPU 上，但把网络执行委托给多线程 CPU 代理，并通过控制通道弥合硬件差异。其作者报告称，在 NVIDIA 加 EFA 系统上取得了提升，但这些测试使用的是他们自己的模型、框架和配置。
两项结果并不相互否定。它们表明，传输设计可以改变结果，而“支持 EFA”并不代表某一条固定的执行路径。运营者需要了解某个构建使用的是 GPU 发起的传输、CPU 代理、消息聚合，还是其他兼容层。
DeepEP 自身公开的要求和性能结果也在不断演变。当前项目文档报告了其在受支持 RDMA 配置上的强劲带宽表现，但仍建议用户直接对更大规模的专家并行部署进行基准测试。在拓扑和拥塞行为各异的云网络上，这一点尤其重要。
集群规模会带来更多不确定性。报告中的测试使用了 48 个 P5en 实例，而 AWS 则讨论了将更广泛的架构扩展到约一千个加速器。一项在 48 个节点上表现良好的设计，不一定能在所有更大规模下保持相同效率。
当多个工作组共享基础设施时，可能出现网络争用。随着模型或工作负载行为变化，token 路由也可能变得更加不均衡。单个较慢的 rank 还可能拖延高度同步的训练操作。
强化学习还会引入自身的变化来源。提示词长度、响应长度、环境延迟、采样设置以及奖励模型复杂度，都会影响 rollout 工作节点花在通信上的时间。当生成或环境执行成为主导时，在通信密集型工作负载上获得的 40% 增益可能会缩小。
该结果对在线服务的说明更为有限。生产推理通常使用更小的批量，并有严格的单请求延迟目标。为 rollout 生成调优的高吞吐量内核，并不会自动降低交互式用户的首 token 时间或每个输出 token 的耗时。
成本方面也没有给出绝对指标。同一集群上的更高吞吐量通常会提升每加速器小时的有效工作量，但文章没有提供总训练成本。它也没有将优化后的配置与其他实例类型或网络库进行比较。
这些缺失并不意味着该结果不重要。它们界定了结果的适用范围。该基准证明，AWS 的 DeepEP 集成能够消除某个大型 MoE 强化学习流水线中的一个重要瓶颈。
EKS 和 Spot 容量改变了 RL 系统的其余部分
只有当调度器、缓冲区、存储和故障模型能够持续为更快的 rollout 集群供给任务时，通信增益才能在运营层面发挥价值。
Amazon EKS 允许该架构为不同任务分配不同节点类型。GPU 节点组可围绕训练和推理需求进行扩展。CPU 组可为环境工作节点扩容，而面向内存的系统则可承接短生命周期的经验数据。
这种异构性对 GRPO 和 RLHF 尤其重要。Rollout 工作节点可以产生大量临时数据，但策略训练器会以同步批量方式消耗这些数据。如果产出和消耗速率出现偏离，一方会等待，另一方则不断积压队列。
共享的内存中经验缓冲区可在短时间内解耦这两种速率。Rollout 工作节点发布已完成的样本，训练器则在准备就绪时拉取批量数据。检查点缓存有助于分发更新后的权重，而无需让每次传输都经过持久化对象存储。
Amazon S3 扮演的是不同角色。它保存数据集、可恢复的检查点、完成的模型工件和最终权重。将这一持久化路径与最频繁的样本交换分离，可避免对象存储延迟主导每一个训练步骤。
这种分离也进一步说明了 EKS 的价值。Kubernetes 并不加速矩阵乘法或专家内核；它负责协调让加速器持续高效工作的各类服务。
EKS 管理部署、重启、扩缩容策略和节点组边界。它可以将稳定的策略训练容量与更具弹性的 rollout 工作节点分开调度。这一边界支持 Amazon 的第二项优化：将 EC2 Spot Instances 用于部分 rollout 生成。
当 AWS 需要收回底层实例时，Spot 容量可能会被中断。对于高度同步的策略训练而言，这种风险十分棘手，因为失去一个工作节点就可能导致协同作业停滞或重启。Rollout 任务则更容易划分和重试。
Amazon 建议为 rollout 工作节点分配有边界的工作单元，并频繁发布样本。当收到中断通知后，工作节点可以清空进行中的请求，并将未完成任务返回队列。其他工作节点则可继续运行，而无需重启整个策略训练组。
该策略并不能让中断毫无代价。丢失的部分生成会浪费一些算力，替代节点还需要加载容器、模型权重和通信库。自动扩缩容决策也必须考虑队列深度、模型加载时间和可用的 Spot 容量。
不过，这种拓扑隔离了两个故障域。策略训练器运行在稳定容量上，而 rollout 生成则使用成本更低但可预测性更差的资源池。这一设计契合了两个阶段不同的同步需求。
40% 的 DeepEP 吞吐量提升可能改变这种平衡。更快的推理工作节点产生经验的速度，可能超过训练器的消耗速度。运营者随后需要调整节点组规模、批量调度，或缩减推理容量，以避免为闲置产能付费。
策略更新后也可能出现相反情况。权重分发和工作节点重启时间可能暂时让经验缓冲区供给不足。因此，一个有用的生产仪表板必须跟踪端到端策略迭代，而不仅仅是每秒生成的 token 数。
团队还需要可复现的构建信息。DeepEP、NCCL、CUDA、libfabric、EFA 驱动、框架版本和 GPU 架构都会影响数据路径。修改其中一个组件，可能会在不知不觉中选择性能更慢的回退路径。
这些运营证据应与模型和实验记录一同保存。工程团队可以在可搜索的技术知识库中保留配置决策、基准说明和故障报告。当后续镜像重建在模型不变的情况下改变吞吐量时，这种做法便尤为重要。
三项信号将显示这项增益是否可泛化
下一项测试是跨模型、集群规模和完整策略迭代的可复现性。
第一个信号是提供绝对吞吐量的公开基准测试包。有价值的结果应包括每秒 token 或轨迹数、延迟分布、专家负载不均衡程度、网络利用率以及重复运行方差。
该测试包应明确基线集合通信方式、所有相关软件版本以及精确的 DeepEP 传输路径。它还应披露模型维度、每个 token 的活跃专家数、批量大小、提示词长度、响应长度和专家并行度。
如果独立团队复现出类似增益，AWS 的声明便更具说服力。如果结果差异很大，该集成依然有价值，但其效果将取决于具体工作负载。无论哪种结果，都能帮助运营者判断其额外复杂性是否值得。
第二个信号是超越已发布的 48 实例配置后的扩展效率。多个集群规模下的结果将显示吞吐量是按比例增长，还是因同步、拥塞和专家不均衡而失去优势。
一项有意义的扩展研究应在增加资源时保持工作负载定义不变。它应同时报告汇总输出和每加速器效率。即使每块新增 GPU 带来的有效工作更少，汇总吞吐量仍然可能上升。
若能在接近一千个加速器时保持强劲效率，将支持 AWS 更广泛的架构主张。若效率急剧下降，则表明 DeepEP 消除了一个瓶颈，但更大规模下出现了另一个瓶颈。
第三个信号是在真实故障条件下端到端策略迭代所需的时间。Rollout 吞吐量之所以重要，是因为训练工作节点需要新鲜经验，而不是因为生成孤立 token 本身就是最终目标。
未来的测量应包括环境执行、奖励评估、缓冲区延迟、策略更新、检查点发布和权重重新分发。它们还应展示 Spot 中断如何影响已完成样本和恢复时间。
更短的完整迭代时间将证明通信优化改善了强化学习进展，而非只是将空闲时间转移到其他环节。如果迭代时间几乎没有变化，团队应在增加更多 rollout 容量之前，先检查训练、存储或同步环节。
Amazon EKS 上的 MoE 强化学习如今已有一条可信路径，可将 Kubernetes 编排、EFA 网络和专用专家通信结合起来。据报道的 40% 提升使这一路径值得测试，但它仍是一项起始测量，而非可迁移的恒定结论。基础设施团队应在标准化该技术栈之前，使用自身的模型、路由配置和 RL 循环复现这一对比。实际问题不在于 DeepEP 是否能画出一张更快的图表，而在于将系统各个部分都纳入计算后，同一集群能否以可接受的可靠性和成本完成更多经过验证的策略更新。
