InfrastructureAWS ML Blog14sem· 2 min de lecture

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.

Dans nos dossiers

AWS NVIDIA

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

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.

InfrastructureActu

1 source

2AWS 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

3AWS ML Blog

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.

UEImpact indirect uniquement: les entreprises françaises et européennes utilisant AWS SageMaker HyperPod pourraient bénéficier de ces améliorations opérationnelles, mais aucune régulation ni acteur français/européen n'est concerné directement.

InfrastructureActu

1 source

4AWS ML Blog

Chargement des LLM accéléré et fenêtres de contexte élargies avec GPUDirect, Amazon FSx for Lustre et TurboQuant

Amazon Web Services vient d'annoncer une combinaison technique qui pourrait transformer le déploiement de grands modèles de langage en production : l'utilisation conjointe d'Amazon FSx for Lustre, de NVIDIA GPUDirect Storage (GDS) et d'une nouvelle technique de quantification appelée TurboQuant. Concrètement, charger un modèle comme Llama 3.1 405B, soit environ 800 gigaoctets de poids en BF16, prend aujourd'hui entre 10 et 20 minutes avec une infrastructure classique. Avec GDS sur les nouvelles instances P6 et P6e d'AWS, propulsées par l'architecture NVIDIA Blackwell, ce délai tombe à quelques secondes. Le flagship P6e UltraServer concentre 72 GPU Blackwell dans un seul domaine NVLink, avec 13,4 téraoctets de mémoire HBM3e et 360 pétaflops de calcul en FP8. Le problème que résout cette approche est fondamental pour l'industrie de l'inférence à grande échelle. Dans le pipeline traditionnel, les poids du modèle transitent séquentiellement depuis le stockage vers la RAM CPU, sont désérialisés, éventuellement quantifiés, puis copiés un par un vers chaque GPU via le bus PCIe. Pendant tout ce temps, parfois vingt minutes, les GPU les plus chers de l'infrastructure restent inactifs. GPUDirect Storage court-circuite entièrement ce chemin : les checkpoints du modèle sont pré-découpés en fragments sur FSx for Lustre, et les huit GPU d'une instance lisent leurs fragments en parallèle directement dans leur mémoire HBM, sans jamais passer par le CPU ni le PCIe. L'impact est immédiat sur trois métriques critiques : la latence au premier token lors d'un démarrage à froid, la réactivité de l'autoscaling lors des pics de charge, et le coût d'infrastructure lié aux GPU qui attendent. Cette annonce s'inscrit dans une course à l'optimisation de l'inférence LLM qui s'est intensifiée depuis l'émergence de modèles à plusieurs centaines de milliards de paramètres. Des frameworks comme vLLM ont certes amélioré le chargement parallèle des poids depuis la version 0.19 et son moteur V1, mais les données continuent d'emprunter le CPU et le bus PCIe, une limitation structurelle que GDS supprime à la racine. AWS introduit simultanément TurboQuant, une technique de mise en cache KV qui permet d'augmenter significativement la taille des fenêtres de contexte disponibles sur ces instances. Ces deux avancées combinées positionnent AWS comme un acteur offensif sur le marché de l'infrastructure d'inférence, face à des concurrents comme Google Cloud et Azure qui développent leurs propres accélérateurs et solutions de stockage haute performance pour répondre aux mêmes contraintes.

UELes entreprises européennes déployant des LLMs à grande échelle sur AWS pourront réduire significativement leurs coûts d'infrastructure liés aux GPU inactifs au démarrage, avec un impact direct sur la compétitivité des services d'inférence en Europe.

InfrastructureOpinion

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, l'essentiel de l'IA · désinscription en un clic