Dans les coulisses de l’entraînement distribué : pourquoi le câblage de vos GPU compte autant que votre stratégie

Dans les coulisses de l’entraînement distribué : pourquoi le câblage de vos GPU compte autant que votre stratégie

Dans la course à l’entraînement de modèles d’IA toujours plus volumineux, les projecteurs sont souvent braqués sur les innovations algorithmiques : nouvelles architectures, astuces d’optimisation et lois de passage à l’échelle. Mais tout praticien ayant tenté de distribuer l’entraînement sur plusieurs GPU sait que le véritable goulot d’étranglement n’est souvent pas mathématique : ce sont les câbles, la topologie et la configuration de votre matériel. Cet article vous emmène dans les coulisses de l’entraînement distribué pour révéler pourquoi le câblage de vos GPU peut être aussi crucial que votre stratégie d’entraînement, et fournit un guide pratique pour configurer un environnement multi-GPU qui tienne réellement ses promesses théoriques.

Le goulot d’étranglement caché : la surcharge de communication

Lorsque vous distribuez l’entraînement sur plusieurs GPU, chaque périphérique calcule ses gradients indépendamment sur sa propre partition de données. Le vrai défi commence lorsque ces gradients doivent être synchronisés – un processus appelé *all-reduce*. Cette étape de communication peut dominer le temps d’entraînement si le réseau entre les GPU n’est pas optimisé.

Les GPU modernes communiquent via NVLink (l’interconnexion haute vitesse de NVIDIA) ou des lignes PCIe. NVLink offre une bande passante nettement supérieure et une latence plus faible que le PCIe. Par exemple, un seul pont NVLink peut délivrer 900 Go/s en bidirectionnel, tandis que le PCIe Gen4 x16 plafonne à environ 32 Go/s. Si vos GPU ne sont connectés que par PCIe, la surcharge de communication peut engloutir 30 à 50 % du temps d’entraînement, surtout pour les grands modèles. C’est là que le câblage compte : la topologie physique de votre cluster GPU détermine directement la rapidité avec laquelle les gradients peuvent être partagés.

La topologie compte : anneau, arbre ou tout-à-tous

La stratégie que vous choisissez pour la synchronisation des gradients dépend également du câblage. Trois topologies sont courantes :

• **Ring All-Reduce** : les GPU sont disposés en anneau logique, chacun transmettant les gradients au suivant. Cette approche passe bien à l’échelle de façon linéaire avec le nombre de GPU, mais nécessite des interconnexions à haute bande passante et faible latence entre les nœuds adjacents.
• **Tree All-Reduce** : une structure hiérarchique où un nœud racine agrège les gradients et les rediffuse. C’est plus simple, mais cela crée un point de défaillance unique et peut créer un goulot d’étranglement à la racine.
• **All-to-All** : chaque GPU communique directement avec tous les autres. Cette approche est idéale pour les petits clusters dotés d’interconnexions rapides comme NVSwitch, mais devient inefficace à mesure que la taille du cluster augmente.

Votre choix de topologie doit correspondre à votre câblage. Par exemple, si vos GPU sont connectés via un seul commutateur PCIe, une structure en arbre peut s’imposer à vous, limitant le passage à l’échelle. Avec NVLink et NVSwitch, vous pouvez implémenter une véritable communication tout-à-tous.

Prérequis

Avant de commencer, assurez-vous que votre système répond à ces exigences matérielles et logicielles :

• **Au moins deux GPU NVIDIA** avec support NVLink (par exemple A100, V100, RTX 3090 ou plus récents). Pour les configurations PCIe uniquement, les performances seront inférieures.
• **Pilotes NVIDIA** version 450 ou ultérieure.
• **CUDA Toolkit** 11.0 ou ultérieur.
• **Python** 3.8 ou ultérieur.
• **PyTorch** 1.10 ou ultérieur (avec le package distribué).
• **NCCL** (NVIDIA Collective Communications Library) installé – c’est le backend de communication.
• **Un système de fichiers partagé** (par exemple NFS) ou un moyen de synchroniser les points de contrôle du modèle entre les nœuds.

Installation pas à pas

1. Vérifier la connectivité des GPU

Commencez par vérifier la topologie de vos GPU pour comprendre le câblage. Utilisez la commande `nvidia-smi topo -m` pour afficher la matrice de connectivité.

nvidia-smi topo -m

Cela montre quels GPU sont connectés via NVLink (marqués "NV" ou "NV#") par rapport au PCIe (marqués "PIX", "PHB" ou "NODE"). Si vous ne voyez que "PIX" ou "PHB" entre les GPU, vous avez une configuration PCIe uniquement.

2. Installer la NVIDIA Collective Communications Library (NCCL)

NCCL est le backend de communication utilisé par le package distribué de PyTorch. Installez-le via le dépôt NVIDIA.

# Ajouter les dépôts de paquets NVIDIA
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update

# Installer NCCL
sudo apt-get install libnccl2 libnccl-dev

Pour les autres distributions Linux, suivez le [guide d’installation NCCL de NVIDIA](https://developer.nvidia.com/nccl) (page d’accueil générale, pas un lien spécifique).

3. Configurer un environnement virtuel Python

Isolez vos dépendances pour éviter les conflits de versions.

python3 -m venv distributed_env
source distributed_env/bin/activate
pip install --upgrade pip

4. Installer PyTorch avec le support CUDA

Utilisez la commande d’installation officielle de PyTorch pour votre version CUDA.

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

Vérifiez l’installation en confirmant que CUDA est disponible.

import torch
print(torch.cuda.is_available())
print(torch.cuda.device_count())

5. Installer les dépendances supplémentaires

Pour cet exemple, nous avons également besoin de `torch.distributed`, qui est inclus avec PyTorch, et éventuellement de `torchinfo` pour le résumé du modèle.

pip install torchinfo

Exemples d’utilisation

Exemple 1 : Entraînement multi-GPU sur un seul nœud avec Distributed Data Parallel (DDP)

C’est la configuration la plus courante pour une seule machine avec plusieurs GPU. DDP gère automatiquement la synchronisation des gradients via NCCL.

Créez un fichier `train_ddp.py` :

import os
import torch
import torch.nn as nn
import torch.optim as optim
import torch.distributed as dist
from torch.nn.parallel import DistributedDataParallel as DDP
from torch.utils.data import DataLoader, TensorDataset
from torch.utils.data.distributed import DistributedSampler

def setup(rank, world_size):
    os.environ['MASTER_ADDR'] = 'localhost'
    os.environ['MASTER_PORT'] = '12355'
    dist.init_process_group('nccl', rank=rank, world_size=world_size)

def cleanup():
    dist.destroy_process_group()

class SimpleModel(nn.Module):
    def __init__(self):
        super().__init__()
        self.fc = nn.Linear(784, 10)

    def forward(self, x):
        return self.fc(x)

def train(rank, world_size):
    setup(rank, world_size)
    device = torch.device(f'cuda:{rank}')

    model = SimpleModel().to(device)
    ddp_model = DDP(model, device_ids=[rank])

    # Jeu de données factice : 1000 échantillons de données aléatoires
    data = torch.randn(1000, 784)
    labels = torch.randint(0, 10, (1000,))
    dataset = TensorDataset(data, labels)
    sampler = DistributedSampler(dataset, num_replicas=world_size, rank=rank)
    loader = DataLoader(dataset, batch_size=32, sampler=sampler)

    criterion = nn.CrossEntropyLoss()
    optimizer = optim.SGD(ddp_model.parameters(), lr=0.01)

    for epoch in range(5):
        sampler.set_epoch(epoch)
        for inputs, targets in loader:
            inputs, targets = inputs.to(device), targets.to(device)
            optimizer.zero_grad()
            outputs = ddp_model(inputs)
            loss = criterion(outputs, targets)
            loss.backward()
            optimizer.step()
        print(f'Rang {rank}, Époque {epoch}, Perte : {loss.item()}')

    cleanup()

if __name__ == "__main__":
    world_size = torch.cuda.device_count()
    torch.multiprocessing.spawn(train, args=(world_size,), nprocs=world_size)

Exécutez le script :

python train_ddp.py

Exemple 2 : Entraînement multi-nœuds avec torchrun

Pour plusieurs machines, utilisez `torchrun` qui gère le lancement des processus et la configuration.

Assurez-vous d’abord que tous les nœuds ont le même environnement et peuvent se joindre sur le réseau. Sur le nœud maître, définissez `MASTER_ADDR` sur son adresse IP.

Créez `train_multinode.py` :

import os
import torch
import torch.nn as nn
import torch.distributed as dist
from torch.nn.parallel import DistributedDataParallel as DDP

def train():
    local_rank = int(os.environ['LOCAL_RANK'])
    global_rank = int(os.environ['RANK'])
    world_size = int(os.environ['WORLD_SIZE'])

    dist.init_process_group('nccl', rank=global_rank, world_size=world_size)
    torch.cuda.set_device(local_rank)
    device = torch.device(f'cuda:{local_rank}')

    model = nn.Linear(784, 10).to(device)
    ddp_model = DDP(model, device_ids=[local_rank])

    # Boucle d’entraînement (simplifiée)
    data = torch.randn(64, 784).to(device)
    labels = torch.randint(0, 10, (64,)).to(device)
    criterion = nn.CrossEntropyLoss()
    optimizer = torch.optim.SGD(ddp_model.parameters(), lr=0.01)

    for _ in range(10):
        optimizer.zero_grad()
        output = ddp_model(data)
        loss = criterion(output, labels)
        loss.backward()
        optimizer.step()

    print(f'Rang {global_rank} terminé')
    dist.destroy_process_group()

if __name__ == "__main__":
    train()

Exécutez sur chaque nœud :

# Sur le nœud maître (IP 192.168.1.10)
torchrun --nnodes=2 --nproc_per_node=4 --rdzv_endpoint=192.168.1.10:12355 train_multinode.py

# Sur le nœud worker (IP 192.168.1.11)
torchrun --nnodes=2 --nproc_per_node=4 --rdzv_endpoint=192.168.1.10:12355 train_multinode.py

Exemple 3 : Mesure de la bande passante de communication

Utilisez l’outil de benchmark NCCL pour mesurer la bande passante réelle entre les GPU. Cela vous aide à comprendre si votre câblage est le goulot d’étranglement.

# Installer nccl-tests
git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests
make

# Exécuter le benchmark all-reduce sur 4 GPU
./build/all_reduce_perf -b 8 -e 128M -f 2 -g 4

La sortie affiche la bande passante du bus en Go/s. Comparez-la au maximum théorique de votre interconnexion. Si vous obtenez des valeurs nettement inférieures, votre câblage (lignes PCIe, ponts NVLink ou topologie du commutateur) limite peut-être les performances.

Comprendre les résultats : câblage contre stratégie

Les benchmarks de `nccl-tests` révéleront une différence frappante entre les GPU connectés par NVLink et ceux connectés par PCIe. Par exemple, sur un système avec quatre GPU A100 connectés via NVSwitch, la bande passante all-reduce peut dépasser 600 Go/s. Sur un système avec quatre GPU connectés via PCIe Gen4 à travers un seul socket CPU, la bande passante pourrait n’être que de 12 Go/s – soit un facteur 50. Cela signifie que même avec une stratégie d’entraînement parfaite (par exemple, accumulation de gradients, précision mixte), votre débit d’entraînement effectif est plafonné par le lien de communication le plus lent.

Conseil pratique : si vous construisez une station de travail multi-GPU, privilégiez la connectivité NVLink. Pour les clusters, envisagez d’utiliser NVSwitch ou InfiniBand pour la communication inter-nœuds. Les stratégies logicielles comme la compression des gradients (par exemple avec `torch.distributed.algorithms.ddp_comm_hooks`) peuvent aider, mais elles ajoutent de la surcharge et de la complexité. La solution la plus simple est de câbler correctement vos GPU dès le départ.

Conclusion

L’entraînement distribué ne se résume pas à des algorithmes élégants – il s’agit aussi de la réalité physique de la façon dont vos GPU communiquent entre eux. La topologie du câblage, qu’il s’agisse de NVLink, PCIe ou InfiniBand, détermine directement la surcharge de communication et peut faire ou défaire vos efforts de passage à l’échelle. En suivant les étapes d’installation et les benchmarks de cet article, vous pouvez diagnostiquer et optimiser votre configuration matérielle, garantissant ainsi que votre stratégie d’entraînement fonctionne à pleine vitesse. N’oubliez pas : un cluster bien câblé est le fondement sur lequel repose tout passage à l’échelle de l’IA. Investissez dans votre câblage autant que dans votre stratégie d’entraînement.