Briser le goulot d’étranglement de la mémoire hôte : comment Peer Direct a transformé les performances cloud de Gaudi
Après avoir introduit les accélérateurs Gaudi dans les instances EC2 DL1 d’Amazon, nous avons été confrontés à un défi qui menaçait l’ensemble du déploiement. Les chiffres de performance n’étaient pas seulement décevants ; ils ont été désastreux. Les modèles qui nécessitaient une formation efficace voyaient jusqu’à 50 % de leurs performances se dégrader lors d’une mise à l’échelle sur plusieurs nœuds. Le problème ? Une topologie de réseau qui acheminait tous les octets de données via la mémoire hôte, provoquant un goulot d’étranglement qui sapait tout ce pour quoi Gaudi était conçu.
J’ai dirigé les efforts d’ingénierie visant à résoudre ce problème, qui ont finalement abouti au développement de ce que nous appelons désormais Peer Direct. Il s’agit d’une fonctionnalité qui a transformé la façon dont les accélérateurs de Gaudi communiquent dans les environnements cloud, et son histoire contient des leçons utiles sur la formation à l’IA distribuée à grande échelle.
Le problème avec les cartes réseau hôtes
Gaudi a été conçu avec la NIC (Network Interface Card) intégrée directement dans le silicium. Chaque puce dispose de dix interfaces réseau pouvant gérer 100 Gbit/s et prendre en charge RDMA avec RoCE v2, permettant aux appareils d’accéder directement à la mémoire des autres sans avoir besoin du processeur ou de cette architecture.
Mais les déploiements cloud ne sont pas toujours conformes à des architectures parfaites. Lorsqu’Amazon a testé Gaudi pour les instances DL1, ils ont dû utiliser des cartes réseau hôtes ordinaires plutôt que le réseau intégré de Gaudi. Les raisons étaient pragmatiques : économies de coûts et logistique liée au travail autour de l’infrastructure de centre de données existante pour s’adapter à une nouvelle topologie de réseau. De leur point de vue commercial, tirer parti de l’infrastructure réseau établie était parfaitement logique.
Du point de vue des performances, ce fut un désastre. Au lieu de transferts RDMA peer-to-peer entre cartes Gaudi, toutes les communications ont fait un long chemin. Les données devaient être dupliquées depuis la mémoire à large bande passante de Gaudi vers la DRAM hôte, traitées par le processeur hôte, envoyées à la carte réseau hôte via TCP/IP, reçues par l’hôte distant et dupliquées dans la mémoire distante de Gaudi. Tous les sauts supplémentaires provoquaient une latence, volaient des cycles de processeur et ajoutaient des restrictions de bande passante qui ruinaient complètement l’évolutivité de la formation distribuée.
Le déficit de performances était si grave que l’on se demandait si le déploiement en vaudrait un jour la peine. Il ne s’agissait pas d’une optimisation triviale ; c’était une menace existentielle pour l’ensemble de l’accord avec AWS.
Pourquoi la performance est si importante
Il vaut la peine de savoir pourquoi une perte de performances de 50 % est si désastreuse dans la vie des modèles d’entraînement, et notamment des grands modèles comme le GPT-5. Il faut désormais des semaines, voire des mois, pour former d’énormes modèles de langage, même sur d’énormes clusters. Si vous utilisez des modèles comportant des milliards ou des milliards de paramètres, chaque point de pourcentage de performance se traduit directement en temps et en dollars.
Considérez l’économie. S’il faut 30 jours pour former un modèle au lieu de 15, non seulement vous attendez plus longtemps ; vous payez le double du temps de calcul. À l’échelle du cloud, avec des centaines ou des milliers d’accélérateurs utilisés en continu, cela représente des millions de dollars. Pire encore, cela réduit de moitié votre vitesse d’itération. Dans un monde compétitif de l’IA où les entreprises s’efforcent de développer des modèles améliorés, doubler le nombre de tests dans le même laps de temps peut faire la différence entre être en avance et être en retard.
Le coût environnemental est également crucial. Les grands modèles nécessitent beaucoup d’électricité pour enseigner. De meilleures performances signifient moins de temps de calcul, ce qui réduit de moitié la consommation d’énergie et les émissions de carbone. Alors que la pression s’accentue sur l’industrie de l’IA pour qu’elle réduise son empreinte carbone, les gains d’efficacité ne sont plus un luxe mais plutôt une nécessité.
La solution que nous avons conçue, Peer Direct, offrait des performances de type RDMA lorsque la configuration physique du réseau n’était pas adaptée au RDMA normal. Nous avions besoin d’un accès direct à la mémoire entre les appareils Gaudi sur différents systèmes sans traverser la mémoire hôte, mais sur des cartes réseau hôtes qui n’étaient pas conçues pour cela en premier lieu.
Le catalyseur était AWS Elastic Fabric Adapter, une interface réseau hautes performances pour les charges de travail HPC et IA sur EC2. EFA fournit des communications de contournement du système d’exploitation à faible latence, généralement inférieure à 10 microsecondes. EFA fournit une sémantique de type RDMA à l’aide de libfabric, une bibliothèque de communication dans l’espace utilisateur fournissant une interface commune à plusieurs technologies réseau.
La tâche consistait à combiner libfabric avec la bibliothèque de communication collective de Habana, HCCL, qui gère toutes les charges de travail de formation distribuées. HCCL a été construit sur l’hypothèse d’un RDMA natif utilisant les cartes réseau sur puce de Gaudi. Nous devions créer un pont permettant à HCCL d’exploiter libfabric de manière transparente pour les communications sans compromettre ses garanties de performances et sa sémantique de communication.
La solution nécessitait plusieurs avancées techniques. Tout d’abord, nous avons introduit un système d’enregistrement de mémoire qui permettait à libfabric d’accéder directement à la mémoire à large bande passante de Gaudi. Nous avons utilisé le framework DMA-BUF du noyau Linux, qui fournit un mécanisme partagé pour partager les tampons des pilotes de périphériques. Lorsque HCCL doit transférer des données, le pilote Gaudi fournit un descripteur de fichier DMA-BUF pour la région mémoire, que libfabric peut utiliser pour créer des transferts RDMA directement à partir de la mémoire de l’appareil.
Deuxièmement, nous avons inclus un cache LRU pour les enregistrements de mémoire. L’enregistrement de la mémoire coûte cher ; cela implique des appels au noyau et des opérations de configuration qui peuvent entraîner une surcharge importante. En mettant en cache le mappage des adresses mémoire sur leurs descripteurs libfabric, nous pourrions réutiliser les enregistrements dans les régions d’accès à chaud, éliminant ainsi la majeure partie des frais d’enregistrement liés à la formation réelle.
Le résultat était un pipeline de communication qui ressemblait à ceci : HCCL appelle le wrapper OFI, qui appelle le handle libfabric mis en cache pour effectuer un transfert RDMA directement de la mémoire Gaudi source à la mémoire Gaudi de destination, sans qu’aucun des deux processeurs ne soit appelé. Le wrapper OFI a été introduit pour garder la base de code propre et éviter les inclusions directes d’en-tête. Il s’agit d’une bibliothèque légère qui est liée dynamiquement à HCCL et permet l’utilisation de libfabric sans nécessiter d’intégration directe.
Une fois le transfert terminé, libfabric génère un rapport via une file d’attente d’achèvement et HCCL continue le calcul avec les données récemment reçues.
L’expérience de développement
Construire Peer Direct impliquait de s’aventurer sur de nouveaux territoires dans des délais serrés. Libfabric n’était pas encore courant dans le domaine des accélérateurs d’IA. Il n’y avait pas beaucoup de documentation publique disponible et les discussions étaient maigres. L’accent était davantage mis sur la plongée dans le code source de libfabric et la rétro-ingénierie basée sur l’expérimentation.
La communication avec les ingénieurs AWS était primordiale mais limitée par le fuseau horaire. Travailler avec une équipe douze heures à l’avance signifiait que les itérations de débogage avaient des délais d’exécution de 24 heures. Chaque problème nécessitait une documentation minutieuse et une communication appropriée, car la collaboration en temps réel n’était pas possible.
Les enjeux étaient élevés puisque l’ensemble du déploiement de DL1 reposait sur le fonctionnement de cette fonctionnalité. Des retards auraient contrecarré un lancement de produit majeur. Personne dans notre équipe n’avait une connaissance approfondie des composants internes de libfabric, nous apprenions donc une base de code complexe tout en concevant simultanément une intégration critique.
Les résultats
Lorsque nous avons effectivement déployé Peer Direct, les améliorations de vitesse valaient tous les efforts déployés. Nous avons constaté une augmentation du débit de 1,5 à 2 fois pour les opérations collectives sur une taille de message de 32 Mo. Sur les messages plus volumineux, les performances étaient encore plus étonnantes, avec un débit jusqu’à 1,76 fois supérieur pour une taille de message de 256 Mo. La surcharge du processeur a créé un goulot d’étranglement qui a complètement disparu.
Plus important encore, ces améliorations des microbenchmarks se sont directement traduites en performances réelles de formation du modèle. En entraînant le modèle DeepSpeed BERT de Habana avec 5 milliards de paramètres sur 128 appareils Gaudi, nous avons constaté un gain de débit substantiel. Les modèles utilisant des méthodes d’optimisation de mémoire plus agressives, comme ZeRO-2, qui dépendent davantage des opérations collectives, ont bénéficié de manière disproportionnée de Peer Direct.
PeerDirect a été l’un des principaux catalyseurs des performances de Gaudi sur les instances AWS DL1, permettant à une formation distribuée à grande échelle de s’exécuter sans effort le jour du lancement. Au-delà de cet impact initial, ces efforts ont jeté les bases de futures fonctionnalités de communication hautes performances et ont prouvé que les accélérateurs d’IA cloud natifs pouvaient rester compétitifs malgré les contraintes de l’infrastructure cloud.
Cette expérience m’a rappelé une leçon importante en ingénierie des systèmes : souvent, les améliorations de performances les plus importantes ne résultent pas de l’optimisation de la voie rapide, mais du fait d’éviter des détours injustifiés. Lors de la formation à l’IA distribuée, ce sont les données qui transitent directement par les accélérateurs, sans copies inutiles et sans intervention du processeur, ce qui différencie un système fonctionnel d’un système évolutif.
Points clés à retenir ? Un « point à retenir » important de ce projet est que les hypothèses sur la topologie du réseau doivent être testées dès le début du processus de formation distribuée. Étant donné que de nombreuses piles d’accélérateurs ont été construites sur la base d’un environnement idéalisé, elles ne prennent pas en compte les sauts supplémentaires, les couches de traduction et/ou les facteurs liés aux coûts qui existent dans les environnements cloud. Par conséquent, avant de se concentrer sur l’optimisation au niveau du modèle ou au niveau du noyau, les ingénieurs doivent effectuer un simple microbenchmark collectif sur la topologie souhaitée. Si l’efficacité de la mise à l’échelle diminue considérablement avec l’augmentation du nombre de nœuds ou de la taille des messages, la raison est probablement le chemin des données, et non le noyau. En identifiant dès le début le détour hôte-mémoire, les ingénieurs peuvent concentrer leurs efforts là où ils auront le plus grand impact.
Un autre enseignement important a été la nécessité de traiter à la fois l’enregistrement de la mémoire et le transfert de données comme des problèmes de performances de premier ordre. La surcharge d’enregistrement de la mémoire peut largement dépasser le temps passé à communiquer si chaque transfert de données nécessite un nouvel enregistrement. Le cache LRU pour les mémoires enregistrées était un ajout non glamour à HCCL ; cependant, il a effectivement éliminé une source systémique de latence et a rendu le chemin RDMA viable pour les charges de travail du monde réel. Lors du développement de systèmes distribués, les ingénieurs doivent évaluer non seulement la bande passante réseau disponible, mais également les coûts du cycle de vie associés à l’allocation des tampons, à leur enregistrement et à la suppression de ces enregistrements. De petites modifications apportées à ces chemins de contrôle peuvent entraîner de fortes augmentations des débits de bout en bout.
Enfin, la méthode d’intégration utilisée dans ce projet fournit un modèle d’intégration. Au lieu de réécrire HCCL pour utiliser directement libfabric, nous avons créé une fine couche d’abstraction qui conservait la sémantique existante tout en remplaçant la couche de transport sous-jacente. Cela présentait plusieurs avantages, notamment la minimisation des risques, la réduction du taux de désabonnement du code et la possibilité de tests incrémentiels. Les équipes confrontées à un défi similaire (c’est-à-dire adapter les bibliothèques de communication natives des accélérateurs aux structures cloud natives) devraient tenter d’isoler la couche de transport, maintenir une sémantique collective et créer de petites interfaces testables entre les deux. Cela permet non seulement un développement plus rapide, mais également une prise en charge plus simple des futurs backends de transport.
Divulgation: Je travaille en tant que responsable de l’équipe AI Runtime chez Intel. Les perspectives partagées dans cet article sont les miennes.
