PyTorch nie widzi GPU: co sprawdzić najpierw?

Ścieżka diagnostyczna w czterech decyzjach

Celem jest znalezienie pierwszej warstwy, która zawodzi, a nie wypróbowywanie kolejnych instalacji. Zachowaj uruchomioną komendę, pierwszy komunikat błędu i wynik każdej kontroli. Jeśli zmienisz jednocześnie Python, pakiet PyTorch i rozmiar batcha, nie będziesz już wiedzieć, która modyfikacja rozwiązała problem.

Skrypt do pobrania realizuje tę progresję i tworzy ograniczony raport techniczny. Nie uruchamia Twojego modelu i nie modyfikuje Twojej instalacji. Użyj go w tym samym środowisku co Twój projekt, w przeciwnym razie sprawdzisz inny interpreter niż ten używany przez niedziałający program.

• Pobierz skrypt diagnostyczny Kernodeck v1 ↓
• Przeczytaj opcje i kody wyjścia ↓
• Pobierz skrypt i jego przykłady JSON ↓
• Odtwórz środowisko projektu ↗

1. Zidentyfikuj faktycznie uruchamiany Python

Terminal, notebook i usługa mogą używać różnych interpreterów. Wyświetl sys.executable w kontekście, który uruchamia projekt, a następnie sprawdź wersję. Ścieżka pozwala wykryć zapomniane środowisko wirtualne lub notebook pozostawiony na innym jądrze. Sprawdź to na swojej maszynie; nie ma potrzeby publikować swojego drzewa katalogów w raporcie.

Następnie użyj tego samego interpretera do odpytywania pakietów. Komenda python -m pip show torch podaje informacje o PyTorch powiązanym z tym Pythonem. Jeśli import torch zawodzi, kolejny krok polega na naprawie tej instalacji: zmniejszenie batcha lub zmiana wag modelu nie rozwiąże problemu brakującego modułu.

python -c "import sys; print(sys.executable); print(sys.version)"
python -m pip show torch

• Python: zidentyfikuj używany plik wykonywalny ↗
• PyTorch: wybierz odpowiednią komendę instalacji ↗

2. Rozróżnij CUDA, ROCm i pakiet bez akceleracji GPU

Zapisz osobno torch.__version__, torch.version.cuda i torch.version.hip. Nie wyciągaj wniosku „pakiet CPU” na podstawie samej wartości None w torch.version.cuda: PyTorch dla ROCm używa HIP, ponownie wykorzystuje torch.cuda i również oczekuje urządzenia o nazwie cuda. Zastąpienie tej nazwy przez rocm lub hip nie jest poprawką, którą należy zastosować.

Następnie sprawdź torch.cuda.is_available() i torch.cuda.device_count(). Te wyniki opisują, czego to środowisko Python może użyć w danym momencie. Nie zastępują minimalnego obliczenia. Narzędzie systemowe może widzieć kartę, podczas gdy pakiet, sterownik dostępny dla procesu lub jego środowisko uniemożliwiają PyTorch jej użycie.

python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.version.hip); print(torch.cuda.is_available()); print(torch.cuda.device_count())"

• PyTorch: ROCm ponownie wykorzystuje interfejsy torch.cuda ↗
• Instalacja i wstępna kontrola PyTorch ↗

3. Wygeneruj raport za pomocą skryptu Kernodeck

Po pobraniu pliku umieść go w katalogu roboczym i uruchom za pomocą Pythona projektu. Domyślnie wymaga GPU. Tryb CPU trzeba zażądać jawnie: jego powodzenie weryfikuje gałąź CPU diagnostyki i nigdy nie zamienia niedostępnego GPU w zweryfikowany GPU. Raport jest wypisywany w terminalu, a z --output w nowym pliku JSON. Istniejący plik nigdy nie jest nadpisywany: wybierz inną nazwę na kolejną próbę.

Skrypt alokuje dwie macierze 2 × 2 w float32, sprawdza ich iloczyn, a następnie gradient i synchronizuje urządzenie GPU. Oczekiwana strata wynosi 196 dla tego stałego obliczenia. Ta bardzo krótka kontrola nie ładuje żadnych wag modelu i nie mierzy żadnej przepustowości. Wymaga od backendu małego rzeczywistego obliczenia, wykraczającego poza samo wykrycie urządzenia.

Opcjonalna kontrola systemowa używa nvidia-smi, gdy jest obecne. Raportuje wyłącznie wersję sterownika NVIDIA i całkowitą pamięć widoczną dla tego narzędzia; nie stanowi równoważnej kontroli systemowej dla ROCm. Limit czasu obliczenia wynosi domyślnie 30 sekund i może wynosić od 5 do 120 sekund. Kontrola systemowa ma własny maksymalny limit czasu wynoszący 3 sekundy.

python kernodeck-diagnostic-v1.py --device-index 0 --timeout 30 --output diagnostic-gpu.json

python kernodeck-diagnostic-v1.py --device cpu --output diagnostic-cpu.json

python kernodeck-diagnostic-v1.py --host-check --output diagnostic-gpu-systeme.json

• Pobierz skrypt Python ↓
• NVIDIA: zakres i opcje nvidia-smi ↗

4. Odczytaj raport i wybierz następne działanie

Zacznij od status, code, exit_code i stage. Blok runtime identyfikuje wersję Pythona i rodzinę systemu. Blok pytorch rozróżnia importowany pakiet, jego wersje kompilacji CUDA/HIP, zadeklarowany backend i widoczne urządzenia. Blok execution wskazuje, gdzie faktycznie odbyło się obliczenie oraz czy zweryfikowano iloczyn i gradient.

W trybie CPU gpu_available i visible_device_count pozostają null: skrypt nie pyta o stan sterownika GPU. To nie jest ani zero, ani awaria. Zwróć też uwagę na execution.device: pakiet skompilowany dla CUDA może równie dobrze wykonać tę kontrolę na CPU, gdy zostanie o to jawnie poproszony.

Raport zawiera wybór danych technicznych. Nie obejmuje zmiennych środowiskowych, ścieżek stacji roboczej, identyfikatorów sesji, pełnej listy pakietów ani surowego śladu wyjątku. Skrypt nie wysyła żadnego raportu do Kernodeck. W przypadku szczegółowego błędu Twojej aplikacji zachowaj jej ślad w swojej przestrzeni roboczej i usuń sekrety przed udostępnieniem.

• Rzeczywisty raport kontroli CUDA ↓
• Rzeczywisty raport kontroli CPU ↓
• Rzeczywisty raport, gdy brakuje PyTorch ↓

5. Od małego obliczenia do Twojej aplikacji

Przed uruchomieniem przygotuj powtarzalne polecenie, zidentyfikowany model, mały zbiór danych i dostępny katalog wyjściowy. Wybierz dane wejściowe, które zachowują istotne cechy końcowej pracy: długość tekstu, wymiary obrazu, format audio lub wymagane pola. Sztucznie krótkie dane wejściowe mogą ukryć problem, który chcesz zaobserwować.

Zdefiniuj konkretne kryterium sukcesu. Dla obliczania osadzeń każdy identyfikator wejściowy powinien otrzymać wektor o oczekiwanym wymiarze, ze skończonymi wartościami. Dla treningu jeden krok powinien dać użyteczną stratę, zaktualizować zamierzone parametry i umożliwić zapis. Kod wyjścia procesu uzupełnia te kontrole; nie zastępuje ich.

Dodaj znaczniki przed odczytem parametrów i po nim, przed importem bibliotek i po nim, przed wczytaniem wag i po nim, przed przygotowaniem danych i po nim, przed ich transferem i po nim, przed obliczeniem i po nim oraz przed zapisem i po nim. Nadaj każdej próbie identyfikator i zachowaj powiązane parametry. Komunikat „model załadowany” powinien odpowiadać zakończonemu zdarzeniu, a nie jedynie zamiarowi załadowania.

Loguj kształty, typy i urządzenia przydatnych tensorów, nie kopiując całego zbioru danych. Podsumowanie takie jak „wejście: 8 sekwencji, maksymalna długość 512, urządzenie cuda:0” pomaga porównać dwie próby. Liczby te opisują tutaj przykład logu, a nie uniwersalną konfigurację. Unikaj umieszczania tokenów dostępu lub wrażliwej zawartości danych wejściowych w tych komunikatach.

6. Napraw błąd na właściwej warstwie

Jeśli małe obliczenie przechodzi, ale wagi są nieosiągalne, sprawdź ich ścieżkę, format i uprawnienia dostępu. Jeśli rozszerzenie nie chce się zaimportować, zweryfikuj jego zgodność z pakietem PyTorch i backendem projektu. Udana diagnostyka nie kwalifikuje wszystkich rozszerzeń aplikacji. Wróć do pierwszego kroku, który zawodzi, zamiast zmieniać kilka zależności naraz.

Błąd urządzenia może wynikać z danych wejściowych, które pozostały na CPU, gdy model jest na GPU. Błąd typu może wynikać z częściowej konwersji lub operatora niezgodnego z wybraną precyzją. Zachowaj pierwszy pełny komunikat i jego ślad. Zmień tylko jedno założenie naraz, a następnie ponownie uruchom minimalne wejście, zanim przywrócisz docelową objętość.

7. Jeśli model startuje, a potem przekracza pamięć

Ustal, czy przekroczenie następuje przy wczytywaniu wag, przy pierwszym obliczeniu czy po kilku iteracjach. Te momenty wskazują na różne przyczyny: zbyt duży model, duże aktywacje lub pamięć podręczna generowania, gromadzenie zachowanych tensorów. Odczytuj torch.cuda.memory_allocated() i torch.cuda.memory_reserved() w tych samych krokach. Pierwsze śledzi alokacje tensorów; drugie obejmuje pamięć zarządzaną przez alokator.

torch.cuda.empty_cache() może zwolnić niewykorzystaną pamięć podręczną, ale nie usuwa tensorów wciąż posiadających referencje. Sprawdź więc listy wyjść, historie strat i obiekty przechowujące graf obliczeń. Następnie zmniejsz batch lub długość wejścia, aby wyizolować czynnik decydujący. Zmiana karty staje się świadomą decyzją, gdy znasz fazę przekraczającą limit i faktycznie potrzebny zapas.

• PyTorch: pamięć przydzielona tensorom ↗
• PyTorch: pamięć zarządzana przez alokator ↗
• PyTorch: co zwalnia empty_cache ↗
• Powiąż pamięć, kontekst i batch wnioskowania ↗

8. Mierz obliczenia, nie zapominając o asynchroniczności

Operacje GPU mogą być asynchroniczne względem programu Python. Stoper umieszczony wokół wywołania może więc mierzyć głównie wysłanie pracy. Do pomiaru diagnostycznego zsynchronizuj GPU na granicach obserwowanego segmentu lub użyj odpowiednich zdarzeń. Ta synchronizacja zmienia przebieg: trzymaj tę instrumentację oddzielnie od normalnego działania Twojej aplikacji.

Zbuduj prosty przykład z trzema segmentami: przygotowanie wejścia, obliczenia, zapis wyjścia. Dla segmentu GPU wywołaj torch.cuda.synchronize(), odczytaj time.perf_counter(), wykonaj obliczenia, zsynchronizuj ponownie, a następnie oblicz różnicę. Pierwszy przebieg i kolejne przechowuj oddzielnie. Ładowanie lub inicjalizacja nie powinny zniknąć w średniej przedstawianej jako całkowity czas odpowiedzi.

• PyTorch: synchronizacja i pomiar obliczeń GPU ↗

9. Kontroluj wyjścia i zachowaj diagnostykę wielokrotnego użytku

W przypadku klasycznej inferencji model.eval() ustawia zachowanie odpowiednich modułów, natomiast torch.inference_mode() wyłącza śledzenie wymagane dla gradientów. Te dwa ustawienia mają różne funkcje. Użyj drugiego, gdy tworzone tensory nie mają później uczestniczyć w obliczeniach z gradientami. Ewaluacja modelu podczas treningu wymaga jawnego przywrócenia właściwego trybu przed wznowieniem.

Porównaj teraz wyjścia z przygotowanym kontraktem: liczbę wyników, zgodność identyfikatorów, wymiary, wartości skończone i odpowiednią metrykę biznesową. Jeśli zwiększasz batch, sprawdź ponownie tę zgodność. Jeśli dodajesz GPU, skontroluj rozdzielenie wejść i zbieranie wyjść. Partie wynajmu oznaczają zamówione karty; batch oznacza przykłady przetwarzane razem przez Twój program.

Wynikiem tej metody jest mały folder: polecenie, wersje, parametry, minimalne wejście, ostatni udany krok, pierwszy błąd, obserwacje pamięci i uzyskane wyjście. Jeśli uruchomienie się powiedzie, zachowaj ten folder jako punkt odniesienia przed zwiększeniem obciążenia. Jeśli uruchomienie się nie powiedzie, pozwala on odtworzyć problem bez powtarzania całego dochodzenia.

Przed długim przetwarzaniem wykonaj także czyste zatrzymanie i wznowienie na tym małym zestawie wejść. Sprawdź, czy już zapisane wyjścia nie zostały utracone ani policzone dwukrotnie. Gdy te kontrole zostaną zaliczone, zwiększaj stopniowo tylko jedną osi — batch, długość, współbieżność lub liczbę procesów — i zapisz zaobserwowany limit. Otrzymujesz zmierzony zakres działania dla swojej aplikacji, a nie przypuszczenie związane z nazwą GPU.

• PyTorch: różnica między inference_mode a eval ↗
• Kontrola wznowienia w nowym procesie ↗

Dostarczony dowód i jego ograniczenia

Przykłady do pobrania pochodzą z rzeczywistych kontroli przeprowadzonych 24 września 2026. Oba uruchomienia z PyTorch używają Windows, Python 3.14.6 i PyTorch 2.11.0+cu128. Kontrola GPU wykorzystuje CUDA, na NVIDIA GeForce RTX 5070; kontrola CPU jawnie żąda CPU. Ten sprzęt kontrolny nie jest prezentowany jako oferta Kernodeck. Dla tego dowodu nie wykonano żadnych obliczeń ROCm.

Udane małe obliczenie pokazuje, że ścieżka alokacji i obliczeń działa na wybranym urządzeniu. Nie mierzy ani szybkości Twojego modelu, ani pamięci potrzebnej dla jego największych wejść, ani jego zgodności z konkretnym rozszerzeniem. Raport nie certyfikuje również topologii wielokartowej. Przejdź do testu reprezentatywnego, zanim zdecydujesz o zwiększeniu obciążenia lub wynajmu.

W przypadku aplikacji CUDA porównaj kartę NVIDIA z Twoimi potrzebami dotyczącymi pamięci i bibliotek; w przypadku łańcucha ROCm przeanalizuj warunki MI300X. Powiązane karty to opcje do zakwalifikowania dla Twojego projektu, a nie lista sprzętu użytego w dowodzie. Uwzględnij czas wstępnej kontroli i eksportu w swoim okresie 3, 7 lub 30 dni.

• Przeczytaj protokół i ograniczenia diagnostyki ↓
• Sprawdź RTX 4090 dla projektu CUDA ↗
• Sprawdź MI300X dla łańcucha ROCm ↗
• Skonfiguruj wynajem po kwalifikacji projektu ↗