Mismo clúster, 33 puntos más de utilización: el cambio estuvo en el orden

17 de agosto de 2026. Dharma-AI ha presentado una comparación entre un asignador de GPU diseñado para tener en cuenta las restricciones del clúster y un planificador basado en FIFO, que atiende los trabajos según su orden de llegada. En siete escenarios de referencia, ambos sistemas utilizaron el mismo hardware y ejecutaron las mismas cargas. La diferencia estuvo en el orden de las decisiones de asignación.

El asignador elevó la utilización de las GPU hasta 33 puntos porcentuales y aumentó en todos los escenarios la producción ponderada por prioridad, con una mejora máxima del 105%. La utilización se expresa en puntos porcentuales respecto al resultado de FIFO, mientras que el valor representa el incremento porcentual de la producción ponderada según la prioridad de los trabajos.

El problema que aborda Dharma-AI no consiste simplemente en mantener ocupadas las GPU. La decisión operativa es determinar qué GPU ejecuta cada trabajo, en qué instante y con qué prioridad. El sistema debe generar una asignación para todo el horizonte de planificación, con una tarea o ningún trabajo en cada combinación de GPU y periodo.

En ese espacio compiten cuatro tipos de cargas: entrenamiento, inferencia en tiempo real, inferencia por lotes y cuantización. El entrenamiento, la inferencia por lotes y la cuantización necesitan bloques contiguos de GPU que se mantengan sin interrupciones hasta completar el trabajo. La inferencia en tiempo real funciona de forma distinta: su demanda cambia en cada instante y puede crecer o reducirse según el tráfico.

También existe una heterogeneidad importante dentro de una misma categoría. Para un mismo modelo base, los trabajos de entrenamiento pueden durar desde unas horas hasta varios días y requerir desde una GPU hasta varias decenas. Estas diferencias hacen que el orden de colocación determine qué trabajos caben realmente en el horizonte disponible.

En la configuración FIFO utilizada como referencia, la inferencia en tiempo real se ejecuta con una reserva fija y el resto de los trabajos se coloca según el orden de llegada, sin considerar su prioridad. Cuando existe capacidad sobrante, esta política puede ofrecer resultados similares a otros métodos. El coste aparece cuando el clúster está sometido a competencia.

La reserva fija obliga a apartar durante todo el día la demanda máxima de cada aplicación de tiempo real. Una aplicación que necesite seis GPU al mediodía y solo dos a las cuatro de la madrugada mantiene las seis reservadas durante 24 horas. Las cuatro GPU adicionales no se utilizan durante el valle y tampoco quedan disponibles para trabajos por lotes.

Según el artículo, ese efecto sitúa la línea de referencia cerca de la mitad del clúster en los escenarios donde domina la reserva: la utilización alcanza el 51,6% en el caso de control mixto y el 53,6% en el escenario con predominio del entrenamiento. El problema se combina con la política de ordenación: FIFO puede comprometer capacidad con trabajos que llegan antes, aunque otros trabajos de mayor prioridad deban esperar o ya no puedan encajar.

En cinco escenarios construidos para provocar competencia, el asignador llevó la utilización desde un intervalo del 52% al 85% hasta otro situado entre el 72% y el 88%. El valor ponderado por prioridad aumentó entre un 24,6% y un 105,1%, con una media del 52%. Dharma-AI señala que las dos métricas mejoraron simultáneamente, sin un intercambio entre ocupación y valor que justificara el resultado de FIFO.

El caso más destacado utilizó una carga con predominio del entrenamiento sobre ocho GPU. La utilización pasó del 53,6% al 87,0%, mientras que el valor ponderado por prioridad creció un 105%. La mejora se atribuye a la recuperación de capacidad reservada para los picos de inferencia en tiempo real y a la colocación del resto de trabajos según su prioridad.

El artículo también separa utilización y valor. En una prueba de escala con 30 trabajos y 64 GPU, FIFO y el asignador obtuvieron la misma utilización, un 44,9%, y completaron 27 de los 30 trabajos. Sin embargo, el asignador produjo un 15,9% más de valor ponderado por prioridad. Es decir, los indicadores de ocupación y cantidad de trabajos terminados podían ser idénticos mientras el resultado económico u operativo era diferente.

Para evitar reglas locales insuficientes, el asignador formula el problema de manera global. Entre sus restricciones se encuentran que cada GPU solo atienda un trabajo por instante, que cada tarea respete su rango de demanda y conserve el trabajo ya iniciado, y que las cargas por lotes ocupen bloques contiguos de GPU dimensionados como potencias de dos. Las tareas de tiempo real tienen además un límite para el número de GPU que pueden intercambiar entre instantes consecutivos, y un trabajo iniciado no puede ser interrumpido.

La propuesta trata la demanda de tiempo real como una curva, no como un techo fijo: asigna recursos en cada instante y utiliza los valles para ejecutar cargas por lotes, dentro del límite de cambios permitido. Para los trabajos por lotes, la colocación se realiza según la prioridad a lo largo de todo el horizonte, en lugar de seguir únicamente el orden de llegada.

Fuente: Hugging Face.