IA : entre puces « maison » et GPU Nvidia, AWS choisit de ne pas choisir
Comme à son habitude, lors de Re:Invent 2023, AWS a vanté ses capacités de calcul. Cette année, la majorité des nouvelles instances ne sont pas encore disponibles, mais le géant du cloud prévoit d’héberger de grosses charges de travail d’IA, tandis qu’il poursuit le développement de ses propres puces.
À la fin du mois de novembre, la filiale d’Amazon a grandement mis en avant son infrastructure dédiée à l’IA et plus particulièrement à l’IA générative.
Il y a d’abord l’annonce de Trainium2, une puce dont les performances seraient quatre fois supérieures à la première génération. Cette puce consacrée à l’entraînement de modèles d’IA et de machine learning concurrence directement les produits de Nvidia et AMD. Elle aurait trois fois plus de mémoire et serait deux fois plus efficiente que Trainium1.
Pour rappel, une carte Trainium rassemble deux processeurs NeuronCore-v2, cadencés à 3 GHz associés à 32 Go de RAM HBM d’une bande passante de 820 Go/s. Chaque carte offre une bande passante de 1 To/s pour l’accès aux données via la fonction Direct Memory Acess (DMA).
Trainium2, en retard, Inferentia2, en production
Selon toute vraisemblance, Trainium2 disposerait donc de 96 Go de mémoire HBM. AWS n’en précise ni la variante ni la quantité de bande passante. Cette RAM est utilisée pour héberger les états et les poids des modèles, ce qui permettrait, en principe, d’entraîner de plus gros modèles qu’auparavant. Anthropic serait l’un des premiers fournisseurs de LLM à en profiter. À titre de comparaison, les puces H100 de Nvidia sont cadencées à 1,92 GHz et associées à 80 Go de RAM HBM3 pour 3,35 To/s de bande passante avec l’interface SXM5. La variante PCIe 5.0, elle, est couplée à 80 Go de RAM HBM2e pour une bande passante de 2 To/s.
AWS avait déjà actualisé ses puces et instances « maison » pour exécuter des algorithmes. Présentées en fin d’année 2022, les instances propulsées par la puce Inferentia2 sont accessibles en disponibilité générale depuis le 13 décembre dans quatre tailles et dans huit régions cloud. Elles reprennent l’architecture des puces Trainium1. La grande différence tient dans la taille des instances : quand un serveur Trainium1 peut accueillir jusqu’à 16 cartes Trn1, sa variante Inf2 n’en héberge que douze au maximum.
En complément, le géant du cloud met à jour son SDK AWS Neuron déjà capable de prendre en charge les frameworks de machine learning TensorFlow et PyTorch. Il supportera bientôt Jax, une librairie open source développée et exploitée à large échelle par les ingénieurs de Google (entre autres, pour entraîner les modèles Gemini).
Pour les utilisateurs de la plateforme SageMaker, les HyperPods doivent permettre d’accéder à des instances préconfigurées incluant les piles logicielles optimisées pour le parallélisme des calculs, ce qui réduirait de 40 % le temps d’entraînement des modèles de fondation. Surtout, AWS donne accès à un mécanisme de détection des équipements défectueux et de failover automatique, un des gros défis pour les ingénieurs ML.
AWS ne ferme pas la porte à Nvidia, bien au contraire
AWS a également élargi son partenariat avec Nvidia. Les deux fournisseurs apporteront au cloud les « superpuces » Grace Hopper GH200.
Précisons que Nvidia propose deux variantes de cette architecture combinant CPU et GPU. Le CPU Grace ne change pas. Il est doté de 72 cœurs ARM Neoverse V2 et a accès à un total de 480 Go de RAM LPDDR5 sur circuit. La première variante est couplée à une puce Hopper disposant jusqu’à 96 Go de RAM HBM3 et d’une bande passante mémoire d’un maximum de 4 To/s. La deuxième sera dotée de 144 Go de RAM HBM3e (141 Go disponibles) pour une bande passante de 4,9 To/s, selon Nvidia. Le fournisseur fabless lancera ce GPU séparément sous l’appellation H200 et dans les systèmes HGX H200, avec une bande passante de 4,8 To/s pour une date de disponibilité prévue au deuxième semestre 2024.
D’abord, le géant du cloud va déployer des racks GH200 NVL32. Comme son nom l’indique, ce rack accueille 32 accélérateurs GH200 dotés chacun de 144 Go de (V) RAM HBM3e. Ceux-là sont répartis par couple, sur 16 lames séparées physiquement en deux groupes par neuf lames consacrées au switch NVLink (900 Go à 1 To/s). Deux groupes de trois lames réparties équitablement entre le bas et le haut du rack accueillent les alimentations nécessaires. Derrière chaque rack, deux braquets se connectent aux lames pour en assurer le refroidissement liquide, tandis qu’au centre un espace rassemble les câbles nécessaires aux interconnexions NVLink.
« Les nœuds de serveur GH200 sont reliés par une cartouche de câble en cuivre passif NVLink pour permettre à chaque GPU Hopper d’accéder à la mémoire de n’importe quelle autre Grace Hopper Superchip dans le réseau, fournissant 32 x 624 Go, soit 19,5 To de mémoire adressable NVLink », assure Nvidia.
Si tel est vraiment le cas, précisons plutôt que le système dispose de 15 To de mémoire LPDDR5 et de 4,5 To de RAM HBM3e partagés.
Dans les data centers d’AWS, chaque GH200 NVL32 sera interconnecté à l’aide du réseau Elastic Fabric Adapter (EFAv3) pouvant atteindre jusqu’à 400 Go/s (3 200 Gbit/s).
Ces racks serviront à propulser des UltraClusters EC2 réunissant « plusieurs milliers de GPU », pilotés par l’hyperviseur Nitro.
AWS prétend qu’il peut déjà interconnecter jusqu’à 20 000 GPU H100, soit 2 500 instances p5.48xlarge (192, vCPU, 2 To de RAM, 8 GPU H100).
Nvidia et AWS collaboreront également pour héberger la plateforme DGX Cloud qui rassemble les logiciels de Nvidia et l’accès à la demande à cette infrastructure.
Si l’association de Nvidia avec un autre fournisseur de cloud n’est pas surprenante (le spécialiste des GPU s’est déjà associé à Google et Microsoft), « la disponibilité de DGX Cloud sur AWS est importante, car les clients AWS utilisent les logiciels et les équipements depuis de nombreuses années », déclare Mike Gualtieri, analyste chez Forrester.
En outre, Nvidia et AWS entendent bâtir ensemble un HPC nommé « Project Ceiba ». La même architecture devra permettre d’interconnecter 16 384 GH200, soit 512 racks GH200 NVL32 pour une capacité de 65 exaflops. Oracle a déjà annoncé qu’il s’équiperait des GH200, tout comme Microsoft, Google et Meta.
À la question de savoir si Nvidia peut répondre à la demande, Ian Buck, directeur général et vice-président des activités Hyperscale et HPC chez Nvidia, répond que « c’est difficile, mais que [le groupe] augmente de manière significative ses capacités de production et de livraison ».
À noter qu’AWS déploiera aussi les H200 dans ses EC2 P5e, ainsi que les cartes L4 et L40S dans les instances G6 et G6e.
Dan NewmanAnalyste, Futurum Research
« Avec ces annonces, AWS montre qu’il va continuer à offrir une diversité de silicium à ses clients », affirme Dan Newman, analyste chez Futurum Research. « En tant qu’hyperscaler, il doit faire preuve de flexibilité et diversifier ses services afin de ne pas s’aliéner certains clients en n’ayant pas les produits et les solutions qu’ils veulent ».
Des puces Graviton (encore) plus performantes
Si le géant du cloud a largement communiqué sur ses capacités de calcul pour entraîner les modèles d’IA générative, n’oublions pas de mentionner l’arrivée prochaine des machines équipées des puces Graviton 4. AWS promet une hausse de 30 % des performances par rapport à la génération précédente et « deux fois plus de cœurs ».
Cette quatrième version inclut 96 cœurs Neoverse V2, 2 Mo de cache L2 par cœur et 12 canaux DDR5 5 600 MHz. Le Graviton serait « jusqu’à 40 % plus rapide pour les bases de données, 30 % plus rapide pour les applications web et 45 % plus rapide pour les grandes applications Java que le Graviton3 », assure AWS. Les instances R8g, accessibles en préversion privée, en sont déjà équipées.
Enfin, en préversion publique dans les régions US West (Oregon), Asie-Pacifique (Séoul) et Europe (Francfort), les instances EC2 U7i, pour les « grosses » bases de données en mémoire, offre 896 vCPU propulsés par des processeurs Intel Xeon Scalable de quatrième génération associés à 12, 16, 24 ou 32 To de RAM DDR5 et jusqu’à 64 To de stockage via Amazon EBS. Il s’agit là d’assurer le maintien en production de SGBD relationnel tel SAP HANA, Oracle et SQL Server. Ces instances prennent en charge RHEL (Red Hat Enterprise Linux Server) ou SLES (SUSE Enterprise Linux Server).