Mismo cluster, 33 puntos más de utilización: el orden lo cambió todo

Introducción

En entornos empresariales de IA la limitación real ya no es tanto la potencia de los modelos como la capacidad de aprovechar las GPUs que se tienen. Un experimento reciente comparó un scheduler FIFO con un asignador consciente de restricciones y demostró que, sin tocar el hardware ni los modelos, cambiar el orden de las decisiones de asignación puede recuperar hasta 33 puntos porcentuales de utilización de GPU y aumentar la salida ponderada por prioridad hasta 105%.

Para equipos y tomadores de decisión en América Latina esto importa: muchas organizaciones operan con flotas acotadas de GPUs, por lo que optimizar la asignación tiene impacto directo en costos, tiempos de entrenamiento y en la capacidad de servir inferencia en producción.

El problema formal: no es “mantener las GPUs ocupadas”

Decir “mantener las GPUs ocupadas” suena simple, pero la decisión real es mucho más concreta y compleja: para cada GPU, para cada trabajo y para cada instante de tiempo, hay que elegir si esa GPU ejecuta ese trabajo (o queda libre). Formalmente es una elección binaria por combinación (GPU, trabajo, timestep). El resultado es una matriz que indica qué corre en cada GPU a lo largo del horizonte de scheduling.

En esa cuadrícula compiten cuatro tipos de carga: entrenamiento, inferencia en tiempo real, inferencia por lotes y cuantización. Pero no todos se comportan igual: entrenamiento, inferencia por lotes y cuantización son trabajos “tipo batch”: una vez que comienzan requieren un bloque contiguo de GPUs hasta terminar. La inferencia en tiempo real, en cambio, es elástica: su demanda cambia en cada timestep según el tráfico.

Ese choque entre dos formas incompatibles —bloques ininterrumpidos frente a demanda cambiante— es el corazón del problema. Además, dentro de un mismo tipo hay heterogeneidad: un mismo modelo puede generar entrenamientos que duran horas o días, y que necesitan desde 1 hasta decenas de GPUs.

¿Qué falla con FIFO bajo contención?

El punto de comparación fue un scheduler FIFO: la inferencia en tiempo real se sirve desde una reserva fija, y todos los demás trabajos se colocan en orden de llegada sin considerar prioridad. Cuando el cluster está holgado, el orden no importa: todo cabe. Pero bajo contención el orden se convierte en decisión de capacidad y genera dos costos principales.

1. La reserva para real-time. La inferencia no puede esperar: las GPUs deben estar disponibles justo cuando la demanda las requiere. Un scheduler FIFO, sin mecanismos para liberar y reclamar GPUs en función del ciclo diario, termina reservando para cada aplicación en tiempo real su demanda máxima del día durante las 24 horas. Así, si una app necesita seis GPUs al mediodía y dos a las 4 a.m., las seis quedan bloqueadas todo el día y cuatro de ellas estarán inactivas la mayor parte del tiempo. No están siendo utilizadas, pero tampoco libres para jobs batch.

Ese efecto explica por qué, en dos escenarios donde la reserva domina, la utilización base quedó cerca de la mitad del cluster: 51.6% en un escenario mixto de control y 53.6% en otro con predominio de entrenamiento. El costo existe incluso si no hay contención; la contención sólo lo hace evidente.

2. El orden de asignación. Bajo contención, lo que cabe depende del orden en que se colocan los trabajos. FIFO asigna por llegada sin ponderar valor o prioridad ni revisar qué debe encajar después, de modo que trabajo de alta prioridad puede quedarse atrás de otro que llegó primero. En la práctica esto compromete capacidad en colocaciones subóptimas: recursos comprometidos en tareas de menor valor impiden ejecutar tareas de mayor valor que llegan después.

Estas dos dinámicas se combinan: bloques reservados para picos de inferencia quitan recursos a los batch jobs, y el reparto restante se consume en el orden de llegada, no en el orden de importancia.

Qué cambió el asignador consciente de restricciones

El nuevo asignador elimina ambos comportamientos problemáticos. Sus principios operativos clave son:

• Tratar la demanda en tiempo real como una curva, no como un techo fijo. La asignación se hace por timestep, permitiendo que la inferencia utilice GPUs sólo cuando las necesita y liberando capacidad en los valles para trabajos batch.

• Colocar los trabajos tipo batch por prioridad a lo largo de todo el horizonte temporal, en lugar de por orden de llegada. Eso permite maximizar valor en términos de prioridad ponderada.

• Restringir cuánto puede cambiar la asignación de GPUs para una aplicación real-time entre timesteps consecutivos, evitando swaps excesivos que podrían afectar latencia o estabilidad.

En la práctica eso significa que los picos de demanda usan GPUs sólo en las franjas donde realmente son necesarios, y los periodos de poca carga se llenan con entrenamiento, cuantización o inferencia por lotes según su prioridad.

Resultados del benchmark

El equipo comparó su asignador con un scheduler FIFO en siete escenarios de benchmark, y en cinco de ellos diseñados para generar contención real. Los resultados son contundentes y consistentes:

• En los escenarios con contención, la utilización global subió desde una banda de 52–85% (FIFO) a 72–88% con el asignador.
• La salida ponderada por prioridad aumentó entre 24.6% y 105.1%, con un promedio de mejora del 52%.
• El mejor caso individual fue un workload con predominio de entrenamiento en 8 GPUs: la utilización ascendió de 53.6% a 87.0% y el valor ponderado por prioridad más que se duplicó (105%).
• En suma, en hardware idéntico y con las mismas cargas, el cambio fue solo el orden y la estrategia de asignación, no el hardware.

Es notable que no hubo intercambio entre métricas: en todos los escenarios tanto la utilización como el valor ponderado mejoraron, sin sacrificios aparentes.

Implicaciones prácticas para empresas en América Latina

Para organizaciones en la región con presupuestos de infraestructura más ajustados, estos resultados sugieren una vía de alto impacto para elevar rendimiento sin comprar más GPUs:

• Mejor gestión puede traducirse en ahorro de costos de infraestructura o en capacidad efectiva extra para proyectos prioritarios.
• Equipos de MLOps y operaciones pueden priorizar el desarrollo o adopción de schedulers conscientes de restricciones antes de ampliar flotas.
• En entornos con variación estacional o diaria de tráfico (ej. comercio electrónico, servicios financieros, atención al cliente), tratar la inferencia en tiempo real como curva permite explotar “valles” para entrenamiento y despliegues.

Conclusión

La lección central es que la ordenación en la que se toman las decisiones de asignación es, en sí, una decisión de capacidad. Mejorar la política de scheduling —tratando la inferencia en tiempo real como demanda por timestep y ubicando trabajos batch por prioridad a lo largo del horizonte— recupera capacidad y eleva el valor entregado por las GPUs existentes.

Para quienes gestionan infraestructura de IA en América Latina, esto significa que antes de buscar más hardware vale la pena revisar y modernizar las políticas de asignación: el mismo cluster puede rendir sustancialmente más simplemente reorganizando el orden en que las cargas compiten por recursos.