AWS lanza Multi-Turn RL en SageMaker: gpt-oss-20b sube del 15 al 69% por $339

AWS ha abierto en SageMaker AI el servicio Multi-Turn Reinforcement Learning (MTRL). Entrena modelos en tareas de varios pasos en las que solo se conoce el resultado final: la cadena de acciones funcionó o no funcionó. En una ejecución de demostración, gpt-oss-20b subió del 61 al 84% de palabras de Wordle resueltas en el conjunto de validación, con el reasoning effort por defecto. Con el effort bajo, con el que se entrenó, el resultado pasó del 15 al 69%. Los tokens de entrenamiento costaron aproximadamente $339.

Por qué el fine-tuning clásico no sirve para agentes

El supervised fine-tuning enseña al modelo a dar la mejor respuesta a un único prompt. Un agente que rellena un informe de gastos o resuelve un ticket de soporte actúa de otra forma: cada paso depende de los anteriores y, casi siempre, no existe una secuencia de referencia que imitar. El RL de un solo paso no sabe atribuir el mérito a una decisión tomada tres pasos antes del resultado. MTRL trabaja con la única señal que existe en los procesos reales: la recompensa por un episodio completo. Usted no describe la trayectoria correcta, solo cómo evaluar el resultado.

La arquitectura se divide en dos mitades. SageMaker AI se ocupa del trabajo de entrenamiento y del modelo de política. El agente, el entorno y la función de recompensa viven en Amazon Bedrock AgentCore o en su propia infraestructura (EKS, EC2, Fargate) a través de un reenviador Lambda. En cada rollout, el servicio llama al runtime de AgentCore con una fila del dataset. El agente, construido con Strands, consulta el modelo de política mediante un endpoint compatible con OpenAI, juega hasta seis turnos con la herramienta guess_word y al final devuelve un único número. Group Relative Policy Optimization (GRPO) compara las recompensas de varios rollouts de la misma palabra y actualiza el adaptador LoRA.

La recompensa depende sobre todo del resultado. Ganar da entre 1,05 y 1,55 según la rapidez, perder da −0,5 y no lograr ninguna conjetura válida da −1,5. Un pequeño término de shaping premia la buena estrategia dentro de cada nivel. El dataset contiene solo la palabra oculta. Las listas de palabras basadas en SCOWL están dentro del agente y sirven únicamente para calcular la recompensa. Para la validación se tomaron 128 palabras que no se solapan con las 640 de entrenamiento (cinco batches completos de 128).

Cuánto costaron los 100 pasos

MTRL no obliga a elegir instancias. Se paga por millón de tokens en tres partidas: prefill, sample y train. En las tareas de varios pasos, el prefill crece porque cada turno vuelve a leer el historial. La ejecución de 100 pasos procesó 105 486 rollouts en 12 horas y 40 minutos, a precios de lista de us-east-1:

• Prefill: 491 616 806 tokens a $0,12 por millón, $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 de AgentCore: aproximadamente $79 por vCPU y memoria según las métricas de CloudWatch, es decir, unos $417 en total

La partida principal, train, crece con la longitud de la trayectoria. Por eso conviene ahorrar en la duración de los episodios y en los razonamientos prolijos. En las tareas de evaluación, el reasoning effort bajo gastó entre un 63 y un 83% menos de tokens de sample por partida que el medio.

Modelos compatibles y trampas de configuración

Por ahora el servicio funciona con cuatro modelos base, y cada uno se entrena mediante un adaptador LoRA:

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

Los autores eligieron GPT-OSS-20B por tener el precio por token más bajo de los cuatro y por permitir fijar el reasoning effort en cada solicitud.

La guía describe varios puntos poco evidentes. El rol del trabajo de entrenamiento debe confiar en job.sagemaker.

amazonaws.com, y no en sagemaker.amazonaws.

com. Hacen falta las dos operaciones, sts:AssumeRole y sts:TagSession; de lo contrario, CreateJob falla con «Could not assume role». El principal solo se nombra tras varios reintentos.

El decorador sagemaker_rft_handler no inicia por sí mismo el servidor HTTP. Hay que envolverlo en BedrockAgentCoreApp y @app.entrypoint, y el entrypoint debe quedar por fuera; si no, cada llamada choca con un timeout de 30 segundos.

Para el lanzamiento se requiere botocore 1.43.37 o posterior, donde apareció por primera vez la operación AgentRFT CreateJob.

El trabajo y el runtime deben estar en la misma región, porque CreateJob rechaza un ARN entre regiones. También hace falta una aplicación MLflow para las métricas.

Antes de gastar tiempo de GPU conviene hacer un smoke test con el payload del repositorio, sustituyendo en el ARN su propia cuenta. El resultado esperado es un 400 «Could not find job» y una recompensa de −1,5, porque el agente no llegó hasta el modelo. Eso confirma que el parseo, la autenticación y el reporte de errores funcionan. Si llega un 403, el ARN contiene otra cuenta. Si llega un timeout, el servidor no arranca.

Qué hacer con esto en la práctica

Wordle es aquí solo un ejemplo didáctico, y los modelos frontier lo resuelven sin problemas. El valor práctico está en otra parte: tomar un modelo pequeño y barato y enseñarle un proceso de varios pasos que no aparece en los datos públicos de entrenamiento, por ejemplo la aprobación interna de solicitudes o el enrutamiento de tickets. Para ello se cambian en main.py el parseo de la tarea, las herramientas y la función de recompensa; el resto del pipeline sigue igual. El dataset puede ser una fila con la lista completa de mensajes, una configuración de herramientas o una especificación de recompensa, porque el servicio se la pasa al agente sin analizarla.

Los datos, el agente y el modelo entrenado permanecen en su cuenta de AWS y no se usan para entrenar los modelos base. El presupuesto final es sencillo: unos $340 en tokens y $80 en runtime dan como resultado un modelo especializado de clase 20B. Para que el coste no se dispare, conviene diseñar de antemano episodios cortos y una recompensa en la que el resultado pese más que los puntos intermedios.