Analyse de la latence : où chaque microseconde compte dans un réseau de clusters d'IA

Lorsqu'on dimensionne des réseaux de clusters d'IA, on commence généralement par la bande passante (100, 200, 400 GbE), et on est ensuite surpris de constater que le test de performance d'AllReduce affiche un résultat bien inférieur au débit maximal. La raison est presque toujours la latence et le régime de petits messages, où les graphiques de bande passante sont inutiles.

Cet article analyse en détail un aller-retour complet et explique chaque étape. Les chiffres ci-dessous correspondent à la fourchette de valeurs consensuelle issue des mesures publiques, de la documentation NVIDIA/Mellanox et de nos propres tests. Il s'agit d'une estimation, et non d'une garantie : les performances varient en fonction de la puce de la carte réseau, du circuit intégré du commutateur, de la version du noyau, des paramètres du BIOS et de votre patience lors des réglages.

Public cible : personnes chargées de la spécification ou du dépannage des architectures de clusters d’IA. Il ne s’agit pas d’un guide de configuration, mais du modèle mental qui le rend accessible.

L'aller-retour complet, une seule glissade

Un échange ping-pong de 64 octets entre deux GPU sur des nœuds différents, via une infrastructure commutée 100 GbE avec RDMA, se décompose à peu près comme suit :

Un RTT RDMA à commutateur unique sur InfiniBand 100 GbE / NDR arrive à ~2 µs pour les petits messages. Un protocole leaf-spine à deux sauts ajoute environ 1 µs. Le même chemin via TCP/IP du noyau aboutit à 20 à 60 µs, un ordre de grandeur supérieur, avec un comportement en queue de peloton encore plus dégradé. Ces deux chiffres déterminent la quasi-totalité des décisions architecturales ci-dessous.

Chemin unidirectionnel RDMA : le saut de commutateur (250–600 ns sur Ethernet, <100 ns sur IB) est la variable dominante ; le délai du fil à <100 m est négligeable.

Le problème ne vient pas du câble.

La lumière se propage dans la fibre optique à environ deux tiers de la vitesse du courant (c), soit une vitesse de propagation d'environ 5 ns/m. Une rangée de 30 m de fibre optique ajoute 150 ns dans un sens ; même une liaison de 500 m sur un campus ne prend qu'une microseconde. La sérialisation est également faible aux débits actuels : une trame de 64 octets à 100 Gbit/s prend 5.12 ns ; une trame jumbo de 9 000 octets prend 720 ns. Pour les petits messages de contrôle, la sérialisation est négligeable ; pour les transferts de données volumineux, elle devient insignifiante dès lors que la bande passante est suffisamment large.

La latence réside en réalité dans le logiciel, dans les circuits intégrés spécifiques aux commutateurs et dans le protocole que vous choisissez.

Tissu Switch : découpe directe ou stockage et revente

Un commutateur à commutation directe (cut-through) commence le transfert dès qu'il a lu l'en-tête de destination. Un commutateur à stockage et retransmission (store-and-forward) met en mémoire tampon la trame entière, valide éventuellement le CRC, puis la transfère.

L'avantage d'InfiniBand est bien réel : les puces HPC optimisent cette technologie depuis deux décennies. Les commutateurs Ethernet modernes dotés d'IA (Tomahawk 5, Jericho3-AI, Spectrum-X) réduisent considérablement l'écart de latence et surpassent InfiniBand en termes de profondeur de mémoire tampon, un facteur crucial pour réduire le trafic entrant.

Dans une structure en feuille-épine, un flux transversal traverse feuille → épine → feuilleLes architectures qui minimisent le nombre de sauts (topologies en arbre épais peu profondes, optimisées pour les rails) ne cherchent pas à économiser de la bande passante ; elles permettent d'économiser 500 ns par saut évité sur chaque liaison collective.

La pile réseau du noyau

Le protocole TCP/IP simple via le noyau Linux prend en charge par paquet : la distribution des interruptions NIC (ou l’interrogation NAPI), l’allocation de skb et de softirq, le traitement TCP/IP, une copie du tampon de socket entre le noyau et l’espace utilisateur, et un changement de contexte dans l’application.

Pour un petit paquet sur x86 moderne, ceci est 10–30 µs aller simple Dans le meilleur des cas, on observe des pics de latence supérieurs à 100 µs en pleine charge. Le système est également limité par le processeur : un cœur est saturé à environ 1 Mpps bien avant la carte réseau. C’est ce coût que le reste de l’article s’efforce d’éliminer.

Contournement du noyau : DPDK, RDMA, XDP, AF_XDP

Quatre méthodes courantes pour extraire le noyau du chemin de données, différant par leur degré de contournement et par ce qu'elles laissent de côté :

Quelques remarques pratiques :

• DPDK et RDMA ne sont pas interchangeables. DPDK exécute le traitement de paquets arbitraires dans l'espace utilisateur à la vitesse de la ligne ; RDMA implémente un protocole sémantique mémoire spécifique avec déchargement matériel. Les charges de travail d'IA nécessitent RDMA : NCCL et les piles de stockage le prennent en charge nativement. DPDK est utilisé dans les proxys d'inférence, la télémétrie et les plans de données personnalisés.
• AF_XDP représente un juste milieu. S'intègre au pilote au niveau de la couche eBPF, offre une latence inférieure à 10 µs et, contrairement à DPDK, ne monopolise pas la carte réseau du système d'exploitation. Solution idéale pour les environnements à usage mixte.
• XDP sans AF_XDP Ce module sert à la suppression, à la redirection et au transfert des paquets (protection contre les attaques DDoS, équilibrage de charge). Il traite les paquets au sein du noyau, au niveau du point d'entrée du pilote, sans les transférer vers l'espace utilisateur.

Pour un cluster d'IA : RDMA sur InfiniBand ou RoCEv2 pour la communication GPU à GPUPour tout le reste (gestion, télémétrie, téléchargement de modèles), utilisez simplement le protocole TCP/IP. Évitez de surdimensionner les chemins lents.

Interruption de la coalescence, GRO/LRO : le piège du débit

Linux et la plupart des pilotes de cartes réseau sont optimisés pour le débit, et non pour la latence. Deux paramètres sont essentiels :

• Interrompre la coalescence. La carte réseau attend une durée configurée en µs (ou un nombre de paquets) avant de déclencher une interruption. Cela réduit la surcharge par paquet ; mais ajoute une latence égale à la durée de la fenêtre. rx-usecs 50 ajoute jusqu'à 50 µs sur une liaison silencieuse.
• GRO / LRO. Le noyau (GRO) ou la carte réseau (LRO) regroupe les segments TCP entrants en un seul skb plus volumineux avant de les transmettre. Ce traitement est moins coûteux, mais l'agrégateur attend délibérément davantage de paquets, ce qui ajoute des microsecondes.

Le compromis est honnête et non négociable : Il est impossible d'avoir à la fois un débit maximal et une latence maximale sur la même configuration. Pour un nœud GPU, la carte réseau RDMA gérant toutes les requêtes de réduction rx-usecs 0 ou 1, fusion adaptative désactivée, GRO désactivé sur l'interface côté RDMA. Une carte réseau de gestion distincte conserve les paramètres par défaut ; elle ne fait pas partie du chemin critique.

Le corollaire : Une carte réseau à double usage (RDMA et téléchargements TCP) offrira des performances médiocres dans les deux cas. À moins de répartir le trafic entre les files d'attente ou les interfaces. Les nœuds d'IA critiques disposent d'une ou deux cartes réseau RDMA dédiées (ConnectX-7/8, BlueField-3) ainsi que d'une carte réseau de gestion distincte.

La couche application n'est pas gratuite non plus.

Deux coûts situés en haut de la pile sont rarement représentés dans les schémas d'architecture :

• memcpy. Un fichier de 4 Mo memcpy L'opération prend environ 200 µs sur un seul cœur à environ 20 Go/s. Si votre système copie les données tensorielles dans une mémoire tampon intermédiaire avant de les envoyer, le temps consommé sera supérieur à celui d'un aller-retour réseau complet. GPUDirect RDMA évite cette étape : la carte réseau lit directement depuis la mémoire du GPU.
• Sérialisation. L'utilisation de Protobuf, JSON ou d'un formatage manuel ajoute plusieurs dizaines de microsecondes pour les charges utiles complexes. Acceptable dans un appel de procédure distante (RPC) du plan de contrôle, mais fatal dans la boucle interne `allreduce`. NCCL y remédie grâce à des descripteurs binaires fixes et à la mémoire préenregistrée.

Si votre pile « optimisée pour RDMA » reste lente, analysez l'espace utilisateur avant d'incriminer l'infrastructure. Nous avons constaté des communications collectives de 30 µs où 25 µs étaient consacrés au remodelage des tenseurs PyTorch et seulement 5 µs à la connexion et à la commutation.

Opérations collectives : latence vs bande passante, et pourquoi la taille des paquets est importante

NCCL (et toute bibliothèque collective) choisit un algorithme en fonction de la taille du message :

• Petits messages sont limités par la latence. NCCL utilise des algorithmes arborescents et son protocole LL (données de 4 octets avec indicateurs de 4 octets, stockées atomiquement sur 8 octets, sans barrières mémoire). La bande passante du bus (BusBw) représente une fraction du débit de ligne ; elle correspond au coût par message multiplié par le nombre de messages.
• Messages volumineux sont limités par la bande passante. NCCL bascule vers des algorithmes en anneau dont le débit se rapproche de celui de la liaison la plus lente. La latence par message devient inférieure à quelques mégaoctets.

La transition se situe approximativement entre 64 Ko et 1 Mo, selon la topologie et la carte réseau. En dessous, la latence du commutateur et de la carte réseau, ainsi que la pile de protocoles, sont prépondérantes. Au-dessus, le débit du réseau atteint des valeurs hors norme.

Le débit maximal annoncé pour le H100 NVLink est de 450 Go/s ; l'atteindre avec des messages plus petits ou entre nœuds nécessite un réglage fin. Pour la gamme Kentino (5090 / 4090 / RTX Pro 6000 Blackwell sur RoCE 100 GbE), il faut s'attendre à une bande passante d'environ 10 à 12 Go/s par nœud pour les messages volumineux sur 100 GbE, avec le même algorithme.

La gigue est pire que la latence.

Si la latence de réduction est de 30 µs ± 1 µs sur chaque nœud, la barrière attend 30 µs. Si cette latence est en moyenne de 30 µs, avec un nœud atteignant 300 µs une fois sur mille itérations, un GPU sur deux reste inactif pendant 270 µs à chaque déclenchement de cette barrière. Sur une époque de 100 000 itérations réparties sur 16 nœuds, cela représente des heures de calcul perdues.

C'est pourquoi la latence P99/P999 est plus importante que la latence moyenne pour l'entraînement des IA. Un collectif de barrières est un victoires les plus lentes Fonctionnement : le cluster se déplace à la vitesse de son nœud le plus faible.

Sources de tremblement :

• Congestion du tampon Incast. AllReduce effectue des opérations de type « plusieurs vers un » à chaque itération. Les commutateurs à faible tampon perdent des paquets, la correction du facteur de puissance (PFC) se déclenche et la latence augmente de 10 à 100 fois. Les commutateurs IA à tampon profond (Jericho3-AI, Spectrum-X) absorbent ce pic de latence.
• Gigue du processeur hôte. Une tâche cron, un thread noyau non limité ou une variation de la fréquence du processeur peuvent générer une anomalie de 1 ms. Isolez les cœurs dédiés au thread d'interruption/d'interrogation de la carte réseau, désactivez les états C sur les processeurs critiques et bloquez les processus.
• Fusion adaptative. Le pilote « aide » en augmentant la coalescence sous charge ; des pics de latence apparaissent alors sans avertissement. Désactivez-le explicitement sur la carte réseau RDMA.
• Asymétrie topologique. Une interface à 200 GbE, une autre à 100 GbE. La plus lente constitue le débit minimal pour chaque réseau collectif.

La latence de queue, et non la latence moyenne, est le SLO approprié pour une infrastructure d'IA.

Le mesurer correctement

ping Il mesure le RTT ICMP au niveau de la pile du noyau sur le plan de gestion. inutile pour la caractérisation d'un tissu RDMA. Les outils qui fonctionnent :

• sockperf ping-pong — Latence UDP/TCP inférieure à la nanoseconde. Idéal pour les analyses de référence et les régressions de la pile du noyau.
• ib_send_lat, ib_write_lat (suite de tests de performance) — Latence RDMA directe. C'est la valeur qui vous intéresse réellement pour InfiniBand et RoCE. Prévoyez environ 1 à 2 µs sur une liaison au sein du même commutateur.
• Micro-benchmarks de l'OSU - osu_latency, osu_bw, osu_allreduce au niveau MPI. L'outil idéal pour les applications HPC avant l'arrivée de NCCL.
• nccl-tests - all_reduce_perf, all_gather_perf, reduce_scatter_perf. Le seul critère de référence qui compte pour l'entraînement de l'IA. Il teste le chemin d'exécution exact utilisé par votre programme. Balayez de 8 octets à 1 Go ; la courbe vous indique où le système présente une défaillance.

Vérification de cohérence : si nccl-tests all_reduce_perf Le débit de communication (busbw) des messages « large » est largement inférieur à 80 % du débit de la ligne NIC ; il s’agit d’un problème d’infrastructure réseau, et non d’un problème logiciel. Parcourez les différentes couches du réseau en suivant les étapes décrites dans cet article.

Habitude utile : Stockez les résultats des tests nccl dans le cadre de la mise en service et relancez-les après chaque modification du firmware, du pilote ou de la topologie. Une régression détectée le jour même où elle se produit ne représente qu'une seule différence. Détectée trois semaines plus tard, elle devient une véritable opération d'investigation.

Quand la latence compte vraiment — et quand elle ne compte pas

La latence est importante :

• Réduction du gradient synchrone En entraînement parallèle sur les données. À chaque itération, pour chaque nœud. Latence de queue = temps de calcul de la perte.
• Parallélisme de pipeline à grain fin avec de petits micro-lots. Le temps de formation des bulles aux limites des étapes est limité par la latence inter-nœuds.
• Divisions de couches parallèles tensorielles qui se déploient et se replient au sein d'une passe avant/arrière — une chaîne de petits collectifs, un jeu de latence pure.
• Communication par étape entre le serveur de paramètres et le serveur à un taux de mise à jour élevé.

La latence, en général, non :

• Regroupement des inférences La granularité de la requête est variable. La latence par requête est principalement due au calcul GPU (TTFT, décodage par jeton). 10 µs de réseau représentent un bruit de fond comparé aux 50 ms de décodage.
• Chargement du modèle en masse À partir du stockage d'objets au démarrage de la tâche. Limité par le débit.
• écriture du point de contrôle vers le stockage en réseau. Écritures séquentielles importantes, optimiser en fonction de la bande passante.
• brassage du chargeur de données Préchargement par les processus de traitement. Traitement par lots, limité par le débit.

L'implication honnête : Un serveur à nœud unique 4× ou 8×GPU (la gamme K-AI phare de Kentino) effectue sa communication inter-GPU via NVLink ou PCIe, et non via le réseau. Le réseau est dédié au stockage, à la télémétrie et à des expériences ponctuelles sur plusieurs nœuds. Optimiser l'infrastructure pour réduire la latence globale n'est rentable que pour l'entraînement multi-nœuds, une pratique rare chez les clients Kentino. Pour l'inférence pure et l'entraînement sur un seul nœud, une connexion 25 GbE avec une pile logicielle propre est suffisante.

---

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.