Aller au contenu principal
Chargement des LLM accéléré et fenêtres de contexte élargies avec GPUDirect, Amazon FSx for Lustre et TurboQuant
InfrastructureAWS ML Blog2sem· 2 min de lecture

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

Source originale ↗·
Chargement des LLM accéléré et fenêtres de contexte élargies avec GPUDirect, Amazon FSx for Lustre et TurboQuant
▶ Voir sur YouTube

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.

Impact France/UE

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

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

AWS met à l'échelle des modèles de fondation sismiques : entraînement distribué avec Amazon SageMaker HyperPod et extension des fenêtres de contexte
1AWS 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
La mise en cache des conteneurs dans Amazon SageMaker AI accélère le déploiement des modèles
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
Comment Uber optimise ses millions de trajets et son IA avec Amazon
3Le 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
Google lance ses puces TPU 8, trois fois plus puissantes, pour accélérer l'entraînement IA et réduire les coûts cloud
4Interesting Engineering 

Google lance ses puces TPU 8, trois fois plus puissantes, pour accélérer l'entraînement IA et réduire les coûts cloud

Google a dévoilé la huitième génération de ses Tensor Processing Units lors de la conférence Google Cloud Next, en introduisant deux puces d'IA distinctes : la TPU 8t, dédiée à l'entraînement des modèles, et la TPU 8i, optimisée pour l'inférence. La TPU 8t peut s'étendre jusqu'à 9 600 puces dans un seul superpod, atteignant 121 exaflops de puissance de calcul, soit près de trois fois les performances de la génération précédente, baptisée Ironwood. Elle vise un taux de "goodput" supérieur à 97 %, c'est-à-dire un temps de calcul productif maximisé, limitant les pauses dues aux pannes ou aux goulots d'étranglement. La TPU 8i, quant à elle, embarque 288 Go de mémoire haute bande passante et 384 Mo de SRAM on-chip, et affiche une amélioration de 80 % du rapport performance/dollar par rapport à la génération précédente, permettant de traiter presque deux fois plus de charge à coût équivalent. Les deux puces seront disponibles en accès général via Google Cloud d'ici la fin de l'année. Cette annonce marque une rupture dans la façon dont l'industrie conçoit l'infrastructure IA. En séparant les cas d'usage entraînement et inférence en deux architectures matérielles distinctes, Google reconnaît que les charges de travail modernes ont des profils radicalement différents. Les agents IA, qui enchaînent des raisonnements, appellent des outils et interagissent en boucle avec d'autres modèles, exigent des temps de réponse très courts et une mémoire rapide proche du processeur, ce que la TPU 8i cible directement. Pour les entreprises clientes, le gain de performance par dollar est concret : gérer deux fois plus d'utilisateurs simultanés sans augmenter la facture cloud change l'équation économique du déploiement de modèles à grande échelle. Google développe ses TPU depuis 2016 pour ses propres systèmes internes, dont Gemini, mais les ouvre désormais plus largement aux clients cloud face à une demande explosive en calcul IA. La stratégie est claire : offrir une alternative intégrée à l'écosystème Nvidia en combinant silicium propriétaire, réseaux personnalisés, frameworks logiciels et services cloud en un seul stack. Les deux puces supportent JAX, PyTorch, SGLang et vLLM, abaissant la barrière à la migration pour les développeurs. Sur le plan énergétique, les TPU 8 offrent jusqu'à deux fois plus de performance par watt que la génération Ironwood et utilisent un refroidissement liquide de quatrième génération. La bataille pour l'infrastructure IA de prochaine génération s'intensifie, avec Google, Microsoft, Amazon et Meta qui investissent massivement dans leurs propres puces pour réduire leur dépendance à Nvidia tout en contrôlant les coûts d'exploitation à long terme.

UELes entreprises européennes déployant des modèles IA sur Google Cloud pourraient bénéficier d'une réduction significative de leurs coûts d'inférence grâce au gain de 80 % du rapport performance/dollar annoncé pour les TPU 8i.

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, rédigé par un humain · désinscription en un clic