AWS lance Multi-Turn RL dans SageMaker : gpt-oss-20b passe de 15 à 69% pour $339

AWS a ouvert dans SageMaker AI le service Multi-Turn Reinforcement Learning (MTRL). Il entraîne des modèles sur des tâches à plusieurs étapes, où seul le résultat final est connu : la chaîne d'actions a fonctionné ou non. Lors d'un run de démonstration, gpt-oss-20b est passé de 61 à 84% de mots Wordle résolus sur l'échantillon de validation, avec le reasoning effort par défaut. Avec l'effort bas, utilisé pendant l'entraînement, le résultat est passé de 15 à 69%. Les tokens d'entraînement ont coûté environ $339.

Pourquoi le fine-tuning classique ne convient pas aux agents

Le supervised fine-tuning apprend au modèle à produire la meilleure réponse à un seul prompt. Un agent qui remplit une note de frais ou traite un ticket de support fonctionne autrement : chaque étape dépend des précédentes, et il n'existe le plus souvent aucune séquence de référence à imiter. Le RL à un seul tour ne sait pas attribuer le mérite à une décision prise trois étapes avant le résultat. MTRL travaille avec le seul signal disponible dans les processus réels : la récompense d'un épisode terminé. Vous ne décrivez pas la trajectoire correcte, mais seulement la façon d'évaluer le résultat.

L'architecture se divise en deux moitiés. SageMaker AI gère le job d'entraînement et le modèle de policy. L'agent, l'environnement et la fonction de récompense vivent dans Amazon Bedrock AgentCore, ou sur votre infrastructure (EKS, EC2, Fargate) via un forwarder Lambda. Pour chaque rollout, le service appelle le runtime AgentCore avec une ligne du dataset. L'agent, construit avec Strands, interroge le modèle de policy via un endpoint compatible OpenAI. Il joue jusqu'à six coups via l'outil guess_word, puis renvoie un seul nombre à la fin. Group Relative Policy Optimization (GRPO) compare les récompenses de plusieurs rollouts du même mot et met à jour l'adaptateur LoRA.

La récompense dépend fortement de l'issue. Une victoire rapporte de 1,05 à 1,55 selon la vitesse, une défaite donne −0,5, et l'absence de toute tentative valide donne −1,5. Un petit terme de shaping récompense une bonne stratégie à l'intérieur de chaque niveau. Le dataset ne contient que le mot à deviner. Les listes de mots basées sur SCOWL se trouvent dans l'agent et ne servent qu'au calcul de la récompense. Pour la validation, 128 mots ont été retenus, sans recoupement avec les 640 mots d'entraînement (cinq batchs complets de 128).

Ce que coûtent 100 steps

MTRL ne demande pas de choisir des instances. On paie au million de tokens, selon trois postes : prefill, sample et train. Dans les tâches multi-étapes, le prefill augmente, car chaque coup relit tout l'historique. Le run de 100 steps a traité 105 486 rollouts en 12 heures 40 minutes, aux prix catalogue de us-east-1 :

• Prefill : 491 616 806 tokens à $0,12 le million, $58,99 • Sample : 159 737 098 tokens à $0,30, $47,92 • Train : 643 308 554 tokens à $0,36, $231,59 • Total : 1 294 662 458 tokens, $338,50 • Runtime AgentCore : environ $79 pour les vCPU et la mémoire, d'après les métriques CloudWatch, soit environ $417 au total

Le premier poste de dépense, train, croît avec la longueur des trajectoires. Il vaut donc mieux économiser sur la durée des épisodes et sur les raisonnements verbeux. Dans les tâches d'évaluation, le reasoning effort bas a consommé 63–83% de tokens de sample en moins par partie que l'effort moyen.

Modèles pris en charge et pièges de configuration

Le service fonctionne actuellement avec quatre modèles de base, chacun entraîné via un adaptateur LoRA :

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

Les auteurs ont choisi GPT-OSS-20B pour son prix par token, le plus bas des quatre, et pour la possibilité de définir le reasoning effort à chaque requête.

Le guide décrit plusieurs points peu évidents. Le rôle du job d'entraînement doit faire confiance à job.sagemaker.

amazonaws.com, et non à sagemaker.amazonaws.

com. Les deux actions, sts:AssumeRole et sts:TagSession, sont nécessaires, sinon CreateJob échoue avec « Could not assume role ». Le principal n'est nommé qu'après plusieurs essais.

Le décorateur sagemaker_rft_handler ne lance pas lui-même de serveur HTTP. Il faut l'envelopper dans BedrockAgentCoreApp et @app.entrypoint, avec l'entrypoint placé à l'extérieur, faute de quoi chaque appel se heurte à un timeout de 30 secondes.

Le lancement exige botocore 1.43.37 ou plus récent, version où l'opération AgentRFT CreateJob est apparue pour la première fois.

Le job et le runtime doivent se trouver dans la même région, car CreateJob rejette les ARN interrégionaux. Une application MLflow est aussi nécessaire pour les métriques.

Avant de dépenser du temps GPU, il vaut la peine de faire un smoke test avec le payload du dépôt, en remplaçant dans l'ARN l'identifiant de votre compte. Le résultat attendu : une erreur 400 « Could not find job » et une récompense de −1,5, car l'agent n'a pas atteint le modèle. Cela confirme que le parsing, l'authentification et le reporting des erreurs fonctionnent. Si vous obtenez un 403, l'ARN contient un autre compte. Si vous obtenez un timeout, le serveur ne démarre pas.

Que faire de tout cela en pratique

Wordle n'est ici qu'un exemple pédagogique, et les modèles frontier s'en sortent très bien. L'intérêt pratique est ailleurs : prendre un petit modèle bon marché et lui apprendre un processus multi-étapes absent des données d'entraînement publiques, comme la validation interne de demandes ou le routage de tickets. Pour cela, on modifie dans main.py l'analyse de la tâche, les outils et la fonction de récompense, le reste du pipeline demeurant identique. Le dataset peut être une ligne contenant la liste complète des messages, une configuration d'outils ou une spécification de récompense, car le service la transmet à l'agent sans l'analyser.

Les données, l'agent et le modèle entraîné restent dans votre compte AWS et ne servent pas à entraîner les modèles de base. Le budget final est simple : environ $340 de tokens et $80 de runtime donnent un modèle spécialisé de classe 20B. Pour éviter que la facture ne gonfle, mieux vaut concevoir à l'avance des épisodes courts et une récompense où l'issue pèse plus que les points intermédiaires.