📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Comprar hardware para IA no es comprar GPUs: es comprar red, cablería y el software que decide dónde se pone cada trabajo. Esta semana me topé con un análisis de SkyPilot que lo deja claro: en los clusters Grace Blackwell de NVIDIA, la diferencia entre un scheduler que entiende cómo está armado el rack y uno que reparte GPUs a lo loco es de hasta 27% de capacidad útil extra. Sin comprar ni una GPU más.
El rack es el nuevo servidor
La generación GB200/NVL72 conecta las 72 GPUs de un rack con una sola tela de NVLink: 18 puertos de 100 GB/s por GPU, 1,8 TB/s por chip y unos 130 TB/s agregados dentro del rack. En la práctica el rack completo se comporta como un acelerador gigante con memoria compartida. ¿Por qué importa? Porque los patrones de comunicación más intensivos del training —el all-reduce del tensor parallelism y el all-to-all del expert parallelism— están en el camino crítico y no se pueden esconder totalmente tras el cómputo.
La cifra de Hugging Face me gustó porque es concreta: mover el training de NVLink a InfiniBand cuesta un 43% de throughput. Y en modelos MoE con expert parallelism alto, la comunicación no optimizada sobre InfiniBand se puede comer hasta un 60% del tiempo de entrenamiento en servidores de 8 GPUs. En NVL72 con 32-way expert parallelism, sirviendo DeepSeek-R1, el salto es de hasta 4,39x de throughput por GPU contra los servidores de 8 GPUs B200.
El placement lo decide todo
El hardware por sí solo no entrega nada. El equipo de GR00T de NVIDIA comparó dos políticas de schedulado durante el pre-entrenamiento de un modelo fundacional para robots, sobre 512 GPUs distribuidas en 128 nodos: la naive repartía nodos entre racks como los encontraba, la consciente del rack puso todo en 8 racks exactos. Resultado: +14,4% de throughput, de 1,59 s a 1,39 s por iteración. En un cluster de 10.000 GPUs ese mismo ahorro son unos 16.700 dólares por hora de training, cerca de 400.000 dólares al día. Por decidir mejor dónde se coloca cada trabajo.
Y viene la parte que complica todo en la vida real: los trabajos terminan en momentos distintos y dejan nodos libres regados entre racks. El cluster tiene la capacidad suficiente, pero esparcida, y cualquier job que necesite un rack entero se queda esperando en la cola. La respuesta que describe SkyPilot es desfragmentación automática: preemptar trabajos que se pueden recuperar desde checkpoint, moverlos a otra parte y liberar un rack completo para el job grande. Los entornos interactivos de desarrollo quedan intactos salvo permiso explícito del administrador.
El principio, no el producto
Lo que me interesa de esto no es NVIDIA ni los clusters de 10.000 GPUs: es el principio. Correr modelos open-weight en servidores propios te enseña rápido que el «no me alcanza el hardware» casi siempre es un «no me alcanza el hardware en este orden«. Cuánto KV cache te cabe depende de dónde viven los pesos; el cuello de botella muchas veces se arregla con colocación, no con compra. En la escala chica igual pasa: el benchmark de vLLM que citan muestra que partir Llama-3.1-70B entre dos H100s dejó 13,9x más bloques de KV cache y 3,9x de throughput. Más memoria libre para cache es más concurrencia y más velocidad, sin tocar el modelo ni el chip.
El take accionable es simple: antes de declarar que «falta GPU», mide. Probablemente falta scheduler.
Fuente del tema: Grace Blackwell needs a new scheduler: 27% more usable GPUs from the same racks, blog de SkyPilot.
Fuente de inspiración: Grace Blackwell needs a new scheduler: 27% more usable GPUs from the same racks
