As ferramentas de monitoramento de CPU e memória não se transferem para as unidades de processamento gráfico GPU no Kubernetes com a mesma facilidade. Embora a plataforma normalmente forneça métricas de uso no nível do contêiner ou do Pod, as equipes de plataforma precisam construir, ao compartilhar uma GPU, a maior parte das camadas de visibilidade, alocação e faturamento por conta própria, desde a coleta de dados até a definição da parcela de cada equipe no custo.
A importância do problema decorre do fato de que a GPU normalmente representa o item mais caro da fatura de infraestrutura. A análise indica que o custo de operação não se limita ao preço do nó, mas também inclui o tempo de engenharia necessário para compensar as lacunas de medição, verificar a precisão dos números e impedir que as cargas ultrapassem o que o Kubernetes lhes alocou.
Por que as métricas habituais não são suficientes?
A ferramenta NVIDIA DCGM exporter, por onde muitos operadores começam, fornece por padrão dados no nível do dispositivo físico. Quando um Pod possui uma unidade de GPU completa, isso pode ser suficiente, mas a situação muda ao usar time-slicing ou MPS para compartilhar o dispositivo. Nesse caso, o mesmo valor pode aparecer para cada Pod que utiliza uma GPU, fazendo parecer que três cargas consumiram 300% de uma unidade que não existe fisicamente.
O problema é que os gráficos podem parecer corretos mesmo quando os dados subjacentes não são válidos para atribuição. Assim, as equipes podem criar relatórios e painéis completos com base em números que, na prática, não distinguem os consumidores.
O que muda na prática para as equipes de plataforma?
A GPU também difere da CPU no modelo de alocação de recursos. No Kubernetes, a GPU geralmente aparece como um recurso inteiro, como nvidia.com/gpu: 1, e o agendador não permite lidar com partes fracionárias da maneira habitual usada com processadores. Já o compartilhamento efetivo ocorre abaixo do nível do agendador, por meio de time-slicing, MPS ou MIG, o que torna mais complexa a comparação entre o que a carga solicitou e o que utilizou.
As equipes também precisam de controles independentes para garantir que aquilo que o Kubernetes registrou como alocado corresponda ao que o aplicativo realmente consegue acessar. A variável de ambiente NVIDIA_VISIBLE_DEVICES pode fazer com que, se não for sobreposta por uma configuração adequada, o contêiner enxergue todas as unidades de GPU do nó, mesmo que o agendador tenha alocado apenas uma.
Além disso, a expressão “uso de GPU de 80%” não necessariamente tem um único significado. Ela pode medir apenas a existência de um núcleo em execução durante parte da janela de amostragem, sem esclarecer o consumo de capacidade computacional ou de largura de banda da memória. Em alguns frameworks, como o vLLM, a maior parte da memória da GPU pode ser reservada na inicialização, fazendo com que a memória ou a largura de banda seja um indicador mais importante do que o número geral de utilização.
Faturamento: a memória é mais atribuível do que a computação
A biblioteca NVIDIA NVML pode mostrar a quantidade de memória mantida por cada process, permitindo depois associar o processo ao Pod e à equipe responsável por ele, observando que a soma dos valores não será igual à memória total da placa, devido à parte que o driver reserva para si.
Já a atribuição do tempo de computação entre cargas executadas em paralelo tem precisão limitada. Duas cargas podem parecer estar ativas em 90% cada, sem que as métricas esclareçam qual consumiu 70% da capacidade e qual consumiu 30%. Por isso, a análise propõe o uso da memória da GPU como uma base prática para o faturamento interno, tratando a medição computacional como um indicador operacional, e não como uma referência precisa para a cobrança.
A escolha do modelo de compartilhamento muda os cálculos
O compartilhamento de GPU não corresponde a um único modelo. O time-slicing alterna o uso do dispositivo sem isolamento, o MPS permite executar simultaneamente núcleos de processos diferentes, enquanto o MIG divide o hardware em partes fixas. Ainda assim, os serviços de nuvem podem cobrar pela GPU física inteira mesmo quando apenas uma parte é usada, e as placas das categorias A100 e H100 podem ser divididas em no máximo sete instâncias, de acordo com o material.
Já o Dynamic Resource Allocation (DRA) tende a ser o caminho futuro para o gerenciamento de recursos, mas ainda está em fase de maturação, e as ferramentas ao seu redor, incluindo ferramentas de escalabilidade como o Karpenter, acompanham essa evolução.
Por que esta notícia é importante?
Na AWS, o preço da GPU compatível com MIG mais barata da categoria A100 é de aproximadamente 22 dólares por hora, ou cerca de 14 dólares quando se usa o preço spot, contra aproximadamente 5 dólares por hora para uma instância comparável baseada apenas em CPU, segundo o material. Portanto, um erro na atribuição do uso não representa um pequeno problema contábil, mas pode afetar diretamente as decisões de capacidade, custo e distribuição justa dos encargos entre as equipes.
A conclusão editorial é que executar GPUs no Kubernetes ainda exige um modelo operacional diferente daquele usado para CPU e memória. As equipes de plataforma precisam determinar o que pode ser medido com precisão, estabelecer regras claras para a distribuição de custos e evitar basear decisões contábeis em um indicador geral de GPU que não descreve o consumo real. Por outro lado, a fonte indica que a maturidade do DRA e a divisão do hardware podem reduzir gradualmente essa lacuna, mas o momento em que isso ocorrerá e os limites das ferramentas atuais continuam sendo questões em aberto.