Mesmo cluster, 33 pontos a mais de utilização de GPU: o que mudou foi a ordem de alocação

A decisão, colocada com precisão

Um grupo de engenheiros brasileiros da Dharma-AI publicou um estudo detalhado sobre gestão de GPUs que coloca números em uma intuição que muitos times de infraestrutura de IA já têm: “manter as GPUs ocupadas” não é uma decisão executável. A decisão real é muito mais específica — qual GPU roda qual tarefa, em qual instante de tempo e com qual prioridade.

O artigo é a segunda parte de uma série que começou com a provocação de que “GPUs ociosas são os novos aviões em solo”. Desta vez, os autores construíram um alocador de GPUs ciente de restrições e o compararam com um escalonador FIFO (primeiro a chegar, primeiro a ser atendido) em sete cenários de benchmark. O resultado central: em hardware idêntico, rodando as mesmas cargas de trabalho, a utilização de GPU subiu até 33 pontos percentuais e a produção ponderada por prioridade cresceu em todos os cenários, chegando a 105% em um deles. “Nada no hardware mudou. O que mudou foi a ordem em que as decisões de alocação são tomadas”, escrevem.

Quatro cargas disputando o mesmo grid

Quatro tipos de carga competem pelo cluster: treinamento, inferência em tempo real, inferência em lote e quantização. Eles se dividem em dois formatos de alocação, e é aí que mora a dificuldade:

• Cargas em lote (treinamento, inferência em lote e quantização): uma vez iniciadas, precisam de um bloco contíguo de GPUs mantido sem interrupção até o fim;
• Inferência em tempo real: elástica, dirigida por uma curva de demanda que muda a cada instante, crescendo e encolhendo conforme o tráfego.

Dois formatos incompatíveis competindo pelo mesmo hardware no mesmo instante é o problema central. Um escalonador FIFO coloca cada tarefa na ordem de chegada, sem pesar o valor daquela tarefa nem verificar o que ainda precisa caber no horizonte — e, para garantir a disponibilidade da inferência em tempo real, a única saída é reservar a demanda máxima do dia inteiro. O custo aparece em todas as horas que não são o pico: uma aplicação que precisa de seis GPUs ao meio-dia e duas às 4h da manhã segura as seis por 24 horas, e as quatro GPUs ociosas ficam indisponíveis para qualquer tarefa em lote o dia inteiro.

O que o alocador faz de diferente

O alocador da Dharma-AI trata a demanda em tempo real como uma curva, e não como um teto, alocando contra a demanda real a cada instante e deixando o trabalho em lote ocupar os vales — limitado apenas por um teto de quantas GPUs uma tarefa de tempo real pode trocar entre instantes consecutivos. Já as tarefas em lote são posicionadas por prioridade ao longo de todo o horizonte, em vez de na ordem de chegada.

O modelo formal define cinco restrições para uma alocação válida: cada GPU serve no máximo uma tarefa por instante; cada tarefa respeita sua faixa de demanda; tarefas em lote ocupam blocos contíguos com tamanho em potência de dois; tarefas em tempo real têm um teto de troca de GPUs entre instantes; e uma tarefa iniciada não pode ser interrompida. A função objetivo combina recompensa por alocar GPU a tarefas em lote (prioridade multiplicada por um decaimento temporal) com penalidade por não atender a demanda em tempo real — e essa penalidade é deliberadamente 5 a 10 vezes maior, o que garante que as obrigações de latência sejam cumpridas dentro da mesma otimização, sem precisar de um autoscaler separado competindo pelas mesmas GPUs.

Os números

Dois testes merecem destaque. No teste de escala (64 GPUs, 30 jobs), FIFO e alocador produziram utilização idêntica (44,9%) e vazão idêntica (27 de 30 jobs concluídos) — mas o alocador entregou 15,9% mais valor ponderado por prioridade. Ou seja, todos os dashboards leem a mesma coisa, e ainda assim o cluster produziu materialmente mais. No teste de prioridade uniforme, forçando todas as tarefas a terem a mesma prioridade, o alocador ainda elevou a utilização de 76,8% para 87,5% e o valor em 23,1% — provando que o ganho não é um artefato de ordenar por prioridade, mas vem do planejamento de posicionamentos ao longo do horizonte.

Previsão de demanda é a base de tudo

Nada disso funciona se os números de demanda estiverem errados. Os autores lembram que um único estimador genérico não basta, porque os quatro tipos de carga têm drivers de custo qualitativamente diferentes. O previsor de treinamento condiciona em 22 features, incluindo uma variável categórica que distingue 10 variantes concretas de treinamento — a diferença entre LoRA (que corta parâmetros treináveis em até 10.000×) e fine-tuning completo muda a duração e a contagem de GPUs por ordens de magnitude. A quantização ganha previsão própria, e a inferência em tempo real é prevista como um perfil de demanda semanal continuamente recalibrado a partir do histórico de tráfego horário.

Para lidar com o fato de que previsões erram, o escalonador otimiza um horizonte de 24 horas, mas compromete apenas o instante atual, re-executando a cada 30 a 60 minutos. Assim, o erro de previsão é absorvido por reotimização em vez de se acumular — e o plano de horizonte vira, ele próprio, um produto de previsão que antecipa riscos de cobertura e janelas ociosas previsíveis.

Por que isso importa agora

Com a explosão da demanda por capacidade computacional para IA, empresas no Brasil e no mundo estão sentindo o custo de clusters subutilizados. O estudo da Dharma-AI mostra que a maior alavanca de eficiência pode não estar em comprar mais GPUs, mas em codificar a disciplina operacional na ordem em que as decisões de alocação são tomadas — a mesma lição que as companhias aéreas aprenderam ao resolver a utilização não com um agendamento ótimo, mas com disciplina na sequência de operações. “As GPUs já estavam instaladas, já estavam comprometidas, já estavam depreciando. O ganho estava em como escolhemos gastá-las”, concluem os autores.