Diseño de Topología de Red para Clústeres GPU: Arquitecturas Fat-Tree, Dragonfly y Optimizadas por Rail

Actualizado el 11 de diciembre de 2025

Actualización de diciembre 2025: DGX SuperPOD especifica fat-tree de tres niveles con switches Quantum-2 InfiniBand (400Gb/s). Un estudio de Meta encuentra que los errores de configuración de red causan el 10.7% de los fallos significativos en trabajos GPU. El ancho de banda de bisección completo es crítico para el entrenamiento distribuido donde los patrones de comunicación cambian dinámicamente. Los pods TPU de Google usan torus 3D; AWS Trainium usa topologías optimizadas para cargas de trabajo específicas.

La arquitectura de referencia DGX SuperPOD de NVIDIA especifica una topología de red fat-tree de tres niveles que conecta hasta 32 sistemas DGX usando switches Quantum-2 InfiniBand a 400 Gb/s por puerto.[^1] La arquitectura proporciona ancho de banda de bisección completo, lo que significa que el ancho de banda agregado entre cualquier mitad del clúster iguala el ancho de banda total hacia cualquiera de las mitades. Las topologías fat-tree dominan los despliegues de clústeres GPU porque proporcionan rendimiento predecible independientemente de qué pares de GPU se comuniquen, una propiedad crítica para el entrenamiento distribuido donde los patrones de comunicación cambian dinámicamente.

Las decisiones de topología de red afectan directamente el rendimiento del entrenamiento, el costo y la complejidad operacional. Un estudio de Meta encontró que los errores de configuración de red causaron el 10.7% de los fallos significativos de trabajos en sus clústeres GPU, con la congestión dependiente de la topología contribuyendo a la variabilidad del rendimiento.[^2] Los pods TPU de Google usan topologías torus 3D que permiten conexiones directas entre aceleradores vecinos, mientras que los clústeres AWS Trainium emplean diferentes topologías optimizadas para sus patrones de carga de trabajo.[^3] Comprender las compensaciones de topología permite a las organizaciones seleccionar arquitecturas que coincidan con sus requisitos específicos de carga de trabajo y restricciones presupuestarias.

Fundamentos de la topología fat-tree

La topología fat-tree se originó del trabajo de Charles Leiserson en 1985 que demostró que las estructuras de árbol podían lograr ancho de banda de bisección completo si la capacidad de enlace aumentaba hacia la raíz.[^4] Las implementaciones modernas usan enlaces de igual capacidad en todo el sistema, logrando ancho de banda completo a través de múltiples rutas paralelas en lugar de enlaces más gruesos.

Arquitectura fat-tree de tres niveles

Un fat-tree de tres niveles consiste en switches leaf que conectan a servidores, switches spine que agregan tráfico de los leaf, y switches core que proporcionan conectividad completa entre los spine.[^5] Cada switch leaf se conecta a cada switch spine, y cada spine se conecta a cada switch core. La malla de conexiones crea múltiples rutas de costo equivalente entre cualquier par de servidores.

NVIDIA recomienda fat-tree para clústeres DGX debido a las características predecibles de latencia y ancho de banda.[^6] La topología asegura que las operaciones colectivas como all-reduce experimenten rendimiento consistente independientemente de la ubicación de las GPU. Los trabajos de entrenamiento no necesitan considerar la topología de red al programar, simplificando la gestión del clúster.

Ratios de sobresubscripción

El ancho de banda de bisección completo requiere capacidad de switch costosa en los niveles superiores. Muchos despliegues aceptan sobresubscripción, donde el ancho de banda de enlace ascendente agregado desde los niveles inferiores excede la capacidad disponible en los niveles superiores.[^7] Un ratio de sobresubscripción de 2:1 significa que solo la mitad del tráfico podría atravesar simultáneamente los niveles superiores.

La sobresubscripción es adecuada para cargas de trabajo con localidad, donde la mayor parte de la comunicación ocurre dentro de racks o pods. Sin embargo, el entrenamiento distribuido con patrones de comunicación all-to-all satura los enlaces sobresubscritos, causando congestión y degradación del rendimiento. Los clústeres de entrenamiento de IA típicamente requieren diseños sin sobresubscripción a pesar del mayor costo.[^8]

Radix y escalabilidad

El radix del switch determina cuántos puertos proporciona cada switch, afectando tanto la escala como el costo. Un switch de 64 puertos construyendo un fat-tree de tres niveles con 32 enlaces descendentes y 32 enlaces ascendentes escala a 32,768 endpoints.[^9] Los switches de mayor radix reducen el número de switches necesarios pero aumentan el costo por switch.

Los switches Quantum-2 de NVIDIA proporcionan 64 puertos a 400 Gb/s, permitiendo despliegues fat-tree a gran escala con conteos de switches razonables.[^10] La próxima generación Quantum-X800 aumenta las velocidades de puerto a 800 Gb/s, duplicando el ancho de banda agregado sin cambiar la estructura de la topología.

Topología optimizada por rail

La topología optimizada por rail surgió del reconocimiento de que los servidores GPU contienen múltiples GPU que comparten interconexiones internas de alta velocidad. En lugar de tratar cada GPU independientemente, los diseños optimizados por rail alinean las conexiones de red con la ubicación de las GPU dentro de los servidores.[^11]

Entendiendo los rails de GPU

Un sistema DGX H100 contiene ocho GPU conectadas vía NVLink, con cada GPU también conectándose a una tarjeta de interfaz de red (NIC).[^12] Las ocho NIC corresponden a ocho "rails" que abarcan el clúster. El rail 0 conecta la GPU 0 de cada servidor, el rail 1 conecta la GPU 1, y así sucesivamente. La comunicación dentro de un rail atraviesa menos saltos de switch que la comunicación entre rails.

NVIDIA NVLink Switch conecta GPUs dentro y entre servidores a 900 GB/s de ancho de banda agregado por GPU.[^13] El dominio NVLink maneja la mayor parte de la comunicación GPU-a-GPU, con la red InfiniBand manejando la comunicación entre dominios NVLink. La topología optimizada por rail alinea las rutas InfiniBand con los dominios NVLink para minimizar el tráfico InfiniBand.

Consideraciones de implementación

Los despliegues optimizados por rail requieren cableado cuidadoso para mantener la alineación de rails entre racks y pods.[^14] Las conexiones mal cableadas rompen la localidad de rail, forzando el tráfico a través de saltos de switch adicionales. La disciplina en la gestión de cables resulta esencial para realizar los beneficios de la optimización por rail.

La topología reduce los requisitos de switches comparada con fat-tree completo a escala equivalente. Los ahorros provienen de eliminar capacidad de switching entre rails que las cargas de trabajo optimizadas por rail raramente usan.[^15] Las organizaciones deben verificar que sus patrones de carga de trabajo realmente exhiban localidad de rail antes de comprometerse con diseños optimizados por rail.

Topología dragonfly

La topología dragonfly organiza los switches en grupos con conectividad intra-grupo densa y enlaces inter-grupo dispersos.[^16] El diseño reduce el conteo de switches comparado con fat-tree mientras mantiene longitudes de ruta razonables entre cualquier par de endpoints.

Estructura dragonfly

Un dragonfly consiste en grupos, cada uno conteniendo múltiples switches completamente conectados dentro del grupo. Los enlaces globales conectan cada switch a switches en otros grupos.[^17] Cualquier par de endpoints se conecta a través de máximo tres saltos: switch local a switch de grupo a switch de grupo remoto a destino.

El conteo de saltos reducido disminuye la latencia para despliegues a gran escala. Menos switches reducen el costo de capital y el consumo de energía. Sin embargo, dragonfly proporciona menor ancho de banda de bisección que fat-tree, haciéndolo más susceptible a la congestión bajo ciertos patrones de tráfico.[^18]

Requisitos de enrutamiento adaptativo

El rendimiento de dragonfly depende fuertemente del enrutamiento adaptativo que distribuye el tráfico entre las rutas disponibles.[^19] El enrutamiento estático concentra el tráfico en enlaces específicos, causando congestión mientras otras rutas permanecen subutilizadas. Los switches deben monitorear la utilización de enlaces y cambiar dinámicamente el tráfico a rutas menos cargadas.

NVIDIA InfiniBand soporta enrutamiento adaptativo adecuado para despliegues dragonfly.[^20] La capacidad requiere configuración y pruebas para asegurar que los algoritmos de enrutamiento respondan apropiadamente a los patrones de tráfico de carga de trabajo. El enrutamiento adaptativo mal configurado puede rendir peor que el enrutamiento estático.

Sensibilidad a la carga de trabajo

Dragonfly es adecuado para cargas de trabajo con patrones de comunicación localizados que mantienen la mayor parte del tráfico dentro de los grupos.[^21] Las cargas de trabajo que generan tráfico aleatorio uniforme a través de todos los endpoints estresan los enlaces inter-grupo más allá de su capacidad. La topología funciona bien para servicio de inferencia con afinidad de solicitudes pero puede tener dificultades con entrenamiento a gran escala usando colectivas globales.

Las organizaciones que evalúan dragonfly deberían caracterizar los patrones de comunicación esperados de la carga de trabajo antes del despliegue. Las herramientas de simulación pueden modelar el rendimiento esperado bajo tráfico realista, identificando potenciales puntos de congestión que requieren ajuste de topología.[^22]

Topologías torus y mesh

Las topologías torus conectan nodos en patrones de rejilla regulares con conexiones de vuelta en los límites. Los pods TPU de Google usan topologías torus 3D que proporcionan conexiones directas entre vecinos sin switching.[^23]

Redes directas versus conmutadas

Las redes torus conectan cada nodo directamente a sus vecinos, eliminando los switches de la ruta de comunicación.[^24] La conexión directa reduce la latencia para la comunicación vecino-a-vecino común en muchos algoritmos paralelos. Sin embargo, la comunicación entre nodos distantes atraviesa múltiples nodos intermedios, aumentando la latencia y consumiendo ancho de banda en cada salto.

Las redes conmutadas como fat-tree proporcionan latencia igual entre cualquier par de endpoints independientemente de la ubicación física. La uniformidad simplifica la programación y el balanceo de carga. Las redes torus requieren ubicación consciente de la topología para minimizar las distancias de comunicación.[^25]

Selección de dimensión

Las topologías torus de mayor dimensión reducen el diámetro (conteo máximo de saltos) a costa de mayor conteo de conexiones por nodo.[^26] Un torus 3D con N nodos por dimensión tiene diámetro 3N/2, mientras que un torus 2D tiene diámetro N. La elección de Google de torus 3D equilibra el conteo de conexiones contra el diámetro.

Las restricciones físicas afectan la selección de dimensión. Un torus 2D se mapea naturalmente a filas y columnas en una sala de máquinas. Un torus 3D requiere racks apilados o conexiones que abarcan distancias sustanciales. Las longitudes de cable en torus de alta dimensión pueden volverse problemáticas a escala.[^27]

Marco de selección de topología

Seleccionar la topología de red requiere evaluar las características de la carga de trabajo, requisitos de escala, restricciones presupuestarias y capacidades operacionales.

Análisis de carga de trabajo

Diferentes cargas de trabajo estresan las redes de manera diferente. Entrenar modelos de lenguaje grandes genera patrones de comunicación all-to-all que requieren alto ancho de banda de bisección.[^28] El servicio de inferencia con batching exhibe comunicación más localizada dentro de grupos de GPU que sirven solicitudes. El preprocesamiento de datos puede generar patrones de shuffle con comunicación aleatoria.

Las organizaciones deberían perfilar las cargas de trabajo esperadas para entender los patrones de comunicación. El monitoreo de clústeres en producción revela patrones de tráfico reales para cargas de trabajo existentes. Los nuevos tipos de carga de trabajo pueden requerir estimación basada en análisis de algoritmos o guía del proveedor.

Consideraciones de escala

Clústeres pequeños de decenas de GPU pueden no requerir optimización sofisticada de topología. Un único switch de alto radix conectando todas las GPU proporciona conectividad completa sin complejidad multi-nivel.[^29] La selección de topología importa más para clústeres que abarcan cientos a miles de GPU donde los costos de switching y las tiradas de cable se vuelven significativos.

El crecimiento futuro afecta la selección de topología. Un fat-tree escala agregando switches leaf y servidores mientras mantiene ancho de banda de bisección completo. Un dragonfly escala agregando grupos pero puede requerir rebalanceo de enlaces globales. Planificar para el crecimiento evita cambios de topología que interrumpan las operaciones.[^30]

Factores económicos

Los costos de switches y cables varían significativamente entre topologías. Fat-tree requiere más switches que dragonfly a escala equivalente. Los diseños optimizados por rail reducen el switching InfiniBand pero requieren sistemas NVLink Switch.[^31] El análisis de costo total debe incluir switches, cables, ópticas, energía, enfriamiento y espacio en rack.

Los costos operacionales también varían. Las topologías complejas requieren capacidades de monitoreo y resolución de problemas más sofisticadas. Entrenar al personal de operaciones en consideraciones específicas de topología agrega costo. Las topologías más simples pueden justificar compensaciones de rendimiento modestas a través de carga operacional reducida.

Implementación y despliegue

La implementación de topología de red requiere planificación cuidadosa que abarca infraestructura física, configuración de switching y pruebas de validación.

Planificación de infraestructura física

Los despliegues de red de alta velocidad requieren cableado estructurado que soporte miles de conexiones a 400 Gb/s o más.[^32] El enrutamiento de cables debe minimizar las violaciones de radio de curvatura y la degradación de señal. Los arreglos de pasillo caliente/pasillo frío deben acomodar las rutas de cables sin ob

[Contenido truncado para traducción]