# AWS介绍在SageMaker HyperPod上用SkyRL训练视觉迷宫导航模型

- Source: MechNext — https://mechnext.eu/zh/article/23-aws-details-a-skyrl-visual-maze-training-run-on-sagemaker-hyperpod
- Published: 2026-09-28
- Updated: 2026-09-28
- Category: Industry News
- Language: zh (Markdown in other languages: ?lang=en, ?lang=de, ?lang=sk, ?lang=pl, ?lang=ru)

> AWS公布了一项使用SkyRL、GRPO和Ray继续训练Qwen3-VL-8B的流程。在其64个留出迷宫的实验中，解题数从28个升至第160步的最高62个。

亚马逊云科技于2026年9月25日发表了[Accelerate multimodal RL training with SkyRL on Amazon SageMaker HyperPod](https://aws.amazon.com/blogs/machine-learning/accelerate-multimodal-rl-training-with-skyrl-on-amazon-sagemaker-hyperpod)。文章记录的是一次具体的视觉迷宫导航后训练实验：模型为视觉语言模型Qwen3-VL-8B，起点是经过VisGym监督微调的检查点，后续训练使用SkyRL与GRPO。文章提供了集群构成、训练设置、评估安排和推理部署步骤。以下数字均是AWS对这次实验的描述，理解它们时需要同时保留相应的任务、配置和评估范围。

### 从已有检查点开始的训练

这条流程并不是从一个未说明的初始状态开始。AWS明确指出，使用的是VisGym监督微调检查点，并在此基础上对Qwen3-VL-8B进行后训练，目标任务是视觉迷宫导航。SkyRL和GRPO是该后训练步骤所用的框架与方法名称。把起点说清楚很重要，因为文中给出的基线和后续成绩属于这条特定训练链路；只看模型名称，无法判断相同数字是否也适用于其他起点或其他任务。文章记录了这个实例中的操作和观察结果，没有给出将其推广到不同模型或数据集的依据。

训练运行在Ray集群上。AWS描述的集群包含三个GPU工作节点和一个CPU头节点，具体为三个ml.g7e.12xlarge工作节点，总计六块GPU，以及一个配有512 GB内存的ml.r5d.16xlarge头节点。这些实例类型和数量说明了实验所用的计算环境。读者如果要理解后面的流程，应该把六块GPU、三个工作节点以及一个头节点视为同一套配置的组成部分，而不是彼此独立的结果。文章没有报告改变节点数量或实例类型之后，迷宫解题率会怎样变化。

### 共享存储和工作分配

按照AWS给出的步骤，Ray集群从SageMaker Studio创建。Amazon FSx for Lustre挂载在`/shared`，用于保存训练检查点、LoRA权重和评估输出。这个路径在流程中连接不同类型的产物：检查点对应训练状态，LoRA权重对应适配器，评估输出则记录评估阶段的结果。AWS还说明，更新后的LoRA适配器权重通过Amazon FSx for Lustre同步。因此，共享存储不仅是文中列出的一个服务名称，也承担了这次运行中保存产物和传递适配器更新的具体任务。有关这一点的结论仍限于文中配置。

在所述配置里，六个vLLM rollout引擎与采用FSDP分片的策略模型共享GPU。这里的“六个”指生成rollout轨迹的引擎数量，不能与六块GPU之外再相加为另一组计算资源。AWS给出的信息是这些组件如何在实验中安排，以及更新后的LoRA权重如何借助共享存储同步。文章并未分别测量单个引擎、分片策略模型或共享GPU方式的独立效果。理解最终解题数字时，更稳妥的读法是把这几项都看作同一实验设置，而不是把其中一项单独解释为成绩变化的原因。

### 每道迷宫题的配置

训练配置为每个迷宫提示生成八条rollout轨迹，并把一次episode限制在最多15步移动。这两个数字分别规定了每道题产生的轨迹数量和单次过程的移动上限。它们让读者能够更准确地知道AWS所说的训练过程采用了什么样的任务边界。如果改用其他轨迹数量或移动上限，文中没有给出相应的实验结果。因此，八条轨迹和15步上限应与后面的64道迷宫评估一起阅读，作为成绩出现时的条件，而不是脱离任务设置的通用建议。

评估使用一个留出的64个迷宫集合，每10个训练步骤进行一次。配置还规定每20个步骤保存完整训练检查点，以及可供推理使用的LoRA导出文件。两个间隔对应不同活动：10步间隔用于查看留出集合上的表现，20步间隔用于保存训练状态和适配器导出。文中给出的解题百分比有明确的分母，即这64道留出迷宫。检查点与导出文件则说明在训练过程中会留下哪些产物；它们本身不构成另一次独立评估，也不扩大解题率所覆盖的任务范围。

### 提交任务与观察运行

在作业提交方面，AWS描述的是一个受保护的Ray端点，使用`sagemaker_ray://`地址格式以及AWS凭证。这个信息说明了示例怎样把作业送入Ray环境，也是复述流程时需要保留的操作细节。它并不提供关于模型在迷宫上表现的额外数字。AWS还写到，HyperPod Observability EKS附加组件会在Amazon Managed Grafana中配置四个Ray仪表板，名称分别是Ray Core、Ray Data、Ray Train和Ray Serve。这四个名称标识了文中可供观察的面板，不能被当成四项训练成绩。

把作业入口、共享存储和仪表板连在一起看，可以看到文章描述的运行路线：集群在SageMaker Studio中创建，作业经受保护的Ray端点提交，训练与适配器相关产物写入指定共享位置，Ray仪表板用于观察环境。这里的路线只是对AWS所列步骤的整理，没有为任何一个环节增加新的技术能力或效果判断。尤其是仪表板的存在，不能说明迷宫解题率为何变化；它只能说明AWS在这套环境中列出了哪些观察界面。结果仍需回到文中明确给出的评估数据。

### 如何阅读解题率

AWS报告的基线解题率为43.75%，即64个迷宫中解出28个。文章给出的最高解题率为96.875%，即64个迷宫中解出62个，出现在第160步。百分比与具体题数相互对应，因此可以明确知道这两个数字是基于多少道题得出的。最高值指这次实验在第160步报告的峰值，而不是对所有训练步骤、所有迷宫或所有部署条件的概括。将28个和62个放在同一个64题集合的范围内比较，才符合文章提供的数据边界。

文章同时提醒读者，结果会有所变化。现有材料没有说明，更换超参数或迷宫配置之后能否再次得到同样的解题率。它也没有提供把“64题中解出62题”用作其他模型、数据集或部署方式基准的证据。因此，读者可以准确引用AWS在这次实验里报告的基线、峰值和对应步骤，却不能把峰值写成普遍性能保证。这个限制并不会改变文中已经报告的数字；它只是明确这些数字直接支持的结论究竟有多宽。

### 从训练产物到推理

流程最后还包含使用训练后适配器进行推理的步骤。AWS把训练得到的LoRA适配器暂存于Amazon S3，并配置Ray Serve，使其在基础模型旁动态加载该适配器。这与前面每20步保存可供推理使用的LoRA导出文件相衔接，说明文章不仅记录训练和评估，也写出了适配器进入推理环节的方式。这里能够确认的是适配器的存放位置、Ray Serve的加载配置，以及它与基础模型一起使用的安排；文中列出的64题成绩不能据此自动延伸为其他推理环境的成绩。

整篇示例的可核对边界由几组具体信息构成：VisGym监督微调检查点是起点，SkyRL与GRPO用于后训练；Ray集群由三个GPU工作节点和一个CPU头节点组成；共享的FSx for Lustre路径承担产物保存与权重同步；每题八条轨迹、每次最多15步；64题留出集合按10步间隔评估；第160步报告62题解出。把这些条件与结论一同保留，才能忠实呈现AWS所发表的实验。对其他配置是否能够重现这一数值，文章没有给出确定答案。