Explicar as expectativas antes de buscar uma GPU mais potente.

Descrever o problema com um resultado e uma janela

Substitua "a GPU não trabalha" por uma observação verificável: o primeiro resultado chega tarde, as etapas apresentam pausas ou o número de saídas aceitas diminui. Informe o conjunto de entradas, a versão da aplicação, as configurações e o período observado. Uma primeira execução pode incluir fases diferentes de uma execução já preparada; não as misture sem especificar.

Divida o percurso em abertura dos arquivos, preparação da CPU, transferência, cálculo na GPU, escrita e depois validação. Essas fases podem se sobrepor: o desenho é uma hipótese a confrontar com os registros. Anote os limites com o mesmo fuso horário e precisão suficiente. Um gráfico de hardware obtido após a pausa não permite explicar a pausa, mesmo que seu valor pareça incomum.

Ler corretamente as porcentagens e as memórias

No NVIDIA SMI, a utilização da GPU indica a parte do intervalo de amostragem durante a qual ao menos um núcleo estava em execução. Não é uma nota de desempenho de todos os componentes. A utilização da memória descreve sua atividade de leitura ou escrita; ela não deve ser confundida com a quantidade de memória ocupada. A documentação também esclarece que alguns campos podem estar indisponíveis conforme o ambiente.

Portanto, conserve o nome exato da métrica e sua unidade. Uma quantidade elevada de memória pode corresponder a dados mantidos em espera; uma baixa atividade pode aparecer durante uma fase normal de preparação. Por outro lado, uma atividade elevada não estabelece que o programa realize um trabalho útil. É preciso observar as saídas e a progressão da aplicação ao mesmo tempo que o hardware.

Coletar um registro correlacionado e suficientemente curto

Escolha uma sequência representativa e limite a coleta a essa sequência. Registre os horários, o identificador da GPU, a atividade, a memória ocupada e as fases da aplicação. Em paralelo, use as ferramentas disponíveis no seu sistema para observar o processo de CPU, suas esperas, suas leituras e gravações. Uma média sobre todos os núcleos pode mascarar uma única thread saturada; observe também os processos envolvidos.

O comando de leitura abaixo é proposto para um alvo NVIDIA autorizado que já disponha do NVIDIA SMI. Ele não foi executado para este guia. Ele mantém as unidades no CSV e exibe uma observação por segundo até ser interrompido. Verifique os campos suportados pela sua versão e encerre a coleta ao final do cenário. Um campo N/A permanece desconhecido: não o transforme em zero.

O log mínimo relaciona um identificador de trabalho, um horário com fuso, a fase atual, uma entrada ou um lote identificável, o progresso e o eventual erro. Ele não deve conter segredo nem conteúdo de negócio inútil ao diagnóstico. Se a telemetria faltar, verifique primeiro o seu dispositivo de coleta e o progresso da aplicação: uma curva vazia não prova que um processo parou. Marque o período sem observação em vez de reconstituí-lo de memória.

nvidia-smi --version
nvidia-smi --query-gpu=timestamp,uuid,utilization.gpu,memory.used,memory.total --format=csv --loop=1

Diferenciar uma pista de uma conclusão

Se a atividade da GPU cair enquanto a aplicação espera suas entradas, examine o caminho dos arquivos. Se ela cair durante uma preparação de CPU longa, examine essa fase e seu paralelismo real. Se os dispositivos esperarem os outros participantes de um trabalho distribuído, verifique o equilíbrio das cargas e as comunicações. Vários sintomas podem ocorrer juntos; sua correlação ainda não é uma prova de causalidade.

Escreva uma hipótese curta e uma modificação que permita distingui-la. Por exemplo, comparar as mesmas entradas já preparadas com sua preparação habitual pode isolar uma etapa, desde que os resultados permaneçam idênticos. Não altere simultaneamente o tamanho do lote, a precisão, o número de processos e a localização dos arquivos: uma melhoria se tornaria difícil de atribuir.

Exemplo fictício: analisar um loop de cem segundos

A equipe fictícia «Revue des maquettes» descreve um loop sem sobreposição: sessenta segundos de preparação de CPU, vinte de cálculo de GPU e depois vinte de exportação. O total é 100 segundos e a fração temporal atribuída ao cálculo de GPU vale 20/100, ou seja, 20%. Esse cálculo pedagógico não prevê a porcentagem de uma ferramenta de amostragem e não corresponde a nenhuma medição de uma GPU do catálogo.

Suponhamos que a preparação possa ser reduzida a trinta segundos, sem alterar o cálculo nem as saídas. O loop então seria 30 + 20 + 20 = 70 segundos: trinta segundos a menos, com uma fração de GPU de 20/70, ou seja, aproximadamente 28,6%. Por outro lado, dividir hipoteticamente apenas o cálculo de GPU por dois daria 60 + 10 + 20 = 90 segundos. O cenário explica por que tratar a espera mais longa pode pesar mais do que trocar de placa.

Aprofundar uma fase com um profiler

Se a observação geral localiza uma zona lenta sem explicá-la, use o profiler adequado à aplicação em uma janela curta. O PyTorch Profiler pode coletar eventos de CPU e CUDA e organizar janelas de coleta. A documentação indica uma sobrecarga quando o registro de formas ou de pilhas está ativado. Uma trace detalhada é, portanto, um instrumento de diagnóstico; seu tempo total não deve ser apresentado sem ressalvas como o tempo normal do programa.

Mantenha os nomes das fases suficientemente explícitos para relacionar uma operação técnica ao seu trabalho: preparação de um grupo de arquivos, transferência, etapa da aplicação ou publicação de saída. Comece com o nível de detalhe necessário para a hipótese. Após a alteração, refaça uma observação comparável e depois uma execução sem instrumentação pesada. Esse segundo controle permite verificar que o benefício também existe nas condições usuais.

Evitar correções que mascaram o problema

Aumentar a concorrência pode preencher a GPU enquanto sobrecarrega o disco, a memória do host ou as saídas. Aumentar o tamanho dos lotes pode alterar a latência e a memória necessária. Reduzir a precisão pode modificar o resultado. Essas decisões não são proibidas, mas devem ser avaliadas com o mesmo objetivo de negócio, com seus efeitos colaterais, em vez de serem adotadas porque a porcentagem exibida aumenta.

Não reinicialize um dispositivo nem altere seus parâmetros de hardware para diagnosticar uma simples queda de atividade. Comece pela leitura e depois faça com que os erros explícitos sejam examinados pelo responsável autorizado. Evite também publicar traces brutas contendo caminhos privados, parâmetros confidenciais ou dados de entrada. Prepare um trecho útil ao diagnóstico e mantenha a prova completa no escopo autorizado da equipe.

Encerrar o diagnóstico com uma prova útil à decisão

O relatório final deve indicar o sintoma, a hipótese adotada, a alteração testada, suas condições e o resultado observado. Mantenha pelo menos uma comparação antes/depois com o mesmo conjunto de entradas, a mesma qualidade e a mesma definição de fim. Se o resultado não for conclusivo, escreva o que foi eliminado e a próxima observação necessária. Uma pista rejeitada e documentada evita que outra pessoa recomece ao acaso.

Uma atividade baixa normal nem sempre exige uma correção. Se a tarefa respeita seu prazo, sua qualidade e seu orçamento, reduzir uma complexidade pode ser preferível a uma otimização frágil. Se uma nova configuração estiver sendo considerada, transmita as restrições demonstradas ao dossiê de recepção. Nenhuma medição isolada classifica o catálogo e nenhum valor deste exemplo constitui um desempenho prometido.