Monitoramento de GPU: a máquina por trás destes números.

Salvo indicação em contrário na legenda, as leituras desta página vêm de uma única workstation: quatro RTX A4000, com um único modelo carregado em todas elas, ocupadas com o nosso próprio tráfego de teste. Estes são os números que o console mostrava enquanto gravávamos as figs. 1 e 5. Os testes de compatibilidade mais abaixo também usaram uma Quadro RTX 5000, o que está indicado neles.

Os painéis por placa leem o driver da NVIDIA, então fazem parte da instalação Linux. Em um Mac com chip Apple, o app para Mac (beta) mostra o uso da GPU e a memória disponível que o Metal informa, sem leitura de potência.

GPUs: 4 × NVIDIA RTX A4000, 16 GiB cada (Ampere, compute 8.6)
VRAM em uso: 59,4 de 64,0 GiB, um modelo nas quatro placas
PCIe: Gen 4 x16 por placa
Driver: 610.57.04, CUDA 13.3

Carga da GPU, potência e tokens, lidos da fig. 1
Leitura	Na captura	Mediana em carga, 24 h	Pico em 24 h
Utilização da GPU, placa mais ocupada (%)	100	100	100
Potência da GPU, soma das quatro placas (W)	548	530	559
Tokens por minuto (painel de 23 de set.)	não exibido	190 mil	880 mil

Os seus números vão ser diferentes. É para isso que serve medi-los. A linha de tokens é anterior à mudança para tokens por segundo; o painel de estatísticas agora mostra tokens por segundo, e estes números são da captura de 23 de setembro no painel antigo, por minuto.

Um número que ele não consegue medir aparece como “not reported”.

A maioria dos painéis de GPU faz a média de quatro placas em uma linha só e desenha um valor ausente como 0. Este dá a cada placa o seu próprio painel: a temperatura em relação ao ponto de throttling que o driver informa, a potência em relação ao limite da própria placa, clocks, ventoinha, o link PCIe como está negociado agora, e ECC e NVLink quando a placa os tem. Duas placas compradas com dezoito meses de diferença continuam sendo duas placas, e um valor que o driver não fornece é marcado como ausente em vez de desenhado como zero.

Quatro painéis de GPU da página Stats sob carga, um por RTX A4000: utilização de 99 a 100 por cento no estado de energia P2, temperaturas de 79 a 94 graus com o limite de throttling marcado em 100 graus, um aviso de redução térmica em três placas, potência de 134 a 138 de um limite de 140 watts, clocks, versão do driver e do CUDA, link PCIe, NVLink e ECC — **Fig. 5**Os quatro painéis de GPU da mesma página Stats, em tamanho real, capturados durante a mesma carga. Todas as placas estão a 99 ou 100% no estado de energia P2, e três delas, entre 90 e 94 °C, são mantidas pelo driver entre 76 e 84% do clock máximo. Role a imagem para o lado para ver as quatro.

O que é lido onde
Por placa	Temperatura e ponto de throttling, potência e o seu limite, clocks do núcleo e da memória, ventoinha, geração e largura PCIe, ECC, NVLink e o processo do mecanismo que usa a placa
Por host	VRAM em uso, utilização da GPU (a placa mais ocupada), potência (a soma das placas) e tokens por segundo
Por solicitação	Tempo até o primeiro token, latência entre tokens e duração, medidos no proxy da mesma forma para os dois mecanismos

O que cada solicitação está esperando.

A página Stats lista cada solicitação em andamento com a sessão do cliente e a etapa em que ela está: na fila do warden, em prefill (o mecanismo lendo o prompt), pensando, escrevendo uma chamada de ferramenta ou respondendo. Um selo mostra a parcela do prompt que provavelmente está no cache da réplica. Quando um prefill demora mais do que o previsto pela taxa de prefill que o warden aprendeu nesta máquina, a página indica o motivo provável da espera: outros prompts na frente, na mesma réplica; um cache que provavelmente foi descartado; ou lentidão sem causa que o warden consiga identificar. A sessão vem do id que cada ferramenta já envia: Claude Code, Codex, OpenCode e pi sem configuração extra; Hermes e Aider com uma linha de configuração.

A tabela In flight com 14 solicitações ativas, todas da chave agent-farm em um único endereço de cliente. Colunas: token, IP do cliente, sessão, modelo, fase, janela de contexto e tempo decorrido. Seis linhas estão em tool call ou answering e oito em prefill, a maioria com um selo estimando de 94 a 100% do prompt em cache; três prefills têm um selo evict? e dois um selo de ampulheta, 1·r0 e 1·r4. Abaixo da tabela: modelo de prefill de 439 tok/s aprendido de 1132 solicitações, estimativa de cache certa em 57% das vezes, e a taxa de acerto por intervalo ocioso, 68% depois de até 30 segundos caindo para 18% depois de 5 a 15 minutos. — **Fig. 12**Catorze solicitações em andamento na máquina de sete GPUs. Abaixo da tabela está o que o warden aprendeu com as solicitações concluídas: esta máquina faz prefill de cerca de 439 tokens por segundo por solicitação, a estimativa de cache dela acertou 57% das vezes, e uma conversa ociosa por mais de dois minutos geralmente encontra o cache já descartado (20% de acerto depois de 2 a 5 minutos). O nome da chave é fictício e o endereço é um endereço de documentação. Abaixo de 768 pixels de largura, a tabela vira uma lista de blocos. Registrado em 5 de outubro de 2026. Role a imagem para o lado para ver todas as colunas.