AWS has described an architecture for mixture-of-experts (MoE) reinforcement learning that brings together Amazon EKS, Elastic Fabric Adapter (EFA) and Amazon S3. It also reports a throughput result: a configuration using DeepEP over EFA delivered 40% higher aggregate reinforcement learning rollout throughput in a specified comparison. The figure is AWS's report for that setup and should be read alongside the details of what was compared.

Where the work runs

The described EKS cluster assigns different parts of the workflow to different instance groups. GPU instances generate rollouts, run reward-model inference and train the policy. CPU instances handle environments and preprocessing. Memory-optimized instances provide experience buffers and checkpoint caches. This layout places the generation of experience, its short-term storage and its use in training within one coordinated architecture.

In the workflow, rollout experience enters a memory-optimized buffer. Policy training takes batches from that buffer and publishes updated checkpoints. Checkpoints and completed artifacts are then persisted to Amazon S3. AWS describes EKS as providing scheduling, scaling, failure recovery and coordination across the worker groups. Those functions matter because rollout generation and policy training are connected by the flow of experience and updated checkpoints.

How expert communication fits in

For communication within GPU instances, the architecture uses NVLink and NVSwitch. EFA carries communication between instances. DeepEP provides a dispatch kernel that routes tokens to remote experts and a combine kernel that gathers the processed tokens. The described path between nodes uses libfabric over EFA. AWS says it migrated DeepEP communication primitives to libfabric and gave DeepEP v2 native EFA support.

These components have distinct roles in the account. EKS coordinates the groups of workers. The buffer holds rollout experience for training, and S3 holds checkpoints and completed artifacts. NVLink and NVSwitch serve communication inside GPU instances, while EFA serves communication between instances. DeepEP's dispatch and combine operations address the movement of tokens to and from experts. Reading the result against those roles helps identify the measured workflow without treating every component as a separately measured gain.

What the 40% comparison covers

AWS's reported comparison used 48 P5en instances running a super-sparse MoE model. Sixteen instances were dedicated to training and 32 to inference. The baseline was a Slime-based stack without EFA-accelerated expert parallelism. The improved configuration used a DeepEP-over-EFA stack. AWS reports that aggregate reinforcement learning rollout throughput was 40% higher with the improved configuration in this comparison.

The metric is aggregate rollout throughput for those two configurations. The evidence does not separately establish the result for other models, instance types or deployments. It also does not isolate how much of the 40% difference came from DeepEP over EFA alone: the compared software stacks differed in other components as well. The supported conclusion is therefore about the observed difference between the specified configurations, with the hardware split and model type kept in view.

Recovery and software context

AWS also describes how interrupted Spot Instance rollout tasks can return to a queue and be reassigned while other rollout workers continue generating experience. This explains a recovery path for rollout work within the architecture. The account provides no measured Spot Instance cost savings, so the described reassignment should not be converted into a numerical savings claim.

The walkthrough lists Amazon EKS 1.31 or later, EFA installer 1.49 with the AWS OFI NCCL plugin, DeepEP 2.0.0, NCCL 2.31.2, SGLang 0.5.17, and PyTorch 2.12.1 with CUDA 13.0 among its requirements. These versions provide context for the implementation described by AWS. The architecture, configuration and reported measurement are set out in the AWS technical article.