Aller au contenu principal
Inférence adaptée à la capacité : basculement automatique entre instances pour les endpoints SageMaker AI
InfrastructureAWS ML Blog3h

Inférence adaptée à la capacité : basculement automatique entre instances pour les endpoints SageMaker AI

Résumé IASource uniqueImpact UE
Source originale ↗·

Amazon SageMaker AI vient d'introduire une fonctionnalité baptisée "capacity-aware instance pool" pour ses endpoints d'inférence, disponible immédiatement pour les nouveaux déploiements comme pour les endpoints existants. Concrètement, les équipes peuvent désormais définir une liste ordonnée de types d'instances GPU plutôt qu'un type unique, et SageMaker parcourt automatiquement cette liste dès qu'une contrainte de capacité se présente, que ce soit à la création de l'endpoint, lors d'un scale-out ou d'un scale-in. Cette mécanique de bascule automatique fonctionne pour les Single Model Endpoints, les endpoints basés sur des Inference Components, et les Asynchronous Inference endpoints. Les métriques Amazon CloudWatch bénéficient également d'une nouvelle dimension InstanceType, permettant de suivre latence, débit, utilisation GPU et nombre d'instances par type de matériel au sein d'un même endpoint.

Jusqu'ici, le déploiement d'un modèle sur SageMaker imposait de choisir un seul type d'instance au moment de la création. Si ce type manquait de capacité, l'endpoint échouait avec une erreur "Insufficient Capacity", forçant les équipes à itérer manuellement sur des alternatives, chaque tentative prenant plusieurs minutes avant de connaître son issue. Le problème se répétait à chaque phase du cycle de vie : lors des montées en charge automatiques, l'autoscaler relançait indéfiniment des requêtes sur le même type d'instance indisponible pendant que le trafic continuait d'augmenter, et lors des descentes, toutes les instances étaient candidates à la suppression sans distinction de priorité. Avec les instance pools, SageMaker essaie le type préféré en premier, bascule immédiatement sur le suivant si nécessaire, et retire en priorité les instances de fallback lors des scale-in, laissant la flotte revenir naturellement vers le matériel privilégié quand il redevient disponible.

Cette annonce s'inscrit dans un contexte où l'accès aux GPU reste l'un des goulots d'étranglement les plus critiques pour les organisations qui industrialisent des charges IA en production. Les grands modèles de langage et les architectures multimodales exigent des types d'instances spécifiques, souvent soumis à une forte tension sur les capacités cloud. AWS rejoint ainsi une tendance plus large dans laquelle les fournisseurs cloud intègrent nativement des mécanismes de résilience face aux pénuries de compute, réduisant la charge opérationnelle sur les équipes MLOps. La possibilité de migrer des endpoints existants sans reconstruction complète est un signal fort : AWS cible autant les workloads de production déjà déployés que les nouveaux projets. Les suites logiques seraient une extension à d'autres services d'inférence managés et une intégration plus fine avec les stratégies de spot instances pour optimiser les coûts tout en maintenant la disponibilité.

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

1AWS ML Blog 

Bonnes pratiques pour l'inférence sur Amazon SageMaker HyperPod

Amazon a enrichi sa plateforme SageMaker HyperPod d'un ensemble de fonctionnalités dédiées à l'inférence de modèles d'IA générative, avec pour promesse affichée une réduction du coût total de possession allant jusqu'à 40%. La solution s'appuie sur Amazon Elastic Kubernetes Service (EKS) comme orchestrateur et permet de créer un cluster en quelques clics depuis la console SageMaker AI. Deux modes de configuration sont proposés : une installation rapide avec des ressources par défaut, et une installation personnalisée permettant d'intégrer des infrastructures existantes. Une fois le cluster actif, l'opérateur d'inférence intégré permet de déployer des modèles directement depuis des buckets S3, des systèmes de fichiers FSx for Lustre, ou depuis le catalogue SageMaker JumpStart, sans écrire une seule ligne de code. Des notebooks d'exemple couvrent les cas d'usage courants : modèles préconstruits, modèles fine-tunés, configurations personnalisées. L'enjeu central de cette mise à jour est la gestion dynamique des ressources GPU, historiquement coûteuse et complexe à piloter. HyperPod introduit une architecture de scalabilité à deux niveaux : KEDA (Kubernetes Event-Driven Autoscaling), un projet open source de la Cloud Native Computing Foundation, gère l'autoscaling des pods en fonction de métriques temps réel comme la longueur de la file de requêtes, la latence, ou des métriques CloudWatch et Prometheus personnalisées. KEDA peut réduire le nombre de pods à zéro en l'absence de trafic, supprimant ainsi les coûts à l'arrêt. En parallèle, Karpenter opère au niveau des nœuds de calcul : il provisionne ou retire des instances selon les besoins des pods en attente, et tourne dans le plan de contrôle EKS, ce qui évite tout surcoût lié à l'autoscaler lui-même. Cette combinaison permet de passer de zéro à une charge de production en réponse à la demande réelle. Ce lancement intervient dans un contexte où le déploiement de modèles de fondation à grande échelle est devenu un point de friction majeur pour les équipes IA en entreprise : infrastructure difficile à calibrer, pics de trafic imprévisibles, surinvestissement GPU, et délais de mise en production allongés. AWS positionne HyperPod comme une réponse complète à ce trilemme coût-performance-simplicité, en absorbant la complexité opérationnelle dans une couche managée. La plateforme concurrence directement les offres de Google (Vertex AI) et Microsoft Azure (ML endpoints managés), qui proposent des approches similaires. Les suites probables incluent une intégration plus poussée avec les outils d'observabilité AWS et une extension du support à d'autres architectures de modèles, alors que la course aux infrastructures d'inférence efficaces s'intensifie dans tout le secteur cloud.

InfrastructureActu
1 source
2AWS ML Blog 

Amazon SageMaker AI accélère l'inférence d'IA générative avec les instances G7e

Amazon Web Services a annoncé la disponibilité des instances G7e sur Amazon SageMaker AI, une nouvelle génération de serveurs d'inférence propulsés par les GPU NVIDIA RTX PRO 6000 Blackwell Server Edition. Ces instances sont disponibles en configurations de 1, 2, 4 et 8 GPU, chaque carte offrant 96 Go de mémoire GDDR7. Concrètement, une instance G7e.2xlarge à GPU unique peut désormais héberger des modèles open source de 35 milliards de paramètres comme Qwen3.5-35B ou GPT-OSS-120B, tandis qu'une configuration à 8 GPU (G7e.48xlarge) atteint 768 Go de mémoire GPU totale et peut faire tourner des modèles de 300 milliards de paramètres sur un nœud unique. La bande passante réseau grimpe à 1 600 Gbps via EFA, soit quatre fois plus que la génération G6e et seize fois plus que les G5. Ces chiffres ont une implication directe pour les équipes d'ingénierie : des modèles qui nécessitaient auparavant plusieurs machines interconnectées peuvent désormais s'exécuter sur un seul nœud, supprimant la latence inter-nœuds et la complexité opérationnelle associée. Les performances d'inférence sont jusqu'à 2,3 fois supérieures à celles des G6e. Pour les applications temps réel comme les chatbots, les pipelines RAG ou les workflows agentiques, cette densité mémoire combinée à une bande passante CPU-GPU quatre fois plus élevée se traduit par des temps de réponse plus courts sous charge élevée. Les modèles multimodaux et de génération d'images, souvent limités par des erreurs de mémoire insuffisante sur les générations précédentes, bénéficient également directement de ce doublement de la capacité par GPU. Cette annonce s'inscrit dans une course aux accélérateurs cloud que se livrent AWS, Google et Microsoft, chacun cherchant à proposer les GPU les plus récents de NVIDIA au plus vite après leur lancement. Les puces Blackwell de NVIDIA, dont la RTX PRO 6000 Server Edition fait partie, représentent la cinquième génération de Tensor Cores avec support natif de la précision FP4, permettant de réduire encore la consommation mémoire pour les grands modèles. Le support de NVIDIA GPUDirect RDMA via EFAv4 ouvre également la voie à des scénarios d'inférence multi-nœuds à faible latence, jusqu'ici peu pratiques sur les instances G-series. À mesure que les modèles de langage et les systèmes agentiques continuent de grossir en taille et en complexité, la capacité à les déployer efficacement sur infrastructure managée comme SageMaker devient un avantage concurrentiel décisif pour les entreprises qui cherchent à maîtriser leurs coûts d'exploitation tout en montant en puissance.

UELes équipes techniques européennes utilisant Amazon SageMaker dans les régions AWS EU peuvent désormais déployer des modèles jusqu'à 300 milliards de paramètres sur un seul nœud, réduisant la complexité opérationnelle et les coûts d'inférence pour les applications temps réel.

InfrastructureActu
1 source
Amazon SageMaker AI propose désormais des recommandations optimisées pour l'inférence d'IA générative
3AWS ML Blog 

Amazon SageMaker AI propose désormais des recommandations optimisées pour l'inférence d'IA générative

Amazon a annoncé que SageMaker AI prend désormais en charge les recommandations optimisées pour le déploiement de modèles d'IA générative en production. Cette nouvelle fonctionnalité s'appuie sur NVIDIA AIPerf, un composant modulaire du framework open source NVIDIA Dynamo, pour fournir automatiquement des configurations de déploiement validées accompagnées de métriques de performance précises. Concrètement, SageMaker AI évalue les combinaisons d'instances GPU, de conteneurs de service, de stratégies de parallélisme et de techniques d'optimisation, puis restitue aux équipes les configurations les plus adaptées à leurs exigences de latence, de débit ou de coût. Eliuth Triana, Developer Relations Manager chez NVIDIA, a salué l'intégration, soulignant qu'elle permet aux entreprises de déployer des modèles d'IA générative avec confiance, en remplaçant des semaines de tests manuels par des configurations prêtes à l'emploi. L'enjeu est considérable pour les équipes d'ingénierie. Aujourd'hui, passer d'un modèle entraîné à un endpoint de production opérationnel prend entre deux et trois semaines par modèle, une durée imposée par la nécessité de tester manuellement des dizaines de configurations possibles : plus d'une douzaine de types d'instances GPU, plusieurs conteneurs de service, différents degrés de parallélisme, et des techniques comme le décodage spéculatif. Sans guidance validée, les équipes provisionnent des instances, déploient le modèle, exécutent des tests de charge, analysent les résultats, puis recommencent. Ce cycle mobilise une expertise en infrastructure GPU et en frameworks de service que la plupart des équipes ne possèdent pas en interne, conduisant systématiquement à du sur-provisionnement coûteux. AWS élimine ce goulot d'étranglement en automatisant l'ensemble du processus d'exploration et de validation des configurations. Cette évolution s'inscrit dans une course à la mise en production de l'IA générative que se livrent les entreprises pour alimenter leurs assistants intelligents, outils de génération de code et moteurs de contenu. Le coût du sur-provisionnement GPU, qui s'accumule à chaque modèle déployé et à chaque mois d'exploitation, représente un problème structurel pour l'industrie. AWS s'appuie sur sa collaboration technique approfondie avec NVIDIA, formalisée ici par l'intégration directe des composants de Dynamo dans SageMaker, pour s'imposer comme la plateforme cloud de référence pour les déploiements d'IA en production. En standardisant le benchmarking via AIPerf, dont les contrôles de concurrence et les options de jeux de données permettent d'itérer rapidement sur des scénarios variés, Amazon réduit la barrière technique pour les organisations qui cherchent à industrialiser leurs modèles sans constituer une équipe d'experts en infrastructure dédiée.

UELes entreprises européennes utilisant AWS SageMaker peuvent réduire leurs délais de mise en production de modèles IA de plusieurs semaines, sans impact réglementaire ou institutionnel direct sur la France ou l'UE.

InfrastructureActu
1 source
Meta Adaptive Ranking Model : infléchir la courbe d'inférence pour déployer des LLM dans la publicité
4Meta Engineering ML 

Meta Adaptive Ranking Model : infléchir la courbe d'inférence pour déployer des LLM dans la publicité

Meta a dévoilé l'Adaptive Ranking Model (ARM), un nouveau système de recommandation publicitaire fonctionnant à l'échelle des grands modèles de langage (LLM). Déployé sur Instagram au quatrième trimestre 2025, ARM a généré une hausse de 3 % des conversions publicitaires et de 5 % du taux de clics pour les utilisateurs ciblés. Le système atteint une complexité de calcul équivalente à celle des meilleurs LLMs — environ 10 GFLOPs par token — tout en maintenant une latence inférieure à 100 millisecondes, soit un ordre de grandeur plus rapide que l'inférence LLM standard. L'enjeu central qu'ARM résout est ce que Meta appelle le « trilemme de l'inférence » : comment faire tourner des modèles d'une complexité comparable à GPT-4 ou Llama dans un environnement publicitaire temps réel, où chaque requête doit aboutir en moins d'une seconde, pour des milliards d'utilisateurs, sans exploser les coûts d'infrastructure. La solution repose sur un routage intelligent des requêtes : plutôt que d'appliquer le même modèle à chaque impression publicitaire, ARM analyse le contexte et l'intention de l'utilisateur pour décider dynamiquement du niveau de complexité nécessaire. Les requêtes simples consomment peu de ressources ; les requêtes complexes mobilisent toute la puissance du modèle LLM-scale. Ce principe d'alignement dynamique entre complexité et contexte permet de maximiser la qualité des prédictions sans surcharger les serveurs. Trois innovations techniques rendent cela possible. Premièrement, une architecture centrée sur la requête plutôt que sur le modèle, permettant de servir un modèle à un trillion de paramètres (O(1T)) de façon économiquement viable. Deuxièmement, une co-conception modèle-matériel : les architectures sont conçues en tenant compte des contraintes précises du silicium utilisé, ce qui améliore significativement l'utilisation des GPU dans des environnements matériels hétérogènes. Troisièmement, une infrastructure de serving repensée autour d'architectures multi-cartes et d'optimisations bas-niveau spécifiques au hardware. Ce développement s'inscrit dans la course que se livrent les grandes plateformes pour intégrer l'intelligence des LLMs dans leurs systèmes de recommandation — un marché où chaque fraction de point de taux de conversion se traduit en milliards de dollars de revenus publicitaires. Pour Meta, dont plus de 98 % des revenus proviennent de la publicité, ARM représente une avancée structurelle : la preuve qu'il est désormais possible de faire fonctionner des modèles de la taille de ceux utilisés pour les chatbots dans des pipelines industriels ultra-contraints en latence et en coût.

UELes annonceurs européens utilisant Instagram et Facebook bénéficient indirectement d'un ciblage publicitaire amélioré, sans impact réglementaire ou stratégique direct pour la France ou l'UE.

InfrastructureOpinion
1 source