Technical Tutorials

La construction de clusters d'entraînement de grands modèles de langage (LLM) repose moins sur l'achat de GPU individuels que sur l'architecture des connexions entre eux. À mesure que les modèles passent de milliards à des billions de paramètres, le « mur réseau » devient le goulot d'étranglement principal. Les ingénieurs doivent choisir entre la solution propriétaire de NVIDIA NVLink pour une couplage serré et Ethernet (spécifiquement InfiniBand ou RoCE) pour la mise à l'échelle horizontale. Cet article détaille les compromis techniques pour vous aider à concevoir la topologie appropriée.

Comprendre le paysage de la bande passante

La différence fondamentale réside dans le débit et la latence. NVLink fournit un réseau à haute bande passante et faible latence directement entre les GPU, faisant efficacement fonctionner plusieurs GPU comme une seule unité de mémoire massive. Ethernet, bien qu'considérablement amélioré avec des technologies comme le 400GbE ou le 800GbE et le RDMA (Remote Direct Memory Access), introduit une latence plus élevée en raison de la couche de commutation et de la surcharge du protocole.

Pour le parallélisme des données, où chaque GPU détient une copie du modèle et traite différents lots de données, Ethernet est souvent suffisant. Cependant, pour le parallélisme de modèle ou le parallélisme de pipeline — où les tenseurs d'activation doivent être échangés fréquemment lors des passes arrière — la bande passante supérieure de NVLink empêche les unités de calcul de rester inactives en attendant les données.

Considérations de topologie

Lors de la conception de votre cluster, vous devez prendre en compte la manière dont les GPU sont regroupés. Une idée fausse courante est que vous pouvez simplement enchaîner les GPU via Ethernet pour tout faire. Voici une analyse pratique :

Topologie NVLink : Généralement utilisée au sein d'un seul nœud (par exemple, 8 GPU H100 connectés via NVSwitch). Cela crée un effet de « super-GPU ».
Topologie Ethernet/InfiniBand : Utilisée pour la communication inter-nœuds. C'est ici que vous connectez des milliers de nœuds entre eux.

Pour des performances optimales dans les frameworks d'entraînement distribués tels que PyTorch Distributed Data Parallel (DDP) ou DeepSpeed, vous devriez viser NVLink au sein des nœuds et un InfiniBand haute vitesse (en utilisant le backend NCCL) entre les nœuds.

Exemple d'implémentation : Configuration de NCCL

Lors de la configuration de votre script d'entraînement, la variable d'environnement NCCL_IB_DISABLE détermine quel backend est utilisé. Pour vous assurer que vous exploitez l'interconnexion haute vitesse, vous devez désactiver NVLink si vous testez la latence réseau pure, ou activer InfiniBand pour les communications inter-nœuds.

# Exemple : Forcer NCCL à utiliser InfiniBand pour la communication inter-nœuds
# Ceci est crucial pour les performances de l'entraînement LLM multi-nœuds
export NCCL_SOCKET_IFNAME=eth0  # Interface de repli
export NCCL_IB_HCA=mlx5        # Spécifier l'adaptateur InfiniBand
export NCCL_DEBUG=INFO         # Vérifier les journaux d'initialisation

# Exécuter votre tâche d'entraînement
python -m torch.distributed.run \
    --nproc_per_node=8 \
    --nnodes=4 \
    --node_rank=$RANK \
    --master_addr=$MASTER_ADDR \
    --master_port=$MASTER_PORT \
    train.py

Surveillez toujours vos journaux NCCL. Si vous voyez des avertissements fréquents concernant « NCCL WARN net/socket failed », cela indique que votre repli sur Ethernet est activé, ce qui dégradera considérablement le débit d'entraînement.

Compromis entre coût et évolutivité

NVLink est coûteux. Il nécessite des commutateurs PCIe spécialisés et une topologie spécifique au sein du châssis du serveur. Ethernet, en particulier avec des commutateurs Ethernet standard 400Gb/800Gb, offre une voie plus rentable pour évoluer vers des centaines ou des milliers de nœuds. Cependant, le « coût » d'Ethernet est souvent payé en temps de développement et en efforts de réglage. L'optimisation des paramètres RDMA, des tailles de tampon et des algorithmes de contrôle de congestion pour Ethernet est nettement plus complexe que la simple connexion à un réseau NVSwitch.

Conclusion

Il n'y a pas de réponse unique adaptée à tous les cas. Pour un ajustement fin à petite échelle (<100 GPU), des clusters uniquement NVLink sont souvent excessifs, et un Ethernet standard suffit. Pour le pré-entraînement de modèles fondamentaux, NVLink est incontournable pour la communication intra-nœud, tandis qu'un Ethernet/InfiniBand haute performance est critique pour la mise à l'échelle inter-nœuds. En comprenant ces rôles distincts, vous pouvez construire une infrastructure LLM qui équilibre efficacement le coût, la complexité et la puissance de calcul brute.