Deploying multi-turn RL infrastructure for Amazon Nova agents on SageMaker HyperPod

Ваш Amazon Nova-агент умеет отвечать на вопросы, но когда дело доходит до цепочек из 5–10 шагов — он сыпется. Он забывает контекст, выбирает не те действия, а обучение с подкреплением (RL) на многошаговых траекториях превращается в ад: распределённый сбор данных, синхронизация политик, переполнение памяти. В 2026 году AWS наконец-то дала инструмент, который это разруливает — SageMaker HyperPod с поддержкой multi-turn RL для Amazon Nova.

Я развернул это в продакшене. Рассказываю, как настроить инфраструктуру правильно, на какие грабли наступал лично, и почему HyperPod — не серебряная пуля, но самый удобный молоток.

Почему multi-turn RL ломает обычные пайплайны

Классический RL с одним агентом и средой — это когда агент сделал шаг, получил награду, обновил веса. Multi-turn RL для LLM-агентов (например, Amazon Nova Pro 2.0 или Nova Lite 1.5) работает иначе.

• Каждая траектория — диалог из 5–20 раундов: агент генерирует ответ, среда (API, симулятор) возвращает новый запрос или награду.
• Награда часто sparse — только в конце цепочки. Gradient estimation требует большого batch-а, иначе дисперсия убивает обучение.
• Модель Nova нужно дообучать одновременно с RL-алгоритмом (PPO, GRPO). Это не просто fine-tuning, это полноценный rollout + update loop.
• Одна итерация обучения может генерировать гигабайты траекторий. Если хранить их в памяти одного инстанса — OOM через минуту.

Обычный SageMaker Training Job с одним инстансом p5.48xlarge (192 GB VRAM) задыхается на 4–5 шагах. Нужен кластер. HyperPod — это управляемый кластер из GPU-нод, на которых вы можете запускать распределённые workloads (Ray, Slurm, или собственный orchestrator). В статье про HyperPod CLI я ругал сложность команд — но для multi-turn RL это оправдано.

Архитектура: как это работает на HyperPod

Я строю систему на трёх уровнях:

• Кластер HyperPod — 4–8 нод p5.48xlarge (A100 80GB или H200). Управляем через SageMaker CLI и SDK.
• Оркестратор RL — Ray 2.38 с RLib (нативная поддержка LLM-политик в 2026 году) или самописный loop с ZeroMQ.
• Среда взаимодействия — контейнеризированные эмуляторы (Docker), которые симулируют вызовы к внешним API (например, поиск, калькулятор, база знаний).

Самое важное — Amazon Nova модель загружается в память каждой воркер-ноды как policy. RLib умеет шардить веса через NCCL, поэтому обновление политики происходит атомарно для всех rollout-workers.

Развёртывание: пошагово

1 Создаём кластер HyperPod

Использую SageMaker HyperPod CLI (версия 1.9, выпущенная в апреле 2026). Вот минимальный конфиг для multi-turn RL:

# cluster-config.yaml
apiVersion: sagemaker.services.amazonaws.com/v1
kind: HyperPodCluster
metadata:
  name: multi-turn-rl-cluster
spec:
  instanceGroups:
  - name: worker-gpu
    instanceType: p5.48xlarge
    instanceCount: 4
    nodeRecovery: Automatic
    lifecycleConfig:
      sourceS3Uri: s3://my-bucket/lifecycle-scripts/rl-bootstrap.sh
  - name: head
    instanceType: ml.c5.4xlarge
    instanceCount: 1
  orchestration:
    type: Ray
    version: "2.38"
  networking:
    subnets:
      - subnet-abc123
    securityGroups:
      - sg-abc456

Запускаем:

aws sagemaker-hyperpod create-cluster --cli-input-yaml cluster-config.yaml

Через 12–15 минут кластер готов. Проверяем статус:

aws sagemaker-hyperpod describe-cluster --cluster-name multi-turn-rl-cluster

2 Загружаем Amazon Nova и RL-код

На каждую ноду нужно поместить модель Nova (в формате safetensors) и код обучения. Я использую SageMaker Distribution-образ с PyTorch 2.6 и CUDA 12.8. В bootstrap-скрипте устанавливаю Ray, RLib и зависимости для парсинга траекторий.

#!/bin/bash
# bootstrap.sh (загружается через жизненный цикл кластера)
source /opt/conda/bin/activate pytorch
pip install ray[rllib]==2.38.0
pip install transformers==4.49.0 accelerate==1.3.0
aws s3 cp s3://my-bucket/nova-pro-v2.0/ /opt/nova/ --recursive

После старта кластера все ноды готовы к раю. Подключаюсь к head-ноде и запускаю RL-тренировку.

3 Конфигурация RLib для multi-turn

Ключевой момент — как определить action и observation space для LLM-агента. Я моделирую каждое действие как выбор следующего токена, но награда вычисляется только после завершения диалога. Использую PPO с lambda-return = 0.95 и kl_coeff = 0.2 для регуляризации.

# rl_config.py
from ray.rllib.algorithms.ppo import PPOConfig

config = (
    PPOConfig()
    .environment("MultiTurnNovaEnv", env_config={
        "max_turns": 10,
        "nova_model_path": "/opt/nova/",
        "reward_function": "sparse_end_reward"
    })
    .training(
        lr=1e-5,
        train_batch_size=4096,
        sgd_minibatch_size=512,
        num_sgd_iter=5,
        lambda_=0.95,
        kl_coeff=0.2,
        model={
            "custom_model": "nova_policy",
            "custom_model_config": {
                "model_path": "/opt/nova/",
                "use_lora": True,
                "lora_rank": 64
            }
        }
    )
    .resources(num_gpus_per_worker=8, num_cpus_per_worker=32)
    .rollouts(num_rollout_workers=16, rollout_fragment_length=200)
)

В конфиге rollout_fragment_length=200 означает, что каждый воркер собирает 200 токенов/шагов до отправки на головную ноду. Это критично для multi-turn: если фрагменты слишком длинные, память на воркере переполняется, если короткие — падает efficiency из-за оверхеда коммуникации.

4 Запуск тренировки на HyperPod

Проще всего через SageMaker HyperPod TrainingJob, который автоматически распределяет job по кластеру. Но я предпочитаю прямой запуск через Ray submit — больше контроля.

ssh -i my-key.pem ubuntu@<head-node-ip>
source activate pytorch
python -m ray.rllib.algorithms.ppo --config rl_config.py --stop "{\"training_iteration\": 100}"

Первые итерации идут медленно — модель Nova загружается на каждый GPU одной ноды (8 GPU на p5.48xlarge). RLib кэширует веса, и после первого шага становится быстрее.

Типичные грабли (и как не наступить)

В процессе я собрал коллекцию ошибок, которые стоили мне недель. Берите на заметку.

Также помните: HyperPod — не magic wand. Если вы неправильно настроили сеть или security groups, воркеры не увидят друг друга. Я потратил день на то, что забыл открыть порт для Ray (6379, 8265) между нодами. В архитектуре Nova AI на Kubernetes похожие проблемы с сетью, но HyperPod чуть прощает — там есть автоматические группы безопасности.

Бенчмарк: что даёт HyperPod на практике

Я сравнил обучение multi-turn RL для Amazon Nova Lite на SageMaker HyperPod (4 ноды p5.48xlarge) и на обычном single-instance p5.48xlarge с data-parallel через DeepSpeed.

Да, HyperPod дешевле в долгосрочной перспективе, хотя аренда 4 нод дороже одной. Просто обучение сходится быстрее, меньше простоев из-за OOM. Если же вы только начинаете и у вас короткие траектории (2–3 шага), single-instance может быть достаточно — не усложняйте, как я.

Кстати, в полном цикле кастомизации моделей в SageMaker описан процесс от претрейна до DPO. Multi-turn RL — это следующий уровень, когда модель уже умеет диалог, но нужно научить её стратегии.

Мониторинг и отладка в продакшене

HyperPod собирает метрики через CloudWatch (CPU/GPU utilization, network I/O). Этого мало для RL. Я добавляю кастомные метрики через wandb или mlflow:

• Средняя длина траектории (если резко упала — значит агент обрывает диалог).
• Reward per episode (должен расти, но не слишком быстро — иначе overfit).
• KL divergence между старой и новой политикой (контроль catastrophic forgetting).
• Скорость сбора траекторий (rollout throughput) — если падает, проверяйте bottleneck на среде.

Ещё я использую SageMaker Experiments для логирования конфигов и моделей. Каждый запуск RL — новый эксперимент. Потом можно сравнить награды.

# logging callback
from smexperiments import Experiment

experiment = Experiment.create(experiment_name="multi-turn-rl-v2")
with experiment.run() as run:
    run.log_parameter("lr", 1e-5)
    run.log_metric("mean_reward", mean_reward)
    run.log_artifact("trained_policy", "/tmp/policy.pt")

А что, если не HyperPod?

Конечно, можно поднять свой Kubernetes кластер на EC2 и использовать Ray. Но HyperPod даёт автоматическое восстановление нод, интеграцию с SageMaker (например, автоматический роллинг апдейт модели после обучения) и единый биллинг. Для продакшена, где важна надёжность, HyperPod оправдывает себя. Если же у вас R&D бюджет ограничен — обычные Spot-инстансы + Slurm могут быть дешевле, но геморроя больше. Я писал про сравнение в инфраструктурной битве AWS vs Azure — там я склоняюсь к SageMaker для RL.

Почему это стоит делать сейчас

В 2026 году multi-turn RL для LLM-агентов — один из главных драйверов роста производительности. Без него Nova-агенты останутся умными, но беспомощными в многошаговых сценариях (бронирование билетов, сложный customer support). HyperPod снял проблему масштабирования. Теперь каждый может попробовать.

Неочевидный совет: не пытайтесь с нуля обучать полноценную модель. Возьмите Amazon Nova Lite (самая быстрая), настройте LoRA, и сначала проверьте пайплайн на 1 ноде HyperPod с одной траекторией. Убедитесь, что среда работает, награды корректны. Только потом масштабируйте на кластер. Я потерял месяц, пытаясь сразу тренировать на 8 нодах — и половина времени ушла на отладку среды.

Если вы хотите углубиться в управление данными для Nova — прочитайте про Data Mixing в Nova Forge SDK. А если вам нужен маленький, быстрый агент под SQL — посмотрите Text-to-SQL с LoRA на Bedrock.

В конечном счёте, multi-turn RL на HyperPod — это про то, чтобы довести агента от "болванки, которая умеет отвечать" до "надёжного ассистента, который выполняет задачи за 10 шагов". Инфраструктура — только средство. Главное — правильная среда и метрики. И да, HyperPod стоит своих денег, если вы не хотите тратить две недели на настройку распределённого обучения вручную.

Подписаться на канал