Dans ce billet, nous explorons les mécanismes de communication entre plusieurs GPU dans un cadre distribué, en se concentrant sur les opérations point à point et collectives offertes par le module torch.distributed de PyTorch. Ces opérations sont essentielles pour coordonner les calculs et échanger des données entre les différents rôles (ranks) dans un environnement multi-GPU. Sous le capot, PyTorch utilise des bibliothèques de communication spécialisées : NCCL pour les GPU NVIDIA, et RCCL pour les GPU AMD. NCCL optimise les communications en détectant automatiquement la topologie du système (PCIe, NVLink, InfiniBand) et en choisissant le chemin le plus efficace. La communication peut être synchrone (bloquante) ou asynchrone (non bloquante). Dans le cas synchrone, l’exécution du code attend la fin de l’opération de communication. En revanche, les opérations asynchrones permettent de poursuivre l’exécution immédiatement après l’envoi de la tâche, en utilisant des objets Request pour gérer la synchronisation ultérieure via req.wait(). Les opérations point à point, comme send et recv, permettent un échange direct entre deux rôles. Bien que ces appels soient marqués comme synchrones, ils bloquent le thread CPU uniquement jusqu’à l’envoi du noyau NCCL dans la file CUDA, pas jusqu’à la fin du transfert réel. Une exception notable concerne le premier appel à recv dans un processus, qui est véritablement bloquant pour initialiser NCCL. Cette particularité peut entraîner des blocages si le code tente d’accéder aux données du GPU avant leur réception, comme illustré dans un exemple où le processus 1 s’arrête sur print(t) en attendant une synchronisation hôte-périphérique. Les opérations collectives, quant à elles, impliquent plusieurs rôles simultanément. Elles sont divisées en catégories : une vers tous, tous vers un, et tous vers tous. La broadcast permet à un rôle source d’envoyer des données à tous les autres. La scatter répartit des morceaux de données d’un liste à chaque rang. La reduce combine des données de tous les rôles selon une opération (par exemple, une somme) et les stocke sur un rôle cible. La gather rassemble des données de tous les rôles sur un seul rôle. Les opérations all_reduce et all_gather sont des variantes distribuées : elles appliquent l’opération sur tous les rôles et retournent les résultats à chacun. Enfin, reduce_scatter combine des données, puis distribue les résultats partiels à chaque rang. La synchronisation est cruciale. Deux outils principaux sont utilisés : request.wait() pour attendre la fin d’une opération asynchrone, et torch.cuda.synchronize() pour bloquer le CPU jusqu’à la fin de toutes les opérations CUDA en cours. Leur différence réside dans le niveau de synchronisation : wait() concerne une seule opération, tandis que synchronize() bloque tout le contexte CUDA. Ces mécanismes forment la base des architectures distribuées pour l’IA, permettant une scalabilité efficace sur plusieurs GPU. Dans le prochain article, nous approfondirons les interconnexions matérielles comme PCIe et NVLink, qui rendent ces communications rapides et efficaces. Expertise sectorielle : Les experts en systèmes distribués soulignent que la maîtrise des opérations collectives est essentielle pour éviter les goulets d’étranglement dans les entraînements de modèles à grande échelle. NCCL, en particulier, est reconnu pour sa performance optimisée sur les infrastructures NVIDIA, ce qui en fait un pilier fondamental des stacks de machine learning modernes. Des entreprises comme NVIDIA, Meta, et Hugging Face exploitent ces primitives pour des frameworks comme PyTorch et DeepSpeed, garantissant des temps d’entraînement réduits et une scalabilité horizontale robuste.