A Dharma AI publicou benchmarks mostrando um alocador de GPU ciente de restrições superando um scheduler FIFO em até 33 pontos percentuais de utilização e 105% em saída ponderada por prioridade em hardware e cargas de trabalho idênticas em sete cenários. A única variável era a ordem em que as decisões de alocação eram tomadas.

Em um cluster multi-tenant executando treinamento, inferência em tempo real, inferência em lote e jobs de quantização simultaneamente, duas formas de alocação incompatíveis competem pelo mesmo hardware. Jobs de treinamento, inferência em lote e quantização precisam de blocos contíguos de GPU mantidos sem interrupção. Inferência em tempo real é elástica: a demanda muda a cada timestep conforme o tráfego cresce e diminui. Um scheduler FIFO não tem mecanismo para reconciliar essas formas sob contenção.

O primeiro custo é a reserva. Como FIFO não pode liberar e recuperar GPUs entre quedas e picos de demanda, a única forma segura de garantir capacidade para inferência em tempo real é reservar a demanda máxima diária de GPU de cada aplicação durante todo o dia. Uma aplicação precisando de seis GPUs no meio do dia e duas às 4 da manhã mantém todas as seis 24 horas por dia. As quatro GPUs ociosas ficam indisponíveis para jobs em lote durante todas as horas que não são horário de pico. Baselines FIFO chegam a 51,6% de utilização no controle de cargas mistas e 53,6% no cenário pesado em treinamento—aproximadamente metade do cluster sentada ociosa.

O segundo custo é a ordenação. Sob contenção real, quais jobs se encaixam no horizonte de scheduling depende da sequência de posicionamento, não meramente da capacidade disponível. FIFO confirma capacidade em ordem de chegada sem verificar o que mais precisa se encaixar ao longo do horizonte completo. Trabalho de alta prioridade fica atrás de qualquer coisa que chegou primeiro, e a capacidade se bloqueia em posicionamentos de baixo valor que obstruem jobs que realmente importam. A decisão principal é uma escolha binária por combinação (GPU, job, timestep)—uma grade, não uma fila—e FIFO não resolve esse problema.

O alocador ciente de restrições aborda ambos. Para inferência em tempo real, ele trata a demanda como uma curva em vez de um teto, alocando contra tráfego previsto a cada timestep, liberando GPUs durante quedas e recuperando-as antes de picos. A capacidade restante é então preenchida por jobs em lote colocados em ordem de prioridade usando uma visão de horizonte completo do schedule. Nos cinco cenários de contenção, a utilização passou de uma faixa de 52–85% para uma faixa de 72–88%. A saída ponderada por prioridade aumentou em todos os casos, com média de 52% e pico de 105,1% no cenário pesado em treinamento com 8 GPUs, onde a utilização saltou de 53,6% para 87,0%. Ambas as métricas melhoraram simultaneamente em todos os cenários de contenção.

Os dois cenários de controle—execuções de baixa contenção onde a ordem dos jobs não importava—não mostraram diferença significativa entre o alocador e FIFO. A técnica adiciona valor proporcional à contenção, não incondicionalmente.

Uma restrição de implementação: este é um problema de programação linear inteira binária. Em escala, com grandes números de GPUs e horizontes de scheduling longos, a latência do solver importa. O post não publica latência do solver ou parâmetros de comprimento de horizonte, que são as primeiras perguntas que um engenheiro de plataforma terá antes de integrar isso em uma fila de produção. A abordagem é bem documentada para cenários de 8 GPUs; o comportamento de escala para 64 ou 256 GPUs não está estabelecido.

Para líderes de plataforma ainda executando FIFO porque "funciona bem": funciona bem quando o cluster tem folga. Uma vez que reservas de inferência em tempo real consomem mais de um terço da capacidade, a fração ociosa é estrutural e nenhuma quantidade de hardware adicional corrige—você está comprando GPUs para ficarem ociosas durante quedas. Os números da Dharma AI sugerem que reordenar decisões de scheduling, não procurement, é o primeiro movimento correto.