La complexité du routage dans les réseaux IA : ECMP, routage adaptatif, DCQCN et pourquoi le HPC en est obsédé

Les articles précédents ont passé en revue les câbles, les cartes réseau, les switches et les topologies. Celui-ci traite de ce qui se passe au-dessus : comment les paquets trouvent un chemin dans une fabric multi-switch, et ce qui empêche la fabric de s'effondrer quand dix mille GPU décident de faire un all-reduce au même instant.

Le trafic IA ne ressemble en rien à celui d'un centre de données classique. Un frontend web envoie des millions de petites connexions TCP. Un entraînement IA envoie quelques flux énormes, parfaitement synchronisés, vers des pairs connus, et tout le monde attend le plus lent. Les techniques qui fonctionnent dans le premier cas s'écroulent dans le second.

Avertissement d'emblée : la plupart des clients Kentino exploitent des clusters de 1 à 4 nœuds. À cette échelle, aucun de ces problèmes ne mord vraiment. Câblez quatre nœuds sur un unique switch 100 GbE (ou sans switch — voir N05), faites tourner du RoCE standard avec les réglages par défaut, et ne pensez jamais à ECMP ni à DCQCN. Nous écrivons quand même cet article parce que (a) c'est un arrière-plan utile pour les décisions de dimensionnement, et (b) le jour où vous passerez de quatre nœuds à seize, tout cela comptera d'un coup.

Ce qu'est ECMP, et pourquoi il a suffi jusqu'à l'IA

ECMP — Equal-Cost Multi-Path — est l'astuce de routage qui fait fonctionner les fabrics leaf-spine et fat-tree. Lorsqu'il existe plusieurs chemins de coût égal entre le leaf A et le leaf B (via les spines S1..S4), le switch calcule un hachage sur des champs du paquet et s'en sert pour choisir un spine. Le hachage classique à 5 tuples porte sur (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 fonctionne à merveille. La loi des grands nombres fait la répartition de charge à votre place. Avec 10,000 flux et 8 spines, vous êtes à quelques pour cent de l'équilibre parfait.

ECMP a été conçu pour de nombreux petits flux. L'entraînement IA envoie quelques flux énormes et synchronisés — l'équilibre statistique s'effondre.

Le problème des flux éléphants

L'entraînement IA est l'exact opposé du trafic web. Une étape d'entraînement : chaque GPU calcule un gradient, chaque GPU envoie son gradient à tous les autres (all-reduce), tout le monde attend le transfert le plus lent, et on recommence.

L'all-reduce, c'est un petit nombre de très gros flux. Un ring-allreduce sur 8 nœuds avec des cartes réseau à 200 Gbps, ce sont 8 flux simultanés, de plusieurs gigaoctets chacun, tous au débit nominal, tous démarrant au même instant. L'article de Meta sur RoCE à grande échelle le documente clairement : dans les clusters IA, un tout petit nombre de flux « éléphants » représente la quasi-totalité des octets, et ils veulent tous le réseau en même temps.

Le hachage 5 tuples d'ECMP déteste cela. Avec N flux éléphants répartis sur S chemins, la probabilité d'absence de collision vaut S! / ((S-N)! · S^N). Pour 8 flux sur 8 spines : environ 2.4 %. Même 32 spines pour 8 flux ne donnent que ~33 %. Ajouter des spines ne change rien au tirage au sort — cela vous donne davantage de liens vides pendant que deux flux se disputent le même.

Une collision surcharge le lien de spine dans un rapport de 2:1, les flux concernés tournent à mi-vitesse, et comme l'étape attend le flux le plus lent, l'itération entière tourne à mi-vitesse. Des mesures en cluster de production font état de pertes de performance allant jusqu'à 40 % sur l'all-reduce à cause des collisions ECMP.

Contournements : hachage amélioré, répartition par paquet, routage adaptatif

Quatre réponses concrètes, par ordre croissant de difficulté de déploiement :

1. Un meilleur hachage (E-ECMP, QP-aware). Le correctif le moins coûteux. Le hachage 5 tuples standard réduit le trafic RDMA à un seul tuple par paire de QP — un flux d'all-reduce ne représente réellement qu'un seul bucket ECMP. Hachez aussi sur le numéro de QP de destination RoCE, et faites en sorte que l'application répartisse le trafic sur de nombreuses QP (« QP scaling »). Les chiffres de Meta : jusqu'à 40 % de mieux sur l'all-reduce. Cela reste statistique — les collisions deviennent rares, elles ne disparaissent pas.

2. Commutation par flowlets. Détecter un trou d'inactivité et re-hacher à partir de là. Efficace en TCP, médiocre sur du RoCE en flux continu.

3. Répartition de charge par paquet (packet spraying). Hacher paquet par paquet, accepter le déséquencement et laisser la carte réseau réassembler. Cela élimine le problème des flux éléphants, mais exige une coopération entre la carte réseau et le switch. C'est ce que fait NVIDIA Spectrum-X — pulvérisation par paquet avec réordonnancement matériel au niveau de la SuperNIC.

4. Routage adaptatif. Le switch suit la congestion port par port et choisit le chemin de coût égal le moins chargé au moment de la commutation, au lieu de hacher à l'aveugle. Combiné au packet spraying, c'est ce dont InfiniBand dispose depuis quinze ans. Le porter sur Ethernet est l'argument phare de NVIDIA Spectrum-X (ASIC Spectrum-4/5 + SuperNIC BlueField ou ConnectX-8), de Cisco Silicon One G200/P200 et de Broadcom Tomahawk 5 / Jericho 3-AI avec fabric ordonnancée à base de cellules.

Pour des clusters de 1 à 8 nœuds, le routage adaptatif est surdimensionné. Pour des jobs de 64 GPU montant à 1,000 GPU, c'est la différence entre « le réseau est le goulot d'étranglement » et « les GPU sont le goulot d'étranglement ». C'est pourquoi tous les fournisseurs Ethernet sérieux du marché IA ont conçu ou acquis sous licence du silicium à routage adaptatif entre 2024 et 2026.

Contrôle de congestion : pourquoi « il suffit de ne pas perdre de paquets » n'est pas gratuit

L'autre moitié de la complexité de routage, c'est ce qui se passe quand trop de trafic arrive au même instant sur un port de switch. Deux choix : un réseau avec pertes jette des paquets et les extrémités réduisent leur débit (l'Internet ouvert) ; un réseau sans perte demande au switch amont de se mettre en pause — aucune perte, mais la congestion se propage à rebours.

RoCE a toujours exigé une fabric sans perte. Les cartes RDMA supportent mal la perte de paquets — un seul paquet perdu déclenche une retransmission go-back-N de tout le message, ce qui sur du 100 GbE signifie renvoyer des mégaoctets. RoCEv2 en go-back-N est pour ainsi dire inutilisable sur un réseau avec pertes à forte charge.

PFC — Priority Flow Control (IEEE 802.1Qbb) est le mécanisme qui rend Ethernet sans perte. Lorsque la file de sortie d'un switch dépasse un seuil pour une priorité donnée, il envoie une trame PAUSE en amont pour demander à l'émetteur d'arrêter de transmettre cette priorité. Huit priorités, huit signaux stop/go indépendants.

Blocage de tête de file et flux victimes

Les pauses PFC sont grossières. Une pause dit « arrête d'envoyer la priorité 3 sur ce lien » — elle ignore quel flux a causé la congestion. Si dix flux partagent la priorité 3 et qu'un seul est congestionné en aval, PFC met les dix en pause. Les neuf autres, les « flux victimes », sont punis pour le problème d'un autre. C'est le blocage de tête de file, la plaie centrale de l'Ethernet sans perte à grande échelle.

Blocage de tête de file : A→X provoque un PFC sur le trunk. B et C, qui parlent à Y (qui va bien), sont eux aussi mis en pause — ce sont les flux victimes.

Interblocage PFC : si la topologie et le trafic forment une dépendance cyclique de liens en pause — A attend B, B attend C, C attend A — toute la fabric se fige. Observé en production. Les switches modernes disposent d'une détection d'interblocage ; les topologies Clos modernes sont exemptes d'interblocage par construction ; mais tout déploiement RoCE sérieux prévoit malgré tout un plan de reprise.

Tout l'enjeu du contrôle de congestion IA moderne est de garder des buffers assez courts pour que PFC ne se déclenche jamais en régime établi. PFC reste armé comme filet de sécurité pour les vraies microrafales. Le mécanisme qui l'empêche de se déclencher s'appelle DCQCN.

DCQCN — le contrôle de congestion standard de RoCEv2

DCQCN (DataCenter Quantized Congestion Notification) est l'algorithme sur lequel le RoCE sans perte a convergé. Développé par Microsoft et Mellanox (SIGCOMM 2015). En 2025-2026, c'est ce que les cartes ConnectX/BlueField de NVIDIA exécutent par défaut, et ce qu'Azure présente comme son standard de production pour « ~85 % du trafic Azure, RDMA, dans toutes les régions publiques ».

DCQCN comporte trois rôles : le CP (Congestion Point) est le switch, qui marque les paquets en ECN lorsque la profondeur de la file de sortie franchit un seuil (de façon probabiliste, de 0 % à Kmin jusqu'à Pmax à Kmax) ; le NP (Notification Point) est la carte réseau réceptrice, qui renvoie un CNP (Congestion Notification Packet) à l'émetteur sur marquage ECN (avec limitation de débit, typiquement un toutes les 50 µs par flux) ; le RP (Reaction Point) est la carte réseau émettrice, qui réduit multiplicativement le débit de la QP sur réception d'un CNP et l'augmente additivement (puis hyper-additivement) en leur absence.

Configuration type d'un switch pour DCQCN en 100 GbE :

# Profil ECN façon NVIDIA Cumulus sur la priorité RoCE sans perte (priorité 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              # début du marquage
  qos ecn-kmax     200KB              # marquage à Pmax
  qos ecn-pmax       1%
  qos pfc priority 3
  qos pfc xoff     400KB              # pause PFC (bien au-dessus de Kmax)
  qos pfc xon      300KB

Kmin/Kmax/Pmax est le triplet le plus ajusté de tout RoCE. Kmin petit (quelques paquets) pour que l'ECN entre en jeu avant l'épuisement des buffers ; Kmax bien plus grand pour que le marquage monte progressivement ; seuil de pause PFC nettement au-dessus de Kmax pour que PFC ne se déclenche que si DCQCN a été trop lent. Déploiement original de Microsoft : Kmin = 5 KB, Kmax = 200 KB, Pmax = 1 %.

Faiblesses connues de DCQCN : l'effondrement en incast (100 émetteurs visent un seul récepteur, la file se remplit plus vite que les CNP ne remontent, PFC se déclenche — DCQCN+ répond à ce point) ; l'iniquité en longue traîne (les flux démarrés tardivement restent bridés plus longtemps) ; la sensibilité aux paramètres (un Kmin réglé pour 4 nœuds ne se généralise pas à 64). Résumé honnête : DCQCN est le choix par défaut parce qu'il fonctionne la plupart du temps. HPCC, Swift, EQDS et un TIMELY remis au goût du jour existent comme remplaçants possibles, mais aucun ne l'a détrôné à ce jour en 2026.

ECN, DCTCP et la place du TCP pur

Mettons les choses au clair, car ces notions sont souvent confondues :

• ECN — mécanisme de couche IP (RFC 3168) où les switches marquent au lieu de jeter. Un signal, auquel rien ne réagit de soi-même.
• DCQCN — la réaction de l'extrémité RDMA. Lit l'ECN via les CNP et ajuste le débit.
• DCTCP — la réaction de l'extrémité TCP. Lit l'ECN dans les ACK et ajuste la fenêtre selon la proportion de paquets marqués. Microsoft + Stanford, SIGCOMM 2010, livré dans Windows Server et Linux.

Si vous exploitez une fabric RoCE pure, vous faites tourner DCQCN — connaissez vos valeurs par défaut. Si du stockage ou du trafic de contrôle en TCP partage le même câble, DCTCP vaut la peine d'être activé (net.ipv4.tcp_ecn = 1 plus des switches compatibles ECN).

Pourquoi le trafic IA sollicite tout cela plus qu'un centre de données classique

Trois propriétés pour lesquelles le contrôle de congestion classique n'a pas été conçu :

1. Rafales synchronisées. Tous les GPU démarrent l'all-reduce à la même nanoseconde. De zéro à 100 % d'utilisation en quelques microsecondes. Aucune montée en charge pour que le slow-start trouve le bon débit. DCQCN démarre au débit nominal précisément pour cette raison.
2. Peu de flux, mais énormes. La loi des grands nombres ne vous sauve pas. 8 flux → collisions ECMP fréquentes ; 8 récepteurs → blocage de tête de file PFC sévère.
3. Le chemin critique, c'est le lien le plus lent. Durée d'une étape d'all-reduce = temps d'achèvement du flux le plus lent. Pas de « cas moyen ». Une probabilité de 1 % de mauvaise collision se cumule sur des mois d'entraînement.

C'est pour cela que les gens du HPC et de l'IA sont obsédés par le réseau d'une manière que les opérateurs web à grande échelle n'ont historiquement pas connue. Le web est élastique — quelques requêtes lentes allongent un peu l'attente de certains utilisateurs. L'entraînement IA ne l'est pas : tout le job avance à la vitesse de son composant synchronisé le plus lent.

La complexité du sans-switch (avant-goût de N05)

N05 traite des topologies sans switch — connexion directe, maillage, anneau, tore 2D/3D, tesseract — pour les petits clusters où acheter un switch 100 GbE est excessif. Quand on retire le switch, chaque nœud devient un routeur : plusieurs cartes réseau, plusieurs chemins, et il faut bien que quelque chose choisisse le saut suivant.

La réponse standard en 2026 est FRR (FRRouting) sur chaque nœud, configuré en BGP unnumbered. BGP unnumbered utilise les adresses IPv6 link-local pour l'appairage, ce qui évite d'attribuer des adresses IPv4 sur chaque lien. Chaque nœud annonce sa loopback, apprend celles de ses pairs, et la table de routage Linux choisit le bon saut suivant.

# Configuration FRR minimale pour un nœud dans un maillage sans switch :
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         # loopback de ce nœud
    redistribute connected
  exit-address-family

Douze lignes par nœud, de l'ECMP sur autant de paires de cartes réseau que le nœud en possède — avec les mêmes réserves que l'ECMP de switch. Sur un maillage de 4 nœuds, les collisions ECMP apparaissent aussi côté hôte. Atténuez avec davantage de QP, ou acceptez la perte (faible à 4 nœuds). « Sans switch » ne veut pas dire « sans complexité de routage » — cela la déplace simplement vers les hôtes.

Quand cela vous concerne

La plupart des lecteurs n'auront rien de tout cela à faire.

• 1 à 4 nœuds, un seul switch, RoCE pour le stockage et un entraînement multi-GPU occasionnel : laissez le switch sur ses réglages par défaut. Les seuils DCQCN et ECN d'origine conviennent. PFC est activé et vous ne le verrez probablement jamais mettre en pause. Les collisions ECMP sont réelles, mais leur impact sur un run de 4 nœuds se compte en pour cent à un chiffre.
• 4 à 16 nœuds, cluster d'entraînement dédié : activez DCQCN explicitement, réglez Kmin/Kmax/Pmax à 5 KB / 200 KB / 1 % (référence Azure), activez le QP scaling dans NCCL, surveillez les compteurs de pause PFC et les taux de CNP. Si les pauses PFC augmentent, DCQCN n'est pas assez agressif — baissez Kmin.
• 16 nœuds et plus, ou 1,000 GPU et plus : le routage adaptatif est rentable. Achetez du Spectrum-X avec les SuperNIC assorties, ou de l'InfiniBand et cessez de vous soucier d'ECMP, ou associez-vous à quelqu'un qui a déjà exploité une fabric à cette échelle. Se tromper coûte des mois de temps d'entraînement.
• Cluster sans switch, quelle que soit sa taille : FRR + BGP unnumbered. 1 à 2 jours de configuration et de tests à chaque doublement du nombre de nœuds. Le gros piège est d'oublier l'ECMP côté noyau (net.ipv4.fib_multipath_hash_policy = 1 pour un hachage L4).

Le réflexe « j'achète plus de bande passante et la congestion n'arrivera jamais » est faux. Le trafic IA synchronisé crée une demande instantanée au débit nominal sur tous les chemins, quel que soit le nombre de spines. La bande passante règle 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 le calcul IA, la robotique et les systèmes qui les relient. Commentaires et corrections bienvenus à info@kentino.com.