Clústeres GPU: cómo repartir capacidad sin inflar prioridades

La respuesta es convertir la capacidad en un presupuesto medible y hacer que la cola compense el uso acumulado, en lugar de confiar en etiquetas como alta o urgente. El 9 de octubre de 2026, Ai2 explicó que sustituyó su scheduler basado en prioridad por tres piezas: presupuestos de tiempo GPU definidos jerárquicamente, fair-share calculado sobre una ventana móvil y un contrato que protege un mínimo de ejecución antes de permitir preempción. La dirección decide por adelantado qué proporción de capacidad financia cada programa; el scheduler prioriza después a los grupos que han recibido menos que su asignación y aprovecha como capacidad no asignada los ciclos que nadie está demandando. Así, un equipo puede ceder temporalmente GPUs sin perder su derecho futuro, mientras un trabajo que ocupa recursos sin avanzar consume el presupuesto de quien lo lanzó. La clave no es una fórmula aislada: es separar estrategia, arbitraje y ejecución para que cada decisión deje evidencia auditable.

La noticia tiene tres días calendario de antigüedad en Lima al publicarse este artículo. Ai2 reporta resultados de su propio entorno —miles de GPUs, cerca de 150 investigadores y demanda de dos a tres veces la capacidad—; no son un benchmark universal. Su aporte transferible es el mecanismo y la forma de evaluarlo. Una startup con ocho GPUs y una plataforma con cientos necesitan escalas distintas, pero ambas pueden distinguir capacidad prometida, capacidad usada, trabajo preemptible y progreso útil.

Una prioridad gratis tiende a inflarse. Si marcar un job como urgente no tiene costo, cada equipo aprende que la única defensa frente a la cola es usar la etiqueta máxima. El scheduler pierde señal y la negociación vuelve al chat, al ticket o a la persona con más influencia. Un presupuesto cambia el incentivo: toda ejecución protegida descuenta tiempo de una asignación visible. Pedir más deja de ser un truco de configuración y se convierte en una conversación explícita sobre impacto, plazo y costo de oportunidad.

El fair-share traduce esa decisión administrativa en orden de cola. En el esquema descrito por Ai2, cada hoja del árbol —programa, proyecto o investigador— tiene una proporción y el scheduler compara uso real con asignación durante una ventana de siete días. Los grupos subatendidos ascienden; los sobre-atendidos ceden. Slurm Fair Tree aplica una idea relacionada al ordenar asociaciones por shares y uso efectivo dentro de cada nivel. El paper de Dominant Resource Fairness añade otra advertencia: cuando CPU, memoria, red y GPU son cuellos distintos, la equidad debe considerar el recurso dominante, no contar jobs como si todos costaran lo mismo.

El contrato de ejecución resuelve el problema temporal. Un job declara cuánto tiempo mínimo necesita para lograr progreso útil y si puede reanudarse. Durante esa ventana queda protegido; después puede ser preemptado y volver a la cola. Sin checkpoint confiable, preemptar convierte equidad en trabajo perdido. Sin límite, un entrenamiento largo congela el reparto. Por eso el contrato debe unir tiempo protegido, estado recuperable y un criterio observable de progreso.

No copie parámetros de otro clúster. Diseñe primero el contrato que su organización puede explicar y verificar. Estas cinco decisiones forman un gate conjunto: si falta una, el scheduler puede optimizar ocupación mientras empeora la entrega real.

Imagine una empresa SaaS con ocho GPUs compartidas por tres iniciativas. El equipo de producto necesita evaluar semanalmente un modelo de clasificación; ingeniería entrena un modelo de recuperación que corre varias horas; investigación explora una arquitectura incierta. El esquema anterior ofrece prioridades alta, media y baja. Al cabo de dos semanas, los tres equipos usan alta: evaluación teme perder su ventana, ingeniería protege un entrenamiento costoso e investigación necesita iterar. La cola ya no expresa estrategia.

Un diseño presupuestado asigna 40% del tiempo a entrega del producto, 35% a plataforma y 25% a exploración, revisado cada mes. Los jobs de debug piden una GPU durante quince minutos y son resumibles por definición. Las evaluaciones reservan ventanas cortas vinculadas a un release. Los entrenamientos declaran checkpoints cada treinta minutos y una protección máxima de dos horas. Si producto no usa su share el martes, investigación aprovecha los ciclos como tiempo no asignado; cuando producto vuelve el miércoles, su deuda de fair-share lo eleva sin expulsar un job antes de su ventana protegida.

El ejemplo es hipotético y no representa un cliente ni un resultado de Wasyra. Su propósito es mostrar que el porcentaje inicial no es la parte difícil. La implementación debe verificar si el checkpoint restaura optimizer, datos, semillas y métricas; si una evaluación con deadline merece una clase aparte; y si CPU, almacenamiento o red impedirán usar las GPUs aunque el scheduler las libere.

Empiece con replay y simulación. Reproduzca al menos cuatro escenarios: demanda normal, una ráfaga de jobs pequeños, un entrenamiento grande que requiere muchos nodos y mantenimiento que obliga a drenar hosts. Compare política actual y propuesta usando las mismas llegadas. Mida por clase p50 y p90 de espera, tiempo hasta primer progreso, trabajo perdido al preemptar, cumplimiento de share cuando existe demanda, starvation y capacidad fragmentada. Una media global puede ocultar que los jobs grandes nunca encuentran un bloque contiguo.

En producción, separe disponibilidad, ocupación, impacto y utilización. Ai2 reportó en una prueba de treinta días 98% de entrega del tiempo adeudado, 98% de ocupación antes y después del cambio, y 18% del tiempo entregado como capacidad no asignada. También observó que el p90 de espera de jobs de debug bajó de dos horas a treinta segundos y que las reparaciones que exigían intervención humana cayeron 74%. Son mediciones del proveedor en su clúster y con su mezcla de trabajo; sirven para entender qué dimensiones observar, no para prometer el mismo resultado.

Defina gates antes del rollout: ningún programa con demanda sostenida puede quedar debajo de su share durante la ventana acordada; la preempción no puede perder más trabajo que el límite aprobado; los jobs con deadline deben cumplir su SLO; y toda excepción debe expirar. Publique un dashboard que explique share, uso, deuda y siguiente oportunidad de ejecución. La explicabilidad reduce teorías informales y permite discutir el presupuesto correcto en vez de culpar a la cola.

Fair-share garantiza una relación entre asignación y uso; no sabe si un experimento es científicamente sólido, si un cliente espera el resultado o si el proyecto debe continuar. Esas decisiones siguen siendo humanas y deben ocurrir durante la revisión de presupuestos. Un árbol mal diseñado puede institucionalizar prioridades antiguas con apariencia matemática. Exija owner, fecha de revisión, hipótesis de impacto y una ruta para reasignar capacidad.

La preempción también redistribuye costo. Checkpoints frecuentes consumen almacenamiento y ancho de banda; checkpoints raros aumentan trabajo perdido. Sesiones interactivas conservan estado volátil que quizá no pueda restaurarse. Ai2 reconoce este límite y planea separar parte de esas sesiones en infraestructura CPU con restauración. Clasifique workloads por capacidad real de recuperación antes de tratarlos como intercambiables.

Finalmente, vigile fragmentación, afinidad y heterogeneidad. Ocho GPUs libres en cuatro hosts no equivalen a ocho GPUs contiguas para un entrenamiento distribuido; una B300 y una H100 tampoco son unidades idénticas. Si el presupuesto usa solo GPU-horas, añada reglas para topología, memoria, energía, región y costo. El modelo de reparto debe representar el cuello dominante que realmente limita el trabajo.

Un clúster compartido necesita dos planos. El plano de portafolio decide qué resultados merecen capacidad y cuánto riesgo acepta; el plano de ejecución convierte esa decisión en orden de cola, protección temporal, preempción y recuperación. Mezclarlos en una etiqueta de prioridad invita a inflación y negociación continua. Separarlos permite medir deuda, explicar decisiones y cambiar presupuestos sin reescribir el scheduler.

Antes de comprar más GPUs, ejecute un replay de demanda real y responda las cinco decisiones: unidad, jerarquía, ventana, contrato y excepción. Si la cola no puede explicar quién recibió menos de lo prometido, cuánto progreso se perdería al interrumpir y qué capacidad quedó ociosa por fragmentación, aún no tiene evidencia para distinguir escasez física de una política defectuosa. Wasyra puede ayudar a diseñar e implementar sistemas de IA a medida, pero el primer entregable debe ser este contrato operativo verificable, no una promesa de utilización perfecta.