Accelerate multimodal RL training with SkyRL on Amazon SageMaker HyperPod

TL;DR · AI 摘要
Accelerate multimodal RL training with SkyRL on Amazon SageMaker HyperPod Artificial Intelligence Accelerate multimodal...
核心要点
- 主题聚焦:Accelerate multimodal RL training with SkyRL on
- 来源:AWS Machine Learning Blog,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
在 Amazon SageMaker HyperPod 上使用 SkyRL 加速多模态强化学习训练 | 人工智能
在 Amazon SageMaker HyperPod 上使用 SkyRL 加速多模态强化学习训练
强化学习(RL)的微调阶段正在成为构建强大语言模型代理的标准步骤。模型通过生成轨迹、接收奖励并根据结果更新策略,学习在多个步骤序列中进行推理和行动。要在大规模场景下运行,每个训练运行需要数百小时 GPU 的 rollout 计算,这需要持久的集群基础设施。该基础设施需要支持长时间作业、在硬件故障后恢复而不丢失进度,并提供对训练动态的可视化。
Amazon SageMaker HyperPod 为 Amazon Elastic Kubernetes Service (Amazon EKS) 上的大规模机器学习(ML)工作负载提供了这种基础设施。通过其集群弹性功能,它会持续监控节点健康状况并自动替换故障节点,从而确保硬件故障不会导致集群崩溃。结合检查点机制,训练任务可以从上次保存的步骤继续执行,而无需从头开始。这对于长时间的多节点强化学习任务至关重要,因为单个硬件故障否则会导致数小时的 rollout 进度丢失。结合 HyperPod 上的 Ray 能力,您可以从 SageMaker Studio 创建 Ray 集群,通过安全连接远程提交任务,并通过 HyperPod Observability EKS 插件为您预置的 Amazon Managed Grafana 仪表板监控训练过程。
在本文中,我们将展示如何利用这些功能,使用开源 RL 框架 SkyRL 在 SageMaker HyperPod 上训练 Qwen3-VL-8B 视觉语言模型,通过组相对策略优化(GRPO)方法在视觉迷宫中导航。从 VisGym SFT 检查点(监督微调的起点)开始,HyperPod 上的 GRPO 微调在固定 64 迷宫评估集上将迷宫解决率从 43.75% 提高到 95% 以上。
先决条件
要跟随本操作指南,您需要:
- 至少包含 3 个 ml.g7e.12xlarge 实例和 1 个 ml.r5d.16xlarge 实例的 SageMaker HyperPod 集群,该集群使用 Amazon EKS 进行编排。
- 在集群中安装以下 Kubernetes 操作符:KubeRay 操作符、HyperPod Observability EKS 插件和 HyperPod Ray 端点操作符(用于远程任务提交)。请参阅 HyperPod 上的 Ray 入门指南。
- 在集群中安装 Amazon FSx for Lustre CSI 驱动程序。您还需要一个 Amazon FSx for Lustre 文件系统、一个由该文件系统支持的 PersistentVolume,以及一个 Pod 可挂载的 PersistentVolumeClaim(ReadWriteMany)。训练任务会在 /shared 路径下使用该存储进行检查点存储、低秩适配(LoRA)适配器同步和评估输出。
- 具有连接到 HyperPod 集群权限的 SageMaker Studio 域。请参阅 为 Ray 设置 SageMaker Studio。
- 安装 toolkit-for-ray-on-sagemaker-ai Python 包。
背景
本节将回顾训练背后强化学习的概念以及操作指南中使用的集群拓扑结构。
多轮强化学习和 GRPO
(此处为代码块内容,保持原样未翻译)标准单回合强化学习(RL)为单个模型输出分配奖励。多回合RL则是在整个步骤序列上训练智能体,智能体观察状态、采取行动、获得反馈,并进入下一个状态。策略从整个回合中积累的奖励进行学习,而不是从任何单一步骤中学习。
以二维迷宫导航的示例问题为例。一个回合是单次迷宫运行,每个回合对应一次移动:模型查看当前迷宫画面,选择方向或决定停止,环境返回更新后的视图。奖励稀疏,因此只有在实际移动次数限制内到达目标时模型才会获得1.0的奖励,其他情况均无奖励。由于移动是否合理取决于周围动作,因此不存在逐次移动的答案指南。
这就是SkyRL的组相对策略优化(GRPO)发挥作用的地方。对于每个起始位置,智能体在当前策略下多次运行迷宫,GRPO将这些运行结果相互比较,强化那些优于组平均表现的运行,同时抑制表现落后的运行。这种组内比较构成了全部训练信号,使GRPO无需单独的评论家或价值模型即可工作。
训练拓扑
此处讨论的解决方案在HyperPod Ray集群上运行SkyRL,包含3个GPU工作节点和1个CPU头节点。SkyRL在同一GPU上实现推理和训练:vLLM引擎生成回合(完整迷宫回合),而使用全分片数据并行(FSDP)分片的策略模型处理梯度更新。每次优化器步骤后,更新的LoRA适配器权重通过Amazon FSx for Lustre共享存储从训练节点同步到推理引擎。
我们使用的实例类型如下。只要工作节点具有足够的GPU内存容纳模型,其他GPU实例和集群规模也可正常工作:
- 工作节点:3x ml.g7e.12xlarge(每台配备2块NVIDIA RTX PRO 6000 Blackwell GPU,共6块GPU)。
- 头节点:ml.r5d.16xlarge(512 GB内存,管理Ray GCS、仪表板和LoRA适配器整合)。
- 策略模型:使用PyTorch FSDP在6块GPU上分片的Qwen3-VL-8B LoRA模型(秩32)。
- 回合引擎:6个共置的vLLM实例,每个GPU对应一个实例。
- 共享存储:/shared目录下的Amazon FSx for Lustre,用于LoRA同步和评估输出。
HyperPod提供集群基础设施:Ray集群通过SageMaker Studio创建,作业提交使用sagemaker_ray://协议,训练指标通过HyperPod Observability插件自动流入预构建的Amazon Managed Grafana仪表板。
图1:Amazon SageMaker HyperPod上的RayCluster拓扑,包含1个CPU头节点和3个GPU工作节点,这些节点通过共享的Amazon FSx for Lustre文件系统共置FSDP策略分片和vLLM回合引擎
解决方案概述
以下步骤逐步说明如何准备训练环境、启动集群、运行作业、监控进度以及部署训练后的模型。
步骤1:准备容器镜像
为了快速入门,请使用以下Dockerfile构建包含SkyRL、VisGym及其依赖项的容器镜像。这是下一步在HyperPod上启动Ray集群时将指定的镜像。该镜像基于官方NovaSky-AI SkyRL基础镜像,并将SkyRL和VisGym固定到特定提交的SHA哈希值,以确保构建过程可复现:
FROM novaskyai/skyrl-train-ray-2.57.0-py3.12-cu13.0ENV HF_HUB_ENABLE_HF_TRANSFER=1 \
QWEN_VL_MODEL=Qwen/Qwen3-VL-8B-Instruct \
UV_PROJECT_ENVIRONMENT=/home/ray/anaconda3
# 将 SkyRL 的完整 FSDP 堆栈集成到系统 Python 的 Ray 环境中(uv .venv 对 `ray start` 不可见)。
# 固定到特定提交 SHA 以确保构建可复现。
ARG SKYRL_REF=4298730b55bb01fe1b711662df53dca42a3b7615
RUN git clone https://github.com/NovaSky-AI/SkyRL.git /home/ray/skyrl \
&& cd /home/ray/skyrl && git checkout ${SKYRL_REF} \
&& cd /home/ray/skyrl/skyrl-train \
&& uv sync --active --extra fsdp \
&& /home/ray/anaconda3/bin/python -c \
"import ray, torch, vllm, transformers, flash_attn; \
from vllm_router.launch_router import launch_router; \
print('skyrl stack OK', torch.__version__, vllm.__version__)"
# uv sync 会移除 Ray 仪表板的附加功能;重新安装 ray[default] 以启用完整仪表板。
RUN uv pip install --python /home/ray/anaconda3/bin/python "ray[default]==2.57.0" \
&& /home/ray/anaconda3/bin/python -c \
"from ray.dashboard.optional_deps import aiohttp"
# VisGym 迷宫环境和数据集生成器。
ARG VISGYM_REF=184fbd5e5dc81e32c8b944d9e40ac54dad62e3f2
RUN git clone https://github.com/anyscale/VisGym.git /home/ray/visgym \
&& cd /home/ray/visgym && git checkout ${VISGYM_REF} \
&& uv pip install --python /home/ray/anaconda3/bin/python -e . "pygame==2.6.1"
ENV FI_PROVIDER=efa FI_EFA_USE_DEVICE_RDMA=1 NCCL_PROTO=simple NCCL_DEBUG=INFO
WORKDIR /workspace
CMD ["/bin/bash"]构建镜像并推送到您账户中的 Amazon Elastic Container Registry(Amazon ECR)仓库。记下完整的镜像 URI,因为在下一步创建 Ray 集群时会用到:
ACCOUNT=$(aws sts get-caller-identity --query Account --output text) REGION=us-west-2 IMAGE_URI="${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com/ray/skyrl-visgym:latest"
aws ecr get-login-password --region ${REGION} | \ docker login --username AWS --password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com
docker build -t skyrl-visgym . docker tag skyrl-visgym ${IMAGE_URI} docker push ${IMAGE_URI}
echo "Image URI: ${IMAGE_URI}"
### 第 2 步:从 SageMaker Studio 启动 Ray 集群
导航到 SageMaker Studio,选择 HyperPod,选择您的集群,然后转到任务标签页。在任务类型列表中选择 RayCluster,然后选择 创建 Ray 集群。
在创建表单中,将集群命名为 skyrl-visgym,设置主节点实例类型为 ml.r5d.16xlarge,并添加三个使用 ml.g7e.12xlarge 的工作节点。将容器镜像设置为第 1 步中推送的 IMAGE_URI。
此处列出的实例类型是我们此次操作所使用的类型。其他实例类型也可以工作,但请注意主节点的一个约束条件:需要大内存。主节点在每个检查点保存时会从 GPU 工作节点汇总 LoRA 适配器碎片,这会暂时将完整的适配器权重集加载到 CPU 内存中。我们使用 ml.r5d.16xlarge 是因为它的大内存容量(512 GB RAM)可以满足这一需求。
#### 挂载 Amazon FSx for Lustre
要连接您的 Amazon FSx 文件系统,请在创建表单右上角选择 YAML 按钮切换到原始清单编辑器,然后在头节点和工作节点的 Pod 规格中添加卷并挂载。每个 Pod 的相关部分如下所示:containers:
- name: ray-head # 或 ray-worker
volumeMounts:
- name: shared
mountPath: /shared
volumes:
- name: shared
persistentVolumeClaim:
claimName: <your-fsx-pvc-name>将 <your-fsx-pvc-name> 替换为由您的 Amazon FSx 文件系统支持的 PersistentVolumeClaim 的名称。配置完成后,/shared 目录将在集群所有节点上可用,训练任务可以从 Pod 中读写检查点、LoRA 权重和评估输出。
启用远程端点功能,您可以通过无需本地 kubectl 端口转发的方式提交作业和访问仪表板。集群会为这两种功能生成 IAM 认证的 URL。
图 2:在 SageMaker Studio 中创建 Ray 集群的表单,已开启远程端点用于作业提交和仪表板访问
当集群状态变为 Running 后,任务标签页中的操作菜单将提供打开 Ray 仪表板、打开 Grafana 和集群管理选项。
图 3:SageMaker Studio 任务标签页中处于 Running 状态的 skyrl-visgym Ray 集群,操作菜单已展开
第 3 步:准备训练脚本
将以下内容保存为工作目录中的 train_job.sh。该脚本首次运行时会下载 SFT 检查点并生成数据集(两者都会存储到 Amazon FSx,因此在多次运行中会保留),然后启动 GRPO 训练任务。
SFT 检查点为 GRPO 提供了良好的起点:Qwen3-VL-8B 已经在 VisGym 演示数据上进行了预训练,能够解析迷宫图像并生成结构化移动动作,因此 GRPO 只需要优化哪些序列能到达目标。
通过设置 trainer.placement.colocate_all=true,vLLM 滚动引擎和 FSDP 策略工作节点共享同一 GPU。在滚动阶段,GPU 并行执行推理;在策略更新阶段,它们共同执行 FSDP 训练。lora_sync_path 指向 Amazon FSx,因此每次优化步骤后,节点上的推理引擎可以立即看到更新后的适配器权重。如果没有共置,需要为训练和推理分配独立的 GPU 池,不同阶段会相互等待,形成浪费计算资源的乒乓模式。共置通过让训练和推理在相同硬件上交替运行,避免了这种空闲时间。这就是为什么 gpu_memory_utilization=0.45 设置得较为保守:每个 GPU 需要同时为 FSDP 分片和 vLLM KV 缓存保留空间。
还有一些其他参数值得留意。n_samples_per_prompt=8 控制 GRPO 每个迷宫提示生成多少条滚动轨迹来计算群体优势。max_turns=15 将每局游戏的移动次数限制为 15 次。hf_save_interval=20 每 20 步将 LoRA 适配器分片汇总到头节点,并保存一个兼容 Hugging Face 的检查点。eval_interval=10 每 10 步运行一次保留的 64 迷宫评估,以便您跟踪训练过程中的解题率。
该任务还会保存完整的训练检查点,以便在中断后恢复。设置 ckpt_interval=20 会在每 20 步将完整的训练状态保存到 ckpt_path。该状态包含模型权重、优化器状态、学习率计划和数据加载器位置。resume_mode=latest 会指示 SkyRL 在任务启动时从该路径下的最新检查点恢复。请将 ckpt_path 指向持久化共享存储,且不绑定到单个节点,例如 Amazon Simple Storage Service (Amazon S3) 前缀或您的 Amazon FSx 挂载点。保持路径在多次运行中稳定,以便重启任务时能定位到检查点。这就是与 HyperPod 集群弹性功能的配合方式。当节点发生故障时,HyperPod 会自动检测并替换故障节点,当您重新提交任务时,它会从上次保存的步骤继续执行,而不是重新开始。此处保存的完整检查点用于恢复训练状态,而 hf_save_interval 导出的则是可用于推理的 LoRA 适配器,因此两者并行运行但服务于不同目的。
#!/usr/bin/env bash
GRPO 从 VisGym SFT 检查点在 maze_2d/easy 上进行微调。
set -euxo pipefail cd /home/ray/skyrl export HF_HUB_ENABLE_HF_TRANSFER=0 export SKYRL_RAY_PG_TIMEOUT_IN_S=600 RUN_ID=$(date +%Y%m%d-%H%M%S) EXPORT_PATH="/shared/runs/${RUN_ID}-train"
ENV_ID=maze_2d/easy TRAIN_DIR=/tmp/visgym_train_256 EVAL_DIR=/tmp/visgym_eval_seeded SFT_CKPT=/shared/models/visgym_sft_mixed_qwen3vl
if [ ! -f "$SFT_CKPT/config.json" ]; then echo "=== 下载 SFT 检查点 ===" mkdir -p "$SFT_CKPT" python -c " from huggingface_hub import snapshot_download snapshot_download(repo_id='VisGym/visgym_model', allow_patterns='mixed_qwen3vl/*', local_dir='$SFT_CKPT', local_dir_use_symlinks=False) import shutil, os; src='$SFT_CKPT/mixed_qwen3vl' [shutil.move(os.path.join(src,f),'$SFT_CKPT') for f in os.listdir(src)]; os.rmdir(src) " fi
python examples/train/visgym/dataset.py --env_id "$ENV_ID" --num_rows 256 --output_dir "$TRAIN_DIR" python examples/train/visgym/dataset.py --env_id "$ENV_ID" --num_rows 64 --seed --output_dir "$EVAL_DIR"
python examples/train/visgym/entrypoint.py \ --env_variant sft \ data.train_data="['$TRAIN_DIR/train.parquet']" \ data.val_data="['$EVAL_DIR/train.parquet']" \ trainer.algorithm.advantage_estimator="grpo" \ trainer.policy.model.path="$SFT_CKPT" \ trainer.policy.model.lora.rank=32 \ trainer.policy.model.lora.alpha=32 \ trainer.policy.model.lora.lora_sync_path="/shared/lora" \ trainer.placement.colocate_all=true \ trainer.strategy=fsdp \ trainer.placement.policy_num_nodes=3 \ trainer.placement.policy_num_gpus_per_node=2 \ trainer.placement.ref_num_nodes=3 \ trainer.placement.ref_num_gpus_per_node=2 \ trainer.ref.fsdp_config.cpu_offload=false \ generator.inference_engine.num_engines=6 \ generator.inference_engine.tensor_parallel_size=1 \ generator.inference_engine.gpu_memory_utilization=0.45 \ generator.inference_engine.engine_init_kwargs.max_model_len=16000 \ environment.env_class=visgym \ trainer.epochs=20 \ trainer.train_batch_size=24 \ trainer.policy_mini_batch_size=12 \ trainer.micro_forward_batch_size_per_gpu=1 \ trainer.micro_train_batch_size_per_gpu=1 \ trainer.update_epochs_per_batch=1 \ trainer.max_prompt_length=2048 \ generator.sampling_params.max_generate_length=1024 \ generator.sampling_params.temperature=0.7 \ generator.max_turns=15 \ generator.max_input_length=8192 \ generator.n_samples_per_prompt=8 \ generator.vision_language_generator=true \ generator.batched=false \ trainer.remove_microbatch_padding=false \ trainer.algorithm.use_kl_loss=false \ trainer.policy.optimizer_config.lr=3.0e-6 \ trainer.eval_interval=10 \ trainer.eval_before_train=true \ trainer.ckpt_interval=20 \ trainer.hf_save_interval=20 \ trainer.logger="console" \ trainer.project_name="vlm_maze_2d_easy" \ trainer.run_name="sft_grpo_${RUN_ID}" \ trainer.resume_mode=latest \ trainer.log_path="/tmp/skyrl-logs" \ trainer.dump_eval_results=true \ trainer.export_path="$EXPORT_PATH" \ trainer.ckpt_path="s3://<your-bucket>/skyrl-visgym/ckpts/sft-grpo"
### 第4步:远程提交训练任务
当安装了toolkit-for-ray-on-sagemaker-ai后,Ray的标准Jobs CLI会通过集群的安全端点进行身份验证,使用包注册的sagemaker_ray://地址方案。该库会使用您的AWS凭证向Ray端点进行身份验证,因此您无需手动操作。这样,您可以从笔记本电脑、CI/CD流水线或具有AWS凭证的环境中提交和跟踪任务,无需kubectl端口转发,也无需直接连接到集群的网络路径。
首先,对EKS集群进行身份验证:
aws eks update-kubeconfig --name <eks-cluster-name> --region us-west-2
然后提交任务,将当前目录作为工作目录传递,以便将train_job.sh上传到集群头节点:
地址格式:sagemaker_ray://<ray-cluster-name>/<namespace>
ray job submit \ --address sagemaker_ray://skyrl-visgym/default \ --submission-id sft-train \ --working-dir . \ -- bash train_job.sh
提交后,使用相同地址跟踪进度:
列出任务并检查状态
ray job list --address sagemaker_ray://skyrl-visgym/default
流式传输日志
ray job logs sft-train \ --address sagemaker_ray://skyrl-visgym/default --follow
您还可以在SageMaker Studio的任务标签页中跟踪任务,或从集群操作菜单直接打开Ray仪表板,查看完整的任务视图及每个Actor的资源使用情况。
### 第 5 步:监控训练进度
HyperPod 提供两种监控方式:用于作业级可视化的 Ray Dashboard,以及用于基础设施和训练指标的 Amazon Managed Grafana。两者都可以通过 SageMaker Studio 的任务标签页直接访问。
#### Ray Dashboard
在 SageMaker Studio 的任务标签页中,选择“打开 Ray Dashboard”。这将自动生成一个临时的经过身份验证的 URL。
您也可以通过 HyperPod CLI 生成 URL:
hyp create ray-dashboard-connection \ --cluster-name <ray-cluster-name> \ --namespace <kubernetes-namespace>
该命令会返回一个预签名 URL。在浏览器中打开该 URL 即可查看 Ray 仪表板。会话有效期最长为六小时。有关详细信息,请参阅 HyperPod 文档中的“生成仪表板连接 URL”。
下图显示了作业视图,包含正在运行的作业、当前步骤以及每个工作节点的资源使用情况。
图 4:Ray Dashboard 的作业视图,显示正在运行的训练作业和每个工作节点的 GPU 使用情况
#### HyperPod 可观测性仪表板
在任务标签页中,选择“打开 Grafana”。HyperPod 可观测性 EKS 插件会在 Amazon Managed Grafana 中预置四个 Ray 仪表板:Ray Core、Ray Data、Ray Train 和 Ray Serve。这四个仪表板都位于 Ray 文件夹下,并支持按集群名称进行筛选。以下是核心仪表板的一部分,显示训练过程中 CPU、GPU 和内存的使用情况。
图 5:Amazon Managed Grafana Ray Core 仪表板面板,显示训练期间的 CPU、GPU 和内存使用情况
#### 追踪评估准确率
SkyRL 每隔 eval_interval=10 步会对固定的 64 迷宫测试集执行一次评估,并将 eval/all/pass_at_1 记录到控制台。您可以在作业日志中使用 grep 查找该信息:
ray job logs sft-train \ --address sagemaker_ray://skyrl-visgym/default | grep "eval/all/pass_at_1"
在我们的实验中,模型在第 100 步左右达到 75% 的解谜率,并在第 160 步达到峰值 96.875%(62/64 迷宫),而 GRPO 后训练之前的基线为 43.75%(28/64 迷宫)。您的结果会根据超参数和迷宫配置有所不同。一旦解谜率达到目标,该步骤的 LoRA 适配器即可用于推理。检查点每 20 步保存一次,路径为 /shared/runs/<run_id>/global_step_<N>/policy/adapter_model.safetensors。
### 第 6 步:部署训练好的模型用于推理
训练完成后,您部署的工件是一个 LoRA 适配器,而不是完整的模型。Ray Serve 会在请求时按需加载该适配器。唯一的要求是适配器的存储位置。Ray Serve 的动态 LoRA 加载器会从云存储(如 Amazon S3)读取适配器,因此首先需要将适配器上传到 S3 前缀。将训练期间选择的检查点步骤中的适配器复制到该前缀:
aws s3 cp --recursive \ /shared/runs/<run_id>/global_step_N/policy/ \ s3://<your-bucket>/lora-adapters/maze-grpo/
每个适配器在该前缀下都有自己的子目录,该子目录名称(本例中为 maze-grpo)即为端点启动后请求适配器时使用的名称。
#### 在 Ray 集群上使用 Ray Serve 进行服务
要托管适配器,请在基于 AWS Deep Learning Container for Ray Serve LLM 构建的 Ray 集群上运行 Ray Serve。该容器集成了 Ray Serve、ray[llm] 堆栈和 vLLM。借助它,您可以使用内置的 ray.serve.llm:build_openai_app 构建器创建一个兼容 OpenAI 的端点,且无需自定义镜像。我们建议在 RayService 上运行推理,KubeRay 会将其协调为自己的 Ray 集群(参见 KubeRay 文档)。
RayService 通过 serveConfigV2 规范描述其 Serve 应用,该规范中 ray.serve.llm:build_openai_app 构建器为每个基础模型接受一个 llm_configs 条目,如下配置所示:
serveConfigV2: | applications:
- name: maze-vlm
route_prefix: / import_path: ray.serve.llm:build_openai_app args: llm_configs:
- model_loading_config:
model_id: visgym-qwen3vl
基础 SFT 模型位于 FSx
model_source: /shared/models/visgym_sft_mixed_qwen3vl lora_config:
S3 中的适配器前缀
dynamic_lora_loading_path: s3://<your-bucket>/lora-adapters max_num_adapters_per_replica: 1 engine_kwargs: enable_lora: true
匹配训练时的 LoRA 秩
max_lora_rank: 32 max_loras: 1 max_model_len: 16000 deployment_config: autoscaling_config: { min_replicas: 1, max_replicas: 1 }
在此配置中,model_source 指向 Amazon FSx 挂载点上的基础 SFT 模型,而 dynamic_lora_loading_path 指向您在上一步中填充的 S3 前缀。将 max_lora_rank 设置为训练时使用的相同 LoRA 秩。最后,请确保 Ray Serve 副本能够获取 AWS 凭据以从您的 S3 存储桶读取适配器。在 Amazon EKS 上,推荐的实现方式是 Amazon EKS Pod 身份。
#### 每个请求的动态 LoRA 加载
配置完成后,单个部署将同时服务基础模型和存储在 S3 前缀下的所有适配器,您可以通过每个请求的 model 字段选择运行哪一个:
- 将 model 设置为 visgym-qwen3vl 以独立运行基础 SFT 模型。
- 将 model 设置为 visgym-qwen3vl:maze-grpo 以在该基础模型上应用 GRPO 适配器。ID 遵循 <base-model-id>:<adapter-name> 的格式,其中适配器名称是您在 dynamic_lora_loading_path 下创建的子目录。
首次请求适配器时,Ray Serve 会将其从 Amazon S3 下载到副本并缓存,因此后续所有请求都将复用已加载的权重而无需重新下载。由于端点支持 OpenAI API,您可以使用兼容 OpenAI 的客户端进行调用。有关完整的配置选项,请参阅 Ray Serve LLM 文档和多 LoRA 部署指南。
适配器部署完成后,模型可以独立运行完整的迷宫回合,每次转弯时输入当前视图并返回下一步动作,直到达到目标。驱动此流程的循环(构建提示、编码迷宫图像、解析动作、推进环境)与 SkyRL 和 VisGym 用于推理的循环相同。将该环境指向已部署的端点,而非围绕原始客户端重新构建。
以下是示例结果:训练后的模型端到端导航两个迷宫:
图6:微调后的模型端到端解决两个迷宫,每回合移动一次,直到到达目标
## 清理资源
完成操作引导后,请清理创建的资源以避免产生费用。在SageMaker Studio中打开任务选项卡,选择skyrl-visgym Ray集群,从操作菜单中选择删除。如果你为训练适配器单独创建了RayService,也请使用kubectl delete rayservice <name>命令一并删除。要释放GPU资源本身,可以将本次操作引导中添加的HyperPod实例组进行缩容,或从Amazon SageMaker AI控制台删除HyperPod集群。如果不再需要SageMaker Studio域名,也可以从SageMaker AI控制台将其删除。
## 结论
在本文中,我们演示了在Amazon SageMaker HyperPod上进行端到端多模态强化学习训练的工作流程:构建自定义容器镜像、从SageMaker Studio启动Ray集群、从VisGym SFT检查点开始为GRPO提供强初始化、使用sagemaker_ray://协议提交任务、通过HyperPod可观测性附加组件提供的Ray仪表板和Grafana仪表板监控评估准确率,并在达到目标解决率后托管训练好的适配器用于推理。整个工作流程运行在Amazon SageMaker HyperPod提供的弹性、自愈计算基础设施上。
相同的模式也适用于SkyRL工作负载或其他基于Ray的强化学习框架。HyperPod基础设施、Studio控制台体验和Amazon FSx共享存储可与使用标准Ray API的框架配合使用。
要开始使用,请参阅Amazon SageMaker HyperPod文档和HyperPod上Ray的入门指南。
## 作者简介
'"`
/think