AWS发布SkyRL on SageMaker HyperPod教程：Qwen3-VL-8B迷宫求解率从 43.75% 提到 95% 以上
AWS官方博客给出完整操作步骤：在SageMaker HyperPod上用开源RL框架SkyRL和GRPO对Qwen3-VL-8B做多轮后训练，固定 64 个迷宫评测集上的解迷宫成功率由 43.75% 提升到 95% 以上。
AI解读：这次是AWS教你怎么在自家平台上跑强化学习后训练：用开源框架SkyRL，把Qwen3-VL-8B这个视觉语言模型放进 2D迷宫里练找路，评测集上的解迷宫成功率从 43.75% 提到 95% 以上。数字很漂亮，但注意这是固定的 64 个迷宫，不是随便什么场景都能套。
它解决的是多轮RL训练里两类实际麻烦。一是模型要跑完整条迷宫轨迹才拿得到奖励，只有到达终点给 1 分，路走得好不好没有逐步答案可对，所以SkyRL用GRPO把同一个起点跑出的多条轨迹互相比较，比组内平均好就加分，不需要额外训练一个critic模型。二是跑几百GPU小时的多机任务时硬件容易挂，HyperPod负责自动检测并替换坏节点，checkpoint让任务从上次保存的步数续跑。
真正被影响的是手里有视觉语言模型、想试RL后训练但不想自己搭集群的团队。按教程，训练和推理共用同一批GPU（3 台ml.g7e.12xlarge，共 6 张RTX PRO 6000 Blackwell），vLLM生成轨迹、FSDP更新策略，LoRA适配器权重通过FSx for Lustre同步，因此需要至少 3 台GPU机器加一台大内存CPU头节点，头节点还要负责合并LoRA分片。
限制也写得很清楚：这是AWS官方博客给出的实操教程，效果数字仅来自那个固定 64 迷宫评测集，不能直接外推到其他任务；环境依赖低秩适配（LoRA rank 32）、colocate模式、gpu_memory_utilization设为 0.45 等具体配置，换成别的模型或集群规模需要重新评估显存和参数。
AWS在官方博客发布了一篇操作教程，介绍如何在Amazon SageMaker HyperPod上用开源强化学习框架SkyRL对Qwen3-VL-8B视觉语言模型做多轮RL后训练。
教程采用Group Relative Policy Optimization（GRPO），从VisGym监督微调（SFT）检查点出发，在固定的 64 个迷宫评测集上把解迷宫成功率从 43.75% 提升到 95% 以上。
整个过程运行在SageMaker HyperPod的Ray集群上：3 台ml.g7e.12xlarge作为GPU工作节点（每台 2 张NVIDIA RTX PRO 6000 Blackwell，合计 6 张），1 台ml.r5d.16xlarge（512 GB内存）作为CPU头节点。
任务通过SageMaker Studio创建RayCluster，使用sagemaker_ray:// 协议远程提交，训练指标进入由HyperPod Observability EKS附加组件提供的Amazon Managed Grafana仪表盘。
多轮RL与GRPO在这套方案里怎么工作
文章先解释了多轮强化学习的设定：单轮RL只给一个模型输出打分，多轮RL则让智能体跑完整条轨迹——观察状态、执行动作、获取反馈、进入下一个状态，策略学习的是整幕累积的奖励。
迷宫任务里，一幕就是从某个起点走完一次迷宫，每一步模型看当前迷宫图像，选择方向或决定停止，环境返回更新后的视图。奖励很稀疏：只有在移动步数限制内到达终点才得 1.0，否则什么都没有；也没有逐步的答案可供对照，因为一步走得好不好取决于前后的走法。
- 每个起点让智能体在当前策略下跑多次迷宫，GRPO把这几条轨迹互相比较：优于组内平均的被强化，落后于组内平均的被压低。
- 这种组内比较就是全部训练信号，因此不需要单独的critic或value模型。
集群拓扑与训练配置
方案在HyperPod Ray集群上运行SkyRL，使用 1 个CPU头节点和 3 个GPU工作节点，训练与推理共用同一批GPU。vLLM引擎负责生成整幕迷宫轨迹，按PyTorch FSDP分片的策略模型负责梯度更新；每次优化器步进后，更新过的LoRA适配器权重通过Amazon FSx for Lustre共享存储同步到推理引擎。
教程说明这些实例类型是作者实际使用的配置；其他GPU实例和集群规模也可行，前提是工作节点有足够显存容纳模型。头节点需要大内存，因为每次保存检查点时它会合并来自GPU工作节点的LoRA适配器分片，会短暂把完整适配器权重载入CPU内存，因此选用了 512 GB内存的ml.r5d.16xlarge。
- 工作节点：3 台ml.g7e.12xlarge，每台 2 张NVIDIA RTX PRO 6000 Blackwell GPU，共 6 张。
- 头节点：ml.r5d.16xlarge，512 GB RAM，负责Ray GCS、仪表盘和LoRA适配器合并。
- 策略模型：Qwen3-VL-8B加LoRA（rank 32），用PyTorch FSDP分片到 6 张GPU上。
- 推理引擎：6 个共置vLLM实例，每张GPU一个。
- 共享存储：Amazon FSx for Lustre挂载在 /shared，用于LoRA同步和评测输出。
训练脚本中的关键参数与容错设计
训练脚本从VisGym SFT检查点出发。教程解释，Qwen3-VL-8B在VisGym演示数据上预训练后已经会解析迷宫图像并输出结构化的移动动作，GRPO只需要优化哪些动作序列能到达终点。设置trainer.placement.colocate_all=true后，vLLM推理引擎和FSDP策略工作节点共用同一批GPU：推理时GPU并行做推理，策略更新时它们集体做FSDP训练；不共置的话需要分开的GPU池，两个阶段之间互相等待，浪费算力。gpu_memory_utilization设为较保守的 0.45，原因是每张GPU要同时为FSDP分片和vLLM KV缓存留出空间。
可恢复性方面，脚本把完整训练状态每 20 步保存一次（ckpt_interval=20），包括模型权重、优化器状态、学习率调度和数据加载位置；resume_mode=latest让SkyRL从该路径下最近的检查点继续。hf_save_interval=20 每 20 步把LoRA适配器分片合并到头节点，保存为Hugging Face兼容格式；eval_interval=10 每 10 步在留出的 64 迷宫评测集上跑一次，跟踪成功率。
- n_samples_per_prompt=8：每个迷宫提示生成 8 条轨迹，用于计算组内优势。
- max_turns=15：每幕最多 15 步。
- ckpt_path建议指向不绑定单个节点的持久共享存储，如Amazon S3前缀或FSx挂载点，路径在多次运行间保持稳定，配合HyperPod节点故障自动替换后续跑。
- 完整检查点用于恢复训练状态，hf_save_interval导出的适配器用于推理，两者用途不同、并行运行。
环境准备与提交方式
教程给出的前置条件包括：一个由Amazon EKS编排的SageMaker HyperPod集群，至少 3 台ml.g7e.12xlarge和 1 台ml.r5d.16xlarge；集群内安装KubeRay operator、HyperPod Observability EKS附加组件和用于远程提交作业的HyperPod Ray Endpoint Operator；安装Amazon FSx for Lustre CSI驱动，并准备FSx for Lustre文件系统、对应的PersistentVolume和ReadWriteMany的PersistentVolumeClaim，供容器以 /shared挂载。还需要一个有权限连接HyperPod集群的SageMaker Studio域，以及安装toolkit-for-ray-on-sagemaker-ai Python包。
容器镜像基于NovaSky-AI的官方SkyRL基础镜像，SkyRL和VisGym都固定到具体commit SHA以保证构建可复现。集群在SageMaker Studio的Tasks标签页中创建，选RayCluster，头节点用ml.r5d.16xlarge，再加 3 个工作节点ml.g7e.12xlarge，镜像设为推送到Amazon ECR的URI。开启Remote endpoints后，提交作业和打开仪表盘都走IAM认证的URL，无需本地kubectl port-forward。
- 远程提交使用ray job submit --address sagemaker_ray://<cluster>/<namespace>，用AWS凭证完成认证，可以从笔记本或CI/CD流水线提交。
- 集群进入Running状态后，Actions菜单提供Open Ray Dashboard、Open Grafana和集群管理选项。
- 监控有两个界面：Ray Dashboard看作业级视图和每个actor的资源使用，Amazon Managed Grafana看基础设施和训练指标。