Por Qué la Programación Consciente de Topología es Clave para el GB200 NVL72
Los modelos de IA modernos—especialmente LLMs de billones de parámetros y arquitecturas mixture-of-experts—requieren una comunicación masiva y de baja latencia entre GPUs. El NVIDIA GB200 NVL72 ofrece poder exascale en un solo rack, con 72 GPUs Blackwell interconectadas vía NVLink a 130 TB/s. Pero de nada sirve tener hardware potente si tu programador de jobs dispersa las cargas de trabajo a través de dominios de red inconexos.
En clústeres compartidos, la programación ingenua (ej.: el plugin cons_res por defecto de Slurm) trata todos los nodos como iguales, a menudo fragmentando los jobs entre switches. Esto provoca una degradación severa del rendimiento: un job que podría usar todo el ancho de banda de NVLink termina limitado por enlaces inter-switch más lentos. La solución es la programación consciente de topología, que alinea las asignaciones de jobs con la jerarquía física de la red.
NVIDIA y SchedMD colaboraron para introducir el plugin topology/block en Slurm 23.11, diseñado específicamente para sistemas rack-scale como GB200 NVL72 y GB300 NVL72. Este post explica cómo funciona, cómo configurar tamaños de segmento y qué revelan los resultados de simulación sobre los trade-offs de ocupación.
Entendiendo el Plugin Block Topology
El plugin topology/block reemplaza el enfoque de 'mejor esfuerzo' del antiguo topology/tree con una estrategia de asignación determinística en bloques. Agrupa nodos en dominios NVLink (conjuntos de nodos que pueden comunicarse completamente vía NVLink sin cruzar switches).
Parámetros Clave
TopologyBlockSched: Habilita la programación en bloques enslurm.conf.SwitchNames: Define los límites de los dominios (ej.:sw0para dominio 0).SegmentSize: Número de nodos asignados contiguamente dentro de un dominio.
Ejemplo de Configuración
# slurm.conf
TopologyPlugin=topology/block
TopologyBlockSched=yes
SwitchNames=sw0 Nodes=node[01-18]
SwitchNames=sw1 Nodes=node[19-36]
SwitchNames=sw2 Nodes=node[37-54]
SwitchNames=sw3 Nodes=node[55-72]
Cuando un job solicita 32 GPUs (8 nodos), el programador de bloques de Slurm intentará asignar los 8 nodos dentro del mismo dominio NVLink (ej.: sw0). Si no hay suficientes nodos libres, recurrirá a dominios adyacentes, pero solo después de agotar las opciones dentro del dominio.
Reglas Prácticas para el Tamaño de Segmento
| Tamaño del Job (GPUs) | Tamaño de Segmento Recomendado (Nodos) | Ejemplo de Carga de Trabajo |
|---|---|---|
| 128+ | 16 | Entrenamiento MoE |
| 32–64 | 4 | LLM denso grande |
| <32 | 1 | Fine-tuning, inferencia |
Importante: Elige tamaños de segmento que sean potencias de dos para un alineamiento óptimo con la topología NVLink. Tamaños no potencia de dos (ej.: 12 nodos) pueden funcionar, pero prueba la eficiencia de tu carga de trabajo específica.
Resultados de la Simulación: Ocupación vs. Fragmentación
Construimos un simulador Slurm independiente (acelerado en el tiempo, basado en VM) para evaluar estrategias de programación en un clúster GB200 NVL72 de 5,000 nodos ejecutando 15,000 jobs en 7 días, con una tasa de fallo de nodos del 2.5%.
Hallazgos Clave
-
La fragmentación es mínima con
topology/block. Los jobs pequeños (1–18 nodos) tienden a ubicarse en los últimos dos nodos de cada dominio, dejando bloques contiguos más grandes libres para jobs grandes. -
La penalidad de ocupación es de ~1% en comparación con una línea base teórica
noTopo(que ignora las restricciones de topología). Esto significa que puedes lograr una utilización casi óptima sin sacrificar el rendimiento. -
Los jobs grandes se benefician más. Los jobs con ≥32 nodos usando un tamaño de segmento de 16 mostraron una mejora de hasta 2.6× en el rendimiento de entrenamiento (según MLPerf) en comparación con la asignación ingenua.
Política Recomendada: Large_Perf_Custom
- Jobs ≥32 nodos → tamaño de segmento 16
- Jobs <32 nodos → tamaño de segmento 2
- Monitorea la fragmentación semanalmente; ajusta los tamaños de segmento si más del 10% de los dominios tienen una fragmentación >50%
Limitaciones y Precauciones
- No es una bala de plata: Si tu clúster ejecuta muchos jobs diminutos (nodo único), el plugin de bloques puede restringir demasiado y aumentar el tiempo de cola. En esos casos, considera una política híbrida que relaje las restricciones de topología para jobs de menos de 4 GPUs.
- El ajuste del tamaño del segmento requiere experimentación: El tamaño óptimo depende de la estrategia de paralelismo del modelo (FSDP, TP, PP, EP). Usa el simulador para validar antes de implementar en producción.
- Las fallas de nodo pueden romper la continuidad del dominio: El plugin de bloques no reequilibra automáticamente después de fallos. Debes drenar o reemplazar manualmente los nodos fallidos para mantener la integridad del dominio.
Próximos Pasos
- Actualiza a Slurm 23.11+ y habilita
topology/block. - Ejecuta el framework de simulación (disponible en el GitHub de NVIDIA) con el trace de tu carga de trabajo.
- Comienza con tamaños de segmento conservadores (potencia de dos) e itera basándote en los datos de monitoreo.
Para una inmersión más profunda en los algoritmos de programación de segmentos, consulta el post original en el blog de NVIDIA.
Conclusión
La programación consciente de topología ya no es opcional para clústeres de IA exascale. El NVIDIA GB200 NVL72, combinado con el plugin block topology de Slurm, ofrece tanto alto rendimiento como alta utilización—siempre que configures los tamaños de segmento con sabiduría. Nuestras simulaciones muestran que la penalidad de ocupación de las restricciones de topología se puede reducir a ~1%, convirtiéndolo en una victoria clara para cualquier infraestructura de IA seria.
Empieza hoy: revisa tu configuración de Slurm, modela tu carga de trabajo con el simulador e implementa la programación en bloques. Tus horas de GPU—y tus investigadores—te lo agradecerán.