InfrastructureAWS ML Blog3h· 2 min de lecture

Optimiser l'entraînement des modèles sur Amazon SageMaker AI avec NVIDIA Blackwell

Amazon Web Services a rendu disponibles sur Amazon SageMaker AI les instances P6-B200, équipées de huit GPU NVIDIA Blackwell B200, pour l'entraînement de modèles de machine learning à grande échelle. Ces GPU de nouvelle génération embarquent 180 Go de mémoire HBM par puce (268 Go sur le B300), contre des capacités bien inférieures sur les générations précédentes, et s'interconnectent via NVLink 5 qui atteint 1,8 To/s de bande passante bidirectionnelle entre GPU. La configuration cible des modèles Transformer allant de 1 à 64 milliards de paramètres, entraînés en parallélisme de données fragmentées (FSDP de PyTorch) sur un nœud unique à huit GPU. L'accès à ces instances peut être réservé via le programme Flexible Training Plan d'AWS pour bénéficier d'une capacité prévisible et d'une gestion automatisée des ressources.

Cette architecture modifie concrètement ce qui est réalisable dans l'entraînement de grands modèles. Jusqu'ici, les ingénieurs se heurtaient à trois contraintes classiques : des tailles de batch limitées par la mémoire GPU, des séquences tronquées pour éviter les erreurs out-of-memory, et un fractionnement du modèle sur plusieurs nœuds qui génère une surcharge réseau importante. Avec 180 Go par GPU, certains modèles qui nécessitaient auparavant plusieurs nœuds peuvent désormais tenir sur un seul nœud à huit GPU, ce qui réduit la latence de communication, accélère les cycles d'itération et diminue les coûts d'infrastructure. Des séquences plus longues deviennent viables pour les tâches de dépendances à longue portée, et le nombre d'étapes de synchronisation des gradients diminue avec des batchs plus grands, améliorant le débit global.

NVIDIA Blackwell représente la cinquième génération de Tensor Cores de la marque, et son architecture dual-chip marque une rupture par rapport aux générations Ampere et Hopper. L'explosion de la taille des modèles ces trois dernières années, de GPT-3 à 175 milliards de paramètres jusqu'aux modèles actuels dépassant le trillion, a poussé les fournisseurs cloud et les fabricants de puces à repenser conjointement leurs offres. AWS et NVIDIA ont renforcé leur partenariat autour de SageMaker pour proposer une intégration clé en main qui abstrait la gestion de l'infrastructure. Les prochaines étapes pratiques pour les équipes ML consistent à calibrer le format de précision (FP8, BF16 ou FP16 selon la taille du modèle), ajuster le checkpointing d'activations pour équilibrer mémoire et calcul, et décider si la priorité est le débit, la réduction des communications inter-GPU ou la longueur de contexte. L'enjeu pour AWS est de capter une part croissante des budgets d'entraînement de modèles fondationnels, un marché où Google Cloud et Microsoft Azure jouent également des capacités GPU Blackwell.

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

La mise en cache des conteneurs dans Amazon SageMaker AI accélère le déploiement des modèles

Amazon Web Services vient d'annoncer une nouvelle fonctionnalité pour SageMaker AI : le cache des images de conteneurs lors des événements de mise à l'échelle. Concrètement, cette optimisation réduit jusqu'à 51 % la latence de démarrage lors du lancement de nouvelles instances, et jusqu'à 2x pour les modèles d'IA générative en conditions réelles. Pour illustrer le gain : avec le modèle Qwen3-8B (16 Go) sur une instance ml.g6.2xlarge et le conteneur LMI de SageMaker (17,7 Go compressé), la latence de démarrage passe de 525 secondes à 258 secondes. Avant le cache, le téléchargement de l'image depuis Amazon ECR prenait à lui seul 333 secondes, en parallèle du téléchargement des poids du modèle depuis S3 (168 secondes). Avec le cache, l'image est déjà disponible localement (0 seconde), et le téléchargement du modèle tombe à 77 secondes, la compétition pour la bande passante réseau étant éliminée. L'enjeu est considérable pour les équipes qui déploient des modèles de langage en production. Lors d'un pic de trafic, chaque seconde de latence au démarrage d'une nouvelle instance se traduit directement en requêtes non servies ou en surcoût d'instances pré-chauffées. Les workloads d'IA générative sont particulièrement touchés car ils utilisent des conteneurs très volumineux, LMI (basé sur vLLM), vLLM natif, NVIDIA Triton, qui pouvaient représenter la majeure partie du temps d'initialisation. La fonctionnalité s'applique aux deux architectures d'endpoints SageMaker : les endpoints à modèle unique (où chaque nouvelle instance héberge sa propre copie du modèle) et les endpoints à composants d'inférence (où de nouvelles instances sont lancées uniquement quand aucune instance existante n'a la capacité suffisante). Si le cache est indisponible, SageMaker revient automatiquement au téléchargement depuis ECR, sans interruption de service. Cette annonce s'inscrit dans une stratégie progressive d'AWS pour réduire la latence de mise à l'échelle sur SageMaker. La plateforme avait déjà introduit des métriques CloudWatch sub-minute permettant de détecter les besoins de scale-out jusqu'à 6 fois plus vite, ainsi qu'un cache de données par instance pour les composants d'inférence réutilisant des instances déjà en cours d'exécution. Mais ces solutions précédentes ne couvraient pas le cas où une toute nouvelle instance devait être lancée, le scénario le plus coûteux. Le cache de conteneurs comble précisément ce manque. Dans un contexte où la concurrence entre AWS, Google Cloud et Azure s'intensifie sur les performances d'inférence, cette optimisation renforce la position de SageMaker pour les déploiements LLM à grande échelle, notamment dans les entreprises qui font face à des pics de charge imprévisibles.

UELes entreprises françaises et européennes déployant des LLMs sur Amazon SageMaker bénéficieront directement de cette réduction de latence au scale-out, sans configuration supplémentaire.

InfrastructureActu

1 source

2AWS ML Blog

AWS met à l'échelle des modèles de fondation sismiques : entraînement distribué avec Amazon SageMaker HyperPod et extension des fenêtres de contexte

TGS, fournisseur de données géoscientifiques pour le secteur énergétique, a réduit le temps d'entraînement de ses modèles fondamentaux sismiques (SFM) de 6 mois à seulement 5 jours grâce à un partenariat avec le AWS Generative AI Innovation Center (GenAIIC). Ces modèles, basés sur une architecture Vision Transformer (ViT) avec entraînement par Masked AutoEncoder (MAE), analysent des données sismiques 3D complexes pour identifier des structures géologiques essentielles à l'exploration énergétique. L'infrastructure déployée repose sur Amazon SageMaker HyperPod, un cluster de 16 instances EC2 P5 équipées chacune de 8 GPU NVIDIA H200 avec 141 Go de mémoire HBM3e, 2 048 Go de RAM système et une connectivité réseau EFAv3 à 3 200 Gbps pour minimiser la latence entre les noeuds. Les données d'entraînement, plusieurs téraoctets, sont streamées directement depuis Amazon S3 sans couche de stockage intermédiaire. Cet accomplissement représente un changement de paradigme pour l'industrie pétrolière et gazière, où l'exploration géologique repose de plus en plus sur des modèles d'IA capables d'interpréter des volumes sismiques massifs. En passant de 6 mois à 5 jours par cycle d'entraînement, TGS peut désormais incorporer de nouvelles données beaucoup plus fréquemment et itérer rapidement sur ses modèles, ce qui se traduit directement en valeur pour ses clients. L'autre avancée majeure est l'extension de la fenêtre de contexte du modèle grâce à des techniques de parallélisme contextuel, permettant d'analyser des volumes 3D nettement plus grands qu'auparavant et de capturer simultanément les détails locaux et les structures géologiques à grande échelle, deux informations jusqu'ici difficiles à obtenir en un seul passage. Le projet s'inscrit dans une modernisation plus large de l'infrastructure AWS de TGS et illustre une tendance croissante dans les industries à forte intensité de données, comme l'énergie ou les géosciences, qui adoptent les modèles fondamentaux spécialisés pour remplacer les pipelines d'analyse traditionnels. L'entraînement distribué à grande échelle sur des données 3D volumétriques pose des défis spécifiques — temps GPU inactifs, goulots d'étranglement réseau, gestion des checkpoints sur des clusters multi-noeuds — que SageMaker HyperPod adresse avec une surveillance automatique de la santé des instances et une gestion résiliente des reprises. La collaboration entre TGS et l'équipe GenAIIC d'AWS ouvre la voie à des modèles sismiques de prochaine génération capables d'analyser des formations géologiques encore plus complexes, avec des implications directes sur l'efficacité et la précision de l'exploration pétrolière et gazière à l'échelle mondiale.

InfrastructureActu

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

4Le Big Data

Comment Uber optimise ses millions de trajets et son IA avec Amazon

Uber a annoncé un renforcement significatif de son partenariat avec Amazon Web Services pour optimiser en temps réel la gestion de ses millions de trajets quotidiens à l'échelle mondiale. Au cœur de cette collaboration, deux puces développées par AWS jouent des rôles complémentaires : Graviton4, conçue pour les calculs cloud intensifs, et Trainium3, spécialisée dans l'entraînement de modèles d'intelligence artificielle à partir de volumes massifs de données. Concrètement, Uber migre une part croissante de ses opérations critiques vers ces architectures matérielles, notamment ses Trip Serving Zones, des serveurs chargés de traiter en continu la localisation des chauffeurs, leur disponibilité et le calcul des itinéraires. Rich Geraffo, vice-président d'AWS, a qualifié Uber de l'une des applications en temps réel les plus exigeantes au monde, soulignant l'ampleur du défi technique que représente cette infrastructure. L'enjeu est considérable : à chaque ouverture de l'application, le système dispose de moins d'une seconde pour attribuer un chauffeur, définir un itinéraire et estimer le délai d'arrivée, et ce pour des millions d'utilisateurs simultanément, sans marge d'erreur même lors des pics de demande. Le passage à Graviton4 permet à Uber d'améliorer sa réactivité, de réduire sa consommation énergétique et de mieux absorber les surcharges de trafic qui peuvent atteindre 2 à 25 fois le niveau normal selon AWS. En parallèle, Trainium3 permet d'affiner les algorithmes d'IA qui analysent des millions de trajets et de livraisons pour améliorer la sélection des chauffeurs, la précision des temps d'arrivée et l'optimisation des options de livraison. Cette montée en puissance technologique vise à maintenir la qualité de service à mesure que les volumes de données traitées augmentent. Ce partenariat s'inscrit dans une tendance lourde du secteur : les grandes plateformes de mobilité à la demande investissent massivement dans des infrastructures cloud sur mesure pour rester compétitives. Uber, qui opère dans des dizaines de pays et traite des milliards de points de données quotidiens, ne peut plus se contenter d'architectures génériques. Toutefois, plusieurs défis subsistent. La migration vers ces nouvelles puces implique d'adapter des algorithmes complexes, de tester chaque scénario de calcul et d'assurer la compatibilité avec les systèmes existants, ce qui représente un investissement en temps, en expertise et en budget considérable. Par ailleurs, même les architectures les plus robustes peuvent être prises de court par des événements imprévisibles, qu'il s'agisse de pics explosifs lors du Black Friday ou d'incidents de circulation en temps réel. L'IA reste tributaire de la qualité et de la fraîcheur des données disponibles, ce qui constitue une limite structurelle que la puissance matérielle seule ne peut pas résoudre.

InfrastructureActu

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