Le réseau est devenu l’un des éléments les plus critiques de l’infrastructure en intelligence artificielle. Pendant des années, de nombreuses équipes ont considéré Ethernet comme une couche généraliste : stable, connue, relativement économique et suffisamment flexible pour presque toutes les charges de travail en entreprise. Dans un cluster IA moderne, cette vision ne suffit plus. Lorsqu’aucune 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 processeur et du système d’exploitation. Son aspect attractif est évident : faible latence, bande passante élevée et meilleure efficacité dans les communications GPU-vers-GPU. Mais sa complexité l’est aussi : 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, des buffers ajustés, et une télémetrie suffisante pour détecter les problèmes avant qu’ils n’altèrent l’entraînement.

Quelle problématique résout RoCE 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 en raison de congestion, pertes ou latence variable, la performance globale en pâtit. Une GPU coûteuse en attente de données représente une capacité inutilisée.

RDMA réduit les copies mémoire et évite une partie du parcours traditionnel via le kernel et le CPU. Au lieu de traiter chaque transfert comme du trafic classique, il autorise les NICs à participer de façon beaucoup plus directe au mouvement des données entre mémoires. RoCEv2 étend cette logique aux réseaux IP/Ethernet, permettant d’apporter des fonctionnalités RDMA sur des réseaux Ethernet.

Google Cloud utilise RoCEv2 dans ses instances A3 Ultra et A4 pour la communication entre nœuds et le trafic GPU-GPU, avec jusqu’à 3,2 Tbps de trafic inter-nœuds GPU-GPU sur A3 Ultra. Meta a également documenté des déploiements RoCE pour un entraînement distribué à grande échelle, avec des clusters de 24 576 GPUs H100 utilisés 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 connectivité RoCE, gestion de congestion, télémetrie et isolation des performances.

Composants techniques : PFC, ECN, DCQCN et QoS

RoCE ne transforme pas Ethernet en une infrastructure sans perte à lui seul. Le réseau doit être configuré pour protéger les classes de trafic RDMA et éviter les pertes en cas de congestion. Plusieurs mécanismes doivent être compris comme un système intégré, non comme des options indépendantes du switch.

PFC, Priority Flow Control, suspend une priorité donnée lorsque la file associée atteint un seuil. Son avantage : éviter les pertes dans la classe RDMA. Son risque : mal configuré, il peut propager la congestion, provoquer du head-of-line blocking, et impacter du trafic qui ne devrait pas être bloqué. Il est donc recommandé de l’appliquer uniquement aux files nécessaires, pas à toute la réseau.

ECN, Explicit Congestion Notification, signale la congestion avant la perte de paquets. Le récepteur ou l’endpoint interprètent cette signal et l’émetteur réduit la vitesse d’envoi. Sur RoCEv2, ECN fonctionne souvent avec des algorithmes de contrôle de congestion comme 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 risque d’engorger des files d’attente.

La séparation des files d’attente (queues) est également cruciale. Le trafic RDMA doit disposer de ses propres classes, files et politiques. Les paquets de notification de congestion, tels que CNP, 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

En IA, une simple topologie leaf-spine générique ne suffit pas. Il faut concevoir en fonction du patron de communication : entraînement distribué, inférence parallèle, stockage, checkpoints, contrôle du trafic n’ont pas tous la même configuration. Le réseau doit éviter la surcharge (oversubscription) pour le trafic critique et assurer 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, par exemple, évoque un réseau 4-way rail-aligned dans A3 Ultra pour assurer 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 essentielle : un fabric RoCE pour GPU ne devrait pas partager sans contrôle le même plan que le trafic de gestion, sauvegardes, stockage, services d’entreprise ou surveillance bruyante. Selon la taille, il peut être pertinent de séparer physiquement le réseau IA, ou simplement d’utiliser une séparation logique, des files d’attente dédiées et des politiques strictes. La décision dépend de l’échelle, du budget, du risque et du niveau d’utilisation prévu.

Checklist pratique avant la mise en production du RoCE

L’erreur la plus courante consiste à considérer RoCE comme une fonction à activer. En réalité, il s’agit d’une architecture à valider en amont. Avant la production, il est conseillé de construire un laboratoire avec le même type de 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 doit inclure des 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 d’autres tests synthétiques ne suffit pas : il faut mesurer avec l’application ou un pattern de trafic qui s’y rapproche.

Il est également crucial de formaliser la gouvernance opérationnelle : 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 est due au réseau ? Comment croiser les métriques GPU, NCCL et switches ? Sans ce cadre, chaque incident entraînera une guerre de coordination entre é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 la processus d’entraînement. La capacité d’utiliser les liens ne suffit pas : il faut également regarder les queues, les pauses, les marques ECN et le comportement des endpoints.

Les métriques essentielles incluent : é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 (si présentes), utilisation par rail, distribution ECMP, erreurs matérielles, CRC, changements d’état, température des fibres et performance NCCL. Côté GPU, il est recommandé de croiser l’utilisation des accélérateurs, le temps d’attente lors des communications collectives et la 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 considéré comme un élément du rendement global du cluster, non comme un simple composant isolé. L’objectif : que l’équipe IA comprenne quand une perte d’efficacité provient 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 erreur consiste à activer PFC sur trop de priorités. Cela peut transformer une protection locale en un problème global. La seconde : recopier des valeurs ECN sans ajustement ad hoc 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 de la même façon.

La sous-estimation de l’importance 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, il ne faut pas négliger la conception pour la reprise après incident. Une fabric qui ne fonctionne qu’en état idéal est inutilisable. Il faut tester la résilience face aux défaillances : coupure de lien, saturation de file, redémarrage d’un leaf ou 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 n’est pas une mode, c’est une compétence nouvelle

L’expansion de RoCE dans l’IA traduit une tendance profonde : les hyperscales et grands clouds souhaitent déployer des réseaux hautes performances sur Ethernet, car cela leur donne une échelle, une diversité de fournisseurs et une base opérationnelle élargie. InfiniBand continuera à jouer un rôle important en HPC et IA, mais Ethernet pénètre désormais dans des territoires auparavant réservés à des fabrics spécialisés.

Pour un équipe technique, cela implique une montée en compétences : il ne suffit plus de connaître la configuration des 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.

La bonne nouvelle : Ethernet reste sa plus grande force, étant une technologie ouverte, connue et largement supportée. La mauvaise : avec RoCE, elle ne pardonne plus les configurations approximatives. Un réseau Ethernet classique peut fonctionner raisonnablement même avec des réglages approximatifs, mais une fabric RoCE pour IA requiert une précision optimale.

En résumé, avant d’investir dans davantage de GPUs, il faut concevoir la réseau 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. RoCE contribue à cette transition, mais nécessite une ingénierie sérieuse, pas une simple activation dans le switch.

Questions fréquentes

RoCE remplace-t-il TCP dans tout le datacenter ?
Non. RoCE est utilisé pour le trafic RDMA à faible latence et haut débit, notamment entre nœuds GPU ou en HPC. Les autres applications peuvent continuer à utiliser TCP/IP classique.

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

Différence entre RoCE et InfiniBand ?
RoCE permet de faire 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 options sont pertinentes 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, performance réelle en entraînement distribué.

source : RoCE AI