Réseau et stockage pour clusters GPU
Comprendre les exigences réseau et stockage spécifiques aux clusters d'entraînement IA à grande échelle.
À retenir
- L'efficacité de scaling est l'indicateur clé de santé réseau d'un cluster d'entraînement.
- InfiniBand et RoCEv2 sont les standards pour les interconnexions inter-nœuds à faible latence.
- Le stockage doit être dimensionné en débit agrégé, pas seulement en capacité.
- Un SLO sur l'efficacité de scaling avec budget d'erreur permet de déclencher une revue avant dérive coûteuse.
Le réseau, goulot d'étranglement invisible
Dans un cluster d'entraînement distribué, les GPU échangent en permanence des gradients via des opérations collectives (all-reduce, all-gather). Si le réseau inter-nœuds est trop lent, les GPU passent leur temps à attendre au lieu de calculer, et le coût du cluster (souvent le poste le plus onéreux de l'infrastructure) est gaspillé.
Topologies dédiées
- InfiniBand : très faible latence, bande passante élevée (200-400 Gb/s par lien), RDMA natif ; standard de facto pour l'entraînement à grande échelle.
- RoCEv2 (RDMA over Converged Ethernet) : alternative Ethernet avec RDMA, nécessite un réseau sans perte (PFC, ECN) correctement réglé.
- NVLink / NVSwitch : interconnexion intra-serveur entre GPU, bande passante bien supérieure au réseau externe, à ne pas confondre avec le réseau inter-serveurs.
Point clé
la performance d'un cluster d'entraînement se mesure autant en efficacité de scaling (temps réel / temps théorique idéal à N GPU) qu'en puissance de calcul brute ; un mauvais réseau peut faire chuter cette efficacité sous 60 %.
Stockage : débit et parallélisme
L'entraînement lit en continu de gros volumes de données (datasets d'images, tokens texte) et écrit des checkpoints réguliers, parfois plusieurs centaines de Go, qu'il faut écrire et relire rapidement en cas de reprise après panne. Un stockage parallèle (Lustre, GPFS, ou solutions objet à haut débit) est nécessaire pour éviter que l'I/O ne devienne le facteur limitant.
| Cas d'usage | Type de stockage recommandé | Exigence clé |
|---|---|---|
| Dataset d'entraînement | Stockage parallèle haute bande passante | Débit agrégé élevé, accès concurrent |
| Checkpoints | Stockage rapide, redondant | Écriture/lecture séquentielle rapide |
| Modèles servis en inférence | Stockage objet ou cache local | Faible latence de premier accès |
Attention
dimensionner le stockage uniquement sur la capacité (To) et non sur le débit agrégé (Go/s) est une erreur fréquente : un cluster de 500 GPU peut saturer un stockage pourtant largement suffisant en capacité si son débit est insuffisant.
Observabilité réseau et calcul de SLO
Pour un cluster d'entraînement, un SLO pertinent porte sur l'efficacité de scaling au-dessus d'un seuil, mesurée sur une fenêtre glissante. Exemple : objectif de 95 % du temps de run passé en calcul effectif (et non en attente réseau) sur 30 jours.
- SLI :
temps_calcul_effectif / temps_total_run - SLO : ≥ 90 % sur 30 jours glissants
- Budget d'erreur : 10 % du temps de run, soit sur un run de 720 heures, 72 heures de dégradation/attente tolérées avant déclenchement d'une revue d'architecture réseau.
Si le run cumule déjà 60 heures d'attente réseau sur les 720 heures prévues, il reste 12 heures de budget d'erreur : la marge devient trop faible pour tolérer une nouvelle dégradation sans revoir la configuration.
Sur le terrain
sur un incident réel, un déséquilibre de câblage InfiniBand (un switch de spine sous-alimenté en liens) avait fait chuter l'efficacité de scaling de 92 % à 68 % sans qu'aucune alerte GPU classique ne se déclenche — seule la métrique d'efficacité de scaling avait révélé le problème.
Astuce
tracez systématiquement l'efficacité de scaling comme métrique de premier niveau sur un dashboard de cluster IA ; c'est l'indicateur le plus fiable pour détecter un problème réseau avant qu'il ne coûte des jours de calcul.