On September 25, 2026, AWS published Accelerate multimodal RL training with SkyRL on Amazon SageMaker HyperPod. The walkthrough follows a specific post-training run for visual maze navigation. It starts with a VisGym supervised fine-tuning checkpoint of the Qwen3-VL-8B vision-language model, then uses SkyRL and GRPO. The configuration and results below are those reported by AWS for that run.

How the run is arranged

The Ray cluster in the walkthrough has three GPU worker nodes and one CPU head node. AWS specifies three ml.g7e.12xlarge workers, providing six GPUs in total, and an ml.r5d.16xlarge head node with 512 GB of RAM. Those details set the scale of the described environment. They do not establish how a different cluster size would affect training or the reported maze result.

The cluster is created from SageMaker Studio. An Amazon FSx for Lustre mount at /shared holds checkpoints, LoRA weights and evaluation output. AWS also says updated LoRA adapter weights synchronize through FSx for Lustre. The shared path therefore connects several stages of this particular workflow: training artifacts are saved there, and the adapter updates are made available through the same storage service.

Six vLLM rollout engines share GPUs with an FSDP-sharded policy model in the described setup. This is a concrete account of where rollout generation and policy training run, rather than a separate performance result for either component. The number of engines, the sharing of GPUs and the adapter synchronization all matter when interpreting the example as a reproducible configuration, but the post does not establish an outcome for other layouts.

Maze episodes and measurement

For each maze prompt, the training configuration generates eight rollout trajectories. It caps an episode at 15 moves. These settings define the attempts and the episode boundary used in the walkthrough. A reader comparing the reported result with another run would need to keep those settings in view; the AWS result alone does not show what happens if either value changes.

The configuration evaluates on a held-out set of 64 mazes every 10 steps. Every 20 steps, it saves both full training checkpoints and inference-ready LoRA exports. These are two distinct intervals in the same run: one governs when the held-out maze set is assessed, while the other governs when recoverable training state and adapter exports are written. The stated solve rates refer to the reported evaluation set.

Jobs are submitted through a secured Ray endpoint using the sagemaker_ray:// address scheme and AWS credentials. For observing the environment, AWS says the HyperPod Observability EKS add-on provisions four Ray dashboards in Amazon Managed Grafana: Ray Core, Ray Data, Ray Train and Ray Serve. The submission route and dashboards describe how the run is operated and watched; they are not additional measures of maze-solving ability.

What AWS reports

The post gives a baseline solve rate of 43.75%, or 28 of the 64 mazes. Its highest reported rate is 96.875%, or 62 of 64, at step 160. Giving both the counts and percentages makes the scope of that result clear: it is an outcome on the specified held-out set during this experiment. The peak should be read as the value AWS observed at that step, within the configuration described above.

AWS says results will vary. The supplied account does not establish whether the same solve rate would recur with different hyperparameters or different maze configurations. It also provides no basis for treating 62 of 64 as a benchmark for other models, datasets or deployments. The useful comparison within the post is between its own baseline and its own peak on the stated 64-maze evaluation.

Using the trained adapter

The walkthrough ends with an inference path for the trained LoRA adapter. AWS stages that adapter in Amazon S3 and configures Ray Serve to load it dynamically alongside the base model. This connects the saved adapter from the training workflow to the described serving setup. Together, the cluster layout, evaluation schedule, reported counts and inference step give readers the boundaries of the example without implying results beyond the experiment AWS documented.