Conservare il primo errore e il suo contesto
Questa guida inizia dopo un avvio riuscito: PyTorch vede il dispositivo, poi la tua applicazione fallisce su un batch o un operatore. Se nessun piccolo calcolo funziona, riparti dalla diagnostica iniziale. Altrimenti, conserva il primo errore, il numero di iterazione e l'ultima fase completata. Una successione di messaggi dopo il primo errore può descrivere le sue conseguenze piuttosto che più cause indipendenti.
Annota la revisione del codice, le versioni di Python e PyTorch, il backend, il tipo numerico e le forme degli input. Per i dati, preferisci un identificatore interno e le dimensioni a una copia integrale del contenuto. Cerca ciò che distingue il batch difettoso: lunghezza, target assente, ultimo lotto incompleto, augmentation o ramo usato raramente. Questo dossier permette di riprodurre il caso senza rilanciare un'intera campagna.
Individuare il lancio difettoso nonostante l'asincronia
Su CUDA, alcune operazioni vengono messe in coda e possono terminare dopo il ritorno della funzione Python. Un errore segnalato durante una copia verso la CPU o una lettura di scalare può quindi derivare da un calcolo precedente. La documentazione PyTorch spiega questa esecuzione asincrona. La riga indicata dalla trace è un punto di osservazione da esaminare, non sempre la causa.
Per una riproduzione breve su NVIDIA/CUDA, proponi un lancio separato con CUDA_LAUNCH_BLOCKING=1. Questa opzione rende le chiamate sincrone e può avvicinare l'errore alla sua origine. Serve alla diagnosi, non alla misurazione dei tempi. Puoi anche inserire temporaneamente delle sincronizzazioni tra le grandi fasi per ridurre l'intervallo sospetto. Rimuovi poi questa strumentazione: modifica l'ordinamento abituale.
Il comando seguente è a scopo didattico e non è stato eseguito. Presuppone un terminale POSIX e uno script train.py esistente. L'assegnazione vale solo per questo lancio; adatta la sintassi alla tua shell. Non generalizzare questa variabile NVIDIA a uno stack ROCm.
CUDA_LAUNCH_BLOCKING=1 python train.pyLeggere una famiglia di errori senza concludere troppo in fretta
Il messaggio riduce il campo di ricerca; non sostituisce un caso riproducibile. Un indice fuori dominio, un tensore sul dispositivo sbagliato e un'allocazione impossibile richiedono verifiche diverse. Mantieni la distinzione tra dati non validi, contratto dell'operatore e ambiente binario. Cambiare simultaneamente batch, precisione e librerie elimina questa distinzione.
Dopo un'asserzione eseguita sul dispositivo, non cercare di proseguire lo stesso addestramento nello stesso processo. NVIDIA indica che cudaErrorAssert invalida le allocazioni esistenti e impone di terminare e riavviare il processo. In un notebook, ciò implica riavviare il kernel prima della riproduzione corretta. Riavviare non corregge tuttavia né un target errato né un indice non valido.
Scorri la tabella per leggere tutte le colonne.| Indizio osservato | Prima verifica | Conclusione da evitare |
|---|---|---|
| device-side assert | Indizi, target e condizioni dell'operatore | La GPU è per forza difettosa |
| Out of memory | Forme, durata di vita dei tensori, memoria del processo | Qualsiasi errore CUDA è una mancanza di VRAM |
| Operatore o kernel non disponibile | Versioni, estensione, backend e dtype | Reinstallare tutto a caso |
| Dispositivi diversi | Posizionamento del modello e di ogni input | Aggiungere una copia senza capirne l'origine |
Esempio pratico: una classe 4 in un problema a quattro classi
Prendiamo un classificatore didattico la cui uscita ha quattro colonne. Le sue classi sono indicizzate da 0 a 3. Un file di annotazioni contenente il valore 4 può rivelare una codifica da 1 a 4 o una quinta classe inattesa. Aumentare semplicemente la dimensione dell'uscita farebbe sparire un vincolo senza risolvere il significato delle annotazioni.
Il controllo proposto qui sotto si applica prima del trasferimento dei target sulla CPU. Non è stato eseguito. Illustra il contratto di CrossEntropyLoss per indici di classe di tipo long, con ignore_index=-100 scelto esplicitamente. Non copre i target costituiti da distribuzioni di probabilità. In questo scenario, [0, 2, 4] deve essere rifiutato; questo risultato atteso è dedotto dalla regola, non presentato come una misura.
Correggi poi il mapping nella preparazione dei dati e controlla la sua biiezione con i nomi delle classi. Non sottrarre 1 ovunque finché non sai se tutte le fonti usano la stessa convenzione. Aggiungi il caso difettoso a un piccolo insieme di verifica conservato con il progetto.
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")Ridurre il programma senza eliminare il trigger
Riproduci prima una sola entry o un solo batch con le stesse trasformazioni. Rimuovi il monitoraggio remoto, la scrittura dei risultati e i rami non correlati al guasto. Mantieni il dtype, le forme e l'operatore sospetti. Se l'errore dipende da una lunghezza o da una disposizione di memoria particolare, un tensore arbitrario di piccole dimensioni potrebbe non riprodurlo più.
Confronta una modifica alla volta: estensione facoltativa disattivata, operatore di riferimento, precisione abituale o la stessa operazione su CPU quando esiste. Un successo su CPU è un indizio, non una validazione CUDA. Per una funzione personalizzata, annota anche le ipotesi su strides, contiguità e dimensioni. Cerca un esempio che fallisce prima della correzione e riesce dopo, con una verifica dell'output invece della sola assenza di eccezioni.
Verificare la correzione sul perimetro iniziale
Una correzione accettabile deve superare il caso minimo, i casi vicini e una porzione rappresentativa del percorso originale. Riprendi in particolare l'ultimo batch, un'entry corta, un'entry lunga e i valori limite del mapping. Verifica che gli elementi rifiutati siano identificabili e che il numero di entry elaborate resti quello atteso. Ignorare silenziosamente le eccezioni può trasformare un crash visibile in un risultato incompleto.
Rimuovi la modalità di diagnostica, riparti da un processo nuovo e conferma il comportamento con la configurazione normale. Conserva la causa, la modifica applicata e il controllo di non regressione. Se avevi interrotto un addestramento, riparti da un checkpoint coerente validato prima dell'errore; la presenza di un file scritto durante un guasto non basta a garantirne la ripresa.
Sapere quando richiedere un'analisi più mirata
Se lo stesso caso minimo fallisce con input validi, prepara una richiesta precisa: operazione, forme, tipi, backend, versioni e primo messaggio pertinente. Rimuovi gli identificatori personali e i percorsi inutili. Un'estensione binaria può richiedere una propria matrice di compatibilità; il supporto generale di PyTorch non valida automaticamente questa estensione.
Su ROCm, PyTorch mantiene l'interfaccia torch.cuda e i nomi dei dispositivi cuda. Controlla torch.version.hip per identificare questo stack prima di applicare una procedura NVIDIA. I messaggi, gli strumenti e le opzioni di diagnostica possono differire. Nessun controllo descritto qui prova la compatibilità degli ambienti preparati con un'offerta Kernodeck; usa questi criteri per precisare la tua esigenza prima di scegliere la GPU.