L'ajustement fin d'un grand modèle de langage (LLM) aujourd'hui impose généralement un compromis entre le contrôle de la boucle d'entraînement et la simplicité opérationnelle. Avec les services entièrement gérés, vous sélectionnez un modèle de base, fournissez les données et les hyperparamètres, et le service gère tout le reste, ce qui fonctionne bien lorsqu'une recette standard préemballée convient à votre problème. Les services moins gérés vous donnent plus de contrôle, mais vous gérez aussi davantage l'infrastructure sous-jacente et les frameworks d'entraînement. Parfois, une recette standard ne suffit pas : vous avez besoin d'une perte personnalisée ou d'un programme de données pour l'ajustement fin supervisé (SFT), de votre propre optimisation des préférences, d'une fonction de récompense d'apprentissage par renforcement (RL), ou d'un algorithme d'alignement publié la semaine dernière. Dès que vous devez façonner vous-même la procédure d'entraînement, vous assumez ce travail d'infrastructure pour gagner la liberté algorithmique.
Aujourd'hui, la personnalisation serverless de modèles dans Amazon SageMaker AI s'enrichit des API de session d'entraînement, qui suppriment ce compromis en plaçant la frontière d'abstraction un niveau plus bas. Au lieu d'abstraire l'algorithme, elles abstraient le calcul. Des opérations comme forward_backward(), optim_step(), et sample() deviennent des appels d'API SageMaker que vous composez selon la procédure requise par votre technique : SFT, optimisation des préférences, RL, ou quelque chose de nouveau. Les appels ciblent une session active et avec état, de sorte que le modèle reste chargé sur les GPU entre les étapes, et vous effectuez autant d'appels que nécessaire. Le service gère la configuration de l'environnement d'exécution, l'exécution distribuée, la synchronisation des gradients, la récupération après panne, l'isolation des locataires et les opérations liées à l'exécution de GPU à grande échelle. Vous écrivez la boucle d'entraînement, et SageMaker AI fait tourner l'infrastructure.
Parallèlement au service, nous publions le SageMaker training sessions cookbook, un ensemble de recettes SFT et RL prêtes à l'emploi que vous pouvez utiliser comme modèles pour vos propres boucles d'entraînement.
Dans cet article, nous présentons le modèle de programmation et les trois clients SDK, et montrons où les API de session d'entraînement se situent parmi les options d'entraînement et de personnalisation de modèles dans SageMaker AI. Nous disséquons ensuite une boucle RL minimale sur des problèmes de mathématiques de niveau primaire (GSM8K) pour montrer comment les opérations s'articulent, et nous terminons par une charge de travail réelle issue du cookbook : l'apprentissage par renforcement sur des problèmes de programmation compétitive, où le code généré est évalué en l'exécutant contre des tests unitaires.
Que sont les API de session d'entraînement de SageMaker AI ?
Avec les API de session d'entraînement de SageMaker AI, vous pouvez piloter une session active, adossée à des GPU, depuis votre propre processus Python sur votre machine locale. Vous appelez les opérations, et SageMaker AI les exécute sur des accélérateurs gérés, chargés avec le modèle de base de votre choix plus votre adaptateur Low-Rank Adaptation (LoRA). Pas de fichier de configuration décrivant toute la tâche à l'avance ni d'étape de création de cluster. Vous contrôlez ce qui se passe à chaque étape, de manière interactive, depuis le code, ce qui vous permet d'itérer et de déboguer rapidement.
La répartition des responsabilités se présente ainsi :
| Vous vous concentrez sur | Vous écrivez | SageMaker AI gère |
| Vos données, environnements RL, agents et algorithme | Une boucle d'entraînement Python qui appelle des opérations telles que forward_backward(), optim_step(), et sample() pour les étapes nécessitant des GPU |
L'allocation de GPU, le chargement du modèle et du LoRA, l'exécution distribuée, la récupération après panne, le stockage des points de contrôle, la sécurité |
L'API est organisée autour de trois clients du SageMaker Python SDK, créés en séquence. Un ServiceClient contient les paramètres au niveau de la plateforme (rôle d'exécution, groupe de paquets de modèles, emplacement de sortie Amazon Simple Storage Service (Amazon S3), et éventuellement une clé AWS Key Management Service (AWS KMS) et une configuration de virtual private cloud (VPC), que vous pouvez aussi remplacer par session) et démarre une session. Le ServiceClient instancie un TrainingClient (opérations d'entraînement et de point de contrôle telles que forward, forward_backward, optim_step, et save_weights_for_sampler), qui à son tour instancie un SamplingClient (sample et un compute_logprobs, pour la génération et la notation lors des rollouts et des évaluations). Chaque appel d'API correspond à une opération dans votre boucle. Une session active sert également un point de terminaison de complétions de chat compatible OpenAI, de sorte que du code client OpenAI existant peut échantillonner à partir de celle-ci.
Figure 1 : Hiérarchie des clients du SageMaker Python SDK pour les API de session d'entraînement
Pour l'apprentissage par renforcement, la boucle a une forme caractéristique. La figure suivante montre une étape d'entraînement et l'endroit où chaque partie s'exécute : les étapes en vert appellent des API sur des GPU gérés par le service, et les étapes en violet, votre logique de contrôle de boucle et de récompense, s'exécutent sur votre machine.
Figure 2 : Une étape d'entraînement, avec les opérations d'échantillonnage, de gradient et de checkpoint sur des GPU gérés, et le contrôle de boucle et la logique de récompense sur votre machine
Chaque étape charge un lot de prompts et (1) échantillonne à partir du modèle courant sur le GPU. Votre code Python (2) note ensuite ces sorties : un vérificateur, un appel à un modèle de récompense, un harnais de test, tout ce que vous pouvez exprimer en code. (3) forward_backward et optim_step transforment les scores en mise à jour de gradient sur le GPU, et (4) save_weights_and_get_sampling_client() rafraîchit l'échantillonneur afin que l'étape suivante tire du modèle mis à jour.
Vous possédez les données, le contrôle de la boucle et la récompense ; SageMaker AI exécute les opérations d'échantillonnage, de gradient et de point de contrôle liées au GPU. Les mêmes primitives couvrent le fine-tuning supervisé (SFT) et d'autres techniques d'entraînement de LLM. Pour le SFT, supprimez les étapes d'échantillonnage et de récompense et appelez forward_backward avec une cross_entropy perte sur des exemples étiquetés.
À qui cela s'adresse-t-il et où s'inscrit-on dans Amazon SageMaker AI ?
Les API de session d'entraînement sont le bon point de départ lorsque vous avez besoin de cycles d'itération rapides et de liberté algorithmique, comme une perte personnalisée, un nouveau signal de récompense RL ou un pipeline multi-étapes, mais que vous ne voulez pas provisionner ni exploiter vous-même une infrastructure GPU.
L'utilisation est facturée par token traité, de sorte que vous ne payez que le calcul consommé par votre boucle. Si votre fonction de récompense prend 10 secondes pour noter un lot sur votre machine, aucun temps GPU n'est facturé pendant son exécution. Par rapport à la facturation GPU horaire, cela présente deux avantages pratiques. Premièrement, il n'y a pas de coût de GPU inactif : le calcul des récompenses, le chargement des données, la journalisation et le débogage se font hors facturation, et vous n'êtes facturé que lorsque vous appelez une opération liée au GPU. Deuxièmement, le coût évolue avec votre jeu de données et votre volume de génération, et non avec la durée réelle ou la taille du cluster, ce qui facilite la prévision des dépenses et la comparaison des expériences. Les économies par rapport à la réservation de GPU pour toute la session peuvent être importantes pour les charges de travail à calcul local intensif, telles que les modèles de récompense complexes, les rollouts agentiques multi-outils ou l'évaluation avec humain dans la boucle.
Les API de session d'entraînement sont conçues pour les équipes dont le travail est défini par l'algorithme d'entraînement, et pas seulement par le jeu de données. Comme vous composez la boucle vous-même, les mêmes primitives prennent en charge le fine-tuning supervisé (SFT) avec une cross_entropy perte sur des données étiquetées, l'apprentissage par renforcement avec ppo, importance_sampling, ou cispo (GRPO, PPO et autres méthodes à référence de groupe), et des objectifs personnalisés, tels que l'optimisation de préférence ou la distillation, construits à partir des mêmes éléments. Elles conviennent à :
- Les chercheurs en post-entraînement et en alignement qui implémentent des méthodes RL (GRPO, PPO, variantes à échantillonnage par importance), des estimateurs d'avantage personnalisés ou de nouveaux objectifs.
- Les équipes effectuant du fine-tuning supervisé ou de l'optimisation de préférence qui ont besoin d'une perte non standard, d'un cursus de données ou d'un pipeline multi-étapes que les recettes pilotées par configuration n'expriment pas.
- Les développeurs de RL agentique et multi-tours qui ont besoin d'une logique de rollout personnalisée, d'une mise en forme des récompenses et de cursus.
- Les ingénieurs en apprentissage automatique (ML) qui ont dépassé le fine-tuning piloté par configuration mais ne veulent pas assumer la charge opérationnelle des clusters GPU.
- Les chercheurs portant du code de boucle d'entraînement existant, puisque le modèle de programmation par opérations correspond directement aux boucles écrites avec les
forward_backward,optim_step, etsampleAPIs de bas niveau.
Les modèles de base pris en charge et les régions AWS où chacun est disponible sont répertoriés dans la documentation des API de session d'entraînement.
Où les API de session d'entraînement s'inscrivent-elles dans Amazon SageMaker AI
Les API de session d'entraînement occupent une position distincte parmi les options de personnalisation de modèles dans SageMaker AI : un contrôle nettement plus important sur l'algorithme d'entraînement que Serverless Model Customization, et beaucoup moins de responsabilité opérationnelle que l'entraînement sur Amazon SageMaker Training Jobs ou Amazon SageMaker HyperPod.
| Option | Contrôle sur l'entraînement | Infrastructure |
| Personnalisation de modèle sans serveur SageMaker (Serverless Model Customization) – API gérées | Faible – vous choisissez un modèle, configurez les hyperparamètres disponibles et fournissez les données | Sans serveur, aucune sélection d'instance |
| Personnalisation de modèle sans serveur SageMaker (Serverless Model Customization) – API de session d'entraînement SageMaker AI | Élevé – vous écrivez la boucle et appelez les primitives | Sans serveur, aucune sélection d'instance |
| SageMaker Training Jobs | Complet | Tâches éphémères gérées où vous sélectionnez le type d'instance |
| SageMaker HyperPod | Complet | Clusters persistants gérés avec récupération avancée après panne |
Figure 3 : Place des API de session d'entraînement parmi les options de personnalisation de modèle dans SageMaker AI
Anatomie d'une boucle d'entraînement : GRPO sur des problèmes de mathématiques
Cette section démonte une boucle d'apprentissage par renforcement minimale pour montrer comment les opérations s'articulent. La tâche est GSM8K, un benchmark d'environ 8,500 problèmes de mathématiques de niveau primaire énoncés en mots, chacun ayant une seule réponse numérique, comme dans l'exemple suivant :
En avril, Natalia a vendu des clips à 48 de ses amis, puis elle en a vendu deux fois moins en mai. Combien de clips Natalia a-t-elle vendus en tout en avril et en mai ? → 72
Nous entraînons un adaptateur LoRA pour GPT-OSS 20B avec Group Relative Policy Optimization (GRPO) : pour chaque question, le modèle génère plusieurs réponses, chaque réponse est notée pour son exactitude, et les réponses qui dépassent la moyenne du groupe sont renforcées. L'exemple complet et exécutable se trouve dans le dépôt d'exemples Amazon SageMaker.
Avant d'ouvrir une session, effectuez les prérequis indiqués dans la documentation.
Ouvrir une session
Créez une session, puis récupérez le tokenizer et un SamplingClient à partir de celle-ci :
from sagemaker.train.training_session import ServiceClient, SamplingParams, AdamParams
svc = ServiceClient(role_arn=role, region=REGION)
training_client = svc.create_lora_training_client(
"openai/gpt-oss-20b", # a name from svc.list_base_models()
training_session_name=SESSION_NAME,
rank=32, alpha=64, # LoRA rank and scaling factor
model_package_group_arn=MODEL_PACKAGE_GROUP_ARN,
s3_output_path=OUTPUT_S3_PATH,
)
tokenizer = training_client.get_tokenizer()
sampling_client = training_client.create_sampling_client()Définir la récompense et l'avantage
La logique propre à la tâche se compose de deux courtes fonctions exécutées sur votre machine :
def compute_reward(response_text, ground_truth):
predicted = extract_answer(response_text) # parse the number after "#### "
return 1.0 if predicted == ground_truth else 0.0
def compute_advantages(rewards):
rewards = np.array(rewards)
advantages = rewards - rewards.mean() # center within the group (the GRPO baseline)
return advantages / (rewards.std() + 1e-8) # normalizeLa boucle
Chaque étape suit les quatre étapes illustrées à la Figure 2. draw, build_prompt, et build_training_datum sont de courts utilitaires dans l'exemple :
for step in range(NUM_STEPS):
datums, pending = [], []
# (1) sample K responses per question in one request each (GPU); returns a future right away
for question, ground_truth in draw(PROMPTS_PER_STEP): # data loading is local
prompt = tokenizer.encode(build_prompt(question), add_special_tokens=False)
pending.append((prompt, ground_truth, sampling_client.sample(
prompt, num_samples=K,
sampling_params=SamplingParams(max_tokens=512, temperature=0.7, top_p=0.9))))
for prompt, ground_truth, future in pending:
result = future.result() # wait once the batch is in flight
# (2) score each response, then center the rewards within the group (local)
rewards = [compute_reward(tokenizer.decode(s.tokens), ground_truth) for s in result.sequences]
advantages = compute_advantages(rewards)
datums += [build_training_datum(prompt, s, a) for s, a in zip(result.sequences, advantages)]
# (3) one gradient step over the batch (GPU); the optimizer step is sequenced behind it
fwd_bwd_op = training_client.forward_backward(datums, loss_fn="ppo")
optim_op = training_client.optim_step(AdamParams(learning_rate=1e-5))
fwd_bwd_op.result(), optim_op.result()
# (4) refresh the sampler so the next step's rollouts come from the updated policy (GPU)
sampling_client = training_client.save_weights_and_get_sampling_client()
training_client.stop()Trois détails font que cette boucle fonctionne :
Les opérations renvoient des futures. Chaque appel lié au GPU renvoie un APIFuture immédiatement : la requête est mise en file d'attente et envoyée par un soumetteur en arrière-plan, et .result() attend la valeur. La boucle soumet toutes les requêtes d'échantillonnage d'une étape avant d'attendre l'une d'elles, de sorte que tout le lot est généré concurremment. Les opérations d'entraînement s'exécutent dans l'ordre où vous les appelez, de sorte que optim_step peut être soumis avant que forward_backward ne soit terminé.
Le datum transporte tout ce dont la loss a besoin. build_training_datum regroupe les tokens du prompt et de la réponse, les logprobs par token issus de sample(), l'avantage, et un weights masque qui exclut le prompt de la loss.
Les points de contrôle sont des paquets de modèles. Chaque sauvegarde enregistre une version dans votre groupe de paquets de modèles, y compris l'actualisation par étape du sampler dans la boucle ci-dessus. Après l'entraînement, deux sauvegardes supplémentaires ajoutent un modèle fusionné pour le déploiement et un état reprenable avec les poids et l'optimiseur.
training_client.save_weights_for_sampler(merge_weights=True).result() # merged, deployable model
training_client.save_state().result() # resumable state (weights + optimizer)Pour reprendre, démarrez une nouvelle session à partir du dernier point de contrôle avec create_training_client_from_state_with_optimizer.
Une session en cours est décomptée de votre quota de sessions simultanées jusqu'à ce que vous appeliez stop() ou qu'elle expire ; arrêtez donc la session quand vous avez terminé, y compris dans les chemins d'erreur, ou ouvrez le client dans un bloc with . Le point de contrôle fusionné se déploie sur un endpoint en temps réel. Pour servir les points de contrôle comme des adaptateurs LoRA à la place, consultez le cookbook notebook de déploiement.
Dans notre exécution de l’exemple, 10 étapes d’entraînement sur 40 problèmes ont fait passer la précision sur données tenues à l’écart de 56 pour cent à 75 pour cent.
Une charge de travail réelle : RL sur la programmation compétitive
GSM8K garde la mécanique visible, mais une charge de travail RL en production ajoute davantage : générations plus longues, interaction multi-tours, un correcteur externe, et un débit suffisant pour garder les GPU occupés. Le SageMaker training sessions cookbook empaquette cela en boucles d’entraînement réutilisables construites sur les mêmes opérations. Pour une nouvelle tâche RL, vous écrivez un environnement : ce que le modèle voit, comment sa réponse est notée, et s’il obtient un autre tour. Le cookbook gère le batching, les modèles de chat, l’estimation des avantages, l’échantillonnage et l’entraînement chevauchés, la validation, la création de points de contrôle avec reprise, et les métriques par étape, et enregistre la configuration de chaque exécution afin qu’elle puisse être répétée. La code_rl recette l’utilise pour entraîner un modèle sur des problèmes de programmation compétitive.
La tâche. Les problèmes proviennent du jeu de données DeepCoder (PrimeIntellect, TACO et LiveCodeBench pour l’entraînement ; Codeforces et LiveCodeBench pour les tests). Le modèle écrit une solution Python, qui est exécutée contre les tests unitaires du problème dans un conteneur SandboxFusion sur votre machine. La récompense est de 1 lorsque tous les tests passent et de 0 sinon, avec une pénalité de 0.1 lorsque la réponse ne contient aucun bloc de code.
Utilisation d’outils multi-tours. Avec deux tours, le modèle peut appeler un check_solution outil, lire les résultats des tests, et réviser sa réponse avant la note finale. Les appels d’outils et les résultats sont rendus dans le format de chat natif du modèle, de sorte que le modèle est entraîné sur le même format de tokens qu’il utilise en inférence.
Ce que la recette ajoute à la boucle minimale :
- Échantillonnage et entraînement chevauchés : Les travailleurs de rollout continuent de générer pendant que l’entraîneur exécute une étape. Un groupe de réponses échantillonné à partir d’une ancienne politique est utilisé s’il a au plus k étapes, et remis en file sinon, et la
cispoperte corrige la différence de politique. - Calcul de gradient en flux :
forward_backwardest soumis en sous-lots au fur et à mesure que les groupes se terminent, au lieu d’une fois par étape. - Validation sur données tenues à l’écart, reprise des points de contrôle, et métriques par étape, publiées éventuellement dans SageMaker managed MLflow.
Figure 4 : La configuration Code RL, avec la boucle d’entraînement locale et le sandbox à gauche et les GPU gérés à droite
Nous avons entraîné un adaptateur LoRA (rang 32) pour GPT-OSS 20B pendant 50 étapes, chacune avec 128 problèmes et 8 réponses par problème, en utilisant deux tours et une limite d’obsolescence de k=3. La récompense d’entraînement est passée de 0.46 à 0.60, et la précision sur 200 problèmes de test tenus à l’écart est passée de 40 pour cent à 50.5 pour cent.
Pour l’exécuter, démarrez le sandbox et lancez la recette :
bash tools/sandbox_up.sh
python -m training_sessions_cookbook.recipes.code_rl.train \
--config training_sessions_cookbook/recipes/code_rl/configs/coderl_oss20b_service.json \
--max_steps_off_policy 3 --stale_policy requeue --num_rollout_workers 80 --max_steps 50 \
--base_model_arn "$BASE_MODEL_ARN" \
--model_package_group_arn "$MODEL_PACKAGE_GROUP_ARN" \
--role_arn "$ROLE_ARN" \
--output_s3_path "$OUTPUT_S3_PATH"Le cookbook contient davantage de recettes sur la même structure, notamment le fine-tuning supervisé sur des jeux de données de chat (Tulu 3, UltraChat), le RL sur GSM8K à pleine échelle, et l'alignement de préférences KTO à partir de retours binaires. Chaque README de recette liste ses commandes, hyperparamètres et métriques attendues.
Conclusion
Les API de sessions d'entraînement SageMaker AI déplacent la frontière d'abstraction vers l'opération d'entraînement : vous écrivez la boucle d'entraînement en Python sur votre propre machine, et le service l'exécute sur des GPU gérés, en prenant en charge le chargement du modèle et du LoRA, l'exécution distribuée, la récupération après panne et la sauvegarde de checkpoints. Une boucle GRPO complète se résume à quatre opérations, sample, forward_backward, optim_step, et save_weights_and_get_sampling_client, avec la logique de récompense et d'avantage dans votre propre code. Ces mêmes opérations passent à l'échelle pour le RL multi-tours avec utilisation d'outils et notation en bac à sable, comme le montre la recette Code RL.
Récompenses personnalisées, rollouts agentiques, débogage étape par étape et nouvelles techniques publiées utilisent tous le même modèle de programmation : l'algorithme reste dans votre boucle, et SageMaker AI exécute les GPU.
Pour démarrer :
- Choisissez une recette dans le cookbook de sessions d'entraînement SageMaker, telle que Code RL.
- Exécutez l' exemple GSM8K du dépôt d'exemples Amazon SageMaker et remplacez la fonction de récompense par la vôtre.
- Lisez la documentation des API de sessions d'entraînement pour les prérequis, les quotas, les Régions, les modèles pris en charge et la référence des API.
Remerciements
Merci à Arun Nagarajan, Xichao Wang et Shruti Sharma pour leurs contributions et leurs conseils sur cet article.