Le 22 octobre 2026, AWS a annoncé les API de sessions d’entraînement d’Amazon SageMaker AI. Elles permettent aux développeurs d’écrire une boucle Python personnalisée pendant que le service gère les GPU. Le développeur garde la main sur l’algorithme et la logique d’entraînement sans avoir à choisir ni à exploiter un cluster GPU.
Ce que le développeur contrôle
Une session est un environnement avec état : le modèle reste chargé entre les appels à l’API. Le développeur prépare la boucle Python, les données, l’algorithme et, pour l’apprentissage par renforcement, l’environnement, l’agent et la fonction de récompense. SageMaker AI prend en charge le provisionnement des GPU, l’exécution distribuée, la synchronisation des gradients, la reprise après incident, l’isolation entre locataires et les points de contrôle.
Dans une boucle, sample() génère des réponses, forward_backward() lance les opérations d’entraînement et optim_step() applique une mise à jour. Le SDK Python organise ces interactions autour de trois clients, créés dans cet ordre : ServiceClient, TrainingClient et SamplingClient. Le calcul local des récompenses ne consomme pas de temps GPU pendant qu’il s’exécute sur la machine du développeur.
« Serverless » signifie ici que le développeur n’a pas à sélectionner ni à gérer un cluster GPU pour ces sessions. Il doit toutefois écrire et exécuter le code Python, préparer son rôle IAM et sa destination de sortie, puis gérer le cycle de vie de la session.
Les champs et accès requis par l’API directe
L’appel direct CreateTrainingSession exige cinq champs : LoraConfig, ModelConfig, OutputConfig, RoleArn et TrainingSessionName. En cas de succès, l’API renvoie un TrainingSessionArn. Le rôle IAM doit avoir accès au chemin S3 de sortie et au groupe de packages de modèles.
ModelPackageGroupArn, Tags et VpcConfig sont facultatifs. Ce contrat de l’API directe est distinct du parcours du SDK, qui utilise notamment ServiceClient.create_lora_training_client. La référence officielle de CreateTrainingSession détaille les champs de la requête.
Modèles, régions et quota
AWS répertorie quatre identifiants de modèles de base, avec une disponibilité qui varie selon la région AWS :
| Modèle | Régions AWS répertoriées |
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 |
Qwen/Qwen3.8-27B | us-west-2 |
Une région AWS est une zone de déploiement du service, pas une indication du pays où se trouve le développeur. Le guide officiel des sessions d’entraînement donne les couples modèle-région pris en charge.
AWS fixe à deux le nombre maximal par défaut de sessions simultanées d’ajustement fin, et le quota peut être modifié. Une session active compte dans ce maximum jusqu’à son arrêt ou son expiration.
Les dimensions de facturation
AWS associe la facturation au traitement des jetons de préremplissage (prefill), d’échantillonnage (sample) et d’entraînement (train). Pour le développeur, ces catégories correspondent aux différentes phases de la session. Le calcul local des récompenses ne consomme pas de temps GPU pendant son exécution locale.
Quelle option SageMaker choisir ?
AWS distingue ces options selon le contrôle exercé sur la boucle d’entraînement et l’infrastructure à gérer :
| Option SageMaker | Contrôle de la boucle d’entraînement | Modèle d’infrastructure |
| API gérées Serverless Model Customization | Choisir un modèle, les hyperparamètres disponibles et les données | Sans serveur, sans sélection d’instance |
| API de sessions d’entraînement | Écrire la boucle et appeler les opérations d’entraînement | Sessions GPU sans serveur, sans gestion de cluster ni sélection d’instance |
| SageMaker Training Jobs | Contrôle complet dans un travail soumis | Travaux gérés et éphémères ; l’utilisateur choisit le type d’instance |
| SageMaker HyperPod | Contrôle complet de l’entraînement | Clusters persistants gérés, avec reprise après incident avancée |
Si l’algorithme doit rester configurable sans gérer de cluster, les sessions d’entraînement placent le contrôle dans le code Python. Les Training Jobs conservent le choix du type d’instance pour chaque travail. HyperPod s’adresse à une organisation autour de clusters persistants. À l’autre extrémité, les API gérées Serverless Model Customization demandent de choisir un modèle et des hyperparamètres disponibles, plutôt que d’écrire la boucle.
AWS illustre ces API avec des exemples d’ajustement fin supervisé et d’apprentissage par renforcement. Dans son exemple GSM8K, un adaptateur LoRA de rang 32 et d’alpha 64 est entraîné sur GPT-OSS 20B avec GRPO, une méthode d’apprentissage par renforcement. AWS rapporte qu’après 10 étapes sur 40 problèmes, la précision sur des problèmes réservés à l’évaluation est passée de 56 % à 75 %. L’exemple utilise aussi max_tokens=512, une température de 0,7, top_p=0.9 et un taux d’apprentissage Adam de 1e-5.
Pour l’exemple de programmation compétitive, AWS décrit des données DeepCoder et des tests sur Codeforces et LiveCodeBench. Les réponses Python sont exécutées dans un conteneur SandboxFusion sur la machine de l’utilisateur : la récompense vaut 1 si tous les tests réussissent, 0 sinon, avec une pénalité de 0,1 lorsqu’aucun bloc de code n’est renvoyé. AWS rapporte qu’une exécution de 50 étapes avec GPT-OSS 20B et LoRA de rang 32 a fait passer la récompense de 0,46 à 0,60. Sur 200 problèmes réservés à l’évaluation, la précision est passée de 40 % à 50,5 %. La configuration comprenait 128 problèmes par étape, huit réponses par problème, deux tours et une limite de décalage k=3.
