AWS lança Multi-Turn RL no SageMaker: gpt-oss-20b sobe de 15% para 69% com $339

A AWS liberou no SageMaker AI o serviço Multi-Turn Reinforcement Learning (MTRL). Ele treina modelos em tarefas de vários passos em que só se conhece o resultado final: a cadeia de ações inteira funcionou ou não. Em uma execução de demonstração, o gpt-oss-20b subiu de 61% para 84% de palavras do Wordle resolvidas no conjunto de validação separado, com o reasoning effort padrão. Com o effort baixo, usado no treinamento, o resultado foi de 15% para 69%. Os tokens de treinamento custaram cerca de $339.

Por que o fine-tuning comum não serve para agentes

O supervised fine-tuning ensina o modelo a dar a melhor resposta para um único prompt. Um agente que preenche uma prestação de contas ou analisa um ticket de suporte age de outra forma: cada passo depende dos anteriores, e na maioria dos casos não existe uma sequência de referência para imitar. O RL de passo único não sabe atribuir mérito a uma decisão tomada três passos antes do resultado. O MTRL trabalha com o único sinal disponível em processos reais: a recompensa pelo episódio concluído. Você não descreve a trajetória correta, apenas como avaliar o resultado.

A arquitetura se divide em duas metades. O SageMaker AI cuida do job de treinamento e do modelo de policy. O agente, o ambiente e a função de recompensa ficam no Amazon Bedrock AgentCore ou na sua própria infraestrutura (EKS, EC2, Fargate), por meio de um forwarder em Lambda. A cada rollout, o serviço chama o runtime do AgentCore com uma linha do dataset. O agente, construído com Strands, acessa o modelo de policy por um endpoint compatível com a OpenAI, joga até seis jogadas usando a ferramenta guess_word e, no fim, devolve um único número. O Group Relative Policy Optimization (GRPO) compara as recompensas de vários rollouts da mesma palavra e atualiza o adaptador LoRA.

A recompensa depende muito do desfecho. A vitória rende de 1,05 a 1,55, conforme a velocidade; a derrota rende −0,5; e nenhum palpite válido rende −1,5. Um pequeno termo de shaping incentiva boa estratégia dentro de cada nível. O dataset contém apenas a palavra sorteada. As listas de palavras baseadas no SCOWL ficam dentro do agente e servem somente para calcular a recompensa. Para validação, foram usadas 128 palavras, sem sobreposição com as 640 de treinamento (cinco batches completos de 128).

Quanto custaram os 100 passos

O MTRL não exige escolher instâncias. A cobrança é por milhão de tokens, em três itens: prefill, sample e train. Em tarefas de vários passos, o prefill cresce, porque cada jogada relê o histórico. A execução de 100 passos processou 105 486 rollouts em 12 horas e 40 minutos, pelos preços de tabela de us-east-1:

• Prefill: 491 616 806 tokens a $0,12 por milhão, $58,99 • Sample: 159 737 098 tokens a $0,30, $47,92 • Train: 643 308 554 tokens a $0,36, $231,59 • Total: 1 294 662 458 tokens, $338,50 • Runtime do AgentCore: cerca de $79 por vCPU e memória, segundo as métricas do CloudWatch, ou seja, cerca de $417 no total

O maior item de custo, o train, cresce junto com o comprimento da trajetória. Por isso vale economizar no tamanho dos episódios e em raciocínios prolixos. Nas tarefas de avaliação, o reasoning effort baixo gastou de 63% a 83% menos tokens de sample por jogo do que o effort médio.

Modelos compatíveis e armadilhas de configuração

Hoje o serviço funciona com quatro modelos base, e cada um é treinado por meio de um adaptador LoRA:

• Amazon Nova 2 Lite: us-east-1 e us-west-2 • GPT-OSS-20B: us-east-1 e us-west-2 • Gemma 4 31B (instruction-tuned): somente us-west-2 • Qwen 3.6 27B: somente us-west-2

Os autores escolheram o GPT-OSS-20B pelo menor preço por token entre os quatro e pela possibilidade de definir o reasoning effort a cada requisição.

O guia descreve alguns pontos pouco óbvios. A role do job de treinamento deve confiar em job.sagemaker.

amazonaws.com, e não em sagemaker.amazonaws.

com. São necessárias as duas operações, sts:AssumeRole e sts:TagSession; caso contrário, o CreateJob falha com «Could not assume role». O principal só é nomeado após várias tentativas.

O decorador sagemaker_rft_handler não inicia o servidor HTTP por conta própria. É preciso envolvê-lo em BedrockAgentCoreApp e @app.entrypoint, e o entrypoint deve ficar por fora; do contrário, toda chamada esbarra em um timeout de 30 segundos.

Para executar, é necessário o botocore 1.43.37 ou mais recente, versão em que a operação AgentRFT CreateJob apareceu pela primeira vez.

O job e o runtime precisam estar na mesma região, porque o CreateJob rejeita ARNs entre regiões. Também é necessário um aplicativo MLflow para as métricas.

Antes de gastar tempo de GPU, vale fazer um smoke test com o payload do repositório, trocando no ARN pela sua própria conta. O resultado esperado é um 400 «Could not find job» e recompensa −1,5, porque o agente não chegou ao modelo. Isso confirma que o parsing, a autenticação e o relato de erros funcionam. Se vier um 403, o ARN aponta para outra conta. Se ocorrer timeout, o servidor não está iniciando.

O que fazer com isso na prática

O Wordle aqui é só um exemplo didático, e os modelos de fronteira já se saem bem nele. O valor prático está em outro ponto: pegar um modelo pequeno e barato e ensiná-lo um processo de vários passos que não existe nos dados públicos de treinamento, como a aprovação interna de solicitações ou o roteamento de tickets. Para isso, mudam-se no main.py a leitura da tarefa, as ferramentas e a função de recompensa, e o restante do pipeline permanece igual. O dataset pode ser uma linha com a lista completa de mensagens, uma configuração de ferramentas ou uma especificação de recompensa, já que o serviço a repassa ao agente sem interpretá-la.

Os dados, o agente e o modelo treinado permanecem na sua conta da AWS e não são usados para treinar os modelos base. A conta final é simples: cerca de $340 em tokens e $80 de runtime resultam em um modelo especializado da classe 20B. Para que o custo não suba, convém projetar de antemão episódios curtos e uma recompensa em que o resultado final pese mais que os pontos intermediários.