Topologies de clusters commutés : Fat-Tree, Leaf-Spine, Dragonfly+, Tesseract

Tous les schémas de cluster des présentations constructeurs commencent de la même façon : une rangée de boîtes marquées « nœud », une rangée de boîtes marquées « switch », et des flèches entre les deux. Ces schémas sont volontairement simples, car le vrai choix sous-jacent — quelle topologie, avec quel taux de sursouscription, avec quelle vitesse par port — constitue la décision la plus lourde en matière de coût dans un cluster IA, après les GPU eux-mêmes.

Cet article constitue la couche topologie entre N02 (quel protocole — InfiniBand, RoCE, Ethernet classique) et N06–N08 (comment le lien se comporte réellement une fois la topologie câblée). Il couvre les quatre familles qui comptent en 2026 : fat-tree / Clos / leaf-spine, dragonfly / dragonfly+, tesseract / hypercube, et la famille torus qui a survécu dans deux recoins précis du HPC. Il se termine par un constat honnête : environ neuf clients Kentino sur dix n'ont besoin de rien de tout cela, et cet article existe pour le dixième.

Public visé : les personnes qui dimensionnent un cluster d'entraînement de 8 à 64 nœuds et le réseau qui l'entoure. Ce n'est pas un guide de configuration Cisco/NVIDIA — c'est le modèle mental qui rend ce guide lisible.

Trois choses différentes que l'on appelle « bande passante »

Avant de dessiner des boîtes et des flèches, le vocabulaire. Trois termes sont employés indifféremment dans la littérature commerciale sur les clusters, alors qu'ils ne désignent pas le même chiffre :

Un switch 400 GbE à 32 ports dispose de 12.8 Tb/s de bande passante agrégée . Placez-y 16 nœuds à 400 GbE chacun et vous obtenez 3.2 Tb/s de bande passante de bissection . Soit 8 nœuds × 400 Gb/s de chaque côté de la coupe. Pour une étape d'allreduce où chacun des 16 GPU envoie la moitié de son gradient à travers la bissection, c'est bien par ces 3.2 Tb/s que le temps d'étape est divisé — pas par 12.8.

Le raccourci : la bande passante de bissection est le seul de ces trois chiffres qui prédit le temps d'une étape d'entraînement sur une charge de travail limitée par l'allreduce. Quand une brochure constructeur annonce la valeur agrégée, prenez mentalement la coupe la plus défavorable et divisez en conséquence pour revenir à la bissection.

Pour un cluster de 16 nœuds à 8 GPU chacun (128 GPU au total) sur des nœuds 100 GbE à NIC unique :

Même nombre de nœuds, même débit de lien, des chiffres différents selon ce que l'on entend par là. C'est le cadre que le reste de l'article utilise.

Fat-tree, Clos, leaf-spine — la même chose avec trois accents

Charles Clos a démontré en 1953 qu'un réseau multi-étages composé de petits commutateurs crossbar peut être non bloquant — n'importe quelle entrée peut atteindre n'importe quelle sortie sans contention — pour une fraction du coût d'un seul crossbar géant. Tous les réseaux de centre de données modernes sont une variante de cette idée. La terminologie, elle, s'est embrouillée :

• Un réseau Clos est la structure mathématique : des étages d'entrée, intermédiaire et de sortie composés de switches plus petits.
• Un fat-tree (Charles Leiserson, 1985) est une variante de Clos où les troncs les plus proches de la racine s'élargissent progressivement, afin que la bande passante de bissection croisse avec N.
• Un Clos replié replie l'étage de sortie sur l'étage d'entrée. Un leaf-spine est un Clos replié à deux niveaux. Un Clos replié à trois niveaux avec leaf, spine et super-spine, c'est ce que la plupart des gens appellent un fat-tree dans la pratique.

Leaf-spine à deux niveaux : chaque leaf est relié à chaque spine. Deux nœuds quelconques communiquent en exactement deux sauts. Bissection complète = aucune sursouscription au niveau spine.

Chaque leaf est relié à chaque spine. Le trafic any-to-any passe au maximum par leaf → spine → leaf, soit deux sauts. Avec assez de bande passante spine, le fabric est non bloquant : chaque nœud peut parler simultanément à tous les autres au débit nominal.

Le ratio de sursouscription est le curseur qui décide du coût. Si chaque leaf dispose de 32 liens descendants 100 GbE (3.2 Tb/s vers le rack) et de 8 liens montants 100 GbE (800 Gb/s hors du rack), la sursouscription est de 4:1 — quatre fois plus de bande passante vers le rack qu'en sortie. La bissection complète signifie 1:1 : autant de lien montant que de lien descendant. Le ratio 2:1 est courant dans les centres de données généralistes. Le 1:1 (bissection complète) est la référence pour un cluster IA.

Le coût double à peu près en passant de 4:1 à 1:1, parce que vous achetez deux fois plus de ports spine et deux fois plus d'optiques. La raison pour laquelle tout cluster IA sérieux paie cette prime : la sursouscription détruit le débit de l'allreduce. Un allreduce synchronisé à 8 flux sur un fabric sursouscrit 4:1 ne tourne pas au quart de la vitesse — il s'effondre sous la contre-pression PFC (N07) et peut perdre 60–80 % du débit théorique dans la pratique. Le calcul dit « diviser par 4 ». La réalité dit « diviser par 5–10 ».

L'architecture de référence DGX SuperPOD de NVIDIA spécifie un fat-tree à trois niveaux avec bissection complète sur InfiniBand Quantum-2 NDR à 400 Gb/s par port. Les clusters d'entraînement RoCE publiés par Meta et les séries ND Azure de Microsoft reprennent la même forme sur Ethernet Spectrum-X. Le secteur a convergé vers le fat-tree à bissection complète pour l'entraînement IA, et l'évolution 2024–2026 consiste à élargir le fat-tree (400 GbE → 800 GbE par port) ou à l'optimiser par rails (section suivante), pas à changer la topologie fondamentale.

Fat-tree optimisé par rails — le dialecte propre à l'IA

Le fat-tree standard traite toutes les NIC de la même façon. L'entraînement IA, lui, se soucie de savoir quel GPU envoie, via sa NIC, quel gradient, car les schémas de trafic de l'allreduce ne sont pas uniformes. La variante optimisée par rails affecte chaque GPU d'un nœud à un « rail » précis — un chemin leaf-spine dédié — et garantit que le i-ième GPU de chaque nœud ne dialogue qu'avec le i-ième GPU de tous les autres nœuds, via le i-ième rail.

Fat-tree optimisé par rails : chaque emplacement GPU est associé à un plan spine indépendant dédié. L'anneau allreduce du GPU 3 n'emprunte que le Rail 3.

Huit fat-trees à deux niveaux indépendants, un par emplacement GPU. L'anneau allreduce du GPU 3 sur 16 nœuds n'emprunte que le Rail 3 et ne franchit jamais les autres rails. Avantages : zéro collision ECMP entre rails, routage plus simple, radix de switch plus faible par plan. Contrepartie : une tâche qui s'étend sur plusieurs emplacements GPU (parallélisme de tenseurs dans le nœud, parallélisme de données entre nœuds) est de toute façon répartie entre les rails par NCCL ; la topologie n'aide donc que si la charge de travail s'y prête. Pour le parallélisme de données et un NCCL conscient des rails, le gain est net ; pour un parallélisme de tenseurs qui traverse les rails, l'économie s'évapore.

Dragonfly et Dragonfly+ — quand le fat-tree est hors budget

Le coût d'un fat-tree croît grossièrement en N log N : chaque doublement du nombre de nœuds exige davantage de bande passante spine, et le troisième niveau double le nombre de switches par point terminal. Pour 1024 nœuds, un fat-tree non bloquant à trois niveaux reste réalisable. Pour 10,000 nœuds, le nombre de switches et le coût des optiques deviennent punitifs. Dragonfly, proposé par John Kim, William Dally et al. en 2008, a été conçu précisément pour franchir ce mur.

L'idée : regrouper les nœuds en groupes. À l'intérieur d'un groupe, tous les switches sont densément interconnectés (souvent un petit Clos). Entre groupes, chaque groupe dispose d'un lien direct vers chacun des autres. Le résultat est un réseau de diamètre 3 (saut local au groupe, saut inter-groupes, saut local au groupe) qui passe à l'échelle sur des nombres de nœuds énormes avec bien moins de câbles longue distance qu'un fat-tree.

Dragonfly : Clos dense intra-groupe, un lien global par paire de groupes. Diamètre 3. Monte à 1000+ nœuds avec moins de câbles longue distance qu'un fat-tree.

La grande économie porte sur le câblage optique. Les optiques longue distance entre racks sont la partie la plus chère d'un fat-tree. Dragonfly les remplace par un gros lien par paire de groupes, et non un par combinaison leaf-spine. Pour un cluster de G groupes de S nœuds chacun, un fat-tree demande environ G × S × log(G × S) câbles ; dragonfly demande G(G − 1)/2 câbles inter-groupes, plus le fabric de chaque groupe. À G = 32 groupes de 32 nœuds (1024 au total), le nombre de câbles longue distance chute d'environ un ordre de grandeur.

Dragonfly+ (Mellanox, 2017) affine le principe pour InfiniBand. Le fabric intra-groupe devient un petit Clos biparti, si bien qu'agrandir un groupe n'impose pas de recâbler, et les liens inter-groupes utilisent le routage adaptatif pour contourner les groupes congestionnés. C'est la topologie de Frontier (ORNL, AMD MI250X exascale) et d' El Capitan (LLNL, MI300A) — tous deux câblés avec des switches HPE Slingshot-11 en agencement dragonfly, diamètre maximal de trois sauts, 12.8 Tb/s par switch.

Le piège, c'est le mode de défaillance des petites tâches réparties sur plusieurs groupes. Dans un fat-tree, deux nœuds situés aux extrémités opposées du cluster voient la même bande passante de bissection que deux nœuds distants d'un rack (au nombre de sauts près). Dans un dragonfly, deux nœuds de groupes différents partagent leur lien inter-groupes avec tous les autres flux inter-groupes. Si votre tâche d'entraînement à 16 GPU se place sur 8 nœuds du groupe A et 8 nœuds du groupe B, vous partagez un seul lien inter-groupes avec tous ceux qui traversent la même paire. Le routage adaptatif aide ; il n'élimine pas la contention.

Conséquence pratique : dragonfly fonctionne à merveille aux dimensions des hyperscalers (1000+ nœuds, tâches calibrées pour remplir les groupes), beaucoup moins bien pour des clusters moyens avec des petites tâches variées. C'est la mauvaise topologie pour un cluster d'entraînement de 16 nœuds — à cette échelle, le fat-tree est moins cher et plus rapide. C'est la bonne topologie pour un supercalculateur de 1024 nœuds à charges de travail mixtes.

Tesseract — l'hypercube 4D

Un tesseract est un hypercube 4D : 16 sommets, chacun relié à exactement 4 voisins, diamètre 4 (le plus long des plus courts chemins entre deux nœuds). Généralisez à k dimensions et vous obtenez un k-cube : 2^k nœuds, chacun avec k liens directs, diamètre k. Le routage par distance de Hamming — XOR entre adresses source et destination, puis un bit basculé à la fois — est trivialement déterministe et équilibré en charge sous trafic aléatoire.

Tesseract (hypercube 4D) : 16 nœuds, chacun avec 4 voisins. Traits pleins = arêtes du cube 3D ; traits pointillés = liens de la 4e dimension. Diamètre 4. Chaque étiquette de nœud est une adresse de 4 bits ; deux voisins diffèrent d'exactement un bit.

Les topologies en hypercube ont dominé le calcul massivement parallèle des années 1980. La Connection Machine CM-2 (Thinking Machines, 1987) comptait 65,536 nœuds câblés en hypercube à 12 dimensions. Intel iPSC/2 exploitait des hypercubes 7D. Le CM-5 (Thinking Machines, 1991) a abandonné l'hypercube au profit du fat-tree, car cette approche ne passait pas élégamment l'échelle au-delà d'environ 1024 nœuds : chaque nouvelle dimension double le nombre de nœuds et impose de recâbler tous les nœuds existants.

En 2026, le terme « tesseract » refait surface dans trois contextes qu'il vaut la peine de distinguer :

1. Comme nom d'un système HPC de recherche / DiRAC. Le DiRAC Tesseract de l'EPCC (Édimbourg) est un cluster HPE SGI 8600 de 1476 nœuds sur Intel Omni-Path. « Tesseract » est une marque ; le fabric, lui, tient plutôt du fat-tree.
2. Comme terme de recherche sur le « plan de contrôle SDN » (Tesseract: a 4D control plane, Yan et al.). Sans rapport avec la topologie physique.
3. Comme topologie sous-jacente de clusters d'accélérateurs compacts sans switch. Un cluster de 16 nœuds câblé littéralement en hypercube 4D présente des propriétés intéressantes : chaque nœud possède exactement 4 NIC, aucun switch central, un routage déterministe, un diamètre de 4. Nous traitons cela en détail dans N05 (topologies sans switch).

Ce qu'un tesseract apporte en 2026 : pas de taxe switch, un routage déterministe par XOR de distance de Hamming, et un faible diamètre (log₂(N)). Ce qui le rend difficile : un N figé (il doit être une puissance de 2), une complexité de câblage qui croît avec la dimension, un nombre de NIC par nœud égal à k, et des collectives IA modernes (anneau/arbre NCCL) qui n'exploitent pas nativement la structure d'hypercube.

Torus — le survivant de deux niches précises

Le k-ary n-cube généralise l'hypercube : au lieu d'une adresse binaire avec un lien par dimension, on utilise une grille k par k par k avec rebouclage. Dans un torus 3D, chaque nœud est relié à 6 voisins (±x, ±y, ±z). Un torus 6D en compte 12.

IBM Blue Gene/L et /P tournaient sur un torus 3D, montant à plusieurs centaines de milliers de nœuds avec seulement 6 liens haut débit par nœud. Fujitsu Tofu (l'interconnexion du K computer, 2011) a généralisé le principe en un maillage/torus 6D — 158,976 nœuds sur Fugaku (en service jusqu'en 2026), agencés en 24×23×24×2×3×2.

Cerebras Wafer-Scale Engine utilise un torus 2D sur le wafer : chaque élément de traitement a 4 voisins, avec rebouclage, ~1 ns par saut. Cela fonctionne parce que les pistes sur wafer ne coûtent presque rien ; des câbles hors wafer, eux, coûteraient cher.

Pourquoi le torus a perdu partout ailleurs : des chemins asymétriques et un mauvais comportement face aux charges de travail IA non uniformes. Les charges de travail IA modernes (anneau/arbre NCCL, algorithmes hiérarchiques de NVIDIA) supposent un any-to-any à bande passante uniforme. Le torus viole cette hypothèse. En 2026, le torus survit à trois endroits : l'interconnexion sur wafer de Cerebras, Fujitsu Fugaku et ses successeurs, et l'intérieur des nœuds SXM via NVSwitch. Hors de ces niches, tout nouveau cluster IA en 2025–2026 est un Clos.

Tableau comparatif

Lien montant du cluster — là où la topologie rencontre le monde extérieur

Un fabric commuté est une île. Il doit se connecter au réseau de l'entreprise (registres de modèles, stockage de jeux de données, S3, télémétrie), aux stations de travail des développeurs (SSH, Jupyter, récupération des points de contrôle) et aux autres clusters (passage de l'entraînement à l'inférence). Cette connexion, c'est le lien montant du cluster.

Deux modèles, aux conséquences très différentes :

Point de sortie unique. Une paire de switches spine (ou un routeur de sortie dédié) termine toute la connectivité externe. Simple à filtrer, facile à limiter en débit, simple à superviser. Mode de défaillance : ce lien est un point de défaillance unique ; le saturer (copie d'un gros point de contrôle, récupération d'un fragment de jeu de données de 10 GB) impacte tous les nœuds simultanément.

Lien montant distribué. Chaque leaf dispose d'un lien montant distinct vers le réseau du campus, souvent en 25 GbE plus lent par-dessus le fabric 100 GbE. Les récupérations de jeux de données et le trafic externe restent locaux au leaf — aucune congestion sur le fabric interne. Mode de défaillance : chaque leaf devient une frontière de sécurité, le filtrage demande N fois plus de travail et la supervision est plus difficile.

Pour le cas de base Kentino (cluster d'entraînement de 4 à 16 nœuds), le point de sortie unique est la bonne réponse. Le fabric interne est purement RDMA (RoCE ou InfiniBand), réglé pour une faible latence et un comportement sans perte. Le lien montant, lui, est de l'Ethernet classique, en TCP, avec une QoS normale. Ne placez pas le stockage objet des jeux de données sur le même fabric sans perte que l'allreduce des GPU : un client S3 mal élevé ne doit pas pouvoir déclencher une contre-pression PFC sur le trafic d'entraînement. Deux fabrics : le plan de données (RDMA sans perte) et le plan d'administration / de sortie (TCP avec pertes). N08 détaille la mise en œuvre pratique.

L'avis honnête de Kentino

La plupart des clients Kentino achètent de 1 à 4 nœuds. À cette échelle :

• 1 nœud. Aucune question de topologie. Du PCIe dans le châssis (K07), une NIC d'administration 25 GbE en sortie, et c'est tout.
• 2 nœuds. Un câble direct entre deux NIC RDMA. Pas de switch. Aucune topologie à choisir.
• 3–4 nœuds. Un seul switch 100 GbE à 32 ports assure le tout-à-tous en bissection complète pour $30k–50k tout compris. Toujours aucune topologie à choisir.

La conversation sur la topologie commence à 8 nœuds, quand le nombre de ports d'un seul switch devient juste, et devient obligatoire à 16 nœuds. En dessous, la bonne réponse est « un bon switch, bissection complète sur chaque port, et passez à autre chose ». Au-dessus, la bonne réponse est « leaf-spine à deux niveaux, 100 ou 200 GbE par nœud, bissection complète (1:1), et ne touchez jamais au curseur de sursouscription à moins d'y être contraint ».

Dragonfly+ est la bonne réponse aux dimensions des hyperscalers. Le tesseract / hypercube est intéressant comme option sans switch pour des clusters compacts (N05). Le torus est un choix verrouillé par le constructeur, réservé aux exploitants HPC dont les charges de travail sont conscientes de la topologie. Pour tous les autres, dans la gamme de prix Kentino, le fat-tree est le choix par défaut. Bissection complète si vous en avez les moyens ; 2:1 sinon ; jamais 4:1 pour l'entraînement IA.

---

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.