Guardar a primeira falha e seu contexto
Este guia começa após um lançamento bem-sucedido: o PyTorch vê o dispositivo, depois a sua aplicação falha em um batch ou um operador. Se nenhum cálculo pequeno funciona, recomece pelo diagnóstico inicial. Caso contrário, conserve o primeiro erro, o número da iteração e a última etapa concluída. Uma sequência de mensagens após a primeira falha pode descrever suas consequências em vez de várias causas independentes.
Anote a revisão do código, as versões de Python e PyTorch, o backend, o tipo numérico e as formas das entradas. Para os dados, prefira um identificador interno e as dimensões a uma cópia integral do conteúdo. Procure o que distingue o batch problemático: comprimento, alvo ausente, último lote incompleto, aumento ou ramo raramente utilizado. Esse dossiê permite refazer o caso sem relançar toda uma campanha.
Localizar o lançamento problemático apesar do assincronismo
No CUDA, operações são enfileiradas e podem terminar após o retorno da função Python. Um erro reportado durante uma cópia para CPU ou uma leitura de escalar pode, portanto, vir de um cálculo anterior. A documentação do PyTorch explica essa execução assíncrona. A linha indicada pelo trace é um ponto de observação a examinar, nem sempre a causa.
Para uma reprodução curta em NVIDIA/CUDA, proponha um lançamento separado com CUDA_LAUNCH_BLOCKING=1. Essa opção torna as chamadas síncronas e pode aproximar o erro de sua origem. Ela serve para diagnóstico, não para cronometragem. Você também pode colocar provisoriamente sincronizações entre grandes etapas para reduzir o intervalo suspeito. Depois, remova essa instrumentação: ela altera o ordenamento habitual.
O comando a seguir é didático e não foi executado. Ele pressupõe um terminal POSIX e um script train.py existente. A atribuição se aplica apenas a esse lançamento; adapte a sintaxe ao seu shell. Não generalize essa variável NVIDIA para uma pilha ROCm.
CUDA_LAUNCH_BLOCKING=1 python train.pyLer uma família de erro sem concluir cedo demais
A mensagem reduz o campo de busca; ela não substitui um caso reproduzível. Um índice fora do domínio, um tensor no dispositivo errado e uma alocação impossível exigem verificações diferentes. Mantenha a distinção entre dados inválidos, contrato de operador e ambiente binário. Alterar simultaneamente o batch, a precisão e as bibliotecas elimina essa distinção.
Após uma asserção executada no dispositivo, não tente continuar o mesmo treinamento no mesmo processo. A NVIDIA indica que cudaErrorAssert invalida as alocações existentes e exige encerrar e relançar o processo. Em um notebook, isso implica reiniciar o kernel antes da reprodução corrigida. Reiniciar, no entanto, não corrige nem um alvo errado nem um índice inválido.
Role a tabela para ler todas as colunas.| Indício observado | Primeira verificação | Conclusão a evitar |
|---|---|---|
| device-side assert | Índices, alvos e condições do operador | A GPU está necessariamente defeituosa |
| Out of memory | Formas, tempo de vida dos tensores, memória do processo | Todo erro CUDA é falta de VRAM |
| Operador ou kernel não disponível | Versões, extensão, backend e dtype | Reinstalar tudo ao acaso |
| Dispositivos diferentes | Posicionamento do modelo e de cada entrada | Adicionar uma cópia sem entender sua origem |
Exemplo trabalhado: uma classe 4 em um problema de quatro classes
Vamos considerar um classificador didático cuja saída possui quatro colunas. Suas classes são indexadas de 0 a 3. Um arquivo de anotações contendo o valor 4 pode revelar uma codificação de 1 a 4 ou uma quinta classe inesperada. Aumentar simplesmente o tamanho da saída faria desaparecer uma restrição sem resolver o significado das anotações.
A verificação proposta abaixo se aplica antes da transferência dos alvos para a CPU. Ela não foi executada. Ela ilustra o contrato do CrossEntropyLoss para índices de classes do tipo long, com ignore_index=-100 explicitamente escolhido. Ela não cobre alvos constituídos de distribuições de probabilidades. Nesse cenário, [0, 2, 4] deve ser rejeitado; esse resultado esperado é deduzido da regra, não apresentado como medição.
Corrija em seguida o mapeamento na preparação dos dados e controle sua bijeção com os nomes das classes. Não subtraia 1 de tudo enquanto você não souber se todas as fontes usam a mesma convenção. Adicione o caso problemático a um pequeno conjunto de verificação mantido junto com o projeto.
import torch
classes = 4
ignore_index = -100
target = torch.tensor([0, 2, 4], dtype=torch.long)
if target.ndim != 1 or target.dtype != torch.long:
raise ValueError("Cibles : vecteur d’indices attendu")
valid = target[target != ignore_index]
if valid.numel() == 0:
raise ValueError("Aucune cible exploitable dans ce batch")
if bool(((valid < 0) | (valid >= classes)).any()):
raise ValueError("Indice de classe hors domaine")Reduzir o programa sem apagar o gatilho
Reproduza primeiro uma única entrada ou um único batch com as mesmas transformações. Remova o monitoramento remoto, a gravação de resultados e os ramos sem relação com a falha. Mantenha o dtype, as formas e o operador suspeitos. Se o erro depende de um comprimento ou de um layout de memória específico, um tensor arbitrário de tamanho pequeno pode não mais reproduzi-lo.
Compare uma alteração por vez: extensão opcional desativada, operador de referência, precisão habitual ou a mesma operação na CPU quando ela existir lá. Um sucesso na CPU é um indício, não uma validação CUDA. Para uma função personalizada, registre também as suposições sobre strides, contiguidade e tamanhos. Procure um exemplo que falha antes da correção e passa depois dela, com uma verificação de saída em vez da mera ausência de exceção.
Verificar a correção no escopo inicial
Uma correção aceitável deve passar no caso mínimo, nos casos vizinhos e em uma porção representativa do percurso original. Retome, em particular, o último batch, uma entrada curta, uma entrada longa e os valores limite do mapeamento. Verifique que os elementos rejeitados são identificáveis e que o número de entradas processadas permanece o esperado. Ignorar exceções silenciosamente pode transformar um crash visível em resultado incompleto.
Remova o modo de diagnóstico, parta de um processo novo e confirme o comportamento com a configuração normal. Guarde a causa, a mudança aplicada e o controle de não regressão. Se você havia interrompido um treinamento, parta de um checkpoint coerente validado antes do erro; a presença de um arquivo escrito durante uma falha não basta para garantir sua retomada.
Saber quando pedir uma análise mais direcionada
Se o mesmo caso mínimo falha com entradas válidas, prepare uma solicitação precisa: operação, formas, tipos, backend, versões e primeira mensagem relevante. Remova os identificadores pessoais e os caminhos desnecessários. Uma extensão binária pode exigir sua própria matriz de compatibilidade; o suporte geral do PyTorch não valida automaticamente essa extensão.
No ROCm, o PyTorch mantém a interface torch.cuda e os nomes de dispositivo cuda. Verifique torch.version.hip para identificar essa pilha antes de aplicar um procedimento NVIDIA. As mensagens, ferramentas e opções de diagnóstico podem diferir. Nenhum controle descrito aqui comprova a compatibilidade dos ambientes preparados com uma oferta Kernodeck; use estes critérios para especificar sua necessidade antes de escolher a GPU.