L'entraînement des modèles d'intelligence artificielle comme GPT-4 coûte des millions de dollars, et une grande partie de ces coûts provient non seulement des puces coûteuses, mais aussi d'un problème caché : la congestion du réseau. Les modèles d'IA modernes nécessitent des milliards de paramètres, qui doivent être calculés sur des milliers de GPU simultanément. Chaque GPU traite une partie des données, mais pour rester synchronisés, ils doivent constamment échanger des informations entre eux. Cette communication intensive génère un surcroît de trafic réseau, qui devient souvent le goulot d'étranglement, même si les GPU sont très performants. Dans un cluster d'IA, le réseau est généralement organisé en topologie spine-leaf, où chaque GPU est connecté à un switch "leaf" (ToR) et les switchs "spine" interconnectent les "leaf". Cette configuration permet une communication rapide et prévisible entre les nœuds. Cependant, pour des modèles de grande taille, le volume de données à transférer est gigantesque. Par exemple, sur un cluster de trois nœuds avec 8 GPU H100 chacun, chaque nœud doit envoyer environ 6,7 Go de données par étape d'entraînement. Avec des milliers d'étapes, cela génère des pétaoctets de trafic réseau. Pour gérer cela, les systèmes de production utilisent des protocoles comme RDMA (Remote Direct Memory Access), qui permet aux GPU d'envoyer des données directement dans la mémoire d'autres GPU sans passer par le CPU, réduisant ainsi la latence. RDMA repose sur le protocole RoCEv2, qui fonctionne sur Ethernet standard, et est accompagné de DCQCN (Data Center Quantized Congestion Notification) et PFC (Priority Flow Control) pour gérer la congestion. Mais ces technologies ne sont pas adaptées aux charges de travail d'IA, qui sont bursty (soudaines et massives), contrairement aux flux de stockage ou de transactions, qui sont plus répartis dans le temps. Dans un cas réel, des GPU comme A0 et C0 peuvent envoyer simultanément des données à B0, créant une surcharge soudaine sur le réseau. Les protocoles traditionnels, comme ECMP (Equal-Cost Multi-Path), peuvent provoquer des collisions de routage, envoyant plusieurs flux vers le même lien, ce qui entraîne une congestion. PFC, en envoyant des signaux de pause, arrête les envois avant que le réseau ne soit pleinement saturé, mais cela peut réduire l'efficacité globale. DCQCN, quant à lui, est réactif et ne peut pas répondre assez vite aux pics de trafic. Lorsque les paquets sont marqués, le réseau est déjà surchargé, et la réaction est trop lente. Cela a conduit des entreprises comme Meta à désactiver les mécanismes de congestion à la couche réseau, en les gérant à l'application. Cependant, cela peut entraîner des blocages et des comportements inéquitables. UCCL (Unified Collective Communication Library) propose une solution différente. Il agit comme une couche de transport logicielle entre NCCL (la bibliothèque de communication collective) et le pilote de carte réseau. UCCL a une visibilité totale sur les flux de communication avant qu'ils ne traversent le réseau, ce qui lui permet de gérer plus efficacement le trafic. Il donne le contrôle au récepteur, qui peut gérer le rythme d'envoi des données, évitant ainsi les pics de congestion. Il utilise aussi des files logicielles et un seul QP (Queue Pair) par carte réseau, ce qui réduit les collisions ECMP et améliore la gestion des transferts. Grâce à une planification intelligente des opérations comme AllReduce, UCCL évite les conflits de trafic et maintient un réseau stable même sous forte charge. Des tests ont montré que UCCL réduit les ralentissements réseau et accélère les opérations AllReduce, même sur des infrastructures existantes sans modifications. Cela en fait une solution viable et facile à intégrer pour les équipes réseau. En résumé, UCCL améliore la coordination entre GPU en gérant le trafic avant qu’il ne cause des problèmes, ce qui est essentiel pour l’entraînement efficace des modèles d’IA de grande taille.