Treino e inferência na mesma GPU: quatro formas de partilhar 10 mil aceleradores

O erro comum é enquadrar o problema como "treino versus inferência". Não é uma disputa entre workloads, é uma disputa entre dois regimes de demanda que nunca se alinham no tempo. Treino é batch: chega em lote, quer 64 cartões por dias, tolera esperar na fila e tolera ser interrompido se houver checkpoint. Inferência é online: chega em curva de tráfego, quer latência p99 previsível, não tolera esperar e não tolera preempção. Quando cada regime ganha o próprio pool, cada pool é dimensionado para o próprio pico, e a soma dos dois picos é a fatura. Os 35% do CMB antes da mudança são exatamente essa soma: metade da capacidade parada esperando o pico do vizinho.

A decisão de arquitetura, portanto, é quem arbitra a fronteira entre os dois regimes: e com que granularidade. Há quatro respostas honestas:

1. Ninguém arbitra: pools separados, fronteira fixa no provisionamento.
2. Um scheduler aberto arbitra no cluster: Kueue para admissão com quota, KEDA para escalar inferência por métrica, HAMi para fatiar o cartão, Fluid para o dado chegar antes da GPU ficar ociosa. É o desenho do CMB.
3. A AWS arbitra com o mesmo scheduler, embalado: SageMaker HyperPod com orquestração EKS e task governance, que instala Kueue e expõe quota, fair-share e empréstimo como política de console.
4. Serviço gerenciado arbitra fora do cluster: inferência no Bedrock ou em endpoints SageMaker, treino em jobs SageMaker, sem frota própria para partilhar.

O resto do artigo compara as quatro. A resposta não é a mesma para um banco com 10 mil cartões e para uma fintech com 40.

O anúncio nomeia cinco projetos e atribui um papel a cada um. Vale traduzir cada papel para o parâmetro que ele controla, porque é aí que a utilização é ganha ou perdida.

Kueue, admissão com quota: cada time submete a uma LocalQueue no próprio namespace; a LocalQueue aponta para uma ClusterQueue com nominalQuota por ResourceFlavor (um flavor por tipo de cartão, é assim que 10 mil aceleradores heterogêneos viram uma fila só). ClusterQueues no mesmo cohort emprestam quota ociosa entre si até o borrowingLimit, e spec.preemption.reclaimWithinCohort: Any devolve o emprestado quando o dono precisa. O ganho principal é o que o anúncio chama de "não reservar capacidade prematuramente": o job só cria pods quando toda a quota está garantida, então 64 cartões não ficam meio alocados esperando os outros 32.

KEDA, inferência escala por sinal de demanda: um ScaledObject com o scaler prometheus (serverAddress, query, threshold, activationThreshold) escala réplicas de servidor de modelo por profundidade de fila ou tokens por segundo, não por CPU. Quando o tráfego cai, as réplicas somem e a quota volta ao cohort para o treino.

HAMi, o cartão vira recurso fracionário: projeto CNCF Incubating que expõe nvidia.com/gpumem (em MB) e nvidia.com/gpucores além de nvidia.com/gpu, com suporte a NVIDIA, Ascend, Cambricon e outros. É o que deixa cinco tenants de LoRA dividirem uma instância do modelo base, o Twinkle, framework interno do banco, faz isso por padrão e reporta 80% menos aceleradores para o mesmo trabalho.

Fluid, dado antes da GPU: projeto CNCF Incubating com Dataset + runtime de cache (Alluxio, JuiceFS) e warm-up. Checkpoint e modelo já estão no nó quando o pod sobe. GPU esperando o object storage é utilização zero que aparece como 100% "alocado".

Prometheus fecha o ciclo: é a fonte de verdade tanto para o KEDA quanto para o painel que provou os 60%.

Todo ponto percentual de utilização acima de 50% é comprado com isolamento a menos. Num banco, isso não é detalhe, é o que o auditor pergunta primeiro.

Há três mecanismos para colocar dois pods no mesmo cartão, e eles não são equivalentes:

Time-slicing: o device plugin ou o driver DRA anuncia N slots por GPU e o scheduler CUDA reveza. Funciona em toda instância NVIDIA da AWS, não exige hardware, e a documentação da EKS é explícita: não oferece isolamento de memória nem de compute entre os pods. Um tenant com leak de memória derruba o vizinho com CUDA out of memory. Serve para dev e para inferência esparsa; não serve para dois tenants de negócio distintos.

MIG: partição em hardware, até 7 instâncias por A100/H100/H200/B200 (menos nos g7/g7e Blackwell), cada uma com memória, compute e largura de banda dedicados. É o único dos três com isolamento de falha em hardware, o que PCI-DSS ou uma trilha de BACEN 4.893 aceita sem discussão. O preço: a partição é estática por nó (nvidia.com/mig.config.state precisa estar success) e só existe na família P e nos Blackwell G.

HAMi: virtualização em software com limite de memória e de cores por pod, imposta onde o backend do dispositivo permite. Mais fino que MIG (qualquer fração, não só 7 perfis), mais seguro que time-slicing (o limite existe), e o único dos três que fala com aceleradores não NVIDIA, relevante para o CMB com frota heterogênea, menos para quem está 100% em EC2. Isolamento de falha continua sendo de software.

A regra que uso: MIG para inferência multi-tenant com SLO, HAMi ou time-slicing para fine-tuning LoRA e experimentação, cartão inteiro para pré-treino. A opção B deixa você escolher por ResourceFlavor; a opção C só oferece MIG ou cartão inteiro. Se o seu caso é "cinco tenants de LoRA numa base", isso decide.

Os diagramas de plataforma unificada mostram o caminho feliz. Os dois incidentes que eu já vi acontecer ficam fora do desenho.

Preempção sem checkpoint. Quando a inferência escala às 9h e o cohort reclama a quota emprestada, o Kueue evicta o job de treino que estava usando GPU alheia. Se o job não grava checkpoint a cada N passos, ele perde tudo desde o início, e no dia seguinte alguém vai pedir para "desligar essa preempção", o que devolve a plataforma aos 35%. A configuração que evita isso não é no Kueue; é no job: checkpoint em intervalo curto o bastante para que o retrabalho médio fique abaixo de 15 minutos, gravado no cache do Fluid com write-back para S3. No Kueue, withinClusterQueue: LowerPriority protege o treino de ser interrompido por outro treino do mesmo time; reclaimWithinCohort: Any diz que quota emprestada pode voltar a qualquer momento. As duas linhas juntas são o contrato.

Escala que oscila. KEDA com threshold justo e cooldownPeriod curto produz flapping: réplicas sobem, o treino é preemptado, o tráfego cai, réplicas descem, o treino reinicia do checkpoint, o tráfego sobe. Cada ciclo custa um cold start de modelo (dezenas de segundos para pesos de 30 GB sem cache) e um retrabalho de treino. Use activationThreshold acima de zero para não acordar réplica com ruído, e cooldownPeriod da ordem de minutos, não segundos.

Dado frio. Sem Fluid ou equivalente, o pod de inferência nasce, pede 30 GB de pesos ao S3 e fica dois minutos alocado com 0% de uso. No painel isso conta como "GPU em uso". É a diferença entre utilização alocada e utilização real, meça DCGM_FI_DEV_GPU_UTIL, não o requests do pod.