O problema com agentes de múltiplas etapas
Quando você constrói agentes empresariais que executam fluxos de trabalho complexos — consultando bancos de dados, chamando APIs, cruzando resultados e se recuperando de falhas no meio do processo — você se depara com um desafio de treinamento fundamental. A qualidade de uma ação individual depende do que acontece várias etapas depois.
O aprendizado por reforço a partir de feedback humano (RLHF) otimiza respostas isoladas, uma de cada vez. Essa abordagem não funciona bem para fluxos de trabalho com múltiplas etapas, onde um agente que valida dados antes de prosseguir pode evitar uma cascata de erros. Técnicas como ajuste fino supervisionado (SFT), geração aumentada por recuperação (RAG) e pré-treinamento contínuo são complementares, mas geralmente não ensinam essas capacidades de tomada de decisão sequencial por conta própria.
O aprendizado por reforço multi-turno (RL multi-turno) preenche essa lacuna ao otimizar sequências inteiras de interação. Assim, os agentes aprendem orquestração de ferramentas, recuperação de erros e raciocínio em múltiplas etapas por tentativa e erro.
A solução da AWS: Nova Forge no HyperPod
O Amazon SageMaker AI já oferece RL multi-turno como uma capacidade totalmente gerenciada e sem servidor. Mas para quem precisa de controle total sobre a pilha de treinamento — ambiente de agente próprio, orquestração personalizada ou configurações específicas de instâncias — a AWS disponibilizou uma infraestrutura dedicada: o Amazon Nova Forge no Amazon SageMaker HyperPod.
O Amazon Nova Forge estende as capacidades do Amazon Nova com suporte a treinamento por RL multi-turno. O post da AWS descreve como implantar essa infraestrutura em duas fases, resultando em um pipeline orientado a eventos que inicia o treinamento automaticamente quando você faz upload de dados no Amazon S3. O exemplo prático usa o jogo Wordle como ambiente de recompensa — um substituto ilustrativo para qualquer tarefa de RL real.
Visão geral da arquitetura
A solução é um pipeline orientado a eventos composto por três camadas principais:
- Amazon SageMaker HyperPod (EKS): pods de treinamento e réplicas de geração vLLM rodando em instâncias P5. O modelo gera respostas e os pods de treinamento aplicam atualizações de peso usando o algoritmo GRPO (Otimização de Política Relativa de Grupo).
- ECS no AWS Fargate: workers de recompensa que executam o ambiente (por exemplo, Wordle ou um ambiente personalizado BYOO — Traga Seu Próprio Orquestrador). Eles recebem respostas do modelo via SQS, avaliam com base em critérios definidos e retornam os sinais de recompensa.
- Amazon Nova Forge SDK: a camada de proxy que roteia mensagens entre o modelo e o ambiente de recompensa, rastreando o estado da conversa entre os turnos.
O AWS Step Functions orquestra toda a execução, acionado pelo Amazon EventBridge quando um arquivo de dados chega ao S3.

Modelo de implantação em duas fases
A arquitetura separa recursos de longa duração dos recursos efêmeros de cada execução de treinamento. Isso reduz custos, acelera iterações e simplifica o gerenciamento.
Fase 1: Implantação via AWS CDK (única vez)
Ao executar cdk deploy, a infraestrutura de base é provisionada:
- Uma Nuvem Privada Virtual (Amazon VPC) com sub-redes privadas e endpoints de VPC
- Um cluster Amazon Elastic Kubernetes Service (Amazon EKS) com um Grupo de Instâncias Restritas (RIG) do HyperPod
- Um cluster Amazon Elastic Container Service (Amazon ECS) no AWS Fargate para workers de recompensa
- Um bucket Amazon S3 para dados de treinamento e checkpoints
- Funções do AWS Identity and Access Management (IAM)
- Um pipeline AWS Step Functions
- Regras do Amazon EventBridge
A implantação leva cerca de 30 a 40 minutos. A maior parte do tempo é gasta na criação do cluster EKS (~15 minutos), instalação do Helm chart do HyperPod via AWS CodeBuild (~5 minutos), provisionamento do cluster HyperPod (~15–25 minutos) e builds de imagens de container Lambda (~5 minutos).
Fase 2: Recursos de runtime (por execução de treinamento)
Quando você faz upload de um arquivo .jsonl no prefixo training-data/ do bucket S3, o EventBridge aciona o pipeline do Step Functions. O Nova Forge SDK implanta seu próprio stack AWS CloudFormation contendo:
- Funções AWS Lambda (proxy de conversação)
- Filas FIFO do Amazon Simple Queue Service (Amazon SQS) para roteamento de mensagens entre modelo e ambiente
- Uma tabela Amazon DynamoDB para rastreamento do estado da conversa
- Tasks ECS Fargate para os workers de recompensa
O SDK gerencia o ciclo de vida desses recursos automaticamente.
Pré-requisitos
Antes de implantar, a AWS lista os seguintes requisitos:
- Assinatura do Amazon Nova Forge: necessária para acessar o SDK e as APIs de treinamento
- Cota de instâncias SageMaker HyperPod: mínimo de 10 ×
ml.p5.48xlargepara 4 réplicas de geração; recomenda-se 12–14 para cargas de produção - Ambiente CDK bootstrapped: execute
cdk bootstrapantes do primeiro deploy - Python 3.12+
- AWS CDK v2: instale com
npm install -g aws-cdk - AWS CLI v2 configurado com permissões para criar VPCs, clusters EKS, clusters HyperPod, funções IAM e Step Functions
- Docker: para build das imagens de container Lambda que empacotam o Nova Forge SDK
Atenção aos custos: esta infraestrutura custa aproximadamente US$ 786 a US$ 1.180 por hora quando em execução (10–12 instâncias ml.p5.48xlarge). Planeje destruir o stack quando não estiver treinando ativamente.
Implantando a infraestrutura
Clone e instalação
git clone https://github.com/aws-samples/sample-nova-multi-turn-rl-infra.git
cd nova-multi-turn-rl-infra
pip install -r requirements.txt
Configuração
Todos os parâmetros são definidos no arquivo cdk.json, na chave context. Dois parâmetros são obrigatórios antes do primeiro deploy:
- project_tag: prefixo único para todos os nomes de recursos (ex:
my-nova-rl) - sdk_resource_prefix: prefixo para recursos criados pelo SDK (ex:
nrl-myproject)
Parâmetros-chave de infraestrutura incluem instance_type (padrão: ml.p5.48xlarge), instance_count (padrão: 10), nova_model (opções: NOVA_MICRO, NOVA_LITE, NOVA_LITE_2 ou NOVA_PRO) e vf_env_id (padrão: wordle). Para usar um ambiente personalizado, defina use_custom_env como true e especifique o diretório em custom-environments/.
Parâmetros de treinamento incluem training_method (RFT_MULTITURN_FULL ou RFT_MULTITURN_LORA), max_steps (padrão: 10), generation_replicas (padrão: 4) e global_batch_size (padrão: 64). Qualquer parâmetro pode ser sobrescrito no momento do deploy:
cdk deploy -c instance_count=1 -c max_steps=20
Deploy
cdk deploy --require-approval never
Acionando uma execução de treinamento
Formato dos dados de treinamento
O arquivo .jsonl usa um formato baseado em metadados — cada linha contém um prompt e a resposta correta que o ambiente de recompensa usa para pontuação:
{"id": "wordle_train_001", "metadata": {"prompt": "Guess the 5-letter word", "answer": "crane"}}
{"id": "wordle_train_002", "metadata": {"prompt": "Guess the 5-letter word", "answer": "slate"}}
{"id": "wordle_train_003", "metadata": {"prompt": "Guess the 5-letter word", "answer": "plumb"}}
O campo id deve ser único em todos os registros. O modelo vê o metadata.prompt no início de cada conversa, e o ambiente de recompensa usa o metadata.answer para pontuar as respostas ao longo dos turnos.
Upload e acionamento automático
# Obter o nome do bucket a partir dos outputs do CDK
BUCKET=$(aws cloudformation describe-stacks --stack-name NovaMultiTurnRlStack \
--query "Stacks[0].Outputs[?OutputKey=='TrainingBucketName'].OutputValue" --output text)
# Upload: o pipeline inicia automaticamente
aws s3 cp training-data.jsonl s3://$BUCKET/training-data/training-data.jsonl
Acionamento manual para execuções avulsas
./scripts/setup.sh \
--data-path s3://$BUCKET/training-data/training-data.jsonl \
--max-steps 5 \
--global-batch-size 32 \
--training-method RFT_MULTITURN_LORA
Monitoramento e depuração
O console do Step Functions é o painel principal. Cada execução exibe o progresso passo a passo com tempo, dados de entrada/saída e histórico de tentativas. Cada etapa escreve em seu próprio grupo de logs no Amazon CloudWatch.
Durante a operação normal, cada etapa do Step Functions é concluída dentro de janelas esperadas: configuração de infraestrutura em 2–3 minutos, implantação de workers de recompensa em 1–2 minutos, validação de dados em menos de 1 minuto e envio do treinamento em 3–5 minutos.
Alertas de falha
Um tópico do Amazon SNS, criptografado com AWS KMS, publica notificações quando uma execução do Step Functions falha. Para se inscrever e receber alertas por e-mail:
# Obter o ARN do tópico a partir dos outputs do CDK
TOPIC_ARN=$(aws cloudformation describe-stacks --stack-name NovaMultiTurnRlStack \
--query "Stacks[0].Outputs[?OutputKey=='AlertTopicArn'].OutputValue" --output text)
# Inscrever e confirmar via e-mail
aws sns subscribe \
--topic-arn $TOPIC_ARN \
--protocol email \
--notification-endpoint your-team@example.com
Depuração de travamentos no treinamento
Se o pipeline iniciar mas o treinamento travar, a causa raiz geralmente está na camada de roteamento de mensagens entre o modelo e o ambiente de recompensa. O SDK oferece um diagnóstico integrado:
from rft_infra import check_all_queues
# Retorna contagens de mensagens (em voo, disponíveis, atrasadas) para todas as filas FIFO
check_all_queues()
Um backlog crescente na fila de requisições com fila de respostas vazia indica que os workers de recompensa não estão processando. O padrão inverso indica que o modelo não está consumindo recompensas.
Saúde do HyperPod
kubectl get pods -n kubeflow
Todos os pods devem exibir status Running ou Completed. Pods presos em Pending indicam capacidade insuficiente de instâncias. Pods em CrashLoopBackOff indicam erros no nível do container — verifique os logs com kubectl logs <pod-name> -n kubeflow.
Custos e limpeza
A tabela abaixo resume os custos por hora desta infraestrutura:
- SageMaker HyperPod 8 × ml.p5.48xlarge: ~US$ 786/hora (configuração mínima)
- SageMaker HyperPod 12 × ml.p5.48xlarge: ~US$ 1.180/hora (configuração de produção)
- Plano de controle EKS: US$ 0,10/hora
- NAT Gateway: ~US$ 0,045/hora
- Workers ECS Fargate: ~US$ 0,15–0,30/hora + transferência de dados
- S3, Lambda, CodeBuild, SQS, DynamoDB: negligível
Para consultar a precificação atual do Amazon Nova Forge, acesse a página de preços do Amazon Nova.
Para destruir o stack inteiro e evitar cobranças:
./cleanup.sh
Para destruir a infraestrutura mantendo os dados de treinamento no S3 (custos de armazenamento ainda se aplicam):
./cleanup.sh --retain-data
Para reduzir custos ociosos, a AWS sugere duas estratégias: escalar para zero com políticas de escalonamento automático em períodos de inatividade, e usar tipos de instâncias de menor custo durante as fases de configuração, transitando para instâncias de maior desempenho apenas quando o treinamento começar.
Próximos passos
Com a infraestrutura implantada, o próximo passo é substituir o ambiente Wordle pelo seu próprio agente que chama APIs ou executa fluxos de trabalho empresariais. O repositório de referência está disponível em aws-samples/nova-multi-turn-rl-infra.
Fonte
Deploying Multi-Turn RL Infrastructure for Amazon Nova on Amazon SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/deploying-multi-turn-rl-infrastructure-for-amazon-nova-on-amazon-sagemaker-hyperpod/)
Leave a Reply