Le réseau est devenu l’un des éléments les plus critiques de l’infrastructure IA. Pendant des années, beaucoup d’équipes ont traité Ethernet comme une couche généraliste : stable, connue, relativement économique et suffisamment flexible pour presque toutes les charges en entreprise. Dans un cluster IA moderne, cette vision n’est plus suffisante. Quand un millier de GPUs entraînent un modèle distribué, le réseau cesse d’être un simple transport pour devenir partie intégrante du système de calcul.

RoCE (RDMA over Converged Ethernet) permet d’utiliser le RDMA via Ethernet pour transférer des données entre serveurs avec moins d’intervention du CPU et du système d’exploitation : faible latence, bande passante élevée, meilleures communications GPU-vers-GPU. Mais sa complexité est à la hauteur de ses avantages : pour fonctionner efficacement en IA, la fabric Ethernet doit se comporter presque sans perte, avec une gestion de congestion maîtrisée, des files d’attente bien dimensionnées et une télémetrie fine pour détecter les problèmes avant qu’ils n’affectent l’entraînement.

Ce que RoCE résout dans les charges IA

Dans l’entraînement distribué, les GPUs ne fonctionnent pas isolément. Ils échangent des gradients, synchronisent des états, exécutent des opérations collectives comme AllReduce, et dépendent d’un avancement quasi synchronisé de tous les nœuds. Si une partie du cluster subit un retard à cause de congestion ou de pertes, la performance globale en pâtit. Un GPU qui attend des données, c’est une capacité inutilisée. RDMA réduit les copies mémoire et évite une partie du parcours via le kernel et le CPU, permettant aux NICs de participer directement au mouvement des données entre mémoires. RoCEv2 étend cette logique aux réseaux IP/Ethernet.

Google Cloud utilise RoCEv2 dans ses instances A3 Ultra et A4, avec jusqu’à 3,2 Tbps de trafic inter-nœuds GPU-GPU sur A3 Ultra (architecture 4-way rail-aligned). Meta a documenté des déploiements RoCE pour l’entraînement distribué à grande échelle, avec des clusters de 24 576 GPUs H100 pour Llama 3 (certains en RoCE, d’autres en InfiniBand). NVIDIA a développé Spectrum-X, une plateforme Ethernet optimisée pour l’IA avec gestion de congestion, télémetrie et isolation des performances. Ces déploiements illustrent l’évolution des infrastructures IA qui, selon les estimations, représentent une part croissante des 875 milliards d’euros dépensés dans le cloud en 2026.

PFC, ECN, DCQCN et QoS : les composants techniques

RoCE ne transforme pas Ethernet en infrastructure sans perte à lui seul. Plusieurs mécanismes doivent fonctionner ensemble, configurés comme un système intégré.

PFC (Priority Flow Control) suspend une priorité donnée quand la file associée atteint un seuil, évitant les pertes dans la classe RDMA. Mal configuré, il peut propager la congestion, provoquer du head-of-line blocking et impacter du trafic qui ne devrait pas être bloqué. Règle : l’appliquer uniquement aux files nécessaires, pas à tout le réseau.

ECN (Explicit Congestion Notification) signale la congestion avant la perte de paquets. Le récepteur interprète le signal et l’émetteur réduit sa vitesse d’envoi. Sur RoCEv2, ECN fonctionne souvent avec DCQCN (Data Center Quantized Congestion Notification), qui ajuste le rythme d’envoi selon les indications de congestion. La clé : marquer suffisamment tôt, sans exagérer, sinon on gaspille de la capacité ou on engorge les files.

La séparation des files est aussi cruciale. Le trafic RDMA doit avoir ses propres classes, files et politiques. Les paquets CNP (Congestion Notification Packets) doivent arriver rapidement : si la signalisation est retardée, l’émetteur continue d’injecter du trafic alors que la fabric est saturée. Cisco recommande de différencier le trafic RoCEv2, d’appliquer ECN et PFC dans la file appropriée, et de traiter les contrôles de congestion en priorité.

Conception de la fabric : topologie, rails et isolation

Une topologie leaf-spine générique ne suffit pas pour l’IA. La conception doit suivre le patron de communication : entraînement distribué, inférence parallèle, stockage, checkpoints et trafic de contrôle n’ont pas tous les mêmes exigences. Le réseau doit éviter la surcharge (oversubscription) pour le trafic critique et garantir des chemins cohérents entre nœuds GPU.

Les déploiements avancés utilisent des architectures rail-aligned ou multi-rail, où les NICs de chaque serveur GPU sont connectés à des fabrics parallèles ou des domaines réseau conçus pour équilibrer le trafic de façon prévisible. Google évoque un réseau 4-way rail-aligned dans A3 Ultra pour un trafic GPU-GPU non bloquant. En environnements privés, cela exige de respecter la symétrie du câblage, la distribution des NICs, le hashing ECMP, le nombre de sauts et la localisation physique des nœuds.

L’isolation est également indispensable : une fabric RoCE GPU ne devrait pas partager sans contrôle le même plan que le trafic de gestion, sauvegardes, stockage ou surveillance. Une solution de stockage comme le Synology PAS7700, conçu pour les environnements critiques all-NVMe, illustre bien cette nécessité de séparer les chemins selon la criticité du trafic. La décision entre séparation physique et logique dépend de l’échelle, du budget et du niveau d’utilisation prévu.

Checklist avant mise en production

L’erreur la plus courante : considérer RoCE comme une fonction à activer. C’est une architecture à valider en amont. Avant la production, construire un laboratoire avec le même NIC, firmware, système d’exploitation, driver, switch, version du NOS, fibre optique et modèle de trafic que dans le cluster final. La différence entre « ça marche en test simple » et « supporte l’entraînement pendant plusieurs semaines » est considérable.

Une validation efficace inclut : tests de débit soutenu, incast, microbursts, trafic mixte, pertes de lien, redémarrage de switch, congestion locale, changements de routage, mise à jour du firmware et charges NCCL réelles. Tester uniquement avec ib_write_bw ou des tests synthétiques ne suffit pas. Il faut mesurer avec l’application ou un pattern de trafic qui s’en approche.

La gouvernance opérationnelle est tout aussi critique : qui peut ajuster les seuils ECN ? Quelle version de firmware est certifiée ? Comment sont surveillés les événements PFC ? Quelles alertes en cas de pertes prioritaires ? Comment déterminer si une dégradation de l’entraînement vient du réseau ? Sans ce cadre, chaque incident entraînera une guerre de coordination entre les équipes réseau, systèmes, plateforme et IA.

Métriques à surveiller

Une fabric RoCE peut sembler saine selon les métriques traditionnelles tout en dégradant l’entraînement. L’utilisation des liens ne suffit pas : il faut aussi surveiller les queues, les pauses, les marques ECN et le comportement des endpoints.

Les métriques essentielles : événements PFC par port et priorité, durée des pauses, paquets ECN marqués, CNP envoyés et reçus, pertes par file, occupation des buffers, latence en file d’attente, retransmissions, utilisation par rail, distribution ECMP, erreurs matérielles, CRC, changements d’état, température des fibres et performance NCCL. Côté GPU, croiser utilisation des accélérateurs, temps d’attente lors des communications collectives et durée des étapes d’entraînement.

NVIDIA pousse cette démarche avec Spectrum-X et sa télémetrie pour les usines IA, où le réseau est traité comme un élément du rendement global du cluster, pas comme un composant isolé. L’objectif : que l’équipe IA comprenne quand une perte d’efficacité vient du réseau, et que l’équipe réseau identifie quand une file d’attente ralentit une charge spécifique.

Erreurs fréquentes lors du déploiement RoCE

La première : activer PFC sur trop de priorités. Une protection locale peut devenir un problème global. La deuxième : recopier des valeurs ECN sans les ajuster selon le switch, la taille des buffers et le pattern de trafic. La troisième : mélanger trafic RDMA et trafic général sans séparation claire. La quatrième : tester uniquement avec des outils synthétiques en supposant que l’entraînement réel se comportera pareil.

La sous-estimation du firmware est aussi fréquente. NICs, drivers, switches et systèmes d’exploitation doivent faire partie d’une même pile opérationnelle. Une version incorrecte peut introduire des latences, pertes ou comportements de congestion difficiles à diagnostiquer. Dans de grands clusters, l’homogénéité opérationnelle est aussi cruciale que la configuration.

Enfin, ne pas concevoir pour la reprise après incident est une erreur sérieuse. Une fabric qui ne fonctionne qu’en état idéal ne tient pas en production. Il faut tester la résilience : coupure de lien, saturation de file, redémarrage d’un leaf, changement de routage ECMP. En IA, une défaillance partielle peut réduire la performance au point de rendre le coût de l’entraînement prohibitif.

RoCE, une compétence de fond pas une option à cocher

L’expansion de RoCE dans l’IA traduit une tendance structurelle : les hyperscales et grands clouds veulent déployer des réseaux haute performance sur Ethernet, parce que ça leur donne une échelle, une diversité de fournisseurs et une base opérationnelle plus large. InfiniBand continuera à jouer un rôle en HPC et IA, mais Ethernet pénètre des territoires autrefois réservés aux fabrics spécialisées.

Pour une équipe technique, cela implique une montée en compétences. Il ne suffit plus de matriser les VLAN, BGP EVPN, MLAG ou QoS général. En réseau IA, il faut comprendre le RDMA, les patterns de communication en entraînement, NCCL, congestion, PFC, ECN, DCQCN, télémetrie et validation avec de véritables charges. C’est une discipline qui croise réseaux, systèmes et plateforme IA.

Ethernet reste sa plus grande force : technologie ouverte, connue et largement supportée. Mais avec RoCE, elle ne pardonne plus les configurations approximatives. Un réseau Ethernet classique peut fonctionner raisonnablement avec des réglages approximatifs. Une fabric RoCE pour IA requiert une précision bien plus grande. Avant d’investir dans davantage de GPUs, il faut concevoir la fabric pour les accompagner. L’IA ne scale pas uniquement avec des accélérateurs, mais avec une fabric capable de déplacer la mémoire, d’éviter les pertes et de réguler la congestion lors de longues périodes d’entraînement continu.

Questions fréquentes

RoCE remplace-t-il TCP dans tout le datacenter ?
Non. RoCE s’utilise pour le trafic RDMA à faible latence entre nœuds GPU ou en HPC. Les autres applications continuent à utiliser TCP/IP classique.

Faut-il obligatoirement activer PFC avec RoCE ?
En pratique, la plupart des architectures RoCEv2 en IA utilisent PFC sur la file RDMA pour éviter les pertes, souvent combiné avec ECN et des contrôles de congestion. La clé : l’appliquer avec précision, pas globalement.

Quelle différence entre RoCE et InfiniBand ?
RoCE permet du RDMA sur Ethernet/IP, exploitant l’écosystème Ethernet. InfiniBand est une fabric spécialisée avec RDMA natif et un stack très intégré. Les deux sont pertinents selon l’échelle, le coût, le matériel et les objectifs.

Que tester avant la mise en production ?
Débit, latence, microbursts, incast, événements PFC, marques ECN, distribution ECMP, défaillances de lien, comportement NCCL et performance réelle en entraînement distribué.

Quelles métriques surveiller en production ?
PFC par port et priorité, durée des pauses, paquets ECN marqués, CNP envoyés/reçus, pertes par file, occupation des buffers, latence en file d’attente, utilisation par rail, distribution ECMP et performance NCCL. Croiser avec les métriques GPU.