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

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.

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.

La construction de l'environnement d'entreprise pour l'IA à base d'agents

Intel a mené plusieurs milliers d'expériences sur des charges de travail d'IA agentique afin d'identifier ce dont une entreprise a réellement besoin pour faire fonctionner des agents logiciels à grande échelle. Pour cela, le groupe a étendu Terminal-Bench, un outil open source de benchmark pour agents IA, en y ajoutant des capacités de profilage, de télémétrie et de rejeu. La méthode retenue repose sur un enregistrement déterministe des réponses des modèles de langage, rejouées ensuite à l'identique à chaque test : cela permet de mesurer la performance des agents indépendamment de la variabilité propre au LLM. Le panel de tâches utilisé était volontairement large : compilation, tests logiciels, opérations de bases de données, logique booléenne, interprétation, ray tracing, compression de données, algèbre linéaire, transcodage vidéo et entraînement de modèles de machine learning. Cette diversité visait à rapprocher les résultats des conditions réelles rencontrées en entreprise. De ces travaux, Intel tire cinq enseignements pratiques, dont l'idée centrale que l'IA agentique constitue un problème de système complet et non un simple enjeu d'inférence. Cette distinction a des conséquences concrètes pour les équipes qui déploient des agents en production. Plutôt que de se limiter aux métriques classiques d'évaluation des modèles, Intel recommande de suivre six indicateurs : le taux de réussite des tâches, le coût par tâche, le temps par tâche, le débit de traitement, la densité d'agents par vCPU et la latence. Le point le plus contre-intuitif concerne le dimensionnement des infrastructures : la bonne unité de mesure n'est pas le nombre brut d'agents déployés, mais la densité d'agents par processeur virtuel disponible. Ainsi, dix agents tournant sur un système à 8 vCPU et vingt agents sur un système à 16 vCPU se comportent de façon comparable, dès lors que la densité reste identique. Cela donne aux architectes un moyen fiable de comparer des capacités entre différentes tailles d'instances et générations de processeurs, et de calibrer leurs infrastructures selon les objectifs métier : les assistants interactifs orientés utilisateur exigent une densité plus faible pour préserver le temps de réponse, tandis que les traitements par lots, comme les flux de travail IT internes, peuvent tourner à densité plus élevée. Ces travaux s'inscrivent dans un contexte où l'IA agentique dépasse largement le cadre du chatbot conversationnel pour devenir un outil d'automatisation de bout en bout des processus métier, capable de planifier des tâches multi-étapes, d'appeler des outils, de lire des résultats et de relancer une action en cas d'échec. Intel préconise notamment de surveiller la latence réelle des tâches plutôt que la seule utilisation moyenne du CPU, et de privilégier une architecture en scale-out plutôt qu'en scale-up, cette dernière n'étant réservée qu'aux charges nécessitant davantage de calcul par agent ou soumises à des contraintes architecturales spécifiques. Ces recommandations visent à outiller les équipes techniques face à la montée en charge attendue des déploiements agentiques dans les prochains mois.

💬 Ce qui me marque le plus dans ce papier, c'est le changement d'unité de mesure. Intel affirme que compter les agents déployés ne veut rien dire : seule la densité d'agents par vCPU permet de comparer deux infras entre elles, dix agents sur 8 vCPU se comportant comme vingt sur 16. Reste qu'Intel a du silicium à vendre derrière cette grille de lecture, donc je la garde en tête sans la prendre pour argent comptant.

Renforcement de l'inférence entreprise sur Amazon SageMaker HyperPod grâce à l'intégration de Hugging Face, NVMe et Route 53

Amazon vient d'enrichir SageMaker HyperPod, sa plateforme d'inférence pour l'intelligence artificielle générative en entreprise, avec plusieurs nouvelles fonctionnalités destinées à améliorer l'observabilité et la flexibilité du déploiement de modèles. La première nouveauté majeure est la capture de données d'inférence, qui permet d'enregistrer les requêtes et réponses à trois niveaux distincts du chemin d'inférence : au niveau du endpoint SageMaker AI, au niveau de l'Application Load Balancer (ALB), et au niveau du pod du modèle lui-même. Chaque niveau se configure indépendamment via une définition de ressource personnalisée (CRD) déclarative, avec un stockage des données capturées dans un bucket Amazon S3, chiffrement optionnel via AWS KMS, et réglages fins du taux d'échantillonnage, de la taille des lots et des limites de charge utile. Par exemple, le niveau du pod capture par défaut 100% des entrées et sorties, tandis que le niveau ALB active les journaux d'accès classiques incluant adresses IP clients, chemins de requêtes et latences. Autre avancée : le déploiement direct de modèles depuis des hubs communautaires comme Hugging Face, sans avoir à pré-charger les poids dans un espace de stockage objet ou fichier, avec prise en charge de l'accès restreint (gated), de l'épinglage de versions et de l'isolation des tokens, compatible avec les moteurs d'inférence vLLM, TGI et SGLang. Ces évolutions répondent à un besoin croissant des entreprises qui déploient des modèles de langage à grande échelle en production : pouvoir surveiller précisément ce qui transite dans leurs pipelines d'inférence, tout en réduisant les frictions opérationnelles. La possibilité de charger les poids d'un modèle directement depuis un stockage NVMe local au nœud de calcul réduit sensiblement la latence de démarrage à froid, un problème récurrent qui pénalise les applications d'IA nécessitant une mise à l'échelle rapide, avec un repli automatique vers le stockage cloud en cas de besoin. La gestion automatique des enregistrements DNS pour les domaines personnalisés via Route 53 simplifie par ailleurs le travail des équipes d'infrastructure, qui bénéficient également de permissions IAM granulaires au niveau de chaque pod pour renforcer les frontières de sécurité. Pour les équipes techniques, cela signifie livrer des applications d'IA plus rapidement sans sacrifier la gouvernance des données ni la visibilité opérationnelle, deux exigences de plus en plus scrutées à mesure que les modèles génératifs s'intègrent dans des processus métiers sensibles. Ces annonces s'inscrivent dans la course que se livrent les grands fournisseurs cloud, Amazon Web Services en tête, pour simplifier l'exploitation de modèles d'IA génératifs à grande échelle, un domaine où la complexité opérationnelle freine encore de nombreuses entreprises. HyperPod, lancé pour l'entraînement de modèles massifs, élargit ainsi son périmètre vers l'inférence de production, un segment où la concurrence avec Google Cloud et Microsoft Azure s'intensifie. L'intégration native avec Hugging Face illustre aussi la volonté d'AWS de faciliter l'accès aux modèles open source les plus populaires, sans complexité de préparation de l'infrastructure. À mesure que les entreprises multiplient les cas d'usage en production, la demande pour des outils d'audit, de traçabilité et de contrôle des coûts d'inférence devrait continuer de croître, poussant les fournisseurs cloud à approfondir ces capacités de gestion fine des workloads d'IA.