Zachowaj pierwszy błąd i jego kontekst
Ten przewodnik zaczyna się po udanym uruchomieniu: PyTorch widzi urządzenie, a następnie Twoja aplikacja zgłasza błąd na batchu lub operatorze. Jeśli żadne małe obliczenie nie działa, zacznij od wstępnej diagnostyki. W przeciwnym razie zachowaj pierwszy błąd, numer iteracji i ostatni zakończony krok. Sekwencja komunikatów po pierwszym błędzie może opisywać jego skutki, a nie kilka niezależnych przyczyn.
Zanotuj rewizję kodu, wersje Python i PyTorch, backend, typ numeryczny i kształty wejść. W przypadku danych preferuj wewnętrzny identyfikator i wymiary zamiast pełnej kopii zawartości. Poszukaj tego, co wyróżnia wadliwy batch: długość, brakujący cel, niekompletny ostatni batch, augmentacja lub rzadko używana gałąź. Ten zapis pozwala odtworzyć przypadek bez ponownego uruchamiania całej kampanii.
Zlokalizuj wadliwe uruchomienie mimo asynchroniczności
W CUDA operacje są kolejkowane i mogą zakończyć się po powrocie funkcji Pythona. Błąd zgłoszony podczas kopiowania do CPU lub odczytu skalara może więc pochodzić z wcześniejszego obliczenia. Dokumentacja PyTorch wyjaśnia to asynchroniczne wykonywanie. Linia wskazana przez trace to punkt obserwacyjny do zbadania, nie zawsze przyczyna.
Aby uzyskać krótkie odtworzenie na NVIDIA/CUDA, zaproponuj osobne uruchomienie z CUDA_LAUNCH_BLOCKING=1. Ta opcja czyni wywołania synchronicznymi i może przybliżyć błąd do jego źródła. Służy do diagnostyki, nie do pomiaru czasu. Możesz też tymczasowo umieścić synchronizacje między głównymi etapami, aby zmniejszyć podejrzany przedział. Następnie usuń tę instrumentację: zmienia ona zwykłe szeregowanie.
Poniższe polecenie ma charakter dydaktyczny i nie zostało wykonane. Zakłada terminal POSIX i istniejący skrypt train.py. Przypisanie stosuje się tylko do tego uruchomienia; dostosuj składnię do swojego shella. Nie uogólniaj tej zmiennej NVIDIA na stos ROCm.
CUDA_LAUNCH_BLOCKING=1 python train.pyCzytanie rodziny błędów bez zbyt pochopnych wniosków
Komunikat zawęża pole poszukiwań; nie zastępuje jednak przypadku odtwarzalnego. Wskaźnik poza zakresem, tensor na niewłaściwym urządzeniu i niemożliwa do wykonania alokacja wymagają różnych sprawdzeń. Zachowaj rozróżnienie między nieprawidłowymi danymi, kontraktem operatora i środowiskiem binarnym. Jednoczesna zmiana batcha, precyzji i bibliotek usuwa to rozróżnienie.
Po asercji wykonanej na urządzeniu nie próbuj kontynuować tego samego treningu w tym samym procesie. NVIDIA wskazuje, że cudaErrorAssert unieważnia istniejące alokacje i wymaga zakończenia, a następnie ponownego uruchomienia procesu. W notebooku oznacza to konieczność zrestartowania jądra przed poprawionym odtworzeniem. Restart nie naprawia jednak ani błędnego celu, ani nieprawidłowego indeksu.
Przewiń tabelę, aby zobaczyć wszystkie kolumny.| Zaobserwowany wskaźnik | Pierwsze sprawdzenie | Wnioski, których należy unikać |
|---|---|---|
| device-side assert | Wskaźniki, cele i warunki operatora | GPU jest z pewnością uszkodzony |
| Out of memory | Kształty, czas życia tensorów, pamięć procesu | Każdy błąd CUDA to brak VRAM |
| Operator lub kernel niedostępny | Wersje, rozszerzenie, backend i dtype | Zainstaluj wszystko od nowa na chybił trafił |
| Różne urządzenia | Umiejscowienie modelu i każdego wejścia | Dodaj kopię bez zrozumienia jej pochodzenia |
Przeanalizowany przykład: klasa 4 w problemie z czterema klasami
Weźmy dydaktyczny klasyfikator, którego wyjście ma cztery kolumny. Jego klasy są indeksowane od 0 do 3. Plik adnotacji zawierający wartość 4 może wskazywać na kodowanie od 1 do 4 lub na nieoczekiwaną piątą klasę. Proste zwiększenie rozmiaru wyjścia usunęłoby ograniczenie, nie rozwiązując znaczenia adnotacji.
Proponowana poniżej kontrola jest stosowana przed przeniesieniem celów na CPU. Nie została uruchomiona. Ilustruje kontrakt CrossEntropyLoss dla indeksów klas typu long, z jawnie wybranym ignore_index=-100. Nie obejmuje celów będących rozkładami prawdopodobieństwa. W tym scenariuszu [0, 2, 4] powinno zostać odrzucone; ten oczekiwany wynik wynika z reguły, a nie jest przedstawiany jako pomiar.
Następnie popraw mapowanie w przygotowaniu danych i sprawdź jego bijekcję z nazwami klas. Nie odejmuj 1 wszędzie, dopóki nie wiesz, czy wszystkie źródła używają tej samej konwencji. Dodaj błędny przypadek do małego zbioru weryfikacyjnego przechowywanego razem z projektem.
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")Zredukuj program bez usuwania wyzwalacza
Najpierw odtwórz pojedyncze wejście lub pojedynczy batch z tymi samymi transformacjami. Usuń zdalne śledzenie, zapisywanie wyników i gałęzie niezwiązane z awarią. Zachowaj dtype, kształty i podejrzany operator. Jeśli błąd zależy od konkretnej długości lub układu pamięci, dowolny mały tensor może go już nie odtworzyć.
Porównuj jedną zmianę naraz: wyłączone rozszerzenie opcjonalne, operator referencyjny, zwykła precyzja lub ta sama operacja na CPU, jeśli tam istnieje. Sukces na CPU to wskazówka, nie walidacja CUDA. W przypadku funkcji niestandardowej zapisz także założenia dotyczące strides, ciągłości i rozmiarów. Szukaj przykładu, który zawodzi przed poprawką i działa po niej, z weryfikacją wyniku, a nie tylko brakiem wyjątku.
Sprawdź poprawność w początkowym zakresie
Akceptowalna poprawka musi przejść przypadek minimalny, przypadki sąsiednie i reprezentatywną część pierwotnego przebiegu. Uwzględnij zwłaszcza ostatni batch, krótkie wejście, długie wejście oraz wartości graniczne mapowania. Sprawdź, czy odrzucone elementy są identyfikowalne i czy liczba przetworzonych wejść pozostaje zgodna z oczekiwaną. Ciche ignorowanie wyjątków może zamienić widoczny crash w niekompletny wynik.
Wyłącz tryb diagnostyczny, uruchom nowy proces i potwierdź zachowanie przy normalnej konfiguracji. Zachowaj przyczynę, zastosowaną zmianę i kontrolę braku regresji. Jeśli przerwałeś trening, wznów z spójnego checkpointu zwalidowanego przed błędem; obecność pliku zapisanego podczas awarii nie gwarantuje możliwości jego wznowienia.
Wiedz, kiedy poprosić o bardziej ukierunkowaną analizę
Jeśli ten sam przypadek minimalny zawodzi przy prawidłowych danych wejściowych, przygotuj precyzyjne zgłoszenie: operacja, kształty, typy, backend, wersje i pierwszy istotny komunikat. Usuń dane osobowe i zbędne ścieżki. Rozszerzenie binarne może wymagać własnej macierzy zgodności; ogólne wsparcie PyTorch nie waliduje automatycznie tego rozszerzenia.
Na ROCm PyTorch zachowuje interfejs torch.cuda i nazwy urządzeń cuda. Sprawdź torch.version.hip, aby zidentyfikować ten stos przed zastosowaniem procedury NVIDIA. Komunikaty, narzędzia i opcje diagnostyczne mogą się różnić. Żadna z opisanych tu kontroli nie dowodzi zgodności przygotowanych środowisk z ofertą Kernodeck; użyj tych kryteriów, aby doprecyzować swoje potrzeby przed wyborem GPU.