Ai2 rediseña el scheduler de sus clusters GPU y reduce 74% las reparaciones manuales

El problema: cuando el scheduler se convierte en una pelea por un recurso escaso

En el Allen Institute for AI (Ai2), la demanda de GPUs duplica o triplica la capacidad disponible en cualquier momento. El equipo de infraestructura de IA, responsable de miles de NVIDIA H100, B200 y B300 repartidos en clusters de entre 88 y 1.024 GPUs, atiende a unos 150 investigadores internos que entrenan modelos de lenguaje, modelos visión-lenguaje, simulación de robótica por reinforcement learning y agentes científicos.

Antes, el scheduler priorizaba por niveles (HIGH, MEDIUM, LOW) y permitía que los workloads se declararan no preemptables. El resultado fue un caso教科书 de tragedy of the commons que el equipo documenta con crudeza:

• Squatting de GPUs: investigadores dejaban workloads vacíos corriendo «por si acaso» para poder debuggear con baja latencia, porque lanzar un job nuevo tardaba demasiado.
• Inflación de prioridad: eventualmente, el 100% de los workloads corrían en HIGH priority, lo que vació de GPU time a los niveles bajos.
• Toil de on-call: como la preemption era opcional, los ingenieros pasaban la mayor parte de sus tickets negociando apagados manuales de jobs no preemptables en hosts con problemas de hardware.

Según recoge el post original de Ai2, esa «jaula perfecta» para observar la tragedia de los comunes ya la había descrito en 2011 Ghodsi et al. en el paper de Dominant Resource Fairness, con la anécdota de una search company donde los usuarios metían while True para inflar la utilización y conservar sus máquinas dedicadas. El hardware cambia; el problema no.

La solución: convertir la asignación de GPUs en un debate de inversión, no de operación

Ai2 rediseñó el scheduler alrededor de tres ideas combinadas:

1. Presupuestos jerárquicos de GPU time: cada proyecto recibe un porcentaje del cluster (por ejemplo, Proyecto A1 tiene garantizado 35% de la capacidad), y los managers —lead researcher, principal investigator, program manager o el CEO— deciden cómo distribuirlo. Nada es gratis: si un workload corre, descuenta del presupuesto del equipo.
2. Fair-share jerárquico sobre una ventana deslizante (por defecto, 7 días), inspirado en el Hadoop Fair Scheduler de 2009 y vigente en SLURM Fair Tree y YARN Fair Scheduler. El scheduler ordena los workloads por la relación entre su consumo real y el presupuesto asignado, así un equipo que no usó su cuota esta semana puede hacer un burst la próxima sin perder sus jobs.
3. Contrato de scheduling («time-slicing»): cada workload declara un minimum runtime. Mientras corre ese mínimo, está protegido de preemption; después, el scheduler puede rebalancear y re-encolarlo. Si el usuario pone el mínimo en cero, el job corre «gratis» pero puede ser interrumpido en cualquier momento.

Esa última pieza fue la que destrabó el toil operacional. Cuando un host tiene problemas de hardware, espera a que los workloads alcancen su mínimo y los drena automáticamente, en lugar de pedir a un humano que negocie con cada dueño de job. Las reparaciones que requerían humano en el loop cayeron 74%, según los datos publicados por Ai2.

Qué se mide, qué se gana

El equipo de Ai2 lo ordena en una pirámide de cuatro métricas que se construyen una sobre otra: availability → occupancy → impact → utilization. Su nuevo scheduler ataca la tercera.

Los resultados reportados en producción tras un rollout cluster por cluster iniciado a fines de julio de 2026, sobre un período de prueba de 30 días:

• 98% de las GPU-horas adeudadas fueron entregadas; 13 de 15 equipos recibieron ≥95%, el peor caso 90%.
• Occupancy del cluster se mantuvo en 98% antes y después del cambio, con demanda 2-3x por encima de la capacidad.
• 18% del tiempo de GPU entregado fue no presupuestado (unallocated), lo que mantuvo la occupancy alta cuando los equipos con presupuesto no estaban listos para correr.
• Latencia p90 de jobs de debug: cayó de 2 horas a 30 segundos. La simulación previa predecía una mejora de 6 horas a 5 minutos, así que el resultado real superó la predicción.
• Median queue wait time en el cluster H100 más grande: de 5 minutos a 24 segundos; p90 de 2,8 horas a 1,8 horas.
• Reparaciones manuales (toil de on-call): -74%.

Un usuario del nuevo sistema lo resume así en el post original:

«El nuevo scheduler hace sentir como si tuviéramos un 30% más de compute. Con el anterior, si no usábamos nuestro slot completo, ese compute se perdía. Ahora, si pasa, después podemos hacer burst más allá de nuestra asignación y ver nuestros jobs correr rápido y sin preemption.»
— Chris Clark, investigador en Ai2

El simulador: la pieza que evitó un desastre en producción

Antes del rollout, Ai2 construyó un simulador que toma el log histórico de workloads y deja que el scheduler tome decisiones de preemption y asignación de GPUs en segundos. Con eso probaron configuraciones como la longitud de la ventana de lookback (la dejaron en 7 días) o el tope de minimum runtime (8 horas).

Una hipótesis específica que validaron: los debug workloads —jobs cortos de 1-2 GPUs con mínimo de 15 minutos o menos— debían tener latencia mucho menor que los entrenamientos grandes. La intuición era que un job pequeño «entra» en más huecos del cluster. Los resultados del simulador se cumplieron —y superaron— en producción.

Esa disciplina de simular antes de migrar es la que separa un rediseño de scheduler de una apuesta a ciegas. Para founders que operan infraestructura propia (render farms, inference clusters, finops de entrenamiento) la lección es directa: antes de tocar producción, replica el comportamiento con datos reales y mide.

Lo que NO mejoró: las sesiones interactivas

No todo fue ganancia. Las sesiones interactivas (análisis de datos, prueba de código mientras se escribe) tenían un cap de una semana en el sistema anterior. Con el time-slicing y el tope de 8 horas, los investigadores perdían el estado volátil de la sesión cada vez que eran preemptados.

Ai2 respondió con dos proyectos de roadmap:

• Un cluster solo de CPU junto al almacenamiento on-prem, dedicado a data prep y dev sessions, preservando el cluster de entrenamiento para lo que realmente necesita GPU.
• Sesiones restaurables: el workload se puede interrumpir al final de su minimum runtime para mantenimiento o time-slicing, y restaurarse en otra parte sin que el investigador reconstruya su estado a mano.

Contexto: Ai2 y el stack abierto de Olmo

Este post forma parte de una seguidilla reciente de lanzamientos abiertos de Ai2. El 1 de octubre de 2026 publicaron Olmo-core 3, un stack de entrenamiento para Mixture-of-Experts open source que reportó un salto de 2,7x en throughput sobre su predecesor: pasó de ~19.400 a ~52.000 tokens/segundo por GPU en un MoE de 47B parámetros sobre 8 NVIDIA B300, según TechCrunch y Unite.AI. La misma nota describe que la fundación recibió en agosto de 2025 una iniciativa conjunta de NSF y NVIDIA por US$152 millones para construir modelos multimodales abiertos para investigación científica.

Es decir, Ai2 está liberando no solo pesos y datos (Olmo, Molmo), sino también la capa de infraestructura —entrenamiento, scheduling, paralelismo— que los produce. Para el ecosistema open source es un habilitador: un equipo pequeño con un cluster de H100 puede razonar sobre las mismas decisiones de scheduling que tomó un instituto con 1.024 GPUs.

Qué significa esto para tu startup

Si corres entrenamiento de modelos o cualquier workload costoso de GPU, este caso tiene tres lecciones directas:

• El «más GPU» no es el único eje. Ai2 extrajo un 30% extra de compute efectivo sin comprar una sola B300 más, simplemente eliminando el desperdicio por squatting y por rigidez de prioridades. Antes de pedir presupuesto para hardware, audita cuánto de tu cluster está corriendo «vacío por las dudas».
• Pon precio al recurso. El clic de diseño más importante fue tratar la hora de GPU como presupuesto en vez de como derecho. Traducido a tu startup: un sistema de cuotas (por equipo, por proyecto, por sprint) con un dashboard visible cambia el comportamiento más que cualquier política escrita. El verificador automático de Ai2 —»todo lo que corre descuenta presupuesto»— es replicable con un wrapper sobre cualquier scheduler existente (SLURM, Kubernetes con plugins de fair-share, o el Fair Scheduler de YARN si vienes de Spark/Hadoop).
• Simula antes de tocar producción. El simulador de Ai2 es la diferencia entre un rediseño exitoso y un trimestre perdido. Replica el patrón con tus logs: extrae histórico de submissions, construye un simulador mínimo, y mide latencias, preemption y fairness por equipo antes de migrar a un scheduler nuevo.

Si quieres profundizar en cómo otros equipos open source resuelven el mismo problema, revisa la documentación de SLURM Fair Tree y el paper original de Dominant Resource Fairness (Ghodsi et al., 2011) — son las dos raíces técnicas que Ai2 está reutilizando, con veinte años de mejoras acumuladas.

Fuentes

• Impactful scheduling for GPU clusters (Hugging Face blog, Ai2)
• Ai2 Releases OlmoCore 3: Open MoE Training Stack Delivers 2.7x Throughput Gain (TechTimes)
• Ai2 Releases Olmo-Core 3, Open Training Stack for Trillion-Parameter MoEs (Unite.AI)

Artículos relacionados:

Ai2 publica Olmo-core 3: 2,7x más rendimiento en MoEs AstaBrief 8B: informes con citas 3,5× más rápidos y open source Ai2 libera AstaBrief: 8B open para reportes de investigación Olmo 3.1 de AI2: open source y RL para startups tech Eyot: el lenguaje que trata al GPU como un hilo