SkyRL, открытый фреймворк обучения с подкреплением, запускается на Amazon SageMaker HyperPod и пост-обучает мультимодальные модели без ручного администрирования кластера. Amazon показала сквозной сценарий: Qwen3-VL-8B учится проходить визуальные лабиринты VisGym методом GRPO, стартуя с SFT-чекпоинта, и поднимает долю решённых задач на фиксированном наборе из 64 лабиринтов с 43,75% до более чем 95%.
Работает это через Ray: кластер поднимается прямо из SageMaker Studio, задание уходит удалённо по защищённому соединению, чекпоинты и LoRA-адаптеры лежат в общей файловой системе Amazon FSx for Lustre. Кластер при этом остаётся под управлением AWS и сам меняет вышедшие из строя узлы.
Ниже разобрано, что именно требуется для такого прогона, как устроен цикл внутри GPU, где смотреть за прогрессом и в каких случаях схема не окупается.
Что такое SkyRL и зачем его запускать на SageMaker HyperPod
SkyRL это открытый RL-фреймворк для пост-обучения языковых и мультимодальных моделей. В сценарии Amazon он дообучает Qwen3-VL-8B, vision-language модель на 8 млрд параметров, методом GRPO. Инфраструктурой выступает Amazon SageMaker HyperPod.
HyperPod это управляемый кластерный сервис AWS с оркестрацией Amazon EKS. Он снимает с команды ручную работу, которая обычно съедает дни при многоузловом обучении: развёртывание узлов, постоянный контроль их состояния, замену вышедшего из строя железа, подключение файловых систем и мониторинга. Для RL это принципиально, потому что одна задача идёт часами и состоит из тысяч циклов генерации ответов и обновления политики. Упавший на середине узел без автоматической замены и чекпоинтов означает потерю всего прогона.
Связка SkyRL и HyperPod закрывает полный цикл. Ray-кластер поднимается из SageMaker Studio, задание отправляется удалённо по защищённому соединению, прогресс виден в Ray Dashboard и готовых дашбордах Amazon Managed Grafana, а результаты обучения хранятся в общей быстрой файловой системе.
RL отличается от supervised fine-tuning механикой обучения. При SFT модель подгоняют под готовые правильные ответы, при RL она учится на собственных генерациях и получает сигнал от reward-функции. GRPO (Group Relative Policy Optimization) обходится без отдельной value-модели: для каждой задачи генерируется группа ответов, их награды сравниваются между собой, и поведение, выигрышное относительно группы, усиливается. По памяти такой подход дешевле классического PPO и проще в настройке.
Практический результат: от 43,75% к более чем 95% на VisGym
Задача в демонстрации это навигация в визуальных лабиринтах VisGym. Модель получает изображение лабиринта и должна выдать последовательность ходов, приводящую к выходу. Для мультимодального RL такой тест удобен: результат проверяется автоматически, размечать награду вручную не нужно, а успех или провал виден однозначно.
Точка старта это SFT-чекпоинт VisGym, уже знакомый с форматом задачи. На нём доля решённых лабиринтов составляет 43,75%. После GRPO-пост-обучения на HyperPod она превышает 95% на том же фиксированном наборе из 64 лабиринтов. Описание сценария Amazon приводит эти цифры как результат конкретного прогона.
Что здесь важно для планирования. Набор из 64 задач фиксирован, поэтому метрика измеряет качество на известном распределении, а не устойчивость к произвольным новым лабиринтам. Это демонстрация стека, а не универсальный бенчмарк: ждать такого же скачка на другой задаче, другом датасете или другой базовой модели нет оснований. Практический вывод скромнее и полезнее: связка SkyRL и HyperPod отрабатывает полный RL-цикл на мультимодальной модели и доводит её до высокой точности в среде с проверяемым результатом.
Требования к инфраструктуре: железо, операторы и файловая система
Сценарий рассчитан на уже существующий кластер, а не на запуск с одной рабочей станции. Минимальный набор выглядит так:
- Кластер SageMaker HyperPod с оркестрацией Amazon EKS.
- Не менее трёх инстансов ml.g7e.12xlarge и один ml.r5d.16xlarge.
- KubeRay operator, который запускает Ray-кластер и управляет подами.
- HyperPod Observability EKS add-on, разворачивающий дашборды Amazon Managed Grafana.
- HyperPod Ray Endpoint Operator, нужный для удалённой отправки заданий.
- CSI-драйвер Amazon FSx for Lustre, сама файловая система, PersistentVolume и PersistentVolumeClaim в режиме ReadWriteMany, смонтированные в поды по пути /shared.
- Домен SageMaker Studio с правами на подключение к кластеру HyperPod.
- Python-пакет toolkit-for-ray-on-sagemaker-ai.
Три ml.g7e.12xlarge несут основную нагрузку: на их GPU живут и генерация ответов, и обучение политики. Четвёртый узел, ml.r5d.16xlarge, GPU не имеет. Это инстанс с упором на память и процессоры, и в сценарии он закрывает служебные и оркестрационные задачи.
Роль операторов объясняется просто. Без KubeRay на HyperPod не появится Ray-кластер, без Ray Endpoint Operator не получится отправить задание из Studio, без Observability add-on не будет готовых дашбордов, а без CSI-драйвера поды не увидят общую файловую систему. Первоисточник перечисляет все эти компоненты как обязательные.
Почему FSx for Lustre, а не обычный EBS
Чекпоинты и LoRA-адаптеры пишутся и читаются одновременно из нескольких подов на разных узлах. Обычный EBS-том монтируется в один под, а режим ReadWriteMany поверх EBS требует отдельных условий и ограничений по зоне доступности. Amazon FSx for Lustre рассчитана на параллельный доступ и высокую пропускную способность, поэтому подходит для многоузловой записи чекпоинтов и обмена адаптерами.
Режим ReadWriteMany здесь не деталь, а условие работы: одна и та же файловая система в каталоге /shared обслуживает хранилище чекпоинтов, синхронизацию LoRA-весов и вывод результатов оценки.
Архитектура обучения: колокация vLLM и FSDP, синхронизация LoRA
RL-цикл состоит из двух чередующихся фаз. Сначала модель генерирует ответы на батч задач, это роллауты, и для них нужен быстрый inference. Затем политика обновляется по полученным наградам, а это уже обучение с шардированием весов.
В сценарии на HyperPod обе фазы живут на одних и тех же GPU: inference-движки vLLM и FSDP-шарды обучаемой модели колокируются. Разносить их на два разных набора узлов не нужно, и GPU не простаивают между фазами. Для RL, где генерация занимает заметную долю времени, такая колокация даёт ощутимую экономию ресурсов.
Связующим звеном выступает LoRA. Обучение идёт не по всем весам модели, а по низкоранговым адаптерам, и после каждого обновления веса адаптера должны попасть в vLLM, который генерирует следующие роллауты. Обмен идёт через /shared на Amazon FSx for Lustre: тренер записывает обновлённые веса, inference-движки читают их перед новой порцией генераций.
Практическая деталь, которую стоит держать в голове: если запись адаптеров запаздывает или рвётся, следующая порция роллаутов уйдёт на устаревших весах, и обучение начнёт буксовать. Общая быстрая файловая система тут не ускорение, а способ сохранить консистентность между фазами.
GRPO на такой архитектуре работает без отдельной reward-модели: нужна проверяемая награда, которую считает код. Разбор похожего подхода с детерминированной reward-функцией, балансирующей recall и precision, есть в материале про кастомизацию Qwen3-8B в SageMaker через SFT и RLVR.
Как запустить: от сборки образа до удалённой отправки задания
Последовательность шагов выглядит так:
- Собрать контейнерный образ с SkyRL и зависимостями и поместить его в реестр, доступный кластеру.
- Убедиться, что в кластере стоят KubeRay operator, HyperPod Observability EKS add-on, HyperPod Ray Endpoint Operator и CSI-драйвер FSx for Lustre.
- Подготовить файловую систему FSx for Lustre, PersistentVolume и PersistentVolumeClaim в режиме ReadWriteMany и смонтировать их в /shared.
- Из SageMaker Studio поднять Ray-кластер на HyperPod, используя пакет toolkit-for-ray-on-sagemaker-ai.
- Отправить обучающее задание удалённо и подключить мониторинг.
Удалённая отправка через sagemaker_ray://
HyperPod Ray Endpoint Operator создаёт защищённую точку подключения к Ray-кластеру. Задание адресуется через протокол sagemaker_ray://, и рабочая станция не получает прямого доступа внутрь кластера. Это удобно по двум причинам: не нужно открывать сетевые порты наружу, а запуск ведётся из привычной SageMaker Studio, где лежат ноутбуки и скрипты.
Схема подходит и для повторяющихся экспериментов: одно и то же задание можно переотправлять с другими гиперпараметрами, не пересобирая окружение и не пересоздавая кластер.
Мониторинг, чекпоинтинг и устойчивость кластера
Смотреть за прогрессом можно двумя способами. Ray Dashboard показывает состояние акторов, задач и ресурсов Ray-кластера, что полезно при отладке первых запусков. Дашборды Amazon Managed Grafana приходят в комплекте с HyperPod Observability EKS add-on и дают метрики уровня кластера: загрузку узлов, состояние GPU, утилизацию памяти. Для RL-задачи длиной в часы вторая панель важнее: по ней видно, упирается ли обучение в вычисления или в обмен данными.
Чекпоинтинг настроен так, что обучение можно возобновить с последнего сохранённого шага, а не с нуля: resume_mode=latest указывает на последний чекпоинт. Это напрямую связано с устойчивостью HyperPod. Сервис непрерывно проверяет состояние узлов и автоматически заменяет неисправные, поэтому отказ одной машины не роняет кластер. В исходном разборе эти две возможности описаны как работающая пара: замена узла плюс чекпоинт дают продолжение с последнего шага.
Для многошагового RL это не мелочь. Каждая остановка означает потерю времени на повторную генерацию роллаутов, а прерывание посреди обновления политики способно испортить прогон целиком. Автоматическая замена узлов и возобновление из чекпоинта превращают такие ситуации в задержку, а не в потерянный эксперимент.
Хостинг обученного LoRA-адаптера для инференса
Результат RL-прогона хранится отдельно от базовой модели: обучение меняет только LoRA-адаптер. Он лежит в /shared на Amazon FSx for Lustre и может быть поднят для инференса отдельно от обучающего кластера. Практический смысл в том, что базовые веса Qwen3-VL-8B остаются неизменными, а адаптер добавляется поверх них. Хранить и версионировать нужно только адаптер, он на порядки меньше полной модели.
Удобство такого разделения в инфраструктуре: обучающий кластер из GPU-инстансов можно освободить, а инференс запустить на подходящем по нагрузке эндпоинте. Конкретная схема сервинга зависит от того, какой стек используется, и в исходном описании сценария она не раскрыта.
Ограничения и кому подходит такой сценарий
Начинать стоит с честного списка того, что сценарий требует и чего не гарантирует.
- Кластер HyperPod с оркестрацией EKS из трёх GPU-инстансов ml.g7e.12xlarge плюс один ml.r5d.16xlarge это платная инфраструктура и настройка, а не запуск на одной видеокарте.
- Предварительно должны работать Kubernetes-компоненты: KubeRay, Observability add-on, Ray Endpoint Operator, CSI-драйвер Lustre. Ошибка в любом из них блокирует запуск.
- Нужны навыки в трёх областях сразу: Kubernetes, Ray и обучение с подкреплением.
- Метрика 43,75% и более 95% получена на фиксированном наборе из 64 лабиринтов. Переносить её на другие задачи нельзя: другой домен, другой набор и другая reward-функция дадут другой результат.
- GRPO требует проверяемой награды, которую считает код. Задачи без объективного критерия успеха в такой пайплайн не укладываются без отдельной reward-модели.
Кому это подходит: командам, которые уже работают в AWS, имеют доступ к HyperPod и решают задачу многошагового RL-дообучения мультимодальных моделей с автоматически проверяемым результатом. Для разового эксперимента с одной моделью порог входа не оправдан: сборка образа, операторы, файловая система и мониторинг займут больше времени, чем сам прогон. Если RL-циклы планируются регулярно, инфраструктура окупается за счёт устойчивости к отказам узлов и отсутствия ручных перезапусков.
Перед выбором платформы полезно свериться с независимыми оценками: разбор Forrester Wave по AI Infrastructure Solutions показывает, какие документы и критерии стоит запрашивать у вендора под задачи дообучения и production-инференса.