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, aucun de ces problèmes n’est réellement problématique. Connectez quatre nœuds avec un seul commutateur 100 GbE (ou sans commutateur – voir [référence manquante]). N05Utilisez RoCE standard avec les paramètres par défaut et ne vous souciez pas d'ECMP ni de DCQCN. Nous écrivons tout de même ceci car (a) cela fournit des informations utiles pour le dimensionnement, et (b) le jour où vous passerez de quatre nœuds à seize, tout cela deviendra soudainement important.

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 provoque une sursouscription du lien principal (ratio 2:1), les flux affectés s'exécutent à demi-vitesse et, comme l'étape attend le flux le plus lent, l'itération s'exécute également à demi-vitesse. Les mesures du cluster de production signalent des collisions ECMP provoquant perte de performance pouvant atteindre 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. Meilleur hachage (E-ECMP, QP-aware). 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 seul compartiment ECMP. Il est également possible de hacher le numéro de QP de destination RoCE et de répartir le trafic de l'application sur plusieurs QP (« mise à l'échelle QP »). Les chiffres de Meta montrent une amélioration d'allreduce jusqu'à 40 %. Cela reste statistique : les collisions sont plus rares, mais pas éliminées.

2. Commutation de flux. Détecter une période d'inactivité, puis recalculer le hachage à partir de là. Fonctionne pour TCP, mais mal pour les connexions RoCE consécutives.

3. Équilibrage de charge au niveau des paquets / pulvérisation des paquets. Hachage par paquet, réordonnancement autorisé, réassemblage par la carte réseau. Cette méthode élimine le problème de flux excessif, mais nécessite la coopération de la carte réseau et du commutateur. C'est le principe de fonctionnement de NVIDIA Spectrum-X : un hachage par paquet avec réordonnancement matériel au niveau de la SuperNIC.

4. Routage adaptatif. Le commutateur analyse la congestion par port et choisit le chemin le moins chargé à coût égal lors de la commutation, au lieu d'effectuer un hachage aléatoire. Combiné à la pulvérisation de paquets, c'est ce qu'InfiniBand propose depuis quinze ans. Son intégration à Ethernet est la principale nouveauté de 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 une architecture planifiée basée sur les cellules.

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 moitié de la complexité du routage concerne ce qui se passe lorsqu'un trop grand nombre de trafics arrivent simultanément sur un port du commutateur. Deux options : a) lossy Le réseau abandonne des paquets et les points d'extrémité se déconnectent (l'Internet ouvert) ; sans perte Le réseau fait pression sur le commutateur en amont pour qu'il se mette en pause — aucune perte de paquets, mais la congestion se propage en sens inverse.

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.

PFC — Contrôle de flux prioritaire La norme IEEE 802.1Qbb garantit le fonctionnement sans perte d'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 a provoqué la congestion. Si dix flux partagent la priorité 3 et que l'un d'eux est congestionné en aval, le PFC effectue une pause. tous les dixLes neuf autres flux « victimes » sont pénalisés pour un problème qui ne les concerne pas. C'est le blocage en tête de file, principal écueil 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é.

Impasse du PFCSi 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 interblocages ; les topologies Clos modernes sont conçues pour éviter les interblocages ; 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 (Notification de congestion quantifiée du centre de données) Il s'agit de l'algorithme sur lequel s'est imposé le RoCE sans perte. Développé par Microsoft et Mellanox (SIGCOMM 2015), il sera utilisé par défaut par les cartes réseau ConnectX/BlueField de NVIDIA à 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 d'Azure.

DCQCN remplit trois rôles : CP (Point de congestion) est le commutateur, marquant les paquets avec ECN lorsque la profondeur de la file d'attente de sortie dépasse un seuil (probabiliste de 0 % à Kmin à Pmax à Kmax) ; NP (Point de notification) est la carte réseau réceptrice, générant un CNP (Congestion Notification Packet) retour à l'expéditeur sur les marques ECN (limitées en débit, généralement une toutes les 50 µs par flux) ; RP (Point de réaction) est la carte réseau de l'émetteur, diminuant de manière multiplicative le débit du QP sur CNP, et l'augmentant 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 incast (100 expéditeurs atteignent un seul destinataire, la file d'attente se remplit plus vite que les CNP ne se propagent en retour, le PFC se déclenche — DCQCN+ résout ce problème) ; injustice à longue traîne (les débits qui démarrent tardivement sont limités plus longtemps) ; sensibilité des paramètres (La méthode Kmin optimisée pour 4 nœuds ne s'applique pas à 64 nœuds). En résumé : DCQCN est la méthode par défaut car elle fonctionne la plupart du temps. HPCC, Swift, EQDS et TIMELY (relancé) sont des alternatives proposées, mais aucune ne l'a supplantée à ce jour (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 Ce document 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 serait 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 réponse standard en 2026 est FRR (FRRouting) sur chaque nœud, configuré pour BGP non numérotéLe protocole BGP non numéroté utilise des adresses IPv6 locales pour l'établissement des connexions, ce qui évite d'attribuer des adresses IPv4 à chaque lien. Chaque nœud annonce son adresse 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.

---

Ceci 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.