AWS et NVIDIA : Révolution dans l'entraînement des modèles IA

AWS et NVIDIA : Une alliance pour l'IA de demain

Dans le domaine de l'intelligence artificielle, le "scaling" des modèles fondamentaux a longtemps été synonyme d'une augmentation de la puissance de calcul pour le pré-entraînement. Cette approche, soutenue par des recherches comme celles de Kaplan et al. (2020), a permis de prédire les améliorations de performance en fonction de l'augmentation des paramètres du modèle et de la puissance de calcul. Cependant, les avancées récentes montrent que le scaling ne se limite plus à cette simple relation.

Pour longtemps, "scaler" dans les modèles fondamentaux signifiait principalement une chose : dépenser plus de puissance de calcul pour le pré-entraînement et voir les capacités augmenter. Cette intuition était soutenue par des travaux empiriques tels que ceux de Kaplan et al. (2020), qui ont rapporté des tendances prévisibles de loi de puissance dans la perte à mesure que l'on augmente les paramètres du modèle, la taille du jeu de données et la puissance de calcul d'entraînement. En pratique, ces tendances justifiaient un investissement soutenu dans des capacités d'accélération à grande échelle et l'infrastructure distribuée nécessaire pour les utiliser efficacement.

Cependant, la frontière a évolué, et le scaling n'est plus une courbe unique. Le cadre des "trois lois de scaling" de NVIDIA souligne utilement que, au-delà du pré-entraînement, la performance s'améliore de plus en plus grâce au post-entraînement (par exemple, le fine-tuning supervisé (SFT) et les méthodes basées sur l'apprentissage par renforcement (RL)) et grâce à la puissance de calcul au moment des tests ("long thinking", recherche/vérification, stratégies multi-échantillons).

Ces régimes de scaling poussent le cycle de vie des modèles fondamentaux — pré-entraînement, post-entraînement et inférence — vers des exigences d'infrastructure convergentes : un calcul d'accélérateur étroitement couplé, un réseau à large bande passante et faible latence, et un stockage distribué. Ils soulèvent également l'importance de l'orchestration pour la gestion des ressources et de l'observabilité au niveau des applications et du matériel pour maintenir la santé des clusters et diagnostiquer les pathologies de performance à grande échelle.

Une autre tendance clé est la dépendance croissante du cycle de vie des modèles fondamentaux à un écosystème de logiciels open-source (OSS) qui englobe les frameworks de développement de modèles, la gestion des ressources de cluster et les outils opérationnels. Au niveau du cluster, la gestion des ressources est généralement assurée par des systèmes tels que Slurm et Kubernetes. Le développement de modèles et l'entraînement distribué sont souvent mis en œuvre dans des frameworks tels que PyTorch et JAX. La surveillance et la visualisation — c'est-à-dire l'observabilité — sont souvent réalisées à l'aide de Prometheus pour la collecte de métriques et Grafana pour la visualisation et l'alerte, positionnées comme une couche opérationnelle au-dessus de l'infrastructure et de la gestion des ressources.

Ce post est destiné aux ingénieurs et chercheurs en apprentissage automatique impliqués dans l'entraînement et l'inférence de modèles fondamentaux, avec une attention particulière aux flux de travail construits sur des frameworks OSS. Il analyse comment l'infrastructure AWS — y compris le calcul d'accélérateur multi-nœuds, le réseau à large bande passante et faible latence, le stockage partagé distribué et les services gérés associés — interagit avec les stacks OSS courants tout au long du cycle de vie des modèles fondamentaux. L'objectif principal est de fournir une base technique pour comprendre les goulets d'étranglement des systèmes et les caractéristiques de scaling couvrant le pré-entraînement, le post-entraînement et l'inférence. Ce post d'introduction met en lumière l'architecture système globale, en soulignant les points d'intégration entre les composants d'infrastructure AWS et les outils OSS qui soutiennent l'entraînement et l'inférence distribués à grande échelle.

Les Briques de Construction AWS

Le reste de cette série examine comment cette architecture en couches est réalisée sur AWS, en progressant à travers l'infrastructure, l'orchestration des ressources, la pile logicielle ML et l'observabilité. Les sections suivantes présentent un aperçu de chaque couche.

Infrastructure : Calcul, Réseau et Stockage

Comme illustré, l'infrastructure repose sur trois blocs de construction couplés : le calcul accéléré avec une grande mémoire de dispositif, une interconnexion à large bande pour la communication collective, et un stockage distribué évolutif pour les données et les points de contrôle.

Le calcul accéléré constitue la base du pré-entraînement, du post-entraînement et de l'inférence des modèles fondamentaux à grande échelle. AWS propose plusieurs générations de GPU NVIDIA dans le cadre de ses instances de calcul accéléré Amazon EC2, y compris la famille d'instances Amazon EC2 P. La famille d'instances P5 comprend p5.48xlarge avec huit GPU NVIDIA H100, p5.4xlarge avec un seul GPU H100 pour des charges de travail à plus petite échelle, et des variantes p5e.48xlarge/p5en.48xlarge avec des GPU NVIDIA H200. La famille P6 introduit l'architecture NVIDIA Blackwell B200 avec p6-b200.48xlarge et Blackwell Ultra B300 avec p6-b300.48xlarge.

À travers ces générations, les axes de scaling dominants sont le débit Tensor maximal, la capacité et la bande passante HBM, et la bande passante d'interconnexion (au sein et entre les nœuds).

En première approximation, le débit maximal des Tensor Cores — mesuré en opérations en virgule flottante par seconde (FLOPS) — aide à situer ces accélérateurs sur un axe commun. Le tableau ci-dessous résume le débit maximal par GPU pour les opérations Tensor denses BF16/FP16 et FP8, ainsi que la capacité HBM et la bande passante HBM, en utilisant des spécifications de classe SXM/HGX qui s'alignent avec les nœuds multi-GPU basés sur NVSwitch/NVLink.

• GPU (variante représentative)
• BF16/FP16 Tensor peak (dense)
• FP8 Tensor peak (dense)
• FP4 Tensor peak (dense)
• B200 (HGX, par GPU)
• B300 (HGX, par GPU)

Note : Les tableaux de produits NVIDIA rapportent souvent le débit Tensor "avec sparsité" ; ce tableau rapporte le débit dense. Lorsque cela est applicable, le débit dense est pris comme la moitié du débit sparse, suivant les recommandations de NVIDIA pour les plateformes de classe HGX. Les chiffres DGX sont au niveau système ; les valeurs de capacité et de bande passante HBM de B200 sont exprimées par GPU en divisant les totaux DGX par huit.

À mesure que les modèles s'échelonnent, le temps d'étape est souvent dominé par la communication collective et le mouvement de la mémoire plutôt que par le débit de calcul brut, ce qui motive un comptage explicite de la bande passante pour le scaling.

Pour les instances multi-GPU, la communication GPU s'étend sur deux régimes. Le scaling interne (NVLink/NVSwitch) fournit une connectivité GPU à GPU à haute bande passante et faible latence au sein d'un nœud, permettant à des collectifs tels que all-reduce et all-gather de s'exécuter sans traverser la pile de mise en réseau hôte. Le scaling externe (EFA) fournit un réseau contournant le système d'exploitation entre les nœuds, qu'AWS utilise comme élément de base pour les Amazon EC2 UltraClusters où des collectifs à forte communication s'étendent sur des milliers d'instances.

Le tableau suivant résume les spécifications clés pour ces types d'instances :

• NVLink BW (agrégé)
• EFA BW (agrégé)
• p6-b200.48xlarge
• p6-b300.48xlarge

Note : La bande passante EFA est convertie de Gbps à GB/s (÷8) pour la cohérence avec d'autres métriques de bande passante ; voir les spécifications de mise en réseau des instances de calcul accéléré EC2. Les chiffres de bande passante NVLink et EFA sont présentés comme des valeurs agrégées par instance plutôt que par lien.

L'Elastic Fabric Adapter (EFA) est une interface réseau pour Amazon EC2 qui fournit une capacité d'accès direct à la mémoire distante (RDMA) contournant le système d'exploitation en utilisant le protocole Scalable Reliable Datagram (SRD). En permettant aux applications de communiquer directement avec le dispositif réseau via l'API Libfabric — contournant le noyau du système d'exploitation — l'EFA réduit la latence et améliore le débit pour les opérations collectives dans l'entraînement distribué.

Plusieurs générations d'EFA sont disponibles sur différentes familles d'instances. Les instances Amazon EC2 P5 et P5e sont équipées de la version 2 d'EFA (EFAv2). La version 3 d'EFA (EFAv3), fournie sur les instances P5en, réduit la latence des paquets d'environ 35 % par rapport à EFAv2. La version 4 d'EFA (EFAv4), disponible sur les instances P6, offre une amélioration supplémentaire de 18 % des performances de communication collective par rapport à EFAv3.

À grande échelle, tant l'entraînement distribué (streaming de corpus et écriture de points de contrôle multi-téraoctets) que l'inférence à grande échelle (staging des poids et gestion de la croissance du cache KV) motivent une hiérarchie de stockage en plusieurs niveaux — NVMe SSD local pour les données chaudes, Lustre pour un accès partagé à haut débit, et Amazon S3 pour la persistance durable.

Dans les principales instances multi-GPU de cette série, le NVMe local est fourni comme stockage d'instance (éphémère) avec une capacité brute de 30,72 To (8 × 3,84 To NVMe SSD).

Lustre est un système de fichiers distribué open-source, conforme à POSIX, largement utilisé dans le calcul haute performance (HPC) pour fournir un espace de noms partagé avec un débit agrégé élevé à travers de nombreux clients. Amazon FSx for Lustre fournit Lustre en tant que service entièrement géré et l'expose comme un système de fichiers parallèle capable de plusieurs téraoctets par seconde de débit, de millions d'IOPS et de latences inférieures à la milliseconde. Les Data Repository Associations permettent l'intégration avec Amazon S3, soutenant le chargement paresseux des ensembles de données d'entraînement et l'exportation automatique des points de contrôle pour la durabilité.

À l'échelle du cluster, ces instances sont déployées dans des Amazon EC2 UltraClusters, qui provisionnent des milliers d'instances accélérées comme un seul cluster étroitement placé au sein d'une zone de disponibilité et les interconnectent à l'aide d'un réseau non-bloquant à échelle petabit.

Pour les charges de travail avec une forte intensité de communication par étape (par exemple, le parallélisme expert dans les modèles MoE où la distribution de tous les tokens s'étend sur de nombreux GPU), la taille du domaine NVLink peut devenir une contrainte de premier ordre. En tant qu'extension de l'axe de scaling interne, l'augmentation du domaine NVLink réduit la fréquence à laquelle la communication critique pour la performance doit quitter le tissu NVLink.

Les Amazon EC2 UltraServers étendent le domaine NVLink au-delà d'une seule instance EC2 en connectant plusieurs instances composants via une interconnexion d'accélérateur dédiée. AWS rapporte que les UltraServers P6e-GB200 sont construits sur la plateforme NVIDIA GB200 NVL72 et exposent jusqu'à 72 GPU Blackwell et 13,4 To de HBM3e agrégée au sein d'un domaine NVLink.