O problema que ninguém quer admitir

Você tem 1.000 GPUs. Tem 150 pesquisadores. A demanda é 2-3x maior que a capacidade. Seu scheduler baseado em prioridade acabou de criar um mundo onde 100% dos jobs são marcados como HIGH, usuários "estacionam" workloads ociosos para reservar GPUs, e seus engenheiros de plantão passam a maior parte do tempo negociando desligamentos em vez de resolver problemas.

Isso é a clássica tragédia dos comuns rolando na infraestrutura de IA. O time de infra do Ai2 publicou recentemente um relato detalhado de como substituiu o scheduler por prioridade por um sistema baseado em orçamentos de tempo de GPU, alocação fair-share hierárquica e um contrato de time-slicing. Os resultados valem ouro para quem opera compute compartilhado.

A pirâmide de métricas

O Ai2 organiza a saúde do cluster em quatro camadas:

  1. Disponibilidade – O hardware está saudável?
  2. Ocupação – O tempo disponível está atribuído a algum workload?
  3. Impacto – Os workloads mais valiosos estão recebendo recursos?
  4. Utilização – A GPU está de fato ocupada durante a vida do workload?

A maioria dos times otimiza disponibilidade e ocupação. O difícil é o impacto — e é aí que a política de agendamento entra. Para uma visão complementar de como workloads agênticos estão mudando as demandas de infra, dá uma olhada na nossa análise de function calling on-device com Google AI Edge Gallery.

GPU cluster server racks with scheduling hierarchy diagram overlay showing budget-based allocation Algorithm Concept Visual

A solução: orçamentos, fair-share e um contrato

Passo 1: Troque GPUs por orçamentos de tempo de GPU

Em vez de dar monopólios de GPUs para times (o que causava capacidade ociosa por causa da sazonalidade da pesquisa), o Ai2 aloca frações de tempo de GPU. Gerentes agem como investidores: antes dos workloads existirem, decidem quanto financiar cada esforço de pesquisa com base no impacto esperado.

Insight chave: toda requisição de tempo de GPU precisa ser financiada por um orçamento, ou não fica protegida de preempção. Nada é de graça. Ficar "estacionado" agora custa o orçamento do seu próprio time.

Passo 2: Scheduler fair-share hierárquico

O scheduler rastreia ocupação numa janela deslizante (padrão: 7 dias) e ordena workloads de alocações subutilizadas acima das sobreutilizadas. O algoritmo não é novo — vem do Hadoop Fair Scheduler (2009) e é usado no Fair Tree do SLURM e no YARN. O que é novo é a entrada: a árvore espelha a estrutura do programa de pesquisa, e os pesos são orçamentos definidos por gerentes, não cotas estáticas.

# Lógica simplificada de ordenação fair-share (conceitual)
# Cada alocação tem um peso (orçamento) e uso real na janela de lookback

alocacoes = {
    'projeto_a1': {'orcamento': 0.35, 'uso': 0.28},  # subutilizado
    'projeto_b2': {'orcamento': 0.20, 'uso': 0.25},  # sobreutilizado
    'projeto_c3': {'orcamento': 0.45, 'uso': 0.47},  # sobreutilizado
}

# Ordena workloads: alocações subutilizadas ganham prioridade
def chave_fair_share(alloc):
    # Menor razão = maior prioridade
    return alloc['uso'] / alloc['orcamento']

ordenadas = sorted(alocacoes.items(), key=lambda x: chave_fair_share(x[1]))
# Resultado: projeto_a1 (0.8) > projeto_c3 (1.04) > projeto_b2 (1.25)
print(ordenadas)

Passo 3: O contrato de agendamento

Cada workload declara um runtime mínimo — a menor ocupação necessária para fazer progresso real. Durante essa janela, fica protegido de preempção. Depois, o scheduler pode rebalancear, re-enfileirando automaticamente workloads resumíveis. Usuários podem setar runtime mínimo zero para trabalho totalmente preemptível e não alocado.

O ciclo de vida do workload:

  1. Submete com runtime mínimo e flag de resumibilidade.
  2. É agendado por fair-share, ponderado pela razão ocupação/orçamento.
  3. Roda pelo runtime mínimo (cobrado do orçamento).
  4. Pode continuar se a alocação ainda prioriza ele (também cobrado).
  5. Pode ser preemptado e re-enfileirado (volta ao passo 2).
  6. Completa, liberando recursos.

Os resultados

  • 98% das horas de GPU devidas foram entregues em 30 dias; 13 de 15 times receberam ≥95%.
  • Ocupação manteve-se em 98% antes e depois, com demanda ainda 2-3x a capacidade.
  • Espera p90 de workloads de debug: 2 horas → 30 segundos.
  • Espera mediana na fila do maior cluster H100: 5 min → 24 seg.
  • Reparos on-call com intervenção humana: queda de 74%.
  • 18% do tempo entregue foi não alocado — absorvendo descompassos de demanda.

Para uma tendência relacionada em como serverless knowledge e MCP estão remodelando a infra de agentes, confere nosso breakdown do Foundry IQ serverless preview.

Developer analyzing fair-share scheduling metrics and GPU utilization dashboards on multiple monitors Coding Session Visual

Limitações e armadilhas

O que não funcionou

  • Sessões interativas sofreram. Pesquisadores costumavam manter sessões de dev por até uma semana. O time-slicing impôs um teto de 8 horas no runtime protegido, após o qual sessões ficavam preemptíveis. Perder estado volátil doeu. O Ai2 agora está construindo um cluster CPU-only para sessões de dev e sessões restauráveis.
  • A curva de aprendizado foi mais íngreme que o esperado. Rollout incremental significou que clusters diferentes se comportavam diferente. Terminologia antiga (tipo "priority") persistiu nas interfaces com significados mudados. Documentação sozinha não resolveu — sessões explicativas ao vivo resolveram.
  • Fragmentação de capacidade é um problema emergente suspeito. Proteção de runtime mínimo pode reduzir a capacidade do scheduler de interromper muitos jobs de uma vez para encaixar um workload grande pendente, potencialmente aumentando esperas para os maiores jobs. O Ai2 está usando simulações para investigar.

Considerações críticas

  • Revisão de orçamento é um processo político. Sair de negociação caso-a-caso para orçamento administrativo é uma melhoria, mas centraliza poder nos gerentes. O sistema assume que gerentes têm o maior contexto sobre tradeoffs — o que nem sempre se sustenta.
  • Acurácia de simulação importa. As previsões do Ai2 foram direcionalmente corretas mas erradas por uma ordem de magnitude em alguns casos (previu 6h→5min para debug; real 2h→30s). Simulações são necessárias mas não suficientes.
  • A janela de 7 dias é um knob ajustável. Curta demais e times com picos passam fome; longa demais e o sistema responde devagar a mudanças de prioridade.

Próximos passos para quem quer aprender

  • Estuda o paper original do Dominant Resource Fairness (Ghodsi et al., 2011) para a base teórica.
  • Explora as implementações do Fair Tree do SLURM e do Fair Scheduler do YARN como referência de produção.
  • Constrói um simulador pequeno você mesmo: modela workloads com (gpus, runtime, minimum_runtime, budget) e implementa uma fila fair-share. Você aprende mais com 200 linhas de simulação do que lendo dez papers.
  • Se você opera infra de GPU compartilhada, audita seu scheduler atual pelas três patologias que o Ai2 nomeou: squatting, inflação de prioridade e toil on-call de workloads não-preemptáveis.

Cloud infrastructure visualization of time-sliced GPU workloads across research teams with preemption markers Dev Environment Setup

A conclusão

O insight central do Ai2 é simples mas poderoso: pare de tentar resolver o quebra-cabeça do agendamento diretamente; faça a liderança pensar como investidores. Decida quanto financiar cada esforço de pesquisa com tempo de GPU antes dos workloads existirem, e deixe um scheduler fair-share impor esses orçamentos com um contrato de time-slicing.

Os resultados — 98% de entrega de alocação, 98% de ocupação, esperas de debug caindo de horas para segundos, 74% menos toil on-call — mostram que isso não é só teoria. É um sistema em produção servindo 150 pesquisadores em milhares de H100/B200/B300.

Se você constrói ou opera compute compartilhado para workloads de IA, isso é leitura obrigatória. O write-up completo está disponível como 근거자료 no blog do Hugging Face.

Leitura relacionada:

Este conteúdo foi elaborado com o auxílio de ferramentas de IA, com base em fontes confiáveis, e revisado pela nossa equipe editorial antes da publicação. Não substitui o aconselhamento de um profissional especializado.