El problema que nadie quiere admitir
Tienes 1,000 GPUs. Tienes 150 investigadores. La demanda es 2-3x la capacidad. Tu scheduler basado en prioridad acaba de crear un mundo donde el 100% de los jobs se marcan como HIGH, los usuarios "estacionan" workloads ociosos para reservar GPUs, y tus ingenieros de guardia pasan la mayor parte del tiempo negociando apagados en vez de arreglar cosas.
Esto es la clásica tragedia de los comunes en la infraestructura de IA. El equipo de infra de Ai2 publicó recientemente un relato detallado de cómo reemplazó su scheduler por prioridad con un sistema basado en presupuestos de tiempo de GPU, asignación fair-share jerárquica y un contrato de time-slicing. Los resultados valen oro para cualquiera que opere cómputo compartido.
La pirámide de métricas
Ai2 organiza la salud del clúster en cuatro capas:
- Disponibilidad – ¿El hardware está sano?
- Ocupación – ¿El tiempo disponible está asignado a algún workload?
- Impacto – ¿Los workloads más valiosos están recibiendo recursos?
- Utilización – ¿La GPU está realmente ocupada durante la vida del workload?
La mayoría de los equipos optimiza disponibilidad y ocupación. Lo difícil es el impacto — y ahí es donde entra la política de agendamiento. Para una mirada complementaria de cómo los workloads agénticos están cambiando las demandas de infra, checa nuestro análisis de function calling on-device con Google AI Edge Gallery.
La solución: presupuestos, fair-share y un contrato
Paso 1: Cambia GPUs por presupuestos de tiempo de GPU
En vez de dar monopolios de GPUs a los equipos (lo que causaba capacidad ociosa por la estacionalidad de la investigación), Ai2 asigna fracciones de tiempo de GPU. Los gerentes actúan como inversionistas: antes de que existan los workloads, deciden cuánto financiar cada esfuerzo de investigación según el impacto esperado.
Insight clave: toda solicitud de tiempo de GPU debe ser financiada por un presupuesto, o no queda protegida de preempción. Nada es gratis. Estacionarse ahora cuesta el presupuesto de tu propio equipo.
Paso 2: Scheduler fair-share jerárquico
El scheduler rastrea ocupación en una ventana deslizante (default: 7 días) y ordena workloads de asignaciones subutilizadas por encima de las sobreutilizadas. El algoritmo no es nuevo — viene del Hadoop Fair Scheduler (2009) y se usa en el Fair Tree de SLURM y en YARN. Lo nuevo es la entrada: el árbol refleja la estructura del programa de investigación, y los pesos son presupuestos definidos por gerentes, no cuotas estáticas.
# Lógica simplificada de ordenación fair-share (conceptual)
# Cada asignación tiene un peso (presupuesto) y uso real en la ventana de lookback
asignaciones = {
'proyecto_a1': {'presupuesto': 0.35, 'uso': 0.28}, # subutilizado
'proyecto_b2': {'presupuesto': 0.20, 'uso': 0.25}, # sobreutilizado
'proyecto_c3': {'presupuesto': 0.45, 'uso': 0.47}, # sobreutilizado
}
# Ordena workloads: asignaciones subutilizadas ganan prioridad
def clave_fair_share(alloc):
# Menor razón = mayor prioridad
return alloc['uso'] / alloc['presupuesto']
ordenadas = sorted(asignaciones.items(), key=lambda x: clave_fair_share(x[1]))
# Resultado: proyecto_a1 (0.8) > proyecto_c3 (1.04) > proyecto_b2 (1.25)
print(ordenadas)
Paso 3: El contrato de agendamiento
Cada workload declara un runtime mínimo — la menor ocupación necesaria para hacer progreso real. Durante esa ventana, queda protegido de preempción. Después, el scheduler puede rebalancear, re-encolando automáticamente workloads reanudables. Los usuarios pueden poner runtime mínimo en cero para trabajo totalmente preemptible y no asignado.
El ciclo de vida del workload:
- Se somete con runtime mínimo y flag de reanudabilidad.
- Se agenda por fair-share, ponderado por la razón ocupación/presupuesto.
- Corre por el runtime mínimo (cobrado al presupuesto).
- Puede continuar si la asignación aún lo prioriza (también cobrado).
- Puede ser preemptado y re-encolado (vuelve al paso 2).
- Completa, liberando recursos.
Los resultados
- 98% de las horas de GPU debidas fueron entregadas en 30 días; 13 de 15 equipos recibieron ≥95%.
- Ocupación se mantuvo en 98% antes y después, con demanda aún 2-3x la capacidad.
- Espera p90 de workloads de debug: 2 horas → 30 segundos.
- Espera mediana en la cola del mayor clúster H100: 5 min → 24 seg.
- Reparaciones on-call con intervención humana: caída de 74%.
- 18% del tiempo entregado fue no asignado — absorbiendo desajustes de demanda.
Para una tendencia relacionada en cómo serverless knowledge y MCP están remodelando la infra de agentes, checa nuestro breakdown del Foundry IQ serverless preview.
Limitaciones y trampas
Lo que no funcionó
- Las sesiones interactivas sufrieron. Los investigadores solían mantener sesiones de dev hasta por una semana. El time-slicing impuso un tope de 8 horas en el runtime protegido, después del cual las sesiones se volvían preemptibles. Perder estado volátil dolió. Ai2 ahora está construyendo un clúster CPU-only para sesiones de dev y sesiones restaurables.
- La curva de aprendizaje fue más empinada de lo esperado. El rollout incremental significó que clústeres distintos se comportaran distinto. Terminología vieja (tipo "priority") persistió en las interfaces con significados cambiados. Documentación sola no resolvió — sesiones explicativas en vivo sí.
- Fragmentación de capacidad es un problema emergente sospechoso. La protección de runtime mínimo puede reducir la capacidad del scheduler de interrumpir muchos jobs a la vez para encajar un workload grande pendiente, potencialmente aumentando esperas para los jobs más grandes. Ai2 está usando simulaciones para investigar.
Consideraciones críticas
- La revisión de presupuesto es un proceso político. Pasar de negociación caso-a-caso a presupuesto administrativo es una mejora, pero centraliza el poder en los gerentes. El sistema asume que los gerentes tienen el mayor contexto sobre los tradeoffs — lo que no siempre se sostiene.
- La precisión de la simulación importa. Las predicciones de Ai2 fueron direccionalmente correctas pero erradas por un orden de magnitud en algunos casos (predijo 6h→5min para debug; real 2h→30s). Las simulaciones son necesarias pero no suficientes.
- La ventana de 7 días es un knob ajustable. Muy corta y los equipos con picos se mueren de hambre; muy larga y el sistema responde lento a cambios de prioridad.
Próximos pasos para quien quiera aprender
- Estudia el paper original de Dominant Resource Fairness (Ghodsi et al., 2011) para la base teórica.
- Explora las implementaciones del Fair Tree de SLURM y del Fair Scheduler de YARN como referencia de producción.
- Construye un simulador pequeño tú mismo: modela workloads con (gpus, runtime, minimum_runtime, budget) e implementa una cola fair-share. Aprendes más con 200 líneas de simulación que leyendo diez papers.
- Si operas infra de GPU compartida, audita tu scheduler actual por las tres patologías que Ai2 nombró: squatting, inflación de prioridad y toil on-call de workloads no-preemptibles.
La conclusión
El insight central de Ai2 es simple pero poderoso: deja de intentar resolver el rompecabezas del agendamiento directamente; haz que el liderazgo piense como inversionistas. Decide cuánto financiar cada esfuerzo de investigación con tiempo de GPU antes de que existan los workloads, y deja que un scheduler fair-share imponga esos presupuestos con un contrato de time-slicing.
Los resultados — 98% de entrega de asignación, 98% de ocupación, esperas de debug cayendo de horas a segundos, 74% menos toil on-call — muestran que esto no es solo teoría. Es un sistema en producción sirviendo a 150 investigadores en miles de H100/B200/B300.
Si construyes u operas cómputo compartido para workloads de IA, esto es lectura obligatoria. El write-up completo está disponible como 근거자료 en el blog de Hugging Face.
Lectura relacionada: