AWS介绍了一种用于混合专家模型（MoE）强化学习的架构，将Amazon EKS、Elastic Fabric Adapter（EFA）和Amazon S3放在同一工作流程中。文章还给出一项吞吐量比较：在指定配置下，采用通过EFA通信的DeepEP软件栈后，强化学习rollout的总体吞吐量比基线高40%。这是AWS对该次比较的报告。理解这个数字，需要同时看清实例分工、通信路径、基线配置以及被测指标；单独引用百分比，无法说明这个结果适用于哪些条件。

架构中的任务如何分配

在AWS描述的EKS集群里，不同类型的实例承担不同工作。GPU实例负责生成rollout、执行奖励模型推理，以及训练策略；CPU实例负责环境和预处理；内存优化实例承担经验缓冲区与检查点缓存。这种分工把生成经验、暂存经验、消费训练数据以及保存训练状态几个环节串在一起。阅读架构时，可以沿着经验数据的去向理解各组实例的作用，而不必把所有计算和存储任务都看成同一种工作。

具体流程从rollout经验进入内存优化的缓冲区开始。策略训练从缓冲区取出批次，完成相应训练工作，并发布更新后的检查点。检查点与已完成的产物随后持久化到Amazon S3。缓冲区、检查点缓存和S3在描述中各有位置：前者参与经验和训练状态的工作流程，S3则保存检查点与完成后的产物。这些环节共同构成AWS所介绍的训练流程，也说明吞吐量测量对应的是一个有多组工作节点参与的系统。

根据AWS的说明，EKS在这个架构里负责工作组之间的调度、扩缩容、故障恢复和协调。rollout生成、奖励模型推理、策略训练、环境处理与预处理被分配到不同组后，协调本身就成为理解系统运行方式的一部分。这里的EKS职责是组织这些工作组及其运行过程；经验从生成端进入缓冲区，再被训练端按批次消费，更新后的检查点又进入后续保存流程。AWS给出的描述覆盖了这些连接关系。

专家间通信的路径

通信路径也按范围区分。GPU实例内部使用NVLink和NVSwitch；实例之间使用EFA。对于MoE中的专家通信，DeepEP提供dispatch内核，将token发送到远端专家，还提供combine内核，收集专家处理后的token。AWS描述的跨节点路径是通过EFA使用libfabric。因而，文章中的DeepEP、EFA以及实例内部的互连技术，分别对应token处理过程和不同范围的通信路径，不能仅凭它们同时出现在架构图中就视为同一个组件。

AWS表示，它参与将DeepEP的通信原语迁移到libfabric，并使DeepEP v2原生支持EFA。这一说明解释了文章为何把DeepEP和EFA放在一起讨论：dispatch把token送往远端专家，combine把已处理的token汇集回来，而跨节点通信使用libfabric经由EFA完成。它提供的是实现路径的背景。至于性能变化有多少来自这一条路径，需要回到实际比较的两套配置，而不能仅根据技术描述给单一组件分配全部收益。

把系统各部分放回自己的位置，有助于读懂AWS提出的方案。EKS负责工作组的调度与协调；GPU、CPU和内存优化实例分别承担已列出的计算与缓冲任务；S3保存检查点和完成产物；NVLink与NVSwitch用于GPU实例内部通信，EFA用于实例之间；DeepEP的两个内核处理token发往专家和返回后的汇集。这个分层说明了一次rollout相关工作如何经过多个环节，也说明总体吞吐量指标覆盖的范围比某一个内核操作更广。

40%的数字来自什么比较

AWS报告的测试使用48台P5en实例，运行一个超稀疏MoE模型。其中16台实例专门用于训练，32台专门用于推理。这样的实例总数和训练、推理分配，是理解结果不可缺少的测试条件。AWS报告的是在这个配置下，强化学习rollout的总体吞吐量发生了什么变化；它没有在已给出的证据中提供其他模型、其他实例类型或其他部署方式也能得到同样百分比的测量。

两套软件配置同样重要。基线采用基于Slime的软件栈，没有通过EFA加速的专家并行；改进配置采用DeepEP通过EFA运行的软件栈。AWS称，启用后一套配置时，这项48实例比较中的总体rollout吞吐量提高了40%。因此，准确表述应同时写明被比较的软件栈、48台P5en实例、超稀疏MoE模型和训练与推理的分工。省略这些条件，容易把特定测量误读成适用于任意环境的性能承诺。

这项比较还有明确的归因界限。基线与改进配置不只在DeepEP通过EFA这一点上不同；软件栈的其他组成部分也有差异。现有证据因此没有单独测出40%的提升中，有多少比例由DeepEP通过EFA本身造成。可以确认的，是AWS报告两套指定配置之间的总体rollout吞吐量差异。不能把全部40%直接归给某个单独改动，也不能据此推算换用别的模型、实例或部署后会得到相同结果。

“总体rollout吞吐量”这个指标也应保持原有含义。AWS给出的40%描述的是所述比较中rollout产出的整体吞吐变化，并非每一项子任务的独立加速比例。GPU上的rollout生成、奖励模型推理和策略训练，CPU上的环境与预处理，以及内存优化实例上的缓冲工作，都属于所介绍流程的组成部分；但已给出的证据没有分别列出各部分对40%的贡献。把指标限定在AWS实际报告的范围内，才能避免对单个环节作出没有测量支持的判断。

任务中断与软件要求

AWS还说明了Spot Instances上的rollout任务被中断时的处理方式：中断的任务可以返回队列，再分配给其他工作节点；与此同时，其他rollout工作节点继续生成经验。这项描述涉及任务重新排队和重新分配，说明架构如何处理一部分rollout工作的中断。它并不构成成本节省的测量结果。已给出的资料没有量化Spot Instances节约了多少费用，因此不能从任务可重新分配这一点推导出具体节省数字。

操作指南列出的要求包括Amazon EKS 1.31或更高版本、带有AWS OFI NCCL插件的EFA安装程序1.49、DeepEP 2.0.0、NCCL 2.31.2、SGLang 0.5.17，以及配合CUDA 13.0的PyTorch 2.12.1。这些版本信息为AWS所述实现提供软件环境背景，也让读者看到文章讨论的是具有明确组件要求的流程。它们本身并不是另一项性能实验，不能取代前述两套配置和实例分配所限定的比较条件。

综合AWS的描述，这篇文章提供的是一套把工作组分工、经验缓冲、检查点保存和专家通信连接起来的MoE强化学习架构，并报告了在特定48台P5en实例配置下的总体rollout吞吐量差异。40%应与基线及改进软件栈的差别一起阅读；Spot任务的重新分配应作为运行机制理解。架构、实现要求和测量结果均来自AWS的技术文章，目前给出的材料没有提供独立验证或其他部署的对应测量。