Monitoramento de GPU para cargas de IA e Machine Learning

Cargas de IA e Machine Learning mudaram a equação de capacidade nos data centers brasileiros. Treinar um modelo de detecção de fraude exige horas seguidas de GPU em utilização plena, e cada minuto ocioso vira desperdício direto no orçamento de infraestrutura. Mesmo assim, a maioria das equipes ainda observa GPU com os mesmos dashboards de CPU.

Esse vácuo de visibilidade explica por que tantos projetos de IA travam sem motivo aparente. Sem métricas específicas de GPU, ninguém enxerga o throttling térmico que reduz o throughput, a memória que estoura no meio de um batch ou o gargalo de PCIe que segura o treinamento distribuído.

Este guia mostra como estruturar o monitoramento de GPU em ambientes de IA, do diagnóstico ad-hoc com nvidia-smi até dashboards de produção integrados ao Prometheus. Além disso, aponta os sinais que indicam gargalo, as ferramentas certas para cada estágio de maturidade e como conectar tudo à observabilidade da aplicação.

O que é monitoramento de GPU e por que CPU não basta

Monitoramento de GPU é a prática de coletar, armazenar e analisar métricas que descrevem o estado de utilização, memória, energia e saúde de placas gráficas usadas em workloads computacionais. Em ambientes de IA, isso vai muito além de saber se a placa está acesa.
O monitoramento tradicional de servidores observa CPU, RAM, disco e rede. Por outro lado, uma GPU moderna combina milhares de núcleos CUDA, hierarquia própria de memória, conexões NVLink, sensores térmicos dedicados e instruções especializadas como tensor cores. Cada uma dessas camadas pode virar gargalo de forma independente.

Para times que já maduraram o monitoramento de CPU em servidores Linux, GPU é o próximo recurso a ganhar a mesma disciplina. A diferença é que as métricas, as ferramentas e os modos de falha não têm equivalente direto no mundo da CPU. Por isso, copiar dashboards de CPU para GPU resulta em pontos cegos.

Vale destacar que monitorar GPU é tarefa compartilhada entre infraestrutura, SRE e MLOps. O time de plataforma precisa garantir que o hardware esteja saudável, enquanto o time de modelos precisa saber se a GPU está sendo aproveitada com eficiência durante treinamento e inferência.

Por que cargas de IA e Machine Learning exigem observabilidade dedicada de GPU

O custo por hora de uma GPU NVIDIA H100 alugada na nuvem ultrapassa US$ 5 com facilidade, e clusters on-premises com A100 representam investimento de milhões. Sem visibilidade adequada, é impossível responder à pergunta básica: estou aproveitando essa capacidade?

Treinamento e inferência se comportam de forma muito diferente do ponto de vista de GPU. Um job de treinamento distribuído sobrecarrega memória e interconexão entre placas, enquanto uma inferência em produção depende de latência consistente e baixa variância. Ambos exigem métricas próprias para detectar degradação cedo.

Conforme apontamos no guia de observabilidade para aplicações de LLM, problemas de qualidade de modelo frequentemente nascem na infraestrutura. Uma GPU com throttling térmico produz inferências mais lentas, e o usuário sente isso antes do dashboard de aplicação detectar.

Por isso, equipes que tratam IA com seriedade colocam métricas de GPU lado a lado com KPIs de modelo. Em contrapartida, operações imaturas só descobrem o problema quando o cliente reclama da latência ou o custo do mês estoura o teto previsto.

Métricas essenciais de GPU para acompanhar

A escolha de métricas é o que separa um dashboard útil de um painel decorativo. As métricas abaixo cobrem os quatro eixos críticos: trabalho útil, memória, energia e saúde. Cada uma tem um identificador no DCGM e um equivalente no nvidia-smi para diagnóstico rápido.

Essa lista é o ponto de partida. Em ambientes maduros, é útil somar métricas de ocupação de tensor cores e contadores expostos pela biblioteca NVML para análise de eficiência por kernel. Comece simples, depois aprofunde por workload.

Ferramentas de monitoramento de GPU: nvidia-smi, DCGM e além

Existem três famílias principais de ferramentas para coletar métricas de GPU NVIDIA, cada uma adequada a um estágio diferente. Conhecer as diferenças evita escolher uma solução sobredimensionada para um problema simples ou subdimensionada para um cluster em produção.

Na prática, a recomendação é começar com nvidia-smi para entender o comportamento da carga, evoluir para DCGM Exporter assim que o cluster passa de poucas placas e considerar APMs comerciais quando a operação envolve múltiplos times e ambientes. O comando abaixo é o ponto de partida mais comum:

# Snapshot completo da GPU a cada 2 segundos
nvidia-smi --query-gpu=utilization.gpu,memory.used,temperature.gpu,power.draw \
            --format=csv -l 2

Para uma referência completa de métricas, consulte a documentação oficial do DCGM. Em seguida, decida se o cenário pede o DCGM Exporter como ponte para o ecossistema Prometheus.

Como integrar GPU em uma stack de observabilidade com Prometheus e Grafana

A integração padrão de mercado combina três componentes: o DCGM Exporter coleta métricas das placas e expõe em endpoint HTTP, o Prometheus faz scrape periódico desses endpoints e o Grafana renderiza dashboards. Esse stack tem baixo overhead, é open source e roda em containers.

O docker-compose.yml abaixo sobe o stack mínimo em um host com GPU NVIDIA e driver instalado, suficiente para validar a coleta antes de partir para Kubernetes ou frotas maiores:

services:
  dcgm-exporter:
    image: nvcr.io/nvidia/k8s/dcgm-exporter:3.3.5-3.4.0-ubuntu22.04
    runtime: nvidia
    ports:
      - "9400:9400"
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"

A configuração de scrape do Prometheus aponta para o endpoint do exporter na porta padrão 9400. O intervalo de 15 segundos atende bem a maior parte dos casos:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: dcgm
    static_configs:
      - targets: ["dcgm-exporter:9400"]

Com o stack rodando, o próximo passo é desenhar dashboards alinhados aos KPIs de observabilidade que o time de SRE já acompanha. Reaproveitar dashboards prontos do Grafana Labs acelera a entrega, mas calibrar thresholds com o histórico real do cluster é o que diferencia um painel útil de um painel ignorado. Para times em nuvem pública, vale combinar essa coleta com o monitoramento Azure nativo, garantindo cobertura tanto na camada de plataforma quanto no nível de aplicação.

Sinais comuns de gargalo em workloads de IA e como agir

Diagnosticar gargalo em GPU é diferente de diagnosticar gargalo em CPU. O sintoma típico é throughput abaixo do esperado, e a causa pode estar em quatro lugares distintos: cálculo, memória, interconexão ou térmico. Saber distinguir esses padrões acelera a resolução.

Um workload está compute-bound quando a utilização de SM fica próxima de 100% e a memória está estável. Esse é o cenário ideal para treinamento: a GPU está fazendo trabalho útil. A ação aqui é otimizar o modelo ou aumentar o batch para extrair ainda mais throughput.

Quando o workload é memory-bound, a utilização de SM oscila bastante enquanto o uso de memória encosta no limite da placa. Aumentar o batch piora a situação e leva ao erro CUDA out of memory. A saída é usar gradient accumulation, mixed precision ou reduzir o tamanho do batch. Em treinamento de modelos grandes, vale rever a estratégia de monitoramento de memória RAM do host também, já que swap mata throughput.

O throttling térmico aparece como queda gradual do clock mesmo com utilização alta. A métrica DCGM_FI_DEV_CLOCK_THROTTLE_REASONS revela a causa exata: HW_THERMAL, HW_POWER_BRAKE ou HW_SLOWDOWN. A correção depende do ambiente: melhorar o fluxo de ar no rack, ajustar o power cap ou redistribuir cargas entre nós.

Já o gargalo de interconexão é típico em treinamento distribuído, quando a banda PCIe ou NVLink não dá conta de sincronizar gradientes entre placas. O sintoma é GPU ociosa esperando dados, mesmo com pipeline cheio. A análise da banda PCIe e do tempo gasto em all-reduce confirma o diagnóstico.

Monitoramento de GPU em produção: treinamento, inferência e multi-tenant

Cada modo de uso da GPU tem perfil próprio de métricas e thresholds. Tratar todos da mesma forma resulta em dashboards genéricos que não ajudam ninguém. Conhecer as diferenças permite alertas mais precisos e menos ruído.

No treinamento, a meta é maximizar utilização sustentada e detectar regressões em throughput de exemplos por segundo. O painel típico cruza utilização de SM, uso de memória, temperatura e tempo de step. Quando o cluster passa de uma máquina, vale acompanhar a banda PCIe/NVLink agregada por nó.

Já na inferência em produção, o foco muda para latência e variância. O p95 e o p99 do tempo de resposta são tão importantes quanto a utilização média da placa. A combinação de batching dinâmico com modelos otimizados em formato TensorRT muda completamente o perfil de consumo, então o monitoramento precisa acompanhar essa evolução.

O cenário de multi-tenant ganhou força com vGPU e MIG (Multi-Instance GPU). Nesse modelo, uma A100 ou H100 é dividida em fatias que rodam workloads de equipes diferentes. O monitoramento precisa enxergar consumo por instância, e não apenas o agregado da placa física, para que cada time veja o próprio uso. Em clusters Kubernetes, o monitoramento de Kubernetes aplicado a GPU exige labels específicos no exporter para correlacionar pod, namespace e dispositivo MIG.

Boas práticas para construir uma estratégia de monitoramento de GPU

Construir uma estratégia que sobreviva ao crescimento do cluster pede mais do que instalar exporter. As práticas abaixo são as que mais separam operações maduras de operações reativas em ambientes brasileiros que estão escalando IA.

Primeiro, defina baselines por workload antes de criar alertas. Treinamento e inferência têm padrões distintos, e thresholds genéricos disparam alertas demais ou de menos. Colete duas semanas de histórico, calcule percentis e ancore os alertas em desvios estatísticos, e não em valores absolutos.

Segundo, separe métricas de saúde de métricas de eficiência. Saúde indica se a placa pode falhar (temperatura, erros XID, throttling). Eficiência indica se o investimento está sendo aproveitado (utilização de SM, tensor cores, memória). Cada tipo vai para um painel diferente e tem um público diferente.

Terceiro, integre métricas de GPU com a aplicação. Conectar dashboards de infraestrutura com traces de inferência e métricas de qualidade do modelo é o que entrega valor real. Para entender o conceito por completo, vale revisitar o que é observabilidade e por que ela se aplica também a workloads de IA.

Quarto, prepare o runbook de troubleshooting. Documente passo a passo o que fazer quando um alerta dispara, especialmente para falhas raras como erros ECC ou XID 79. Sem runbook, cada incidente vira investigação do zero.

Por fim, revise a arquitetura a cada nova geração de GPU. H100 mudou métricas que eram padrão na A100, e a próxima geração vai mudar de novo. Plataformas de observabilidade gerenciada aliviam essa carga ao manter integrações sempre atualizadas com os exporters oficiais da NVIDIA e do ecossistema de exporters Prometheus.

Conclusão

Monitorar GPU deixou de ser luxo de hyperscaler para virar requisito básico de qualquer empresa que rode IA com seriedade. A combinação de nvidia-smi para diagnóstico, DCGM Exporter para coleta contínua e Prometheus com Grafana para visualização cobre desde laboratórios de pesquisa até clusters de produção, com baixo overhead e custo de licença zero.

O ponto crítico está em escolher as métricas certas, calibrar thresholds com base no histórico real do workload e integrar tudo à observabilidade da aplicação. Sem essa disciplina, dashboards viram decoração e o investimento em GPU vira desperdício invisível.

A OpServices ajuda equipes brasileiras a estruturar essa observabilidade de ponta a ponta, do hardware ao modelo. Se a sua operação está escalando IA e precisa de visibilidade real sobre o uso de GPU, fale com um especialista da OpServices e descubra como acelerar a maturidade do seu monitoramento.