Topologías de clúster conmutadas: Fat-Tree, Leaf-Spine, Dragonfly+, Tesseract

Todo diagrama de clúster de una presentación comercial empieza igual: una fila de cajas etiquetadas como «nodo», una fila de cajas etiquetadas como «conmutador» y flechas entre ellas. Los diagramas son deliberadamente simples porque la decisión real que hay debajo — qué topología, con cuánta sobresuscripción, con qué velocidad por puerto — es la mayor decisión de coste de un clúster de IA después de las propias GPU.

Este artículo es la capa de topología entre N02 (qué protocolo: InfiniBand, RoCE o Ethernet convencional) y N06–N08 (cómo se comporta realmente el cable una vez montada la topología). Cubre las cuatro familias que importan en 2026: fat-tree / Clos / leaf-spine, dragonfly / dragonfly+, teseracto / hipercubo, y la familia torus que sobrevivió en dos rincones muy concretos del HPC. Termina con la conclusión honesta: aproximadamente nueve de cada diez clientes de Kentino no necesitan nada de esto, y el artículo existe para el décimo.

Público: quien esté dimensionando un clúster de entrenamiento de 8 a 64 nodos y la red que lo rodea. No es un recetario de configuración de Cisco/NVIDIA, sino el modelo mental que hace legible ese recetario.

Tres cosas distintas que la gente llama «ancho de banda»

Antes de dibujar cajas y flechas, el vocabulario. Tres términos se usan indistintamente en la literatura comercial de clústeres y no son el mismo número:

Un conmutador 400 GbE de 32 puertos tiene 12.8 Tb/s de ancho de banda agregado. Conecte en él 16 nodos a 400 GbE cada uno y tendrá 3.2 Tb/s de ancho de banda de bisección (8 nodos × 400 Gb/s a cada lado del corte). En un paso de allreduce en el que cada una de las 16 GPU envía la mitad de su gradiente a través de la bisección, es por esos 3.2 Tb/s por lo que se divide el tiempo de paso, no por 12.8.

El atajo: el ancho de banda de bisección es el único de estos tres números que predice el tiempo de paso de entrenamiento en una carga de trabajo limitada por allreduce. Cuando un folleto comercial cite el agregado, tome mentalmente el peor corte y divida en consecuencia para volver a la bisección.

Para un clúster de 16 nodos con 8 GPU cada uno (128 GPU en total) en nodos de una sola NIC a 100 GbE:

Mismo número de nodos, misma velocidad de cable, números distintos según lo que se quiera decir. Este es el marco que usa el resto del artículo.

Fat-tree, Clos, leaf-spine: lo mismo con tres acentos

Charles Clos demostró en 1953 que una red multietapa de pequeños conmutadores crossbar puede ser no bloqueante —cualquier entrada puede alcanzar cualquier salida sin contención— por una fracción del coste de un único crossbar gigante. Toda red moderna de centro de datos es alguna variante de esta idea. La nomenclatura se ha enredado:

• Una red Clos es la estructura matemática: etapas de entrada, intermedia y de salida formadas por conmutadores más pequeños.
• Un fat-tree (Charles Leiserson, 1985) es una variante de Clos en la que los troncos más cercanos a la raíz son progresivamente más gruesos, de modo que el ancho de banda de bisección escala con N.
• Un Clos plegado repliega la etapa de salida sobre la etapa de entrada. Un leaf-spine es un Clos plegado de dos niveles. Un Clos plegado de tres niveles, con leaf, spine y super-spine, es lo que la mayoría llama fat-tree en la práctica.

Leaf-spine de dos niveles: cada leaf se conecta con todos los spines. Dos nodos cualesquiera se comunican en exactamente dos saltos. Bisección completa = sin sobresuscripción en la capa de spine.

Cada leaf se conecta con todos los spines. El tráfico cualquiera-con-cualquiera es como mucho leaf → spine → leaf, dos saltos. Con suficiente ancho de banda de spine, el fabric es no bloqueante: todos los nodos pueden hablar simultáneamente con todos los demás a velocidad de línea.

La relación de sobresuscripción es la palanca que decide el coste. Si cada leaf tiene 32 enlaces de bajada de 100 GbE (3.2 Tb/s hacia el rack) y 8 enlaces de subida de 100 GbE (800 Gb/s fuera del rack), la sobresuscripción es 4:1 — cuatro veces más ancho de banda hacia el rack que desde él. Bisección completa significa 1:1: tanto enlace de subida como de bajada. 2:1 es habitual en centros de datos de uso general. 1:1 (bisección completa) es la referencia en clústeres de IA.

El coste se duplica aproximadamente al pasar de 4:1 a 1:1, porque compra el doble de puertos de spine y el doble de ópticas. La razón por la que todo clúster de IA serio paga ese sobreprecio: la sobresuscripción destruye el rendimiento del allreduce. Un allreduce sincronizado de 8 flujos sobre un fabric 4:1 sobresuscrito no funciona a un cuarto de velocidad: se desploma bajo la contrapresión PFC (N07) y puede perder entre el 60 y el 80 % del rendimiento teórico en la práctica. La teoría dice «divida entre 4». La realidad dice «divida entre 5 o 10».

La arquitectura de referencia DGX SuperPOD de NVIDIA especifica un fat-tree de tres niveles con bisección completa sobre InfiniBand Quantum-2 NDR a 400 Gb/s por puerto. Los clústeres de entrenamiento RoCE publicados por Meta y la serie ND de Azure de Microsoft construyen la misma forma sobre Ethernet Spectrum-X. El sector ha convergido en el fat-tree de bisección completa para el entrenamiento de IA, y la evolución de 2024-2026 consiste en hacer el fat-tree más ancho (400 GbE → 800 GbE por puerto) o rail-optimized (siguiente sección), no en cambiar la topología de fondo.

Fat-tree rail-optimized: el dialecto específico de la IA

El fat-tree estándar trata igual a todas las NIC. Al entrenamiento de IA sí le importa qué NIC de GPU envía qué gradiente, porque los patrones de tráfico del allreduce no son uniformes. La variante rail-optimized asigna cada GPU de un nodo a un «rail» concreto —una ruta leaf-spine dedicada— y garantiza que la GPU i-ésima de cada nodo solo hable con la GPU i-ésima de todos los demás nodos a través del rail i-ésimo.

Fat-tree rail-optimized: cada slot de GPU se asigna a un plano de spine independiente y dedicado. El anillo de allreduce de la GPU 3 usa solo el Rail 3.

Ocho fat-trees independientes de dos niveles, uno por slot de GPU. El anillo de allreduce de la GPU 3 a lo largo de 16 nodos usa solo el Rail 3 y nunca cruza a otros rails. Ventajas: cero colisiones ECMP entre rails, enrutamiento más simple y menor radix de conmutador por plano. Contrapartida: un trabajo que abarca varios slots de GPU (paralelismo de tensores dentro del nodo, paralelismo de datos entre nodos) acaba repartido entre rails por NCCL de todos modos, así que la topología solo ayuda si la carga de trabajo se alinea. Para paralelismo de datos y NCCL consciente de rails es una ventaja clara; para paralelismo de tensores que cruza rails, el ahorro se evapora.

Dragonfly y Dragonfly+: cuando no puede permitirse un fat-tree

El coste del fat-tree crece aproximadamente como N log N: cada duplicación del número de nodos exige más ancho de banda de spine, y el tercer nivel duplica el número de conmutadores por extremo. Para 1024 nodos, un fat-tree de tres niveles no bloqueante es construible. Para 10,000 nodos, el número de conmutadores y el coste de las ópticas se vuelven punitivos. Dragonfly, propuesta por John Kim, William Dally y otros en 2008, se diseñó precisamente para escalar más allá de ese muro.

La idea: agrupar los nodos en grupos. Dentro de un grupo, todos los conmutadores están densamente conectados (a menudo mediante un Clos más pequeño). Entre grupos, cada grupo tiene un enlace directo con todos los demás. El resultado es una red con diámetro 3 (salto local al grupo, salto entre grupos, salto local al grupo) que escala a cantidades enormes de nodos con muchos menos cables de larga distancia que un fat-tree.

Dragonfly: Clos denso intragrupo, un enlace global por par de grupos. Diámetro 3. Escala a más de 1000 nodos con menos cables de larga distancia que un fat-tree.

El gran ahorro está en el cableado óptico. Las ópticas de larga distancia entre racks son la parte más cara de un fat-tree. Dragonfly las sustituye por un enlace grueso por par de grupos, no uno por cada combinación leaf-spine. Para un clúster con G grupos de S nodos cada uno, un fat-tree necesita aproximadamente G × S × log(G × S) cables; dragonfly necesita G(G − 1)/2 cables entre grupos más el fabric de cada grupo. Con G = 32 grupos de 32 nodos (1024 en total), el número de cables de larga distancia cae en aproximadamente un orden de magnitud.

Dragonfly+ (Mellanox, 2017) refina esto para InfiniBand. El fabric intragrupo pasa a ser un pequeño Clos bipartito, de modo que ampliar un grupo no obliga a recablear, y los enlaces entre grupos usan enrutamiento adaptativo para esquivar los grupos congestionados. Esta es la topología de Frontier (ORNL, exaescala AMD MI250X) y El Capitan (LLNL, MI300A), ambos cableados con conmutadores HPE Slingshot-11 en disposición dragonfly, con un diámetro máximo de tres saltos y 12.8 Tb/s por conmutador.

La pega es el modo de fallo de los trabajos pequeños que abarcan varios grupos. En un fat-tree, dos nodos situados en extremos opuestos del clúster ven el mismo ancho de banda de bisección que dos nodos separados por un rack (salvo por el número de saltos). En un dragonfly, dos nodos de grupos distintos comparten su enlace entre grupos con todos los demás flujos que cruzan grupos. Si su trabajo de entrenamiento de 16 GPU cae en 8 nodos del grupo A y 8 del grupo B, estará compartiendo un único enlace entre grupos con todos los que coincidan en ese mismo par. El enrutamiento adaptativo ayuda, pero no elimina la contención.

Implicación práctica: dragonfly funciona de maravilla en tamaños de problema de hiperescalar (más de 1000 nodos, trabajos dimensionados para llenar grupos) y no tan bien en clústeres medianos con trabajos pequeños y variados. Es la topología equivocada para un clúster de entrenamiento de 16 nodos: a esa escala, el fat-tree es más barato y más rápido. Es la topología acertada para un superordenador de 1024 nodos con cargas de trabajo mixtas.

Teseracto: el hipercubo 4D

Un teseracto es un hipercubo 4D: 16 vértices, cada uno conectado exactamente con 4 vecinos, diámetro 4 (el camino más corto más largo entre dos nodos cualesquiera). Generalice a k dimensiones y obtendrá un k-cubo: 2^k nodos, cada uno con k enlaces directos y diámetro k. El enrutamiento por distancia de Hamming —XOR entre las direcciones de origen y destino, invirtiendo un bit cada vez— es trivialmente determinista y se equilibra solo con tráfico aleatorio.

Teseracto (hipercubo 4D): 16 nodos, cada uno con 4 vecinos. Las líneas continuas son aristas del cubo 3D; las discontinuas, enlaces de la cuarta dimensión. Diámetro 4. Cada etiqueta de nodo es una dirección de 4 bits; los vecinos difieren exactamente en un bit.

Las topologías de hipercubo dominaron la computación masivamente paralela de los años ochenta. La Connection Machine CM-2 (Thinking Machines, 1987) tenía 65,536 nodos cableados como un hipercubo de 12 dimensiones. Intel iPSC/2 usaba hipercubos 7D. La CM-5 (Thinking Machines, 1991) abandonó el hipercubo en favor del fat-tree porque ese enfoque no escalaba con elegancia más allá de unos 1024 nodos: cada nueva dimensión duplica el número de nodos y obliga a recablear todos los nodos existentes.

En 2026, el término «teseracto» sigue apareciendo en tres sitios que conviene distinguir:

1. Como nombre de un sistema HPC de investigación / DiRAC. El DiRAC Tesseract del EPCC (Edimburgo) es un clúster HPE SGI 8600 de 1476 nodos sobre Intel Omni-Path. «Tesseract» es marca; el fabric se parece más a un fat-tree.
2. Como término de investigación de «plano de control SDN» (Tesseract: a 4D control plane, Yan et al.). No guarda relación con la topología física.
3. Como topología subyacente de clústeres compactos de aceleradores sin conmutador. Un clúster de 16 nodos cableado como un hipercubo 4D literal tiene propiedades interesantes: cada nodo tiene exactamente 4 NIC, no hay conmutador central, el enrutamiento es determinista y el diámetro es 4. Lo tratamos a fondo en N05 (topologías sin conmutador).

Lo que ofrece un teseracto en 2026: sin peaje de conmutador, enrutamiento determinista mediante XOR por distancia de Hamming y diámetro bajo (log₂(N)). Lo que lo complica: N fijo (debe ser potencia de 2), la complejidad del cableado crece con la dimensión, el número de NIC por nodo es igual a k y las colectivas de IA modernas (ring/tree de NCCL) no aprovechan de forma nativa la estructura del hipercubo.

Torus: el superviviente en dos rincones muy concretos

El k-ario n-cubo generaliza el hipercubo: en lugar de una dirección binaria con un enlace por dimensión, usa una rejilla de k por k por k con envolvente. En un torus 3D, cada nodo está conectado con 6 vecinos (±x, ±y, ±z). Un torus 6D tiene 12 vecinos.

IBM Blue Gene/L y /P funcionaban sobre un torus 3D y escalaban a cientos de miles de nodos con solo 6 enlaces de alta velocidad por nodo. Fujitsu Tofu (la interconexión del K computer, 2011) lo generalizó a una malla/torus 6D: 158,976 nodos en Fugaku (activo durante 2026), dispuestos en 24×23×24×2×3×2.

Cerebras Wafer-Scale Engine usa un torus 2D en la propia oblea: cada elemento de proceso tiene 4 vecinos, con envolvente y ~1 ns por salto. Funciona porque las pistas dentro de la oblea son casi gratis; los cables fuera de ella no lo serían.

Por qué el torus perdió en todo lo demás: caminos asimétricos y mal comportamiento con cargas de trabajo de IA no uniformes. Las cargas de trabajo de IA modernas (ring/tree de NCCL, algoritmos jerárquicos de NVIDIA) dan por supuesto un tráfico cualquiera-con-cualquiera de ancho de banda uniforme. El torus incumple eso. En 2026, el torus sobrevive en tres sitios: la interconexión en oblea de Cerebras, Fugaku de Fujitsu y sus sucesores, y el interior de los nodos SXM mediante NVSwitch. Fuera de esos nichos, todo clúster de IA nuevo de 2025-2026 es Clos.

Tabla comparativa

Uplink del clúster: cómo la topología se encuentra con el mundo exterior

Un fabric conmutado es una isla. Tiene que conectarse con la red corporativa (registros de modelos, almacenamiento de datasets, S3, telemetría), con las estaciones de trabajo de los desarrolladores (SSH, Jupyter, copia de checkpoints hacia fuera) y con otros clústeres (traspaso de entrenamiento → inferencia). Esa conexión es el uplink del clúster.

Dos modelos, con consecuencias muy distintas:

Punto de uplink único. Un par de conmutadores de spine (o un router de uplink dedicado) termina toda la conectividad externa. Fácil de proteger con cortafuegos, fácil de limitar en tasa, fácil de monitorizar. Modo de fallo: ese enlace es un punto único de fallo; saturarlo (la copia de un checkpoint grande, la descarga de un shard de dataset de 10 GB) afecta a todos los nodos a la vez.

Uplink distribuido. Cada leaf tiene un uplink propio a la red del campus, a menudo a 25 GbE sobre el fabric de 100 GbE. Las descargas de datasets y el tráfico externo se quedan en el leaf, sin congestionar el fabric interno. Modo de fallo: cada leaf es una frontera de seguridad, el trabajo de cortafuegos se multiplica por N y la monitorización es más difícil.

Para el caso base de Kentino (clúster de entrenamiento de 4 a 16 nodos), el punto de uplink único es la respuesta correcta. El fabric interno es solo RDMA (RoCE o InfiniBand), ajustado para baja latencia y comportamiento sin pérdidas. El uplink es Ethernet convencional, TCP y QoS normal. No ponga el almacén de objetos de datasets en el mismo fabric sin pérdidas que el allreduce de las GPU: un cliente S3 que se comporte mal no debería poder disparar contrapresión PFC sobre el tráfico de entrenamiento. Dos fabrics: plano de datos (RDMA sin pérdidas) y plano de gestión/uplink (TCP con pérdidas). N08 cubre la configuración práctica.

La opinión honesta de Kentino

La mayoría de los clientes de Kentino compran entre 1 y 4 nodos. A esa escala:

• 1 nodo. No hay pregunta de topología. PCIe dentro de la caja (K07), una NIC de gestión de 25 GbE hacia fuera y listo.
• 2 nodos. Un cable directo entre dos NIC RDMA. Sin conmutador. Sin topología que elegir.
• 3–4 nodos. Un único conmutador 100 GbE de 32 puertos resuelve el todos-con-todos con bisección completa por $30k–50k con todo incluido. Sigue sin haber topología que elegir.

La conversación sobre topología empieza con 8 nodos, cuando el número de puertos de un solo conmutador se queda justo, y se vuelve obligatoria con 16 nodos. Por debajo de eso, la respuesta correcta es «un buen conmutador, bisección completa en todos los puertos y siga con su vida». Por encima, la respuesta correcta es «leaf-spine de dos niveles, 100 o 200 GbE por nodo, bisección completa (1:1) y no toque nunca la palanca de la sobresuscripción salvo que le obliguen».

Dragonfly+ es la respuesta correcta en tamaños de problema de hiperescalar. El teseracto / hipercubo resulta interesante como opción sin conmutador para clústeres compactos (N05). El torus es una elección atada a un fabricante, para operadores de HPC con cargas de trabajo conscientes de la topología. Para todos los demás dentro de la franja de precio de Kentino, el fat-tree es la opción por defecto. Bisección completa si puede permitírsela; 2:1 si no; nunca 4:1 para entrenamiento de IA.

---

Esto forma parte de la Kentino Wiki, una serie de referencia sobre computación de IA, robótica y los sistemas que las conectan. Se agradecen comentarios y correcciones en info@kentino.com.