Dlaczego środowisko do ML częściej się psuje niż działa
Łańcuch zależności: sterownik, CUDA, cuDNN, PyTorch i reszta
Środowisko do uczenia maszynowego na GPU to kilka warstw, które muszą do siebie pasować. W uproszczeniu:
Sterownik NVIDIA – niskopoziomowa warstwa, dzięki której system w ogóle „widzi” kartę i może z niej korzystać.
CUDA – zestaw bibliotek i narzędzi do uruchamiania obliczeń na GPU, w tym runtime i kompilator nvcc.
cuDNN – biblioteka z wysoko zoptymalizowanymi prymitywami dla sieci neuronowych (konwolucje, LSTM itp.).
PyTorch (lub inny framework) – warstwa, której faktycznie używa się w kodzie ML, zbudowana pod konkretną wersję CUDA/cuDNN.
Inne biblioteki – np. TensorRT, XGBoost z obsługą GPU, pakiety do augmentacji, rozszerzenia C++/CUDA.
Każda z tych warstw ma swoje wersje, a producenci zapewniają kompatybilność tylko dla konkretnych kombinacji. Sterownik musi być wystarczająco nowy, żeby obsłużyć daną wersję CUDA, a PyTorch musi być skompilowany z konkretną wersją CUDA i cuDNN. Gdy choć jedna część jest za stara albo pochodzi z innego źródła, pojawiają się błędy typu „nie znaleziono biblioteki”, crashe przy starcie lub dziwne zwiechy bez komunikatów.
Co najczęściej się gryzie w praktyce
Najwięcej problemów robią:
Mieszanie instalacji systemowej CUDA z paczkami conda/pip – system ma CUDA 12.1, a w środowisku ML instalujemy PyTorch z wbudowaną CUDA 11.8. Wtedy loader potrafi „złapać” nie tę bibliotekę, którą trzeba.
Wiele wersji CUDA w systemie – ścieżki w PATH i LD_LIBRARY_PATH wskazują na różne katalogi, a aplikacje losowo trafiają na starą lub nową wersję.
Aktualizacje sterownika bez patrzenia na kompatybilność – zbyt stary sterownik vs zbyt nowy PyTorch/CUDA, albo odwrotnie.
Instalowanie „po taniości” wszystkiego w jednym globalnym Pythonie – kolejne projekty nadpisują sobie biblioteki, pip/conda wchodzą sobie w drogę.
Na małym projekcie takim jak prosty klasyfikator CIFAR10 drobna niezgodność może wyjść dopiero po kilku godzinach – np. przy pierwszym większym batchu na GPU. Wtedy człowiek zaczyna googlować komunikaty i szybko okazuje się, że winne są stare pozostałości po poprzedniej instalacji.
Koszt godzin spędzonych na błędach środowiskowych
Średnio jedna poważniejsza rozjazdówka wersji CUDA/sterowników potrafi zjeść od kilku do kilkunastu godzin. Typowy scenariusz:
Instalacja wszystkiego „zgodnie z tutorialem sprzed roku”.
Próba uruchomienia treningu – crash lub komunikat o braku bibliotek.
Szukane rozwiązań w sieci, testowanie komend innych osób, reinstalacje, restart systemu.
Ponowna konfiguracja środowiska, czasem nawet reinstalacja systemu, jeśli syf w /usr/local jest bardzo duży.
W tym samym czasie można by przetestować kilka architektur modelu, sprawdzić hiperparametry i przygotować porządny pipeline danych. Z punktu widzenia „efekt vs wysiłek” rozsądniej jest poświęcić jedno popołudnie na przemyślaną konfigurację niż kilka weekendów na gaszenie pożarów.
Minimalistyczne podejście kontra ciągłe aktualizacje
Istnieją dwa skrajne podejścia:
„Działa, nie ruszam” – gdy środowisko jest już stabilne, ogranicza się aktualizacje do niezbędnego minimum.
„Zawsze najnowsze wszystko” – automatyczne aktualizacje sterowników, CUDA i bibliotek w imię „wydajności i bezpieczeństwa”.
Do ML, szczególnie w projekcie komercyjnym lub dłuższym badaniu, zwykle lepiej sprawdza się opcja pierwsza: zamrozić wersje na konfiguracji, która działa, i nie dotykać jej bez powodu. Aktualizacje mają sens, jeśli:
nowa wersja przynosi wyraźny zysk wydajnościowy lub funkcjonalny (np. nowy operator w PyTorch, którego rzeczywiście potrzeba),
aktualna wersja traci wsparcie bezpieczeństwa,
zależy ci na konkretnym nowym modelu lub repozytorium, które wymaga nowszego PyTorcza/Pythona.
Kluczowa myśl: środowisko ML to część infrastruktury, a nie zabawka do ciągłego dłubania. Im mniej niepotrzebnych zmian, tym mniej konfliktów.
Jak zaplanować środowisko: sprzęt, system i strategia wersji
Wybór GPU: ile naprawdę potrzeba na start
Najlepszy sprzęt to taki, na który cię stać i który pozwala uruchomić realne projekty, a nie benchmarki z Twittera. Do większości zadań ML na start nie jest potrzebna karta z górnej półki typu RTX 4090. Dużo ważniejsza jest ilość VRAM i wsparcie CUDA niż liczba FPS w grach.
Praktyczne kategorie:
Budżet minimum do nauki: starsze karty typu GTX 1060 6 GB, 1070, 1660, RTX 2060. Pozwalają trenować mniejsze modele (np. ResNet, małe segmentatory) przy rozsądnych batch size’ach.
Środek stawki: RTX 3060 12 GB, 3060 Ti, 3070. Dobry kompromis ceny i VRAM – wystarczy do większości projektów computer vision i NLP przy odrobinie rozsądku.
Wyższa półka: RTX 3080, 3090, 40xx – sensowna, jeśli generujesz dochód z ML, robisz dużo eksperymentów lub pracujesz z większymi modelami.
Karty profesjonalne (Quadro, RTX A6000, H100 itp.) mają sens głównie w firmach lub centrach danych. Do zastosowań „domowo–projektowych” karta gamingowa daje znacznie lepszy stosunek wydajności do ceny. Lepiej kupić tańszą kartę i dołożyć RAM/SSD niż przepłacać za „pro” etykietkę bez wyraźnej potrzeby.
System: Windows czy Linux pod ML
Oba systemy da się skonfigurować stabilnie, ale różnią się wygodą i typowymi pułapkami.
Windows:
Łatwiejsze sterowniki dla osób mniej technicznych (instalatory, GeForce Experience).
Więcej komercyjnego oprogramowania (np. narzędzia do adnotacji danych, IDE).
Więcej „magii” w tle: antywirus, automatyczne aktualizacje, integracje – czasem wchodzą w konflikt z narzędziami ML.
Linux (np. Ubuntu LTS):
Bardziej przewidywalne środowisko, lepsza integracja z narzędziami serwerowymi.
Większość dokumentacji ML (w tym PyTorch, CUDA) jest testowana głównie na Linuxie.
Więcej manualnych kroków na start, ale potem mniej niespodzianek.
Dla wielu osób rozsądnym kompromisem jest Windows + WSL2 (Ubuntu jako subsystem). To wygodne, bo:
Masz normalny Windows na co dzień.
Środowisko ML działa w Linuxie z dostępem do GPU (przy nowych sterownikach).
Jeśli budżet czasowy jest ograniczony, a system będzie głównie do ML, najprostsza droga to świeże Ubuntu LTS z oficjalnymi sterownikami NVIDIA i conda/mamba.
Strategia środowisk: jedna stabilna baza czy wiele izolowanych środowisk
Łatwo wpaść w pokusę „jeden Python, jedna instalacja PyTorch, wszystko w jednym miejscu”. Tyle że po pierwszym większym projekcie i kilku bibliotekach z GitHuba kończy się to konfliktem wersji i potrzebą przeinstalowania połowy narzędzi.
Bardziej opłacalna długofalowo jest kombinacja:
Jedna stabilna baza systemowa: sterowniki NVIDIA + ewentualna jedna wersja CUDA instalowana systemowo, jeśli naprawdę jej potrzebujesz.
Osobne środowisko conda/venv na każdy większy projekt: tam instalujesz PyTorch i całą resztę.
Z punktu widzenia czasu:
Stworzenie nowego środowiska i zainstalowanie PyTorch to kwestia kilku minut.
Naprawa globalnego, zapchanego środowiska – często kilka godzin lub formatowanie systemu.
Dlatego lepiej od razu uznać, że izolacja projektów to standard, a nie „fanaberia DevOpsów”.
Plan wersji: trzymanie się oficjalnej matrycy kompatybilności
PyTorch publikuje klarowną tabelę kompatybilności: dla każdej wersji PyTorch podaje:
obsługiwane wersje CUDA,
obsługiwane wersje Pythona,
obsługiwane systemy (Windows/Linux/macOS) i architektury GPU.
Zamiast kombinować, wystarczy:
Wybrać wersję Pythona, którą chcesz (np. 3.10).
Wejść na stronę instalacji PyTorch i zaznaczyć: system, pakiet (pip/conda), wersję CUDA.
Skopiować polecenie instalacji, które PyTorch wygeneruje.
Następnie upewnić się, że sterownik NVIDIA jest co najmniej tak nowy, jak wymagana wersja do danej wersji CUDA. NVIDIA podaje tabelę: sterownik minimalny vs wersja CUDA. W praktyce bezpiecznie jest zainstalować sterownik nieco nowszy, ale nie „zupełnie najnowszy” z pierwszego dnia wydania.
Sterowniki NVIDIA – fundament, którego lepiej nie tykać co tydzień
Rola sterownika i różnica względem CUDA Toolkit
Sterownik NVIDIA to warstwa komunikacji między systemem operacyjnym a GPU. Zapewnia:
obsługę grafiki (renderowanie, gry, GUI),
warstwę NVIDIA Kernel Module odpowiedzialną za dostęp do GPU z poziomu CUDA,
interfejs nvidia-smi do monitoringu i zarządzania GPU.
CUDA Toolkit to osobny zestaw:
kompilator nvcc,
runtime CUDA (biblioteki cudart),
dodatkowe narzędzia i przykłady.
PyTorch z GPU wykorzystuje sterownik i biblioteki CUDA, ale może mieć wbudowaną swoją wersję CUDA (szczególnie w paczkach conda/pip). Dlatego:
sterownik instaluje się zwykle raz na system,
CUDA Toolkit często w ogóle nie jest potrzebny systemowo, jeśli nie kompilujesz własnych rozszerzeń.
Dobór wersji sterownika: stabilność ponad nowość
Sterowniki NVIDIA dzielą się na:
Game Ready – aktualizowane często, nastawione na gry, z minimalnymi poprawkami pod nowe tytuły.
Studio / Production – rzadziej aktualizowane, testowane dłużej, skierowane pod pracę (rendering, ML itp.).
Do ML lepszy stosunek stabilności do ryzyka mają wydania „Studio” lub tzw. długoterminowe (LTS), dostępne szczególnie na Linuxie. Zwykle:
wybierz nie najstarszy, ale też nie premierowy sterownik,
sprawdź, jakie wersje sterownika są zalecane dla twojej karty i wersji CUDA (na stronie NVIDIA).
Jeśli korzystasz z karty sprzed kilku generacji, najnowszy sterownik wciąż zazwyczaj ją obsługuje, ale nie daje realnych zysków w ML. Za to każda aktualizacja to potencjalne nowe źródło konfliktów, dlatego lepiej robić ją tylko gdy jest powód.
Instalacja sterowników na Windows: GeForce Experience czy czysta instalacja
Na Windows są dwie główne drogi:
GeForce Experience – automatyka, powiadomienia o nowych wersjach, tryb „Game Ready”.
Czysta instalacja ze strony NVIDIA – pobierasz konkretną wersję i zaznaczasz „clean install”.
Dla środowiska ML dużo bezpieczniejsza jest druga opcja:
Wejdź na stronę NVIDIA, wybierz model karty i system.
Wybierz sterownik w wariancie „Studio” lub z dłuższym wsparciem.
Podczas instalacji zaznacz Czysta instalacja (Clean Install), by usunąć śmieci po starych wersjach.
Wyłącz automatyczne aktualizacje w GeForce Experience lub w ogóle nie instaluj tego programu.
Taki schemat zmniejsza ryzyko niespodziewanego update’u sterownika, po którym PyTorch nagle przestaje widzieć GPU lub zaczyna rzucać błędami w połowie treningu.
Instalacja sterowników na Ubuntu: repozytorium czy runfile
Na Ubuntu dwie najpopularniejsze metody to:
Metoda 1: sterownik z repozytorium Ubuntu
To najszybsza ścieżka dla większości użytkowników. Sprawdza się szczególnie na świeżym systemie i przy popularnych kartach (seria GTX/RTX).
Zaktualizuj listę pakietów:
sudo apt update
sudo apt upgrade
Sprawdź, jakie sterowniki są dostępne:
ubuntu-drivers devices
Zainstaluj sugerowany sterownik:
sudo ubuntu-drivers autoinstall
lub ręcznie, np.:
sudo apt install nvidia-driver-535
Zrestartuj system.
Po restarcie sprawdzasz:
nvidia-smi
Jeśli widzisz listę GPU i wersję sterownika – fundament jest postawiony. Metoda repozytoryjna ma jedną zaletę kluczową z perspektywy czasu: sterownik aktualizuje się wraz z systemem, bez ręcznego polowania po stronach NVIDIA. Minus – nie zawsze jest to absolutnie najnowsza wersja, ale do ML zwykle to plus, nie wada.
Metoda 2: sterownik z pliku .run od NVIDIA
Ta ścieżka ma sens głównie wtedy, gdy:
masz bardzo nową kartę, której sterowniki nie trafiły jeszcze do repo Ubuntu,
potrzebujesz konkretnej wersji spoza oficjalnych pakietów.
Kroki są bardziej wymagające:
Pobierz plik .run ze strony NVIDIA (konkretna wersja sterownika).
Przełącz się na konsolę tekstową (Ctrl+Alt+F3) i zatrzymaj serwer graficzny (GNOME/KDE):
sudo systemctl stop gdm3 # lub lightdm, sddm – zależnie od środowiska
Nadaj uprawnienia do uruchomienia:
chmod +x NVIDIA-Linux-x86_64-*.run
Uruchom instalator:
sudo ./NVIDIA-Linux-x86_64-*.run
Zwykle wystarczy zaakceptować domyślne opcje.
Po instalacji włącz ponownie środowisko graficzne i zrestartuj:
sudo systemctl start gdm3
sudo reboot
Ta metoda daje większą kontrolę, ale trudniej ją odkręcić. Na desktopie, gdzie liczy się czas i święty spokój, wygodniejsze są pakiety z repozytorium. Plik .run ma sens w specyficznych przypadkach (nowy GPU w serwerze, niestandardowa dystrybucja).
Kiedy aktualizować sterownik, a kiedy odpuścić
Aktualizacja ma koszt: kilka–kilkanaście minut pracy i ryzyko, że coś przestanie działać. Dlatego opłaca się podchodzić do niej jak do małego projektu:
Aktualizuj, gdy nowa wersja:
naprawia konkretny błąd, który cię dotyka (kernel panic, wycieki pamięci, problemy ze wznowieniem po uśpieniu),
jest wymagana przez nową wersję CUDA/PyTorch, którą naprawdę chcesz użyć.
Nie aktualizuj „bo jest nowa”, jeśli obecna konfiguracja:
bez problemu obsługuje wybrane wersje CUDA / PyTorch,
nie generuje losowych freeze’ów i błędów.
Na maszynie do projektów ML lepiej mieć stabilny, „nudny” sterownik przez rok niż zmieniać go co dwa tygodnie w rytmie nowych gier.
CUDA Toolkit i cuDNN – kiedy instalować systemowo, a kiedy nie
CUDA systemowa vs CUDA „wbudowana” w PyTorch
Większość użytkowników myli dwa scenariusze:
CUDA systemowa – instalowana jako paczki systemowe (np. cuda-11-8 na Ubuntu, instalator .exe na Windows). Dodaje narzędzia, kompilator nvcc, biblioteki w /usr/local/cuda*.
CUDA „bundled” – wbudowana w pakiet PyTorch (wheel/conda). PyTorch przychodzi z własnym runtime CUDA i cuDNN, więc nie korzysta z twojej instalacji systemowej.
W scenariuszu typowego użytkownika:
pracujesz w PyTorch/TensorFlow, nie piszesz modułów C++/CUDA,
instalujesz biblioteki z pip/conda, bez ręcznego kompilowania.
W takim przypadku systemowa instalacja CUDA Toolkit jest zbędna. Wystarczy:
aktualny, stabilny sterownik NVIDIA,
PyTorch z wariantem „CUDA X.Y” dobranym z ich strony.
Mniej systemowej magii to mniej możliwych konfliktów typu „PyTorch używa innej wersji CUDA niż reszta pakietów”.
Kiedy systemowa CUDA jest rzeczywiście potrzebna
Systemowy Toolkit przydaje się, gdy:
piszesz własne kernle w CUDA i potrzebujesz nvcc,
kompilujesz rozszerzenia C++/CUDA, które oczekują konkretnej lokalizacji CUDA (np. niektóre projekty z GitHuba),
budujesz frameworki lub biblioteki od zera (kompilacja PyTorch/TensorFlow ze źródeł).
Wtedy rozsądniej jest:
wybrać jedną, konkretną wersję CUDA Toolkit (np. 11.8),
trzymać się jej przez dłuższy czas,
instalować pozostałe elementy (PyTorch i spółkę) tak, by pasowały właśnie do tej wersji.
Strategia „5 wersji CUDA obok siebie” kończy się problemami z $PATH, LD_LIBRARY_PATH i narzędziami, które łapią losową kombinację bibliotek.
Instalacja CUDA Toolkit na Ubuntu – wariant konserwatywny
Wariant dla osób, które naprawdę potrzebują Toolkitu:
Usuń stare paczki CUDA, jeśli bawiłeś się wcześniej:
Po tej operacji PyTorch i inne biblioteki nadal mogą używać wbudowanej wersji CUDA. Systemowa instalacja będzie używana głównie przez nvcc i projekty, które jawnie do niej linkują.
cuDNN: instalować ręcznie czy pozwolić PyTorchowi zrobić swoje
cuDNN to zestaw niskopoziomowych bibliotek dla sieci neuronowych (konwolucje, LSTM itd.). Bezpośrednio odpowiada za dużą część wydajności. W codziennej pracy z PyTorch:
użytkownik nie musi instalować cuDNN osobno,
pakiety PyTorch z CUDA mają cuDNN wbudowane i dopasowane wersją.
Ręczna instalacja cuDNN ma sens wtedy, gdy:
kompilujesz framework ze źródeł (TensorFlow, PyTorch),
pracujesz z narzędziami, które oczekują systemowego cuDNN (częściej w środowiskach serwerowych).
Na desktopie dla projektów ML najprostsza i najtańsza czasowo konfiguracja to: sterownik + PyTorch z CUDA + brak dodatkowego cuDNN w systemie.
Źródło: Pexels | Autor: Google DeepMind
Menedżery środowisk: conda, mamba, venv i pip – co, gdzie i po co
Dlaczego izolacja środowisk oszczędza godziny
Instalowanie wszystkiego globalnie (systemowy Python + pip) kusi prostotą, ale tylko na początku. Po kilku miesiącach:
różne projekty wymagają różnych wersji PyTorch/TensorFlow,
jedna biblioteka wymaga Pythona 3.11, druga 3.9,
aktualizacja pakietu pod jeden projekt psuje inny.
Menedżer środowisk rozwiązuje ten problem, tworząc oddzielne „mini-systemy” z własnym Pythonem i pakietami. Koszt – kilka sekund przy tworzeniu środowiska, oszczędność – brak wojen wersji.
conda: kombajn od Anacondy
conda łączy w sobie:
zarządzanie środowiskami (jak venv),
instalację pakietów binarnych (nie tylko Python, ale też CUDA, biblioteki C/C++).
Z punktu widzenia ML:
bardzo wygodne instalowanie PyTorch/TensorFlow z gotowymi paczkami,
łatwa obsługa różnych wersji Pythona równolegle,
niezależność od systemowych bibliotek w wielu przypadkach.
Podstawowy workflow:
# nowe środowisko z konkretnym Pythonem
conda create -n ml101 python=3.10
# aktywacja
conda activate ml101
# instalacja PyTorch (komenda z ich strony)
conda install pytorch pytorch-cuda=11.8 -c pytorch -c nvidia
Minusem conda jest wolniejsze rozwiązywanie zależności i nieco większe zużycie miejsca na dysku. Przy dzisiejszych cenach SSD i czasie, który oszczędza, zwykle to korzystny kompromis.
mamba: przyspieszony zamiennik conda
mamba korzysta z tego samego formatu pakietów i repozytoriów co conda, ale ma znacznie szybszy solver zależności. Nadaje się szczególnie wtedy, gdy:
często tworzysz nowe środowiska,
instalujesz większe zestawy pakietów naukowych.
Typowy układ:
# instalacja mamby w bazowym środowisku conda
conda install -n base -c conda-forge mamba
# tworzenie środowiska mambą
mamba create -n cv python=3.10
# aktywacja jak w conda
conda activate cv
# instalacja pakietów
mamba install pytorch pytorch-cuda=11.8 -c pytorch -c nvidia
Dla osoby, która nie chce tracić czasu na czekanie, aż conda „pomyśli”, mamba to prosta wygrana bez zmiany nawyków.
venv + pip: lekkie środowiska bez dodatkowych narzędzi
Standardowa biblioteka Pythona zawiera venv, które pozwala tworzyć izolowane środowiska bez conda. To dobry wybór gdy:
masz już zainstalowanego Pythona systemowo lub z oficjalnego instalatora,
potrzebujesz prostego, lekkiego setupu,
pracujesz głównie z pakietami z PyPI.
Podstawowy schemat:
# Linux / macOS
python3 -m venv .venv
source .venv/bin/activate
# Windows
python -m venv .venv
..venvScriptsactivate
# potem używasz pip jak zwykle
pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118
W tym wariancie nie masz „magicznej” obsługi CUDA w stylu conda, ale za to wszystko jest prostsze i bliższe temu, co dzieje się na serwerach produkcyjnych (gdzie często używa się pip + venv).
Jak łączyć conda/mamba z pip bez bałaganu
Realnie wiele projektów potrzebuje obu: pakiety binarne z conda i świeższe wersje bibliotek z pip. Żeby uniknąć chaosu:
Najpierw tworzysz środowisko conda/mamba.
Instalujesz ciężkie rzeczy (PyTorch, CUDA, duże zależności C/C++) przez conda/mambę.
Mniejsze, czysto pythonowe biblioteki dokładane są na końcu przez pip.
Przykład:
mamba create -n nlp python=3.10
conda activate nlp
# duże rzeczy z conda
mamba install pytorch pytorch-cuda=11.8 -c pytorch -c nvidia
# reszta z pip
pip install transformers datasets wandb
Dzięki temu unikasz sytuacji, w której pip podmienia biblioteki instalowane przez conda, co bywa źródłem „magicznych” błędów segmentacji albo sprzecznych wersji.
Instalacja PyTorch z GPU bez niespodzianek
Algorytm „od sterownika do importu”
Najprostszy, powtarzalny schemat, który działa na większości maszyn:
Sprawdź GPU i sterownik:
nvidia-smi
Jeśli komenda nie działa – sterownik jest źle zainstalowany lub go brak.
Utwórz nowe środowisko (conda/mamba lub venv) dla projektu.
Wejdź na stronę instalacji PyTorch i wybierz:
System (Linux/Windows),
Package: conda lub pip,
Compute Platform: CUDA X.Y (nie „CPU”).
Dobór właściwego wariantu instalacji PyTorch
Po wybraniu systemu, menedżera pakietów i wersji CUDA na stronie PyTorch pojawia się konkretna komenda instalacji. Tu pojawiają się pierwsze rozjazdy:
na conda/mamba – zwykle polecenie z kanałami -c pytorch -c nvidia,
na pip – adres --index-url wskazujący na koło z CUDA, np. cu118.
Z praktyki:
na laptopie / desktopowym Linuksie lub Windows – spokojnie można używać pip + venv,
gdy środowisk jest dużo, a projekty ciężkie (CV, RL) – wygodniejsza bywa conda/mamba, szczególnie przy kilku GPU.
Najczęstszy błąd to branie domyślnej komendy z sekcji „Pip” z zaznaczoną opcją „CUDA” i wklejenie jej do środowiska conda, w którym wcześniej zainstalowana była inna wersja PyTorch z CUDA. W efekcie powstaje hybryda, która działa do pierwszej poważniejszej aktualizacji.
Test minimalny po instalacji
Zamiast od razu odpalać duży projekt, lepiej wykonać krótki test:
torch.version.cuda jest None – zainstalowana jest wersja tylko CPU,
pojawia się np. 11.8 – to wersja kompatybilna z użytymi bibliotekami, niekoniecznie ta sama, co systemowy Toolkit.
Próby „uaktualnienia” tej wersji przez dogrywanie systemowego CUDA zwykle kończą się rozjechaniem środowiska. Zamiast tego lepiej przeinstalować PyTorch na wariant z inną wersją CUDA, zgodnie z macierzą zgodności ze strony PyTorch.
Aktualizacja PyTorch bez niszczenia projektu
Jeśli stary projekt działa na starszym PyTorch, a nowy wymaga świeższej wersji, najtańszym czasowo rozwiązaniem jest stworzenie nowego środowiska:
# stare środowisko, nie ruszamy
conda create -n project_old --clone project_old
# nowe środowisko pod nowszą wersję
conda create -n project_new python=3.10
conda activate project_new
# instalacja nowszego PyTorch zgodnie z instrukcją
Klucz w tym, żeby nie robić „masowej aktualizacji” w istniejącym środowisku produkcyjnym. Oszczędza to polowania na subtelne regresje i błędy numeryczne, które wychodzą dopiero po kilku dniach trenowania.
Typowe konflikty i błędy: komunikaty, przyczyny, szybkie naprawy
„CUDA driver version is insufficient for CUDA runtime version”
Ten komunikat oznacza, że:
sterownik NVIDIA jest za stary w stosunku do bibliotek CUDA używanych przez PyTorch,
PyTorch próbuje użyć funkcji, których sterownik nie rozumie.
Najprostsza ścieżka:
Sprawdź sterownik:
nvidia-smi
Porównaj jego wersję z tabelą „CUDA compatibility” na stronie NVIDIA.
Zdecyduj, co taniej zaktualizować:
jeśli sterownik jest bardzo stary – zaktualizuj sterownik,
jeśli korzystasz z nietypowego, stabilnego sterownika (np. na starym GPU) – zainstaluj PyTorch z niższą wersją CUDA.
Na starszych kartach (np. seria GTX 9xx) bardziej opłaca się dobrać adekwatny wariant PyTorch zamiast walczyć o najnowszy sterownik, który i tak nie przyniesie spektakularnego przyspieszenia.
„CUDA out of memory” przy pierwszym treningu
To nie konflikt wersji, ale bardzo częste potknięcie. Oznacza, że:
batch size lub model są za duże jak na pamięć karty,
inne procesy (np. przeglądarka z akceleracją GPU) zjadają część VRAM.
Zamiast zmieniać wersje PyTorch/CUDA, zwykle wystarczy:
zmniejszyć batch_size,
zamknąć aplikacje korzystające intensywnie z GPU,
na czas eksperymentów ograniczyć użycie GPU przez inne procesy (np. na serwerze CUDA_VISIBLE_DEVICES).
Jeżeli torch.version.cuda to None, zainstalowana jest wersja CPU-only.
Jeżeli używasz IDE (VS Code, PyCharm) – potwierdź, że interpreter wskazuje na właściwe środowisko, nie na systemowego Pythona.
Konflikty między pip i conda w jednym środowisku
Najbardziej zdradliwy scenariusz to:
instalacja PyTorch przez conda (z własnym CUDA),
później aktualizacja części bibliotek przez pip (np. pip install --upgrade torch).
Efekt: miks bibliotek, w którym część pochodzi z conda, a część z pip, często z różnymi wersjami CUDA. Objawy:
błędy segmentacji (Segmentation fault),
nagłe zamknięcie Pythona bez komunikatu,
dziwne błędy typu „symbol not found in …/libcudart.so”.
Szybsza jest ewakuacja do nowego środowiska niż próba ręcznego odkręcenia:
conda deactivate
conda create -n clean_ml python=3.10
conda activate clean_ml
# instalacja wszystkiego od nowa według przemyślanej kolejności
Problemy z LD_LIBRARY_PATH, PATH i wieloma wersjami CUDA
Przy kilku równoległych instalacjach CUDA (np. systemowa + w katalogu użytkownika + w dockerze) narzędzia łapią losowe biblioteki. Objawy:
różne wersje libcudart.so w zależności od katalogu uruchomienia,
kod działa z terminala, ale nie działa z poziomu IDE,
PyTorch ładuje się tylko po ustawieniu specyficznych zmiennych środowiskowych.
Minimalistyczny przepis:
trzymać jedną systemową instalację CUDA Toolkit (lub żadnej, jeśli nie jest potrzebna),
usunąć ręczne dopiski do LD_LIBRARY_PATH, które nie są konieczne,
korzystać z dockera tam, gdzie potrzeba wielu wersji CUDA naraz.
Na desktopie przeważnie wystarczy usunięcie starych katalogów /usr/local/cuda-X.Y i reset zmiennych środowiskowych w ~/.bashrc, a następnie poleganie na tym, co wnosi PyTorch w swoim pakiecie.
„Illegal instruction” lub nagłe crashe po imporcie
Na starszych CPU (bez nowszych rozszerzeń SIMD) lub bardzo starych dystrybucjach Linuksa import PyTorch może kończyć się komunikatem Illegal instruction lub natychmiastowym zamknięciem procesu. Dzieje się tak, gdy binarka PyTorch została zbudowana z założeniem wsparcia instrukcji niedostępnych na danym procesorze.
Realne opcje:
użyć starszej wersji PyTorch zbudowanej dla mniej „agresywnej” architektury CPU,
przesiąść się na nowszy system (często taniej czasowo niż debugowanie),
w ostateczności – samodzielnie skompilować PyTorch (zwykle przerost formy nad treścią dla pojedynczej maszyny domowej).
Windows vs Linux: dwa przepisy na stabilne środowisko ML
Scenariusz budżetowy na Windows
Na Windowsie pokusa instalacji wszystkiego „na raz” jest duża: instalatory Anacondy, CUDA, cuDNN, kolejne wersje Visual Studio. Im prostszy plan, tym lepiej:
Sterownik NVIDIA:
zainstaluj oficjalny sterownik Game Ready lub Studio z GeForce Experience albo z katalogu sterowników NVIDIA,
nie instaluj dodatkowo „CUDA Toolkit” tylko po to, by działał PyTorch – nie jest potrzebny.
Python:
najprościej – oficjalny instalator Pythona z python.org (zaznacz opcję „Add Python to PATH”),
alternatywnie – Miniconda, jeśli wolisz conda/mamba.
Środowisko wirtualne:
za pomocą python -m venv .venv w katalogu projektu lub przez conda.
PyTorch:
z komendy ze strony PyTorch, z odpowiednim --index-url (pip) lub przez conda.
Taki zestaw jest wystarczający do większości zastosowań: od prostych modeli NLP po średnie projekty CV. Dopiero gdy pojawia się konieczność kompilacji własnych rozszerzeń, sens ma doinstalowanie Visual Studio Build Tools i ewentualnie CUDA Toolkit.
Najpopularniejsze pułapki na Windows
Na Windowsie problemy częściej wynikają z:
kilku instalacji Pythona (MS Store, python.org, Anaconda),
IDE wskazującego na inny interpreter niż ten, w którym instalujesz pakiety,
instalacji starego CUDA Toolkit z tutoriala znalezionego w sieci.
Prosty sposób, by sprawdzić, którego Pythona używa dany terminal:
where python
python -c "import sys; print(sys.executable)"
Jeśli ścieżka nie prowadzi do katalogu, w którym spodziewasz się swojego środowiska (np. projekt.venvScriptspython.exe), to znaczy, że instalacje poszły w różne miejsca. Naprawa zazwyczaj sprowadza się do:
usunięcia zbędnych instalacji Pythona,
korzystania konsekwentnie z jednego menedżera środowisk (venv albo conda),
ustawienia właściwego interpretera w IDE.
Scenariusz budżetowy na Linux (Ubuntu / podobne)
Na Linuksie najwięcej czasu zjadają sterowniki i konflikty między pakietami dystrybucji a repozytoriami zewnętrznymi. Da się to uprościć:
Instalacja sterownika NVIDIA:
na Ubuntu – przez „Dodatkowe sterowniki” lub ubuntu-drivers autoinstall,
unikać jednoczesnego używania sterowników z repo distro i skryptów run z NVIDIA.
Brak systemowego CUDA Toolkit (na start):
dla typowego workflow z PyTorch lepiej zacząć bez Toolkitu,
w razie potrzeby dorzucić jedną, wybraną wersję (jak wcześniej opisano).
Źródła informacji
CUDA C Programming Guide. NVIDIA – Oficjalna dokumentacja CUDA, wersje, wymagania sterowników i zgodność
NVIDIA cuDNN Developer Guide. NVIDIA Developer – Opis cuDNN, kompatybilność z wersjami CUDA i GPU, zalecenia instalacji
PyTorch Documentation – Get Started with GPU Support. PyTorch – Instrukcje instalacji PyTorch z konkretnymi wersjami CUDA, wsparcie GPU
NVIDIA GPU Driver Documentation. NVIDIA Support – Informacje o sterownikach, cyklu wsparcia i zależnościach z CUDA
Ubuntu Server Guide – Graphics and GPU Acceleration. Canonical – Zalecenia instalacji sterowników NVIDIA i użycia GPU w Ubuntu LTS
Windows Subsystem for Linux Documentation. Microsoft – Opis WSL2, wsparcie GPU i integracja z narzędziami linuksowymi
