«Лабиринт вместо разметки»: AWS провела GRPO-дообучение Qwen3-VL-8B на SageMaker HyperPod

Что сделали

Разбор описывает полный цикл многоходового RL на Amazon SageMaker HyperPod: сборку контейнера, запуск Ray-кластера из SageMaker Studio, само обучение и раздачу полученного адаптера для инференса.

Модель — Qwen3-VL-8B, стартовая точка — SFT-чекпойнт VisGym, а задача агента — проходить двумерные лабиринты. GRPO-дообучение на HyperPod подняло решаемость с 43,75 процента до более чем 95 процентов на фиксированном наборе из 64 лабиринтов.

Инфраструктуру даёт HyperPod на Amazon Elastic Kubernetes Service (Amazon EKS): благодаря функциям отказоустойчивости кластера он следит за состоянием экземпляров и автоматически заменяет отказавшее оборудование на ходу.

В связке с чекпойнтингом это значит, что задание продолжается с последнего сохранённого шага, а не начинается с нуля — для длинных многоузловых прогонов, где один отказ железа стоил бы часов роллаутов, это принципиально.

Дополнительно Ray-кластер создаётся прямо из SageMaker Studio, задание уходит по протоколу sagemaker_ray://, а метрики обучения попадают в готовые дашборды Amazon Managed Grafana, которые разворачивает HyperPod Observability EKS add-on.

Многоходовой RL и GRPO

Обычный одноходовой RL выдаёт награду за один ответ модели, а многоходовой обучает агента на последовательности шагов: он наблюдает состояние, действует, получает обратную связь и переходит к следующему состоянию, а политика учится по награде, накопленной за весь эпизод.

В лабиринте эпизод — это один проход, а ход — один шаг: модель смотрит на текущую картинку, выбирает направление или решает остановиться, среда присылает обновлённый вид. Награда разреженная — 1.0 начисляется только за достижение цели в пределах лимита ходов. Разметки «по шагам» не существует, потому что качество отдельного хода зависит от соседних.

Именно здесь работает Group Relative Policy Optimization (GRPO): для каждой стартовой позиции агент прогоняет лабиринт несколько раз под текущей политикой, а GRPO сравнивает эти прогоны между собой — усиливает те, что обошли среднее по группе, и придавливает отстающие.

Это сравнение внутри группы и есть весь сигнал обучения, поэтому отдельная модель-критик или модель ценности не нужна.

Топология обучения

Схема такая: Ray-кластер HyperPod из трёх GPU-воркеров и CPU-head, а SkyRL совмещает инференс и обучение на одних и тех же GPU — движки vLLM генерируют роллауты, то есть целые эпизоды прохождения, а политика, шардированная через Fully Sharded Data Parallel (FSDP), считает обновления градиентов.

Конкретика по железу: воркеры 3 × ml.g7e.12xlarge, на каждом по две NVIDIA RTX PRO 6000 Blackwell, всего шесть GPU; head — ml.r5d.16xlarge с 512 ГБ памяти; политика Qwen3-VL-8B с LoRA ранга 32, разложенная по шести GPU через PyTorch FSDP; шесть совмещённых инстансов vLLM, по одному на GPU.

Общее хранилище — Amazon FSx for Lustre, смонтированный в /shared: через него идёт синхронизация LoRA и запись результатов оценки.

Совмещение убирает простои: без него пулы GPU для обучения и инференса ждали бы друг друга между фазами, а с ним они работают по очереди на одном и том же железе. Поэтому gpu_memory_utilization выставлен консервативно, на 0.45 — каждому GPU нужен запас одновременно и под FSDP-шард, и под KV-кэш vLLM.

После каждого шага оптимизатора обновлённые веса LoRA-адаптера синхронизируются с обучающих рангов в инференс-движки через /shared.

Контейнер и запуск кластера

Образ собирается от novaskyai/skyrl-train-ray-2.57.0-py3.12-cu13.0: SkyRL и VisGym ставятся из закреплённых коммитов, чтобы сборка была воспроизводимой, а полный FSDP-стек SkyRL кладётся в системный python, который видит ray start — отдельный uv-venv для этого не годится.

Дальше образ уходит в Amazon Elastic Container Registry (Amazon ECR), в SageMaker Studio создаётся RayCluster с именем skyrl-visgym, head-инстансом ml.r5d.16xlarge и тремя воркерами ml.g7e.12xlarge.

Том Amazon FSx for Lustre подключается через PersistentVolumeClaim к спекам head- и worker-подов, чтобы /shared был доступен на каждом узле кластера и задание могло читать и писать чекпойнты, веса LoRA и результаты оценки.

Из требований к окружению: кластер HyperPod с оркестрацией Amazon EKS минимум на три ml.g7e.12xlarge и один ml.r5d.16xlarge, установленные операторы KubeRay, HyperPod Observability EKS add-on и HyperPod Ray Endpoint Operator, драйвер FSx for Lustre CSI с файловой системой и PVC, домен SageMaker Studio с правами на подключение к кластеру и пакет toolkit-for-ray-on-sagemaker-ai.

Большая память head-узла нужна не для красоты: при каждом сохранении чекпойнта он консолидирует шарды LoRA-адаптера с GPU-воркеров и на короткое время загружает полный набор весов адаптера в CPU-память.

Параметры задания

Ключевые ручки обучения: n_samples_per_prompt=8 задаёт число роллаутов на промпт лабиринта, по которым считается групповое преимущество, max_turns=15 ограничивает эпизод пятнадцатью ходами, а eval_interval=10 прогоняет отложенную оценку каждые десять шагов, чтобы видеть решаемость по ходу обучения.

hf_save_interval=20 раз в двадцать шагов собирает шарды адаптера на head-узле и сохраняет чекпойнт в формате, совместимом с Hugging Face, а ckpt_interval=20 с той же частотой пишет полное состояние обучения — веса модели, состояние оптимизатора, расписание learning rate и позицию в даталоадере.

resume_mode=latest говорит SkyRL подхватывать самый свежий чекпойнт по указанному пути, поэтому ckpt_path должен вести на долговечное общее хранилище вроде префикса Amazon S3 или тома FSx и не меняться между запусками — иначе повторный запуск не найдёт своё состояние.

Обучение шло двадцать эпох, learning rate — 3.0e-6, а полное состояние сохранялось именно для того, чтобы связать чекпойнтинг SkyRL с самовосстановлением HyperPod: узел заменяется автоматически, задание перезапускается и продолжает с последнего шага.

Результат и мониторинг

Отложенная оценка по 64 лабиринтам каждые десять шагов показывает динамику: примерно 75 процентов решаемости к шагу 100 и пик 96,875 процента (62 лабиринта из 64) на шаге 160 — против базовых 43,75 процента (28 из 64) до GRPO-дообучения.

Смотреть за этим можно в двух местах: Ray Dashboard даёт видимость уровня задания, а Amazon Managed Grafana — инфраструктурные и обучающие метрики. Add-on Observability разворачивает четыре готовых дашборда Ray, и оба интерфейса открываются прямо из вкладки Tasks в SageMaker Studio.

Когда решаемость достигает целевой, адаптер LoRA с нужного шага уже готов к инференсу — отдельного этапа «собрать модель» не требуется.

Что уходит в инференс

Артефакт развёртывания — не полная модель, а LoRA-адаптер: динамический загрузчик Ray Serve читает адаптеры из облачного хранилища, поэтому адаптер выбранного шага сначала кладут в префикс Amazon S3.

Одно развёртывание обслуживает и базовую модель, и все адаптеры из префикса, а какой именно запускать, выбирает имя адаптера в запросе. Endpoint говорит на OpenAI-совместимом API, поэтому вызывать его можно любым совместимым клиентом, а загруженный адаптер кэшируется на реплике и при следующих запросах повторно не скачивается.

Дальше модель проходит лабиринт сама: на каждом ходу принимает текущий вид и возвращает следующий шаг до достижения цели. Цикл, который за этим стоит, — сборка промпта, кодирование картинки лабиринта, разбор действия, шаг среды — тот же, что SkyRL и VisGym используют на роллаутах.