# Amazon SageMaker masque les GPU derrière des API Python > Amazon SageMaker propose des API de sessions d’entraînement pour composer ses propres boucles IA, sans gérer les GPU ni l’infrastructure distribuée. Type : Actualité IA · Catégorie : Outils · Publié le 2026-10-23 · Signal IA - Order & Chaos Source : https://www.orderchaos.eu/signal-ia/actu/amazon-sagemaker-facture-vos-boucles-ia-au-jeton-pas-au-gpu Tags : sagemaker, entraînement, gpu, llm, aws, inference --- ## En résumé - Amazon SageMaker exécute les opérations GPU d’une boucle écrite en Python. - Les API prennent en charge le réglage supervisé, l’optimisation des préférences et le renforcement. - La facturation dépend des jetons traités pendant les opérations utilisant les GPU. **Le signal :** Amazon SageMaker facture les sessions d’entraînement au nombre de jetons traités, plutôt qu’à l’heure d’utilisation des GPU. **Amazon [SageMaker](/signal-ia/actu/amazon-sagemaker-accelere-linference-avec-13-avancees)** lance des API de sessions d’entraînement pour Amazon SageMaker AI le 23 octobre 2026. Elles permettent d’écrire une boucle d’entraînement Python sans gérer directement les GPU. Le développeur compose des appels comme `forward_backward()`, `optim_step()` et `sample()`. SageMaker AI exécute ces opérations sur des accélérateurs gérés, avec le modèle de base et l’adaptateur LoRA chargés. La session conserve le modèle en mémoire entre les étapes. Le service prend aussi en charge la préparation de l’environnement, l’exécution distribuée, la synchronisation des gradients, la récupération après incident et l’isolement des clients. L’annonce présente ces API comme une nouvelle option de personnalisation serveur, située sous l’algorithme plutôt qu’au-dessus. **Une session conserve le modèle** propose une interaction depuis un processus Python local. Aucun fichier de configuration ne décrit l’intégralité du travail. Aucune étape de création de cluster n’est nécessaire. Le développeur contrôle chaque opération et peut donc itérer ou déboguer rapidement. Le SDK Python organise l’interface autour de trois clients créés successivement. Le `ServiceClient` configure le rôle d’exécution, le groupe de modèles et l’emplacement [Amazon](/signal-ia/actu/amazon-ajoute-2-millions-de-gpu-nvidia-a-aws) S3. Il démarre ensuite une session. Le `TrainingClient` gère notamment les opérations d’entraînement et de sauvegarde. Le `SamplingClient` sert à générer des sorties et à calculer leurs probabilités. Un point d’accès compatible avec les complétions de conversation OpenAI est également disponible. ## SageMaker délègue les opérations GPU **La boucle reste personnalisable** pour plusieurs usages de post-entraînement. En réglage supervisé, le développeur retire l’échantillonnage et la récompense, puis utilise `forward_backward` avec une perte `cross_entropy` sur des exemples annotés. En apprentissage par renforcement, le code local charge des invites, demande des réponses au modèle et calcule une récompense. Cette récompense peut provenir d’un vérificateur, d’un modèle de récompense ou d’un banc de tests. Les appels `forward_backward` et `optim_step` transforment ensuite les scores en mise à jour des gradients sur le GPU. Enfin, `save_weights_and_get_sampling_client()` actualise l’échantillonneur pour l’étape suivante. Les données, la logique de boucle et la récompense restent sous contrôle du développeur. **Le modèle GPT-OSS 20B** illustre ce fonctionnement sur GSM8K, un ensemble d’environ 8 500 problèmes de mathématiques élémentaires. L’exemple entraîne un adaptateur LoRA avec Group Relative Policy Optimization. Pour chaque question, le modèle génère plusieurs réponses. Chaque réponse reçoit un score de correction, puis les réponses dépassant la moyenne du groupe sont renforcées. Le code de démonstration utilise notamment un rang LoRA de 32 et un facteur d’échelle de 64. Les paramètres d’échantillonnage indiqués comprennent 512 jetons maximum, une température de 0,7 et une valeur `top_p` de 0,9. Le [carnet de recettes SageMaker](https://github.com/aws/sagemaker-training-sessions-cookbook) fournit cet exemple exécutable. ## Amazon facture les jetons traités **La facturation dépend des jetons** traités pendant les opérations consommant les GPU. Le temps utilisé localement pour calculer une récompense ne déclenche pas de facturation GPU. AWS oppose ce mécanisme à une facturation horaire d’un GPU réservé pendant toute la session. Les calculs de récompense, le chargement des données, la journalisation et le débogage peuvent donc se dérouler hors de ces opérations facturées. Le coût suit ainsi le volume de données et de générations, plutôt que la durée totale ou la taille d’un cluster. Cette approche vise notamment les travaux comportant des modèles de récompense complexes, des agents utilisant plusieurs outils ou des évaluations avec intervention humaine. La documentation répertorie les modèles et régions compatibles. **Les trois clients** positionnent ces sessions entre deux offres SageMaker AI. La personnalisation serveur entièrement gérée fournit moins de contrôle algorithmique, avec un modèle, des hyperparamètres et des données configurables. Les tâches d’entraînement SageMaker et SageMaker HyperPod offrent un contrôle complet, mais demandent davantage de décisions d’infrastructure. Les sessions API conservent une infrastructure sans serveur et permettent d’écrire la boucle. Elles ciblent les chercheurs en alignement, les équipes de réglage supervisé ou d’[optimisation](/signal-ia/actu/sagemaker-cloue-lia-avec-des-optimisations-fulgurantes) des préférences, les développeurs d’agents et les ingénieurs ayant dépassé les recettes configurées. Le [SDK Python SageMaker](https://github.com/aws/sagemaker-python-sdk) et la [documentation des sessions](https://aws.amazon.com/blogs/machine-learning/write-your-own-training-loop-without-managing-gpus-with-amazon-sagemaker-training-sessions/) détaillent l’interface.