SageMaker Training Sessions laisse écrire sa propre boucle RL sans provisionner de GPU

22 octobre 2026. AWS rend généralement disponibles les Training Session APIs de SageMaker AI, qui permettent de personnaliser un modèle avec sa propre boucle d’entraînement. 22 octobre 2026. Le catalogue de départ tient en quatre modèles de base : GPT-OSS 20B, Gemma 4 31B, Qwen3.6 27B et Qwen3.8 27B. 22 octobre 2026. La facturation passe aux jetons — prefill, sample, train — et non plus aux instances provisionnées. Le point clé : pour la première fois, le post-entraînement personnalisé sort de la gestion de clusters GPU.

Pour une équipe ML ou plateforme, la nouvelle n’est pas cosmétique. C’est la disparition d’un plafond : jusqu’ici, tout ce qui dépassait le SFT ou le DPO — un GRPO, un PPO, une fonction de perte maison — vous renvoyait à vos propres clusters ou à des plateformes tierces de post-entraînement.

Un plafond de l’ancien modèle

Les API de fine-tuning haut niveau de SageMaker contraignaient la boucle à des workflows prédéfinis, typiquement le supervised fine-tuning (SFT). Impossible d’écrire une fonction de perte personnalisée, de lancer du RL frontière avec des rollouts élastiques, ou de s’affranchir des décisions d’infrastructure imposées par ces API. Pour toute équipe qui itérait sur des objectifs d’entraînement nouveaux — GRPO, DRO, DAPO — ou qui devait déboguer une divergence de perte, la seule issue était de reprendre la main sur l’infrastructure.

Les Training Sessions renversent le rapport : au lieu de soumettre un script d’entraînement complet, vous ouvrez une session et appelez des opérations unitaires — forward_backward(), optim_step(), sample() — que vous composez dans la procédure de votre choix. Le modèle reste chargé sur les GPU entre les appels, et le service gère l’exécution distribuée, la synchronisation des gradients et l’isolation des locataires.

Une boucle RL en quelques lignes

Le cœur de l’offre tient dans cet exemple, tiré de la documentation :

from sagemaker.train.training_session import ServiceClient, AdamParams

svc = ServiceClient(region="us-west-2", role_arn="arn:aws:iam::111122223333:role/MyRole")
tc = svc.create_lora_training_client(base_model="openai/gpt-oss-20b", rank=32, alpha=64)

# Boucle RL personnalisée avec échantillonnage on-policy
sc = tc.create_sampling_client()
for step in range(num_steps):
    ops = [sc.sample(p, num_samples=4, sampling_params=params) for p in prompts]
    rollouts = [op.result() for op in ops]
    tc.forward_backward(build_batch(rollouts), loss_fn="ppo").result()
    tc.optim_step(AdamParams(learning_rate=5e-5)).result()
    sc = tc.save_weights_and_get_sampling_client()

tc.stop()

L’essentiel est là : vous contrôlez l’algorithme — ici un PPO on-policy avec échantillonnage à quatre échantillons par prompt — pendant que AWS porte les GPU, la distribution et la reprise sur panne. Le sampling client est recréé à chaque sauvegarde de poids pour que les rollouts restent alignés sur la politique courante.

AWS liste quatre usages cibles : le contrôle complet d’une boucle personnalisée (SFT, RL ou techniques nouvelles), les pipelines multi-étapes enchaînant plusieurs procédures dans une même session, le débogage pas à pas d’une divergence de perte ou d’un reward hacking, et le RL multi-tours où la génération des rollouts et la mise à jour de la politique partagent le même état de modèle.

Trois portes, trois niveaux de contrôle

SageMaker propose désormais trois chemins vers la personnalisation, et le choix n’est pas anodin. Le premier, Serverless model customization, est le workflow géré sans programmation : vous fournissez un jeu de données, l’API applique un SFT prédéfini. Le second, les Training Session APIs, vous confie la boucle — vous écrivez forward_backward(), optim_step() et sample() — pendant que le service porte les GPU. Le troisième, SageMaker Training Jobs, reste la porte des scripts complets : vous soumettez un job d’entraînement entier quand vous avez besoin d’un contrôle qui dépasse la session — pré-entraînement, adaptation d’architecture, données propriétaires massives.

Le bon critère de choix est le degré de contrôle sur l’algorithme, pas sur le matériel. Tant que votre technique tient dans un workflow standard, restez sur le chemin géré. Dès que vous touchez à la fonction de perte ou au signal de récompense, les Training Sessions sont le point d’équilibre : vous gardez l’algorithme, AWS garde l’infrastructure. Les Training Jobs ne redeviennent pertinents que pour ce qui sort du cadre d’une session stateful.

Une facturation qui suit le calcul du RL

Le passage aux trois compteurs — prefill, sample, train — mérite qu’on s’y arrête, car il change le calcul économique. En SFT, l’essentiel du coût vient du prefill (les entrées) et du train (la passe arrière). En RL, le sample devient dominant : chaque rollout génère des jetons qui seront évalués pour produire le signal de récompense, et un GRPO multi-tours peut multiplier les échantillons par plusieurs ordres de grandeur. C’est précisément le poste que les équipes sous-estiment en migreant depuis un coût par heure d’instance. Le conseil opérationnel est simple : instrumentez le nombre de jetons générés par rollout avant de lancer, et fixez un plafond de sample par expérience.

Quatre modèles, trois compteurs, un quota

La version initiale est volontairement étroite. Quatre modèles de base seulement : openai/gpt-oss-20b (us-east-1, us-west-2, ap-south-1), google/gemma-4-31B-it (us-west-2, ap-south-1), Qwen/Qwen3.6-27B (us-west-2, ap-south-1) et Qwen/Qwen3.8-27B (us-west-2). La personnalisation passe par LoRA (rank, alpha), ce qui cadre la taille des mises à jour.

La facturation change de nature : trois dimensions au jeton — prefill (les jetons d’entrée au début de chaque pas), sample (les jetons générés pendant le rollout, évalués pour le signal de récompense) et train (la passe arrière qui met à jour les poids). C’est un modèle de coût aligné sur le calcul réel du RL, pas sur des heures d’instance réservées. Le quota par défaut est de 2 sessions d’entraînement simultanées, ajustable via Service Quotas.

Verdict

Si votre post-entraînement se limite au SFT ou au DPO, ne migrez pas : les API haut niveau restent plus simples, et le gain des Training Sessions ne se matérialise que lorsque vous écrivez votre propre boucle.

Si vous faites du RL personnalisé — GRPO, PPO, fonctions de récompense maison, RL multi-tours — ou si vous devez déboguer du reward hacking, cette brique retire la taxe d’exploitation GPU : plus de sélection d’instances, plus de gestion de cluster, plus de planification de capacité. Deux réserves à intégrer au calcul : le catalogue à quatre modèles limite les bases aujourd’hui, et la facturation au jeton (prefill + sample + train) peut réserver des surprises si vos rollouts sont longs — calibrez le budget avant de lancer, et traitez le quota de 2 sessions comme un goulot à faire augmenter explicitement.

Références

• AWS Docs — Training session APIs, Amazon SageMaker AI
• AWS What’s New — Amazon SageMaker AI announces training session APIs (22 octobre 2026)
• ExplainX — SageMaker Training Sessions: Custom RL Loops, No GPUs