Dharma AI publicó benchmarks mostrando un asignador de GPU consciente de restricciones superando un programador FIFO en hasta 33 puntos porcentuales de utilización y 105% en salida ponderada por prioridad en hardware y cargas de trabajo idénticas en siete escenarios. La única variable era el orden en el que se tomaban las decisiones de asignación.
En un clúster multi-tenant ejecutando entrenamiento, inferencia en tiempo real, inferencia por lotes e interrupción de trabajos de cuantización simultáneamente, dos formas de asignación incompatibles compiten por el mismo hardware. Los trabajos de entrenamiento, inferencia por lotes y cuantización necesitan bloques contiguos de GPU mantenidos sin interrupción. La inferencia en tiempo real es elástica: la demanda cambia en cada timestep a medida que el tráfico crece y se reduce. Un programador FIFO no tiene mecanismo para conciliar estas formas bajo contención.
El primer costo es la reserva. Debido a que FIFO no puede liberar y recuperar GPUs entre depresiones y picos de demanda, la única forma segura de garantizar capacidad para inferencia en tiempo real es reservar la demanda máxima diaria de GPU de cada aplicación durante todo el día. Una aplicación que necesita seis GPUs al mediodía y dos a las 4 de la mañana retiene las seis durante todo el día. Las cuatro GPUs inactivas no están disponibles para trabajos por lotes durante cada hora que no sea tiempo de pico. Los baselines de FIFO llegan al 51,6% de utilización en el control de carga mixta y al 53,6% en el escenario pesado de entrenamiento—aproximadamente la mitad del clúster inactivo.
El segundo costo es la ordenación. Bajo contención real, qué trabajos se ajustan al horizonte de programación depende de la secuencia de colocación, no meramente de la capacidad disponible. FIFO confirma la capacidad en orden de llegada sin verificar qué más debe ajustarse en todo el horizonte. El trabajo de alta prioridad espera detrás de lo que llegó primero, y la capacidad se bloquea en colocaciones de bajo valor que obstruyen trabajos que realmente importan. La decisión principal es una opción binaria por combinación (GPU, trabajo, timestep)—una cuadrícula, no una cola—y FIFO no resuelve ese problema.
El asignador consciente de restricciones aborda ambos. Para inferencia en tiempo real, trata la demanda como una curva en lugar de un techo, asignando contra el tráfico predicho en cada timestep, liberando GPUs durante depresiones y recuperándolas antes de picos. La capacidad restante se llena con trabajos por lotes colocados en orden de prioridad utilizando una vista de horizonte completo del cronograma. En los cinco escenarios de contención, la utilización se movió de una banda de 52–85% a una banda de 72–88%. La salida ponderada por prioridad aumentó en todos los casos, promediando 52% y alcanzando un pico de 105,1% en el escenario pesado de entrenamiento de 8 GPUs, donde la utilización saltó de 53,6% a 87,0%. Ambas métricas mejoraron simultáneamente en todos los escenarios de contención.
Los dos escenarios de control—ejecuciones de baja contención donde el orden de los trabajos no importaba—no mostraron una brecha significativa entre el asignador y FIFO. La técnica agrega valor proporcional a la contención, no incondicionalmente.
Una restricción de implementación: este es un problema de programación lineal entera binaria. A escala, con grandes números de GPUs y horizontes de programación prolongados, la latencia del solucionador importa. El artículo no publica latencia del solucionador o parámetros de longitud de horizonte, que son las primeras preguntas que un ingeniero de plataforma tendrá antes de conectar esto en una cola de producción. El enfoque está bien documentado para escenarios de 8 GPUs; el comportamiento de escalado a 64 o 256 GPUs no está establecido.
Para líderes de plataforma que aún ejecutan FIFO porque "funciona bien": funciona bien cuando el clúster tiene margen. Una vez que las reservas de inferencia en tiempo real consumen más de un tercio de la capacidad, la fracción inactiva es estructural y ninguna cantidad de hardware adicional la corrige—está comprando GPUs para que estén inactivas durante las depresiones. Los números de Dharma AI sugieren que reordenar decisiones de programación, no adquisiciones, es el primer movimiento correcto.