InfrastructureAWS ML Blog6sem· 2 min de lecture

Réservez de la capacité GPU à court terme pour vos workloads ML avec EC2 Capacity Blocks et SageMaker

Amazon Web Services propose deux solutions complémentaires pour sécuriser de la capacité GPU à court terme : les EC2 Capacity Blocks for ML et les SageMaker training plans. Les Capacity Blocks permettent de réserver un nombre précis d'instances GPU pour une fenêtre temporelle définie, jusqu'à huit semaines à l'avance, avec des durées allant de 1 à 14 jours (par paliers d'un jour) ou de 15 à 182 jours (par paliers de sept jours). Chaque bloc peut couvrir jusqu'à 64 instances d'un même type, et une organisation peut cumuler jusqu'à 256 instances sur une même date en combinant plusieurs blocs au sein d'AWS Organizations. Contrairement aux réservations de capacité à la demande classiques (ODCR), ces Capacity Blocks sont entièrement en libre-service et affichent une décote de 40 à 50 % par rapport aux tarifs à la demande, tout en offrant une bien meilleure disponibilité pour les instances de type P, particulièrement recherchées.

Ces solutions répondent à un besoin concret et pressant : la demande mondiale de GPU pour l'entraînement, le fine-tuning et l'inférence de modèles d'intelligence artificielle dépasse largement l'offre disponible. Pour les équipes qui ont besoin de GPU de manière ponctuelle, que ce soit pour des tests de charge, la validation de modèles, des ateliers techniques ou la préparation d'une mise en production, les options existantes présentent des limites sérieuses. Les instances à la demande ne garantissent pas la disponibilité au moment du lancement, et relâcher une instance peut signifier ne plus pouvoir la récupérer. Les instances Spot, bien que jusqu'à 90 % moins chères, peuvent être interrompues à tout moment par AWS. Les Capacity Blocks éliminent cette incertitude : la capacité est garantie pendant toute la durée réservée, ce qui permet de planifier des workloads critiques en temps contraint sans risque de pénurie de ressources.

Cette pénurie de GPU n'est pas nouvelle : depuis l'explosion des usages d'IA générative à partir de 2023, les grands hyperscalers comme AWS, Google Cloud et Microsoft Azure font face à une concurrence intense pour l'acquisition et la mise à disposition de puces Nvidia H100 et autres accélérateurs. AWS avait introduit les Capacity Blocks dès 2023 pour les instances P5, mais l'offre s'est depuis progressivement élargie. L'intégration avec les SageMaker training plans vise à couvrir également les usages managés, où AWS gère l'infrastructure sous-jacente. À terme, ces mécanismes de réservation structurée devraient devenir la norme pour toute organisation menant des expérimentations ML d'envergure, car ils permettent de concilier agilité opérationnelle et maîtrise des coûts sans recourir à des contrats pluriannuels.

Impact France/UE

Les équipes françaises et européennes utilisant AWS pour leurs workloads ML peuvent sécuriser de la capacité GPU à court terme avec une décote de 40-50%, réduisant l'incertitude opérationnelle liée à la pénurie mondiale de GPU.

Dans nos dossiers

Microsoft AWS Azure Google Cloud

Cet article vous a été utile ?

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

À lire aussi

1AWS ML Blog

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

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é.

InfrastructureActu

1 source

2AWS ML Blog

Surveiller et déboguer l'inférence IA générative avec SageMaker sur CloudWatch

Amazon Web Services a enrichi son service SageMaker AI d'un système de supervision avancé pour les endpoints d'inférence en temps réel : la plateforme émet désormais plus de 100 métriques détaillées couvrant la santé GPU, la latence au niveau des tokens, la pression sur le cache KV, la répartition du trafic entre zones de disponibilité et les diagnostics de démarrage à froid. Ces données alimentent automatiquement un tableau de bord intégré appelé SageMaker Insights, accessible directement depuis la console Amazon CloudWatch sous la section « Infrastructure Monitoring ». Le tableau de bord s'organise en trois vues, Performance, Capacité, Fiabilité, et exploite les métriques via une interface compatible PromQL, permettant également leur intégration dans des outils tiers comme Grafana ou Datadog. Deux architectures d'endpoints sont supportées : les endpoints mono-modèle (SME), où chaque modèle dispose de ses propres instances GPU, et les endpoints à composants d'inférence (IC), qui permettent à plusieurs modèles de partager la même infrastructure GPU avec une mise à l'échelle indépendante par modèle. Cette évolution répond à un besoin critique des équipes MLOps et SRE qui gèrent en production des dizaines de modèles sur des centaines d'instances GPU. Jusqu'ici, diagnostiquer un pic de latence P99 sur un endpoint LLM exigeait de déterminer en quelques minutes si la cause était une saturation de la mémoire GPU, un cache KV saturé, un déséquilibre de trafic entre zones ou une politique d'autoscaling trop lente, sans outillage natif pour y répondre rapidement. Le nouveau système supprime la nécessité de configurer manuellement des dashboards Grafana et des exporteurs Prometheus, ce qui représente un gain opérationnel significatif. Les métriques sont émises nativement au format OpenTelemetry, standard ouvert qui facilite l'interopérabilité avec l'écosystème d'observabilité existant des entreprises. La montée en puissance de l'inférence LLM en production a profondément modifié les priorités des équipes d'infrastructure machine learning : si l'entraînement des modèles concentrait autrefois l'essentiel de l'attention, c'est désormais le « serving » à grande échelle qui pose les défis les plus complexes, notamment en termes de coût GPU, de disponibilité et de gestion multi-modèles. L'architecture IC, recommandée par AWS pour les charges de travail IA génératives en production, permet de mutualiser l'infrastructure GPU entre plusieurs modèles et d'assurer la haute disponibilité via une distribution des répliques entre zones de disponibilité. Cette annonce s'inscrit dans une compétition accrue entre les grands fournisseurs cloud, AWS, Google Cloud et Azure, pour proposer des environnements de déploiement LLM clés en main, où l'observabilité devient un argument différenciant à mesure que les équipes industrialisent leurs pipelines d'inférence.

UELes équipes MLOps et SRE européennes industrialisant des pipelines d'inférence LLM en production bénéficient indirectement d'un outillage d'observabilité natif, réduisant la complexité opérationnelle sans configuration manuelle de Prometheus/Grafana.

InfrastructureOpinion

1 source

3AWS ML Blog

Paralléliser le décodage spéculatif avec P-EAGLE sur Amazon SageMaker AI

Amazon Web Services a mis en open source une nouvelle méthode d'inférence appelée P-EAGLE (Parallel-EAGLE), désormais intégrée nativement dans Amazon SageMaker JumpStart pour accélérer le déploiement de grands modèles de langage en production. Basée sur la technique du décodage spéculatif, P-EAGLE transforme une étape jusqu'ici séquentielle en opération entièrement parallèle : au lieu de générer les tokens candidats un par un via plusieurs passes successives, elle les prédit tous simultanément en une seule passe vers l'avant. Sur des GPU NVIDIA B200 avec quantification FP8, des benchmarks réalisés sur le modèle Qwen3-Coder-30B-A3B-Instruct montrent des gains allant jusqu'à 1,69x de débit supplémentaire par rapport à EAGLE-3, le framework de référence précédent. À une concurrence de 1, P-EAGLE avec K=11 tokens spéculatifs atteint 1 167 tokens de sortie par seconde, contre 955 pour EAGLE-3 et seulement 294 sans spéculation. Cette avancée répond à un problème concret qui freinait les déploiements à grande échelle : plus on voulait spéculer loin dans la séquence, plus la latence augmentait de façon linéaire, annulant une partie du gain. P-EAGLE casse cette contrainte en remplissant les positions intermédiaires avec des marqueurs appris, permettant de prédire plusieurs tokens à la fois sans coût séquentiel supplémentaire. Pour les entreprises qui servent des millions de requêtes quotidiennes sur des modèles de code ou de génération longue, un gain de 1,69x de débit se traduit directement en réduction de coûts d'infrastructure ou en capacité à absorber davantage de trafic sans redimensionner le parc de GPU. L'intégration dans SageMaker JumpStart simplifie encore l'adoption : les développeurs peuvent déployer un endpoint optimisé P-EAGLE sans gérer manuellement les kernels CUDA sous-jacents ni les configurations de serving distribué. Le décodage spéculatif existe depuis plusieurs années comme technique d'optimisation d'inférence, et EAGLE en était devenu l'implémentation la plus performante, avec EAGLE-3 introduisant des prédictions directes de tokens et la fusion de représentations issues de plusieurs couches du modèle cible. Mais toutes ces versions conservaient une limite architecturale fondamentale héritée de l'autoregressivité du modèle brouillon. AWS a contourné ce plafond avec P-EAGLE, qu'il a choisi de reverser à la communauté open source plutôt que d'en faire un avantage exclusif. La méthode s'inscrit dans une compétition intense entre fournisseurs cloud pour offrir l'inférence la plus rapide et la moins coûteuse, notamment sur les modèles de code et de raisonnement qui génèrent des séquences longues. Avec son intégration SageMaker, AWS positionne P-EAGLE comme la voie par défaut pour les déploiements de modèles open-weight en production, au moment où des modèles comme Qwen3 et leurs successeurs s'imposent comme alternatives sérieuses aux modèles propriétaires.

UELes équipes européennes déployant des grands modèles en production sur infrastructure cloud peuvent bénéficier indirectement d'une réduction des coûts d'inférence GPU.

InfrastructureActu

1 source

4AWS ML Blog

Faciliter l'accès externe à Amazon SageMaker MLflow via un proxy REST API

Amazon Web Services a publié un guide technique expliquant comment construire un service proxy Flask sécurisé pour accéder à Amazon SageMaker MLflow via HTTPS, sans recourir directement au SDK MLflow. Ce tutoriel s'adresse aux équipes de machine learning dont les entreprises imposent des politiques de sécurité strictes, des restrictions réseau, ou des contraintes liées aux systèmes hérités qui rendent l'utilisation directe du SDK impossible. L'architecture proposée s'articule autour de trois composants : un Application Load Balancer (ALB) d'AWS qui gère le routage du trafic entrant, un service proxy Python/Flask qui intercepte et transforme les requêtes HTTPS, et Amazon SageMaker MLflow lui-même, disponible en deux modes de déploiement distincts, soit un serveur de suivi géré (MLflow Tracking Server), soit une application serverless (MLflowApp). Le proxy prend en charge l'authentification AWS IAM, la pré-signature des URLs et la transformation des requêtes avant de les acheminer vers SageMaker. L'intérêt concret de cette solution réside dans sa capacité à réconcilier deux réalités souvent incompatibles dans les grandes organisations : les exigences de sécurité établies et l'adoption des services cloud natifs. De nombreuses entreprises en pleine transformation cloud se retrouvent bloquées face à une incompatibilité entre leurs workflows ML existants et les nouvelles infrastructures AWS, faute de pouvoir modifier leurs politiques réseau ou de sécurité. Ce proxy offre une réponse pragmatique : les systèmes métiers continuent d'envoyer des requêtes HTTPS standard, tandis que le proxy se charge de les signer avec les identifiants IAM avant de les relayer de manière sécurisée vers SageMaker MLflow. Le résultat est une intégration qui préserve la conformité sans imposer de refonte des outils existants. MLflow est devenu un standard de facto pour la gestion du cycle de vie des modèles de machine learning, permettant de tracer les expériences, versionner les modèles et piloter les déploiements. Amazon l'a intégré à SageMaker pour offrir une version managée aux équipes déjà sur son cloud, mais cette intégration supposait jusqu'ici l'utilisation du SDK Python, un prérequis bloquant dans de nombreux contextes d'entreprise. Ce guide illustre une tendance plus large dans l'ingénierie ML en entreprise : la nécessité de bâtir des couches d'adaptation pour connecter les outils modernes aux infrastructures existantes. En s'appuyant sur Flask, un framework Python minimaliste et largement maîtrisé, ainsi que sur les mécanismes d'authentification AWS standard, la solution proposée reste à faible complexité technique, réutilisable et évolutive, réduisant la friction lors des migrations cloud sans sacrifier la sécurité.

InfrastructureTuto

1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, rédigé par un humain · désinscription en un clic