¿Puede un clúster de GPUs producir más sin cambiar de hardware? Un experimento de Dharma AI muestra que sí. La diferencia no estuvo en instalar aceleradores más potentes ni en ejecutar cargas distintas, sino en cambiar el orden en que se toman las decisiones de asignación.
Al comparar un asignador consciente de restricciones con un scheduler FIFO, la utilización mejoró hasta 33 puntos porcentuales y el valor de salida ponderado por prioridad aumentó hasta 105,1%. Las pruebas usaron el mismo hardware y las mismas cargas de trabajo.
El problema no es llenar las GPUs, sino decidir quién las usa
Decir “mantén las GPUs ocupadas” parece sencillo, pero no es una instrucción que un sistema pueda ejecutar directamente. El scheduler debe decidir qué GPU ejecuta cada trabajo, en qué momento y durante cuánto tiempo.
La dificultad aumenta porque cuatro tipos de cargas compiten por el mismo recurso:
- Entrenamiento, que suele necesitar bloques continuos de GPUs durante horas o días.
- Inferencia en tiempo real, cuya demanda cambia con el tráfico.
- Inferencia por lotes, que también requiere asignaciones relativamente estables.
- Cuantización, capaz de consumir horas de GPU mientras otros trabajos esperan.
El entrenamiento, la inferencia por lotes y la cuantización necesitan una forma de asignación rígida: un bloque contiguo de GPUs que no se interrumpa. La inferencia en tiempo real funciona de manera opuesta. Puede crecer durante un pico de tráfico y reducirse durante la madrugada.
¿Ves el conflicto? Si un sistema reserva permanentemente la capacidad máxima para la inferencia, desperdicia recursos durante las horas de baja demanda. Si asigna todo siguiendo el orden de llegada, puede dejar sin espacio a trabajos prioritarios o a tareas que necesitan una cantidad específica de GPUs.
Qué cambia frente a FIFO
El scheduler FIFO coloca los trabajos según el momento en que llegan. La inferencia en tiempo real recibe una reserva fija y el resto de las tareas espera su turno, sin considerar prioridad ni la forma que deberán tener las asignaciones futuras.
Ese enfoque puede funcionar cuando existe capacidad de sobra. Pero cuando hay competencia, el orden deja de ser un detalle y se convierte en una decisión de capacidad.
Una tarea que llega primero puede ocupar un bloque que otra, más prioritaria, necesita después. El resultado es paradójico: algunas GPUs permanecen reservadas o sin uso, mientras trabajos valiosos no encuentran una configuración compatible.
El nuevo asignador analiza todos los trabajos pendientes a lo largo de un horizonte de 24 horas. Así puede decidir qué debe ejecutarse ahora sin cerrar las opciones para las tareas que todavía deben entrar en el plan.
La utilización no depende únicamente de cuántas GPUs existen. También depende de cómo se ordenan las decisiones que determinan quién puede usarlas.
Hasta 33 puntos más de utilización
Dharma AI evaluó el sistema en siete escenarios. En cinco pruebas diseñadas para generar alta competencia, la utilización pasó de un rango de 52% a 85% con FIFO a uno de 72% a 88% con el nuevo asignador.
El caso más llamativo fue el escenario intensivo en entrenamiento, con ocho GPUs y 16 trabajos. La utilización subió de 53,6% a 87%, un aumento de 33,4 puntos porcentuales. El valor ponderado por prioridad aumentó 105,1%, más del doble.
Estos fueron los resultados reportados:
| Escenario | Utilización | Valor | Aumento de valor | Latencia |
|---|---|---|---|---|
| Control mixto | 51,6% → 72,4% | 7.093 → 10.980 | +54,8% | 1 ms |
| Competencia de tiempo real | 75,0% → 80,2% | 3.233 → 4.029 | +24,6% | 1 ms |
| Intensivo en entrenamiento | 53,6% → 87,0% | 8.553 → 17.545 | +105,1% | 2 ms |
| Mixto grande | 76,8% → 82,7% | 13.977 → 20.101 | +43,8% | 2 ms |
| Sobresuscrito | 85,4% → 87,5% | 4.311 → 5.760 | +33,6% | 1 ms |
| Prueba de escala | 44,9% → 44,9% | 44.233 → 51.248 | +15,9% | 15 ms |
| Prioridad uniforme | 76,8% → 87,5% | 25.219 → 31.052 | +23,1% | 2 ms |
La utilización mejoró en seis de los siete escenarios y quedó exactamente igual en la prueba de escala. El valor, en cambio, aumentó en todos.
Más utilización no siempre significa más valor
La prueba de 64 GPUs y 30 trabajos deja una lección importante. FIFO y el asignador terminaron con la misma utilización, 44,9%, y completaron la misma cantidad de trabajos: 27 de 30.
Sin embargo, el asignador produjo 15,9% más valor ponderado por prioridad. En otras palabras, los paneles de monitoreo mostraban una ocupación idéntica, pero el clúster entregaba resultados diferentes.
Esto importa porque una GPU ocupada no necesariamente está generando el trabajo más valioso. Un sistema puede maximizar la ocupación y aun así priorizar mal sus recursos.
El escenario con prioridades uniformes también es revelador. Incluso cuando todos los trabajos tenían la misma prioridad, la utilización pasó de 76,8% a 87,5% y el valor aumentó 23,1%. La mejora no depende únicamente de ordenar por importancia. También proviene de planificar las asignaciones a lo largo del tiempo.
Cómo funciona el asignador
El sistema incorpora cinco restricciones para garantizar que las asignaciones sean legales:
- Cada GPU puede atender como máximo un trabajo en cada instante.
- Cada tarea debe respetar su rango de demanda y conservar los trabajos que ya están en ejecución.
- Las cargas por lotes ocupan bloques contiguos de GPUs, con tamaños basados en potencias de dos.
- Las tareas de tiempo real tienen un límite para la cantidad de GPUs que pueden cambiar entre dos instantes consecutivos.
- Un trabajo que ya comenzó no puede ser interrumpido.
El objetivo combina dos elementos. Asignar una GPU a una tarea por lotes genera una recompensa basada en su prioridad y en el tiempo restante. No satisfacer la demanda de una tarea en tiempo real genera una penalización.
La penalización por demanda no cubierta es entre cinco y diez veces mayor que la recompensa de asignar una GPU a un trabajo por lotes de prioridad equivalente. Esa diferencia protege las obligaciones de latencia sin depender de una reserva estática durante todo el día.
Durante un periodo de baja demanda, una GPU puede pasar temporalmente a una tarea por lotes. Si el tráfico vuelve a crecer, el modelo tiene en cuenta el costo de recuperar esa capacidad y limita cuánto puede cambiar una aplicación entre instantes.
Un horizonte de 24 horas, pero solo una decisión comprometida
El scheduler calcula un plan para las próximas 24 horas, aunque solo confirma la asignación del instante actual. Luego vuelve a ejecutar el proceso cada 30 o 60 minutos con información actualizada.
Este diseño evita un problema conocido como efecto fin del mundo. Un optimizador que solo mira hasta el final de su horizonte puede tomar decisiones aparentemente buenas que provocan un desastre justo después de ese límite.
Aquí, el plan futuro sirve para tomar una mejor decisión ahora, no para bloquear todas las decisiones posteriores. Cada nueva ejecución conserva lo que realmente está funcionando y reorganiza el resto según la demanda actual.
La arquitectura ofrece dos modos:
- Modo rápido: ejecuta la heurística y devuelve una asignación en el camino crítico.
- Modo completo: usa esa asignación como punto de partida para que un modelo formal intente mejorarla, ideal para revisiones periódicas.
La heurística tarda entre 1 y 2 milisegundos en los escenarios con competencia. En la prueba de 64 GPUs y 30 trabajos, tardó 15 milisegundos, una latencia suficientemente baja para ejecutarse cada vez que llega una nueva solicitud.
Los pronósticos también son parte del scheduler
Ningún asignador puede planificar bien si desconoce cuánto durará cada trabajo o cuánta demanda tendrá la inferencia en tiempo real. Esos datos no son certezas: son predicciones.
Por eso Dharma AI utiliza estimadores especializados. El entrenamiento, por ejemplo, depende de factores como el ajuste completo del modelo, LoRA, SFT, DPO, RLHF, RLVR o CPT. El tamaño del modelo por sí solo no permite estimar correctamente la duración ni el número de GPUs necesarias.
El pronosticador de entrenamiento utiliza 22 características e identifica diez variantes concretas de entrenamiento. La cuantización tiene un modelo separado según el número de parámetros y el algoritmo utilizado, como bitsandbytes, AWQ o GPTQ.
En inferencia en tiempo real no se estima cada trabajo de forma aislada. El sistema construye un perfil semanal de demanda a partir del tráfico horario y lo convierte en necesidades de GPU. Ese perfil por demanda reemplaza la reserva fija basada en el pico máximo.
¿Y qué ocurre si el pronóstico falla? La respuesta está en reoptimizar con frecuencia. El sistema no intenta acertar todo el día desde una única ejecución. Actualiza sus decisiones antes de que los errores se acumulen.
La lección para cualquier equipo de infraestructura
Este experimento muestra que optimizar GPUs no significa necesariamente comprar más GPUs. A veces el recurso ya está instalado, pero se desperdicia por reservas rígidas, asignaciones fragmentadas o decisiones tomadas sin mirar el conjunto.
La idea es aplicable más allá de los clústeres de inteligencia artificial. Cuando varias cargas con prioridades y formas distintas compiten por un recurso limitado, el orden de las decisiones puede tener tanto impacto como la cantidad total de capacidad disponible.
En este caso, el hardware no cambió. Tampoco cambiaron las cargas. Lo que cambió fue la disciplina con la que se asignó cada GPU, considerando el presente, el futuro cercano, la prioridad y las restricciones físicas del clúster.
Eso convierte la orquestación en algo más que una tarea operativa. Es una palanca estratégica: puede transformar capacidad reservada o mal distribuida en más trabajos completados y más valor producido.