while True<\/code> para inflar la utilizaci\u00f3n y conservar sus m\u00e1quinas dedicadas. El hardware cambia; el problema no.Le\u00edste lo que hace la IA. \u00bfY en tu negocio?En CAR, due\u00f1os de empresa arman en 7 d\u00edas su primer sistema funcionando: que ning\u00fan cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.\ud83d\udc65 Probar 7 d\u00edas<\/a><\/div> La soluci\u00f3n: convertir la asignaci\u00f3n de GPUs en un debate de inversi\u00f3n, no de operaci\u00f3n<\/h2> Ai2 redise\u00f1\u00f3 el scheduler alrededor de tres ideas combinadas: - Presupuestos jer\u00e1rquicos de GPU time<\/strong>: cada proyecto recibe un porcentaje del cluster (por ejemplo, Proyecto A1 tiene garantizado 35% de la capacidad), y los managers \u2014lead researcher, principal investigator, program manager o el CEO<\/a>\u2014 deciden c\u00f3mo distribuirlo. Nada es gratis: si un workload corre, descuenta del presupuesto del equipo.<\/li>
- Fair-share jer\u00e1rquico<\/strong> sobre una ventana deslizante (por defecto, 7 d\u00edas), inspirado en el Hadoop Fair Scheduler de 2009<\/strong> y vigente en SLURM Fair Tree<\/strong> y YARN Fair Scheduler<\/strong>. El scheduler ordena los workloads por la relaci\u00f3n entre su consumo real y el presupuesto asignado, as\u00ed un equipo que no us\u00f3 su cuota esta semana puede hacer un burst<\/em> la pr\u00f3xima sin perder sus jobs.<\/li>
- Contrato de scheduling (“time-slicing”)<\/strong>: cada workload declara un minimum runtime<\/strong>. Mientras corre ese m\u00ednimo, est\u00e1 protegido de preemption; despu\u00e9s, el scheduler puede rebalancear y re-encolarlo. Si el usuario pone el m\u00ednimo en cero, el job corre “gratis” pero puede ser interrumpido en cualquier momento.<\/li> <\/ol> Esa \u00faltima pieza fue la que destrab\u00f3 el toil operacional. Cuando un host tiene problemas de hardware, espera a que los workloads alcancen su m\u00ednimo y los drena autom\u00e1ticamente<\/strong>, en lugar de pedir a un humano que negocie con cada due\u00f1o de job. Las reparaciones que requer\u00edan humano en el loop cayeron 74%<\/strong>, seg\u00fan los datos publicados por Ai2.
Qu\u00e9 se mide, qu\u00e9 se gana<\/h2> El equipo de Ai2 lo ordena en una pir\u00e1mide de cuatro m\u00e9tricas que se construyen una sobre otra: availability \u2192 occupancy \u2192 impact \u2192 utilization<\/strong>. Su nuevo scheduler ataca la tercera. Los resultados reportados en producci\u00f3n tras un rollout cluster por cluster iniciado a fines de julio de 2026<\/strong>, sobre un per\u00edodo de prueba de 30 d\u00edas: - 98% de las GPU-horas adeudadas fueron entregadas<\/strong>; 13 de 15 equipos recibieron \u226595%, el peor caso 90%.<\/li>
- Occupancy del cluster se mantuvo en 98%<\/strong> antes y despu\u00e9s del cambio, con demanda 2-3x por encima de la capacidad.<\/li>
- 18% del tiempo de GPU entregado fue no presupuestado<\/strong> (unallocated), lo que mantuvo la occupancy alta cuando los equipos con presupuesto no estaban listos para correr.<\/li>
- Latencia p90 de jobs de debug<\/strong>: cay\u00f3 de 2 horas a 30 segundos<\/strong>. La simulaci\u00f3n previa predec\u00eda una mejora de 6 horas a 5 minutos, as\u00ed que el resultado real super\u00f3 la predicci\u00f3n.<\/li>
- Median queue wait time en el cluster H100 m\u00e1s grande<\/strong>: de 5 minutos a 24 segundos<\/strong>; p90 de 2,8 horas a 1,8 horas.<\/li>
- Reparaciones manuales<\/strong> (toil de on-call): -74%<\/strong>.<\/li> <\/ul> Un usuario del nuevo sistema lo resume as\u00ed en el post original:
“El nuevo scheduler hace sentir como si tuvi\u00e9ramos un 30% m\u00e1s de compute. Con el anterior, si no us\u00e1bamos nuestro slot completo, ese compute se perd\u00eda. Ahora, si pasa, despu\u00e9s podemos hacer burst m\u00e1s all\u00e1 de nuestra asignaci\u00f3n y ver nuestros jobs correr r\u00e1pido y sin preemption.” \u2014 Chris Clark<\/strong>, investigador en Ai2 <\/blockquote> El simulador: la pieza que evit\u00f3 un desastre en producci\u00f3n<\/h2> Antes del rollout, Ai2 construy\u00f3 un simulador que toma el log hist\u00f3rico de workloads y deja que el scheduler tome decisiones de preemption y asignaci\u00f3n de GPUs en segundos. Con eso probaron configuraciones como la longitud de la ventana de lookback (la dejaron en 7 d\u00edas) o el tope de minimum runtime (8 horas<\/strong>). Una hip\u00f3tesis espec\u00edfica que validaron: los debug workloads<\/strong> \u2014jobs cortos de 1-2 GPUs con m\u00ednimo de 15 minutos o menos\u2014 deb\u00edan tener latencia mucho menor que los entrenamientos grandes. La intuici\u00f3n era que un job peque\u00f1o “entra” en m\u00e1s huecos del cluster. Los resultados del simulador se cumplieron \u2014y superaron\u2014 en producci\u00f3n. Esa disciplina de simular antes de migrar<\/strong> es la que separa un redise\u00f1o de scheduler de una apuesta a ciegas. Para founders que operan infraestructura propia (render farms, inference clusters, finops de entrenamiento) la lecci\u00f3n es directa: antes de tocar producci\u00f3n, replica el comportamiento con datos reales y mide. Lo que NO mejor\u00f3: las sesiones interactivas<\/h2> No todo fue ganancia. Las sesiones interactivas (an\u00e1lisis de datos, prueba de c\u00f3digo mientras se escribe) ten\u00edan un cap de una semana<\/strong> en el sistema anterior. Con el time-slicing y el tope de 8 horas, los investigadores perd\u00edan el estado vol\u00e1til de la sesi\u00f3n cada vez que eran preemptados. Ai2 respondi\u00f3 con dos proyectos de roadmap<\/a>: - Un cluster solo de CPU<\/strong> junto al almacenamiento on-prem, dedicado a data prep y dev sessions, preservando el cluster de entrenamiento para lo que realmente necesita GPU.<\/li>
- Sesiones restaurables<\/strong>: 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.<\/li> <\/ul>
Contexto: Ai2 y el stack abierto de Olmo<\/h2> Este post forma parte de una seguidilla reciente de lanzamientos abiertos de Ai2. El 1 de octubre de 2026<\/strong> publicaron Olmo-core 3<\/strong>, un stack de entrenamiento para Mixture-of-Experts open source<\/a> que report\u00f3 un salto de 2,7x en throughput<\/strong> sobre su predecesor: pas\u00f3 de ~19.400 a ~52.000 tokens\/segundo por GPU en un MoE de 47B par\u00e1metros sobre 8 NVIDIA B300<\/strong>, seg\u00fan TechCrunch y Unite.AI. La misma nota describe que la fundaci\u00f3n recibi\u00f3 en agosto de 2025<\/strong> una iniciativa conjunta de NSF y NVIDIA por US$152 millones<\/strong> para construir modelos multimodales abiertos para investigaci\u00f3n cient\u00edfica. Es decir, Ai2 est\u00e1 liberando no solo pesos y datos (Olmo, Molmo), sino tambi\u00e9n la capa de infraestructura \u2014entrenamiento, scheduling, paralelismo\u2014 que los produce. Para el ecosistema open source es un habilitador: un equipo peque\u00f1o con un cluster de H100 puede razonar sobre las mismas decisiones de scheduling que tom\u00f3 un instituto con 1.024 GPUs. Qu\u00e9 significa esto para tu startup<\/h2> Si corres entrenamiento de modelos o cualquier workload costoso de GPU, este caso tiene tres lecciones directas: - El “m\u00e1s GPU” no es el \u00fanico eje.<\/strong> Ai2 extrajo un 30% extra de compute efectivo<\/strong> sin comprar una sola B300 m\u00e1s, simplemente eliminando el desperdicio por squatting y por rigidez de prioridades. Antes de pedir presupuesto para hardware, audita cu\u00e1nto de tu cluster est\u00e1 corriendo “vac\u00edo por las dudas”.<\/li>
- Pon precio al recurso.<\/strong> El clic de dise\u00f1o m\u00e1s 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<\/a> visible cambia el comportamiento m\u00e1s que cualquier pol\u00edtica escrita. El verificador autom\u00e1tico de Ai2 \u2014”todo lo que corre descuenta presupuesto”\u2014 es replicable con un wrapper sobre cualquier scheduler existente (SLURM, Kubernetes<\/a> con plugins de fair-share, o el Fair Scheduler de YARN si vienes de Spark\/Hadoop).<\/li>
- Simula antes de tocar producci\u00f3n.<\/strong> El simulador de Ai2 es la diferencia entre un redise\u00f1o exitoso y un trimestre perdido. Replica el patr\u00f3n con tus logs: extrae hist\u00f3rico de submissions, construye un simulador m\u00ednimo, y mide latencias, preemption y fairness por equipo antes<\/em> de migrar a un scheduler nuevo.<\/li> <\/ul> Si quieres profundizar en c\u00f3mo otros equipos open source resuelven el mismo problema, revisa la documentaci\u00f3n de SLURM Fair Tree<\/strong> y el paper original de Dominant Resource Fairness (Ghodsi et al., 2011)<\/strong> \u2014 son las dos ra\u00edces t\u00e9cnicas que Ai2 est\u00e1 reutilizando, con veinte a\u00f1os de mejoras acumuladas.
Fuentes<\/h2> - Impactful scheduling for GPU clusters (Hugging Face blog, Ai2)<\/a><\/li>
- Ai2 Releases OlmoCore 3: Open MoE Training Stack Delivers 2.7x Throughput Gain (TechTimes)<\/a><\/li>
- Ai2 Releases Olmo-Core 3, Open Training Stack for Trillion-Parameter MoEs (Unite.AI)<\/a><\/li> <\/ul>Le\u00edste lo que hace la IA. \u00bfY en tu negocio?En CAR, due\u00f1os de empresa arman en 7 d\u00edas su primer sistema funcionando: que ning\u00fan cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.\ud83d\udc65 Probar 7 d\u00edas<\/a><\/div> <\/div><\/div><\/div><\/p>\n \n \n