Complexité du routage dans les réseaux d'IA : ECMP, routage adaptatif, DCQCN et pourquoi les spécialistes du calcul haute performance s'y intéressent tant.

Les articles précédents traitaient des câbles, des cartes réseau, des commutateurs et des topologies. Celui-ci s'intéresse à ce qui se passe en amont : comment les paquets empruntent un chemin à travers une infrastructure multi-commutateurs et comment cette infrastructure évite l'effondrement du réseau lorsque dix mille GPU décident de réaliser une réduction simultanée.

Le trafic lié à l'IA est fondamentalement différent de celui d'un centre de données classique. Une interface web envoie des millions de petites connexions TCP. En revanche, une session d'entraînement d'IA envoie quelques flux énormes et parfaitement synchronisés à des pairs connus, et chacun attend le plus lent. Les techniques efficaces dans le premier cas s'avèrent inadaptées au second.

Avertissement : la plupart des clients Kentino utilisent des clusters de 1 à 4 nœuds. À cette échelle, ces problèmes sont négligeables. Connectez quatre nœuds à un seul commutateur 100 GbE (ou sans commutateur, voir N05 ), utilisez RoCE standard avec les paramètres par défaut et oubliez ECMP et DCQCN. Nous écrivons tout de même ces lignes car : a) elles fournissent des informations utiles pour le dimensionnement ; b) dès que vous passez de quatre à seize nœuds, tout cela devient crucial.

Qu’est-ce que l’ECMP et pourquoi était-il suffisant jusqu’à l’avènement de l’IA ? Qu’est-ce que l’ECMP et pourquoi était-il suffisant jusqu’à l’arrivée de l’IA ?

ECMP (Equal-Cost Multi-Path) est une technique de routage qui permet le fonctionnement des architectures leaf-spine et fat-tree. Lorsqu'il existe plusieurs chemins de coût égal entre la feuille A et la feuille B (via les spines S1 à S4), le commutateur calcule le hachage des champs des paquets et utilise ce hachage pour sélectionner une spine. Le hachage classique à 5 tuples est : (src IP, dst IP, src port, dst port, protocol).

Pour les charges de travail cloud traditionnelles (des millions de connexions TCP éphémères), ECMP est parfaitement adapté. La loi des grands nombres assure l'équilibrage de charge. Avec 10 000 flux et 8 nœuds de répartition, on obtient un équilibre quasi parfait.

ECMP a été conçu pour de nombreux petits flux. L'entraînement de l'IA envoie quelques flux synchronisés de grande ampleur, ce qui rompt l'équilibre statistique.

Le problème du flux d'éléphants

L'entraînement des IA est l'inverse du trafic web. Une étape d'entraînement : chaque GPU calcule un gradient, puis l'envoie à tous les autres (allreduce), chacun attendant le transfert le plus lent, et ainsi de suite.

Allreduce consiste en un petit nombre de flux très volumineux. Un cluster Ring-allreduce sur 8 nœuds équipés de cartes réseau 200 Gbit/s représente 8 flux simultanés, chacun de plusieurs gigaoctets, tous à débit maximal et démarrant simultanément. L'article de Meta sur RoCE à grande échelle l'a clairement démontré : dans les clusters d'IA, un nombre infime de flux « éléphants » absorbent la quasi-totalité des octets et sollicitent tous le réseau simultanément.

Le hachage à 5 tuples d'ECMP déteste cela. Avec N flux d'éléphants sur S chemins, la probabilité de collision nulle est S! / ((S-N)! · S^N)Pour 8 flux sur 8 épines : environ 2.4%Même avec 32 épines pour 8 flux, on n'atteint qu'environ 33 %. Ajouter des épines ne change rien au résultat : cela crée davantage de liens vides pendant que deux flux se disputent un seul.

Une collision surcharge le lien principal (ratio 2:1), les flux affectés s'exécutent à vitesse réduite de moitié, et comme l'étape attend le flux le plus lent, l'itération s'exécute également à vitesse réduite de moitié. Les mesures effectuées sur le cluster de production indiquent que les collisions ECMP peuvent entraîner une perte de performance allant jusqu'à 40 % sur allreduce.

Solutions de contournement : hachage amélioré, équilibrage de charge au niveau des paquets, routage adaptatif

Quatre réponses concrètes, classées par ordre croissant de perturbation à déployer :

1. Amélioration du hachage (E-ECMP, compatible avec les QP). Solution la plus économique. Le hachage standard à 5 tuples regroupe le trafic RDMA en un seul tuple par paire QP ; un flux allreduce unique correspond donc à un compartiment ECMP. Il est également possible de hacher le trafic en fonction du numéro de QP de destination RoCE et de répartir le trafic sur plusieurs QP (mise à l'échelle QP) pour l'application. D'après les chiffres de Meta : performances allreduce jusqu'à 40 % supérieures. Ces résultats restent statistiques : les collisions sont plus rares, mais pas éliminées.

2. Commutation de flux. Détection d'une période d'inactivité, puis nouveau hachage. Fonctionne avec TCP, mais mal avec RoCE enchaîné.

3. Équilibrage de charge au niveau des paquets / distribution de paquets. Hachage par paquet, acceptation du réordonnancement, réassemblage par la carte réseau. Élimine le problème de flux éléphant, mais nécessite la coopération de la carte réseau et du commutateur. C'est le principe de fonctionnement de NVIDIA Spectrum-X : distribution de paquets par paquet avec réordonnancement matériel au niveau de la SuperNIC.

4. Routage adaptatif. Le commutateur analyse la congestion de chaque port et sélectionne le chemin le moins chargé et de coût égal lors de la commutation, au lieu d'effectuer un hachage aléatoire. Associée à la pulvérisation de paquets, cette technologie est utilisée par InfiniBand depuis quinze ans. Son intégration à Ethernet est la principale nouveauté des solutions NVIDIA Spectrum-X (ASIC Spectrum-4/5 + SuperNIC BlueField ou ConnectX-8), Cisco Silicon One G200/P200 et Broadcom Tomahawk 5 / Jericho 3-AI avec architecture cellulaire planifiée.

Pour les clusters de 1 à 8 nœuds, le routage adaptatif est superflu. Pour les tâches nécessitant plus de 64 GPU et pouvant atteindre 1 000 GPU, il fait toute la différence entre un goulot d'étranglement lié au réseau et un goulot d'étranglement lié aux GPU. C'est pourquoi, entre 2024 et 2026, tous les principaux fournisseurs de solutions Ethernet pour l'IA ont développé ou acquis sous licence des puces de routage adaptatif.

Contrôle de la congestion : pourquoi « ne pas perdre de paquets » n’est pas gratuit

L'autre aspect de la complexité du routage réside dans ce qui se produit lorsqu'un trop grand volume de trafic arrive simultanément sur un port de commutateur. Deux cas de figure se présentent : un réseau avec pertes abandonne les paquets et les terminaux ralentissent leur activité (Internet ouvert) ; un réseau sans pertes sollicite le commutateur en amont pour qu'il suspende le trafic – aucune perte de paquets, mais la congestion se propage en amont.

Historiquement, RoCE exigeait une infrastructure sans perte. Les cartes réseau RDMA gèrent mal les pertes de paquets : la perte d'un seul paquet déclenche la retransmission de l'intégralité du message (go-back-N), ce qui, sur un réseau 100 GbE, implique le renvoi de plusieurs mégaoctets. RoCEv2 avec le mécanisme go-back-N est donc pratiquement inutilisable sur un réseau sujet aux pertes et en cas de forte utilisation.

Le PFC (Priority Flow Control , norme IEEE 802.1Qbb) garantit un fonctionnement sans perte sur Ethernet. Lorsqu'un commutateur dépasse un seuil dans sa file d'attente de sortie par priorité, il envoie une trame PAUSE en amont, demandant à l'émetteur d'interrompre la transmission de cette priorité. Huit priorités correspondent à huit signaux d'arrêt/de démarrage indépendants.

Blocage en tête de file et flux de victimes

Les pauses PFC sont imprécises. Une pause signifie « arrêtez l'envoi de la priorité 3 sur cette liaison » ; le système ne sait pas quel flux est à l'origine de la congestion. Si dix flux partagent la priorité 3 et que l'un d'eux est congestionné en aval, le PFC suspend les dix . Les neuf autres flux, dits « victimes », sont pénalisés pour le problème d'un autre. C'est le blocage en tête de file, principal inconvénient de l'Ethernet sans perte à grande échelle.

Blocage en tête de file : A→X provoque un blocage du flux principal. La communication entre B et C et Y (normalement) est également interrompue ; le flux victime est bloqué.

Blocage PFC : si la topologie et le trafic créent une dépendance cyclique de liens en pause (A attend B, B attend C, C attend A), l’ensemble du réseau se bloque. Ce problème a été observé en production. Les commutateurs modernes intègrent une détection des blocages ; les topologies Clos modernes sont conçues pour éviter les blocages ; toutefois, tout déploiement RoCE sérieux prévoit un plan de reprise d’activité.

L'objectif du contrôle de congestion moderne de l'IA est de maintenir les tampons suffisamment petits pour que le PFC ne se déclenche jamais en régime permanent. Le PFC reste armé comme filet de sécurité pour les véritables micro-rafales. Le mécanisme qui l'empêche de se déclencher est le DCQCN.

DCQCN — le contrôle de congestion standard pour RoCEv2

DCQCN (DataCenter Quantized Congestion Notification) est l'algorithme sur lequel converge le protocole RoCE sans perte. Développé par Microsoft et Mellanox (SIGCOMM 2015), il sera utilisé par défaut par les cartes réseau NVIDIA ConnectX/BlueField à partir de 2025-2026 et considéré par Azure comme la norme de production pour environ 85 % du trafic RDMA dans toutes les régions publiques.

Le DCQCN remplit trois rôles : le CP (point de congestion) est le commutateur qui marque les paquets avec ECN lorsque la profondeur de la file d'attente de sortie dépasse un seuil (probabiliste de 0 % à Kmin à Pmax à Kmax) ; le NP (point de notification) est la carte réseau du récepteur qui génère un CNP (paquet de notification de congestion) renvoyé à l'expéditeur sur les marques ECN (limité en débit, généralement un toutes les 50 µs par flux) ; le RP (point de réaction) est la carte réseau de l'expéditeur qui diminue de manière multiplicative le débit du QP sur CNP, et l'augmente de manière additive (puis hyper-additive) en leur absence.

Configuration typique d'un commutateur pour DCQCN sur 100 GbE :

# NVIDIA Cumulus-style ECN profile on the lossless RoCE priority (priority 3)
interface swp1..swp32
  qos remark dscp-to-tc 26 to 3       # DSCP 26 → TC 3
  qos congestion-mark ecn priority 3
  qos ecn-kmin       5KB              # start marking
  qos ecn-kmax     200KB              # mark at Pmax
  qos ecn-pmax       1%
  qos pfc priority 3
  qos pfc xoff     400KB              # PFC pause (well above Kmax)
  qos pfc xon      300KB

Kmin/Kmax/Pmax est le triplet le plus optimisé dans RoCE. Kmin est faible (quelques paquets) afin que l'ECN s'active avant l'épuisement du tampon ; Kmax est beaucoup plus élevé, ce qui permet une augmentation progressive du marquage ; le seuil de pause du PFC est bien supérieur à Kmax, de sorte que le PFC ne se déclenche que si le DCQCN est trop lent. Configuration initiale de Microsoft : Kmin = 5 Ko, Kmax = 200 Ko, Pmax = 1 %.

Faiblesses connues de DCQCN : effondrement des incasts (100 expéditeurs contactent un seul destinataire, la file d'attente se remplit plus vite que les CNP ne se propagent, le PFC se déclenche – DCQCN+ corrige ce problème) ; iniquité liée à la longue traîne (les flux démarrés tardivement sont limités plus longtemps) ; sensibilité aux paramètres (Kmin optimisé pour 4 nœuds ne s'applique pas à 64 nœuds). En résumé : DCQCN est le protocole par défaut car il fonctionne la plupart du temps. HPCC, Swift, EQDS et TIMELY (remis à l'heure actuelle) sont des alternatives proposées, mais aucune ne l'a supplanté en 2026.

ECN, DCTCP et les cas où TCP pur trouve sa place.

Séparation nette car ces éléments sont souvent confondus :

• ECN — Mécanisme de couche IP (RFC 3168) où les commutateurs marquent au lieu de supprimer. A signal, rien ne réagit de soi-même.
• DCQCN — le point de terminaison RDMA réaction. Lit l'ECN via les CNP, ajuste le débit.
• DCTCP — le point de terminaison TCP réactionLecture des ECN dans les ACK, redimensionnement de la fenêtre en fonction de la proportion de paquets marqués. Microsoft + Stanford, SIGCOMM 2010, disponible pour Windows Server et Linux.

Si vous utilisez une infrastructure RoCE pure, vous utilisez DCQCN — familiarisez-vous avec vos paramètres par défaut. Si vous avez également du stockage/contrôle TCP sur le même câble, il est judicieux d'activer DCTCP (net.ipv4.tcp_ecn = 1 plus les commutateurs compatibles ECN).

Pourquoi le trafic généré par l'IA met tout cela à rude épreuve davantage que les centres de données traditionnels

Trois propriétés pour lesquelles les systèmes de contrôle de la congestion classiques n'ont pas été conçus :

1. Rafales synchronisées. Tous les GPU démarrent simultanément (à la même nanoseconde). Utilisation de 0 à 100 % en quelques microsecondes. Aucun temps de préchauffage pour un démarrage lent afin d'atteindre la fréquence optimale. Le DCQCN démarre directement à sa fréquence nominale pour cette raison précise.
2. Peu de flux, mais importants. La loi des grands nombres ne vous sauvera pas. 8 flux → collisions ECMP fréquentes ; 8 récepteurs → blocage HoL PFC sévère.
3. Le chemin critique est le maillon le plus lent. Temps d'étape réduit = temps d'exécution maximal. Pas de « cas moyen ». Une probabilité de 1 % d'une collision grave s'accumule au fil des mois d'entraînement.

C’est pourquoi les spécialistes du calcul haute performance et de l’intelligence artificielle accordent une importance démesurée au réseau, contrairement aux opérateurs web traditionnels. Le web est élastique : les requêtes lentes prennent un peu plus de temps pour certains utilisateurs. L’entraînement des IA, lui, ne l’est pas : l’ensemble du processus s’exécute à la vitesse de son composant synchronisé le plus lent.

La complexité sans interrupteur (aperçu de N05)

N05 décrit les topologies sans commutateur (connexion directe, maillée, en anneau, en tore 2D/3D, tesseract) pour les petits clusters où l'acquisition d'un commutateur 100 GbE est superflue. En l'absence de commutateur, chaque nœud devient un routeur : plusieurs cartes réseau, plusieurs chemins, et un élément doit sélectionner le prochain saut.

La solution standard en 2026 est l'utilisation de FRR (FRRouting) sur chaque nœud, configuré pour BGP non numéroté . BGP non numéroté utilise des adresses IPv6 locales pour l'établissement des connexions, ce qui évite d'attribuer des adresses IPv4 sur chaque lien. Chaque nœud annonce son interface de bouclage, apprend celles de ses pairs, et la table de routage Linux sélectionne le prochain saut approprié.

# Minimal FRR config for a node in a switchless mesh:
router bgp 65001
  bgp router-id 10.0.0.1
  neighbor enp1s0 interface remote-as external
  neighbor enp2s0 interface remote-as external
  neighbor enp3s0 interface remote-as external
  address-family ipv4 unicast
    network 10.0.0.1/32         # this node's loopback
    redistribute connected
  exit-address-family

Douze lignes par nœud, ECMP réparties sur autant de paires de cartes réseau que le nœud possède — avec les mêmes limitations que pour l'ECMP d'un commutateur. Dans un réseau maillé à 4 nœuds, les collisions ECMP apparaissent également côté hôte. Il est possible de les atténuer en augmentant le nombre de QP ou d'accepter la perte (faible pour 4 nœuds). L'absence de commutateur ne signifie pas l'absence de complexité de routage ; celle-ci est simplement déplacée vers les hôtes.

Quand cela compte pour vous

La plupart des lecteurs n'auront pas besoin de faire tout cela.

• 1 à 4 nœuds, un seul commutateur, RoCE pour le stockage et l'entraînement occasionnel multi-GPU : Laissez les paramètres par défaut. Les seuils DCQCN et ECN par défaut sont corrects. Le PFC est activé ; vous ne constaterez probablement jamais de pause. Les collisions ECMP sont réelles, mais leur impact sur une exécution à 4 nœuds est inférieur à 10 %.
• 4 à 16 nœuds, cluster d'entraînement dédié : Activez explicitement DCQCN, définissez Kmin/Kmax/Pmax à 5 Ko / 200 Ko / 1 % (valeur de référence Azure), activez la mise à l'échelle QP dans NCCL, surveillez les compteurs de pauses PFC et les taux CNP. Si les pauses PFC augmentent, DCQCN n'est pas suffisamment agressif ; diminuez Kmin.
• Plus de 16 nœuds ou plus de 1 000 GPU : Le routage adaptatif est rapidement rentabilisé. Optez pour Spectrum-X avec des SuperNIC compatibles, ou InfiniBand et oubliez les problèmes d'ECMP, ou collaborez avec un partenaire ayant déjà déployé une infrastructure de cette envergure. Une mauvaise configuration peut engendrer des mois de formation.
• Groupe de distribution sans interrupteur, toutes tailles : FRR + BGP non numéroté. 1 à 2 jours de configuration et de tests par doublement du nombre de nœuds. Le principal écueil est d'oublier l'ECMP côté noyau (net.ipv4.fib_multipath_hash_policy = 1 pour le hachage L4).

L'idée de « acheter plus de bande passante pour éviter la congestion » est erronée. Le trafic IA synchronisé génère une demande instantanée à débit maximal sur chaque chemin, quel que soit le nombre de nœuds. La bande passante résout les problèmes de débit, pas les problèmes de coordination.

---

Cet article fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus à info@kentino.com.