Antes de expandir o pool de GPUs, meça o resultado de cada workload

A fonte parte de uma distinção simples: GPU alocada, GPU ocupada e workload entregando resultado valioso são coisas diferentes. Uma fila crescente de batch pode indicar problema de timing, de capacidade de serving ou de escolha de modelo e hardware, e não necessariamente falta de GPU. Por isso, cada workload deve ter documentados prazo, tempo de execução esperado, requisitos de recursos e se aceita interrupção.

O exemplo prático: quatro GPUs disponíveis das 12h às 17h e quatro jobs de avaliação, cada um com duas GPUs por uma hora. Rodar tudo ao meio-dia exige oito GPUs. Rodar dois jobs às 12h e dois às 13h termina tudo até as 14h, com as mesmas quatro GPUs e o mesmo consumo de oito GPU-horas. Ferramentas como o Kueue servem de ponto de admissão, mas a equipe ainda precisa decidir como representar e aplicar prazos. Para serving, a fonte recomenda teste de carga representativo, mantendo modelo, hardware, configuração e mix de requisições constantes, aumentando a taxa de chegada e observando vazão, qualidade e latência (incluindo tempo até o primeiro token). No custo, o OpenCost fornece a alocação por workload, e a métrica sugerida é o custo por resultado verificado. No exemplo ilustrativo, US$ 2 por hora para 990 resultados qualificados dão cerca de US$ 2,02 por mil, e uma configuração testada a US$ 1,50 cai para cerca de US$ 1,52. A proposta 3915 do OpenCost, que traria telemetria do motor de serving ao modelo de custo, segue como rascunho.

Para quem opera plataforma de GPU em Kubernetes, a leitura é que o pedido de mais capacidade deveria vir acompanhado de prazo, teste de carga e custo por resultado. Sem isso, a expansão pode só esconder um problema de agendamento ou de dimensionamento.