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

A conta de GPU virou item de linha no orçamento de qualquer time que roda IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → em produção, inclusive no Brasil, onde instância com acelerador é cara e frequentemente escassa nas regiões locais das nuvens. Um estudo publicado no blog do Hugging Face pela equipe da Dharma AI, intitulado Same Cluster, 33 Points More Utilization: What Changed Was the Order, argumenta algo desconfortável: boa parte do desperdício não está no hardware nem no modelo, está na ordem em que as decisões de alocação são tomadas.

A tese é direta. Os autores construíram um allocator ciente de restrições e o compararam com um escalonador FIFO em sete cenários de benchmark, no mesmo hardware e com os mesmos workloads. A utilização de GPU subiu até 33 pontos percentuais e o priority-weighted output (a produção ponderada por prioridade) subiu em todos os cenários, chegando a 105%. Nada mudou na máquina. Mudou só quem entra primeiro na grade.

A decisão que o FIFO não sabe tomar

O texto começa desmontando o clichê de "manter as GPUs ocupadas". Isso não é uma decisão executável. A decisão real é mais estreita e mais difícil: qual GPU roda qual job, em qual timestep, com qual prioridade. Formalmente, é uma escolha binária por combinação de GPU, job e timestep, e o resultado é uma grade com o nome de um job em cada célula, ou nada.

Quatro tipos de workload disputam essa grade: treinamento, inferência em tempo real, inferência em batch e quantização. Eles se dividem em duas formas de alocação incompatíveis. Treinamento, batch e quantização são "batch-like": uma vez iniciados, precisam de um bloco contíguo de GPUs mantido sem interrupção até terminar. Já a inferência em tempo real é elástica, dirigida por uma curva de demanda que muda a cada timestep. Duas formas incompatíveis brigando pelo mesmo hardware no mesmo instante é o núcleo do problema.

Onde o FIFO sangra sob contenção

O baseline usa uma política razoável quando sobra folga: inferência em tempo real servida a partir de uma reserva fixa e todo o resto colocado por ordem de chegada. O problema aparece sob contenção, e custa de duas maneiras.

A primeira é a reserva. Como um escalonador por ordem de chegada não tem mecanismo para liberar GPUs num vale de tráfego e reclamá-las antes do próximo pico, a única forma de garantir disponibilidade é reservar o pico máximo do dia inteiro. Uma aplicação que precisa de seis GPUs ao meio-dia e duas às 4h segura as seis por 24 horas. As quatro ociosas ficam indisponíveis para qualquer batch. É por isso que o baseline fica perto de metade do cluster em cenários dominados por reserva (51,6% no controle misto, 53,6% no caso pesado em treino).

A segunda é a ordem em si. Sob contenção real, quais jobs cabem depende da sequência de colocação, não só de quanta capacidade existe. O FIFO coloca cada job na chegada, sem pesar o quanto ele vale nem checar o que ainda precisa caber no horizonte. Resultado: trabalho de alta prioridade espera atrás de quem pediu primeiro, e capacidade fica comprometida em posições que jobs posteriores não conseguem usar. A analogia que os autores usam é boa: é como uma companhia aérea dando aeronaves para quem ligou primeiro e descobrindo que não sobrou avião para a rota que realmente paga.

O que o allocator faz de diferente

A correção tem dois movimentos. A demanda de tempo real passa a ser tratada como curva, não como teto: aloca-se contra a demanda de cada timestep, com o trabalho batch ocupando os vales, limitado por um teto de quantas GPUs um job de tempo real pode trocar entre timesteps consecutivos. E os jobs batch-like são colocados por prioridade ao longo de todo o horizonte, não por ordem de chegada.

O modelo formal define cinco restrições para uma alocação legal: no máximo um job por GPU por timestep; respeito à faixa de demanda com o que já roda sendo herdado e mantido; blocos contíguos dimensionados em potência de dois; teto de swap para tempo real; e nada iniciado pode ser interrompido. A função objetivo tem dois termos: alocar GPU a um batch rende recompensa igual à prioridade vezes um peso de decaimento temporal; não atender demanda de tempo real gera penalidade proporcional ao déficit.

O detalhe que costura tudo: o peso da penalidade de tempo real é de 5 a 10 vezes maior que o peso de alocação. Uma unidade de demanda de tempo real não atendida custa o que 5 a 10 GPU-timesteps de batch de prioridade equivalente custam. É essa assimetria que torna seguro emprestar GPU ao batch no vale, porque subatender tempo real depois é tão caro que a penalidade, e não uma reserva estática, protege a disponibilidade. O peso temporal decai porque, na próxima rodada de escalonamento, novos jobs terão chegado: capacidade usada agora vale mais que capacidade prometida depois.

Heurística no caminho quente, modelo formal atrás

Alocação combinatória disso é NP-difícil, e o escalonador é reinvocado a cada chegada de job, então a resposta precisa voltar no intervalo entre duas requisições de API. Por isso a arquitetura coloca uma heurística no hot path e o modelo formal atrás, como especificação. A heurística não é um greedy genérico: suas regras são as restrições estruturais do modelo, então toda grade que ela produz é legal por construção. Roda em 1 a 2 ms nos cenários contendidos e em 15 ms com 64 GPUs e 30 jobs. Há dois modos: o fast devolve a grade da heurística; o full usa essa grade como ponto de partida para o modelo formal tentar melhorá-la, indicado para revisão periódica.

Os números, e o cenário que separa ocupação de valor

Os sete resultados publicados:

• Controle misto (8 GPUs, 10 jobs): 51,6% → 72,4%, valor +54,8%, 1 ms
• Contenção de tempo real (8 GPUs, 8 jobs): 75,0% → 80,2%, +24,6%, 1 ms
• Pesado em treino (8 GPUs, 16 jobs): 53,6% → 87,0%, +105,1%, 2 ms
• Misto grande (14 GPUs, 16 jobs): 76,8% → 82,7%, +43,8%, 2 ms
• Sobrescrito (8 GPUs, 9 jobs): 85,4% → 87,5%, +33,6%, 1 ms
• Teste de escala (64 GPUs, 30 jobs): 44,9% → 44,9%, +15,9%, 15 ms
• Prioridade uniforme (14 GPUs, 16 jobs): 76,8% → 87,5%, +23,1%, 2 ms

Dois cenários merecem atenção. No teste de escala, FIFO e allocator produzem utilização idêntica (44,9%) e o mesmo throughput (27 de 30 jobs concluídos), mas o allocator entrega 15,9% mais valor ponderado por prioridade. É o argumento central em forma medida: ocupação não diz o que o cluster está ganhando. Dois dashboards idênticos podem esconder saídas materialmente diferentes.

O teste de prioridade uniforme responde ao ceticismo óbvio. Se você força todos os jobs à mesma prioridade, o allocator ainda move a utilização de 76,8% para 87,5% e o valor em 23,1%. Ou seja: o ganho não é só artefato de ordenar por prioridade, planejar as colocações ao longo do horizonte contribui por conta própria.

Previsão de demanda e o horizonte deslizante

Nada disso funciona se os números de demanda estiverem errados, e eles são previsões, não entradas. A Dharma AI usa estimadores especializados por tipo de workload. O forecaster de treino condiciona em 22 features, incluindo uma variável categórica com 10 variantes de treino (LoRA corta parâmetros treináveis em até 10.000× e memória em ~3× contra full fine-tuning; DPO elimina o modelo de recompensa e o loop de amostragem do RLHF). Quantização ganha forecast próprio por tiers de calibração e algoritmo (bitsandbytes, AWQ, GPTQ). Tempo real vira perfil de demanda semanal continuamente recalibrado, sob o mesmo custo de swap que o otimizador aplica, para que previsão e otimizador não briguem entre si.

Contra o erro de previsão, a arquitetura usa horizonte deslizante: otimiza 24 horas, mas commita só o timestep atual e reroda a cada 30 a 60 minutos. O plano das horas seguintes existe apenas para que a decisão de agora saiba que existe futuro, evitando o end-of-world effect. O erro é absorvido pela reotimização em vez de compondo.

O que fica em aberto

Os números são de benchmark sintético construído para contenção genuína, com baseline de ordenação única, não um estudo A/B em produção com tráfego real de um cliente. Para times brasileiros, a lição prática independe de adotar o código da Dharma AI: se seu cluster reserva GPU pelo pico do dia e escalona por chegada, provavelmente há capacidade parada que uma política ciente de prioridade e de forma de bloco recuperaria, sem comprar mais hardware. Onde não vale o esforço é justamente onde o FIFO já é aceitável: cluster com folga, onde tudo cabe independentemente da ordem. A recomendação óbvia é medir sua taxa de contenção antes de trocar o escalonador. Os autores disponibilizam demos e modelos open-source no Hugging Face para quem quiser reproduzir os cenários.

Fonte: Hugging Face Blog