Wydajne trenowanie modeli ML na GPU: jak dobrać sprzęt, sterowniki i konfigurację środowiska

Dlaczego trenowanie modeli ML na GPU wymaga świadomej konfiguracji

CPU vs GPU w praktycznych treningach

GPU jest projektowane do wykonywania ogromnej liczby prostych operacji równolegle, co idealnie pasuje do obliczeń macierzowych w sieciach neuronowych. Różnica względem CPU jest szczególnie widoczna przy trenowaniu głębokich modeli, gdzie liczba parametrów i operacji na krok optymalizacji rośnie wykładniczo.

Trening małej sieci klasyfikacyjnej na klasycznym zbiorze danych może na CPU trwać kilkanaście minut, podczas gdy na przeciętnym GPU czas spada do minut lub nawet sekund na epokę. W przypadku bardziej złożonych modeli – jak CNN-y do wizji komputerowej czy transformatory w NLP – różnice są jeszcze bardziej drastyczne: godziny redukują się do kilkunastu minut, a dni do kilku godzin. To zmienia cały proces eksperymentowania: można częściej testować hipotezy, szybciej poprawiać architekturę i skracać cykl iteracyjny.

Jednocześnie GPU nie przyspiesza wszystkiego. Część pracy nadal wykonuje CPU: przygotowanie danych, augmentacja, wczytywanie z dysku, zarządzanie procesami. Bez odpowiedniej konfiguracji środowiska może się okazać, że GPU „czeka” na dane albo CPU blokuje kolejne kroki treningu, mimo że karta graficzna teoretycznie jest bardzo wydajna.

Na co faktycznie wpływa GPU podczas treningu

W praktyce GPU oddziałuje przede wszystkim na trzy obszary trenowania modeli ML:

• Czas pojedynczej iteracji (batcha) – każda propagacja w przód i wstecz przez sieć uruchamia zestaw operacji na tensorach. Im więcej rdzeni i większa przepustowość pamięci, tym szybciej te operacje się wykonują.
• Maksymalny rozmiar modelu – ilość dostępnej pamięci VRAM decyduje, jak duży model i jak duży batch można utrzymać jednocześnie. Duże modele NLP czy segmentacji obrazu bywają niemożliwe do uruchomienia na GPU z małą pamięcią.
• Efektywny batch size – większy batch często oznacza stabilniejsze gradienty i lepsze wykorzystanie GPU. Ograniczeniem jest właśnie VRAM. Dobrze dobrane GPU pozwala znacząco zwiększyć batch size względem CPU.

Do tego dochodzi obsługa niższej precyzji (FP16, bfloat16) oraz specjalizowanych jednostek (tensor cores), które mogą przyspieszać wybrane typy obliczeń, szczególnie w nowoczesnych frameworkach optymalizujących trening pod kątem mieszanej precyzji.

Trzy filary wydajności: sprzęt, sterowniki, środowisko

Na wydajność treningu modeli ML na GPU składają się trzy powiązane obszary:

• Sprzęt – karta graficzna, CPU, RAM, dyski, zasilacz, chłodzenie. Słaby dysk lub przegrzewające się GPU mogą zniweczyć korzyści z drogiej karty.
• Sterowniki i biblioteki niskopoziomowe – sterowniki NVIDIA, CUDA, cuDNN, biblioteki BLAS i inne komponenty, które decydują, jak dobrze framework potrafi „rozmawiać” z GPU.
• Konfiguracja środowiska i kodu – wersje PyTorch/TensorFlow, ustawienia batch size, num_workers w loaderach danych, mixed precision, logika augmentacji, zarządzanie wieloma GPU.

Wystarczy, że jeden z filarów jest źle ustawiony, aby całość działała znacznie poniżej potencjału. Przykład: wydajne GPU, poprawne sterowniki, ale dane trzymane na wolnym dysku HDD – efektem jest niska aktywność GPU i epoki trwające niepotrzebnie długo.

Jak rozpoznać źle skonfigurowane środowisko GPU

Poniżej kilka sygnałów ostrzegawczych, że środowisko trenowania modeli ML na GPU nie jest ustawione optymalnie:

• GPU usage nisko oscyluje (np. 10–30%) przy jednoczesnym wysokim użyciu CPU – oznaka, że CPU lub I/O są wąskim gardłem.
• VRAM prawie pusty podczas dużych treningów – może wskazywać na używanie CPU zamiast GPU albo zbyt mały batch size.
• Częste pauzy w treningu – widoczne jako „schodki” w logach czasu batchy; powód to najczęściej wczytywanie danych z dysku lub blokady w DataLoaderze.
• Błędy CUDA out of memory przy relatywnie małych modelach – sygnał, że pamięcią GPU zarządza się nieefektywnie (brak czyszczenia cache, zbyt duże batch size, niepotrzebne tensory na GPU).
• Brak wykrywania GPU przez framework – wynik błędnej kombinacji sterowniki/CUDA lub uruchamiania kodu w środowisku, które ma tylko wersję CPU.

Co sprawdzić przed inwestycją w GPU

Zanim przejdzie się do doboru i konfiguracji GPU, sensownie jest odpowiedzieć sobie na kilka pytań:

• Krok 1: Jaki typ modeli będzie trenowany? Klasyczne ML, małe sieci, czy duże transformery i generatywne modele?
• Krok 2: Gdzie pojawia się obecne wąskie gardło? Można użyć prostego profilowania: sprawdzić wykorzystanie CPU, GPU, dysku, RAM podczas treningu na mniejszym modelu.
• Krok 3: Czy planowany jest rozwój modeli? Jeśli dziś trenowany jest tylko prosty CNN, ale docelowo mają być większe architektury, lepiej od razu zaplanować zapas VRAM.
• Krok 4: Czy projekty wymagają multi-GPU (data parallel, model parallel, distributed training) czy wystarczy jedno mocne GPU?

Po tej wstępnej diagnozie łatwiej uniknąć inwestowania w zbyt drogi lub źle dopasowany sprzęt i skoncentrować się na elementach, które rzeczywiście skrócą czas treningu.

Jak dobrać GPU do zadań ML – kryteria, modele, kompromisy

Krok 1: Określenie typu zadań ML

Dobór karty graficznej do trenowania modeli ML zaczyna się od zrozumienia profilu zadań. Innej konfiguracji wymaga małe laboratorium klasycznych modeli, a innej intensywne eksperymenty z dużymi transformerami czy modelami generatywnymi.

Można wyróżnić kilka głównych scenariuszy:

• Klasyczne ML + małe sieci – proste MLP, małe CNN na niedużych obrazach, kilka milionów parametrów. Tu wystarczy średnia karta gamingowa z umiarkowaną ilością VRAM.
• Wizja komputerowa (CNN, detekcja, segmentacja) – YOLO, U-Net, ResNet na obrazach średniej lub wysokiej rozdzielczości. Trening potrafi zjeść dużo pamięci, szczególnie przy większym batch size.
• NLP (transformery) – BERT i pochodne, duże modele sekwencyjne. Modele NLP intensywnie korzystają z GPU, a VRAM często jest kluczowym ograniczeniem.
• Modele generatywne (GAN, diffusion, LLM) – wymagają bardzo dużych GPU, szczególnie przy finetuningu dużych modeli lub generowaniu wysokiej jakości obrazów.
• Reinforcement Learning z symulacją – często łączy intensywne obliczenia na GPU z dużym obciążeniem CPU (symulacje, logika środowiska).

Dla większości osób zaczynających z DL sensowny kompromis daje karta gamingowa ze średniej lub wyższej półki z wystarczającą ilością VRAM, przy czym priorytetem powinna być pamięć, a dopiero później liczba rdzeni.

Kluczowe parametry GPU istotne dla trenowania modeli

Przy wyborze GPU do ML warto zwrócić uwagę na kilka kluczowych cech:

• Pamięć VRAM – absolutnie krytyczna. To ona decyduje, czy model w ogóle się zmieści. Dla prostych projektów: 8–12 GB, dla wizji i średnich transformerów: często 12–24 GB, dla dużych LLM i modeli generatywnych – powyżej 24 GB.
• Przepustowość pamięci – wpływa na to, jak szybko GPU może przesyłać dane między pamięcią a rdzeniami. Przy operacjach tensorowych to często ważniejsze niż same „TFLOPS” w specyfikacji marketingowej.
• Obsługa FP16 / bfloat16 i tensor cores – nowoczesne GPU (np. z serii RTX czy A/H) mają akcelerację dla obliczeń w niższej precyzji. W połączeniu z mixed precision w PyTorch/TensorFlow pozwala znacząco przyspieszyć trening i zmieścić większe modele w tej samej ilości VRAM.
• TDP (pobór mocy) i chłodzenie – wpływa na stabilność i głośność pracy. GPU pracujące blisko limitu termicznego będzie zrzucać taktowanie, czyli realnie zwalniać w środku treningu.
• Interfejs i rozmiar fizyczny – konieczność dopasowania do płyty głównej (PCIe), obudowy i zasilacza.

Dla treningu modeli ML na GPU najczęściej największy wpływ na komfort pracy ma VRAM oraz obsługa mieszanej precyzji. Różnice w surowej mocy obliczeniowej między sąsiednimi modelami kart z tej samej generacji bywają mniej odczuwalne niż skok w ilości pamięci.

Gamingowe RTX vs prosumenckie i serwerowe GPU

Karty graficzne, które spotyka się przy trenowaniu modeli ML, można z grubsza podzielić na trzy kategorie:

• Karty gamingowe (GeForce RTX) – stosunkowo tanie, dostępne w sklepach konsumenckich, bardzo dobra wydajność FP16/FP32, zazwyczaj ograniczona ilość VRAM (8–24 GB). Dobry wybór dla pojedynczych stanowisk i mniejszych laboratoriów.
• Karty prosumenckie / workstation – często te same lub podobne chipy, ale z większą ilością VRAM i inną polityką sterowników. Mogą oferować lepszą stabilność pod obciążeniem i dłuższe wsparcie, ale są droższe.
• Karty serwerowe (A100, H100, L4 i podobne) – zaprojektowane pod data center, bardzo duża ilość VRAM, wysoka przepustowość, wsparcie dla NVLink i rozproszonego treningu. Przeznaczone raczej do klastrów i rozwiązań enterprise niż do pojedynczego domowego stanowiska.

W praktyce wiele zespołów zaczyna od RTX-ów, a dopiero przy rosnącej skali i specyficznych potrzebach przechodzi na GPU serwerowe lub chmurowe instancje z kartami klasy A100/H100.

Jeden mocny GPU czy kilka słabszych

Pojawia się dylemat: zainwestować w jeden mocny GPU z dużą ilością VRAM, czy kupić kilka słabszych kart? Odpowiedź zależy od charakteru pracy:

• Jeden mocny GPU sprawdza się, gdy:
  • modele są duże i wymagają dużo pamięci,
  • trening multi-GPU jest zbyt skomplikowany względem zysku,
  • chodzi głównie o szybkie iterowanie pojedynczych eksperymentów.
• Kilka słabszych GPU ma sens, gdy:
  • wiele osób ma trenować równolegle różne modele,
  • potrzebne jest skalowanie przez data parallel (np. duże batch size, trening rozproszony),
  • modele mieszczą się w pamięci pojedynczej karty, ale cała przepustowość jednego GPU to za mało.

W środowisku zespołowym często bardziej opłaca się mieć kilka kart średniej klasy, aby różne projekty mogły działać równolegle, niż jedną bardzo mocną kartę blokowaną przez jeden trening. Przy trenowaniu pojedynczych dużych modeli NLP wygodniejszy bywa natomiast pojedynczy GPU z dużą ilością VRAM.

Minimalne wymagania VRAM dla wybranych typów modeli

Przybliżone wymagania pamięci w kontekście typów zadań pozwalają od razu odrzucić zbyt słabe konfiguracje:

• Małe CNN na obrazach niskiej rozdzielczości: 8–10 GB VRAM wystarczy do komfortowej pracy.
• Modele detekcji/segmentacji na obrazach średniej rozdzielczości (np. YOLO, U-Net): 12–16 GB VRAM pozwala na rozsądny batch size.
• Modele NLP klasy BERT bazowy, średnie transformery: 12–24 GB VRAM dla finetuningu na pełnej precyzji, mniej przy agresywnej mieszanej precyzji.
• Większe modele generatywne, LLM większe niż kilkaset milionów parametrów: 24 GB VRAM i więcej, często w konfiguracji multi-GPU.

Reszta sprzętu pod GPU: CPU, RAM, dyski, zasilacz i chłodzenie

CPU – żeby GPU nie czekało

Procesor nie przyspieszy bezpośrednio obliczeń na GPU, ale może je skutecznie spowolnić, jeśli będzie zbyt słaby. Kluczowe zadania CPU to przygotowanie batchy (augmentacja, tokenizacja), zarządzanie procesami treningu i komunikacja z dyskiem.

Krok 1: określ profil obciążenia:

• Głównie wizja komputerowa z intensywną augmentacją w locie (np. rotacje, przekształcenia geometryczne, skomplikowane przekształcenia kolorów)? CPU będzie miał sporo pracy.
• NLP z transformatorami i prostą tokenizacją offline? Zwykle mniej obciążające dla CPU.
• Reinforcement Learning z dużą symulacją po stronie CPU? Tu procesor często staje się wąskim gardłem.

Krok 2: dobierz klasę CPU:

• 8–12 rdzeni dla pojedynczego GPU i typowych zadań DL to rozsądne minimum, żeby nie ograniczać karty.
• 16 rdzeni i więcej przy kilku GPU lub mocnej augmentacji danych i równoległych data loaderach.
• W zastosowaniach serwerowych (wiele kart, wielu użytkowników) sens mają procesory z dużą liczbą rdzeni i wsparciem dla szerokich linii PCIe.

Typowy błąd: bardzo mocne GPU sparowane ze słabym, 4-rdzeniowym procesorem. Objawem są niskie wartości GPU Utilization w monitorach typu nvidia-smi mimo niewielkiego batch size. Przy takim miksie nawet najlepsza karta nie pokaże pełni możliwości.

Co sprawdzić: liczba fizycznych rdzeni, obsługa PCIe (generacja i liczba linii), wsparcie dla dużej ilości RAM.

RAM – ile potrzebuje typowe środowisko ML

Pamięć operacyjna trzyma dane po stronie CPU: batch’e przed wysłaniem na GPU, cache datasetów, modele podczas pre- i postprocessingu. Braki RAM-u kończą się intensywnym swapowaniem na dysk, co praktycznie zabija wydajność.

Krok 1: oszacuj wymagania zadania:

• Proste eksperymenty, małe zbiory danych: 16 GB RAM bywa wystarczające, ale nie zostawia dużego marginesu.
• Średnie i większe projekty DL (wizja, NLP, RL) na jednym GPU: 32 GB RAM daje dużo większy komfort, szczególnie przy notebookach Jupyter i kilku równoległych procesach.
• Wiele GPU, równoległe treningi, duże dataset’y (np. obrazowe zapisane w pamięci dzielonej): 64 GB RAM i więcej często staje się standardem.

Krok 2: unikaj asymetrycznych konfiguracji (np. 3 kości w dual-channel), jeśli nie ma wyraźnego powodu. Spadek przepustowości pamięci CPU może odbić się na szybkości data loaderów.

Co sprawdzić: ilość RAM w kontekście wielkości datasetów, konfiguracja dual/quad-channel, użycie pamięci podczas typowego treningu (np. htop w Linuxie).

Dyski – SSD NVMe zamiast „wąskiego gardła”

Dla dużych datasetów to dysk dyktuje, jak szybko kolejne batch’e trafią do RAM-u, a potem na GPU. Tani HDD jest tu najczęstszą przyczyną „dziwnych” spadków wydajności.

Krok 1: wybierz typ dysku pod dataset:

• SSD SATA – wystarczy do małych i średnich projektów, ale przy większych zbiorach może nie nadążać przy wielu równoległych wątkach IO.
• SSD NVMe – najlepszy wybór pod intensywne trenowanie; wysoka przepustowość i niskie opóźnienia znacznie skracają czas wczytywania danych.
• HDD – może służyć jako archiwum, ale nie jako miejsce bezpośredniego odczytu danych treningowych.

Krok 2: zaplanuj podział:

• System operacyjny + narzędzia: osobna partycja lub dysk.
• Aktualnie używane dataset’y i cache’y (np. Hugging Face): szybki NVMe.
• Archiwum modeli, starych datasetów, logów: tani, pojemny dysk (SSD/HDD).

Przykład: jedna z częstych optymalizacji w praktyce to przeniesienie całego folderu z danymi z dysku talerzowego na NVMe – bez zmiany kodu, jedynie przez aktualizację ścieżek, trening przyspiesza nawet kilkukrotnie przy dużych datasetach obrazowych.

Co sprawdzić: typ i prędkość dysku, użycie IO podczas treningu (np. iotop), położenie folderów z danymi i cache’ami.

Zasilacz i okablowanie – stabilność pod pełnym obciążeniem

Trening modeli ML to nie test syntetyczny trwający minutę, tylko nierzadko wielogodzinne obciążenie blisko 100% TDP. Zasilacz musi wytrzymać taki scenariusz bez resetów i dropów napięcia.

Krok 1: policz budżet mocy:

• Weź TDP GPU (lub realny pobór z testów społeczności) i dodaj zapas ok. 30–40% na piki oraz resztę podzespołów.
• Przy jednym mocnym GPU klasa 750–850 W z certyfikatem 80+ Gold zwykle wystarcza.
• Przy dwóch GPU często potrzebne są zasilacze rzędu 1000–1200 W i więcej.

Krok 2: zwróć uwagę na liczby i typy złączy PCIe (8-pin/16-pin). Przejściówki dołączane do kart bywają awaryjne i przy długotrwałym obciążeniu mogą się przegrzewać.

Typowy błąd: zasilacz „no-name”, który teoretycznie ma wysoki wattage na naklejce, ale przy długim obciążeniu prowadzi do losowych restartów albo wyłączania się GPU.

Co sprawdzić: moc zasilacza z zapasem, jakość marki, liczba linii i złączy PCIe, stabilność pod obciążeniem (test np. jednoczesnym obciążeniem CPU i GPU).

Chłodzenie i obudowa – jak nie dławić GPU temperaturą

Wysokie temperatury powodują throttling (obniżenie taktowania), co oznacza realny spadek prędkości treningu. Dobre chłodzenie to nie tylko cisza, ale i stabilna wydajność.

Krok 1: oceniaj przepływ powietrza, nie tylko liczbę wentylatorów:

• Obudowa powinna mieć jasno zdefiniowany „strumień” – powietrze wpada z przodu/dół, wypada z tyłu/góry.
• Przy kilku GPU lepiej sprawdzają się obudowy o dobrej wentylacji niż zamknięte, wygłuszane konstrukcje.

Krok 2: monitoruj temperatury podczas treningu, a nie tylko w spoczynku. Narzędzia typu nvidia-smi, hwinfo, lm-sensors szybko pokażą, czy GPU dobija do limitów termicznych.

Co sprawdzić: temperatury CPU/GPU pod obciążeniem, taktowanie GPU w czasie (czy nie spada), ilość i kierunek wentylatorów w obudowie, dystans między kartami przy multi-GPU.

System operacyjny i sterowniki: wybór i instalacja krok po kroku

Jaki system pod trenowanie na GPU

Można trenować zarówno na Windowsie, jak i na Linuxie, ale różnice w komforcie pracy i wsparciu narzędzi bywają znaczące.

• Linux (Ubuntu, Debian, Rocky/Alma dla serwerów) – domyślny wybór dla większości środowisk ML, najlepsza integracja z narzędziami CUDA, łatwa automatyzacja (skrypty, Ansible, Docker).
• Windows – może być wygodny na stacjach roboczych, ale bywa bardziej kapryśny przy aktualizacjach sterowników i konfiguracji wielu środowisk.
• WSL2 – kompromis: Linux działający wewnątrz Windows, obecnie obsługujący CUDA na wielu konfiguracjach, ale wciąż z pewnym narzutem i dodatkowymi punktami awarii.

Jeśli sprzęt ma służyć przede wszystkim do ML i pracy zespołowej, Linux jest bezpieczniejszym wyborem. Jeśli to domowa stacja do wielu zadań (gry, inne aplikacje), Windows z dobrze skonfigurowanym WSL2 też się sprawdza.

Co sprawdzić: czy kluczowe biblioteki, których używa projekt, mają stabilne wsparcie na wybrany system; politykę aktualizacji (LTS vs częste upgrade’y).

Instalacja sterowników NVIDIA na Linuxie – scenariusz krok po kroku

Przykład dla Ubuntu LTS (bez użycia pakietów z GUI, krokami terminalowymi):

Krok 1: zablokowanie otwartych sterowników nouveau

sudo bash -c 'echo "blacklist nouveau" > /etc/modprobe.d/blacklist-nouveau.conf'
sudo bash -c 'echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist-nouveau.conf'
sudo update-initramfs -u
sudo reboot

Krok 2: dodanie repozytorium sterowników i instalacja

sudo add-apt-repository ppa:graphics-drivers/ppa
sudo apt update
ubuntu-drivers devices  # podpowiedź zalecanej wersji
sudo apt install nvidia-driver-XXX  # XXX zastąp sugerowaną wersją
sudo reboot

Krok 3: weryfikacja instalacji

nvidia-smi

Jeśli polecenie pokazuje listę GPU, sterownik działa. Jeśli pojawia się błąd, najczęściej problemem jest konflikt z nouveau, wcześniejszą wersją sterownika lub niezgodny kernel.

Co sprawdzić: wersję kernela (uname -r), obecność modułu nvidia (lsmod | grep nvidia), wynik nvidia-smi.

Instalacja sterowników na Windows – pułapki do uniknięcia

Na Windowsie najczęstszym źródłem problemów są nakładające się aktualizacje sterowników (np. przez Windows Update) oraz „resztki” po starych wersjach.

Krok 1: wyłącz instalowanie sterowników GPU przez Windows Update (w Ustawieniach lub przez polityki grupy w wersjach Pro).

Krok 2: pobierz sterownik bezpośrednio z witryny NVIDIA (wersja Studio lub Game Ready – do ML zwykle obie działają, ale stabilniejsze bywają wydania Studio).

Krok 3: podczas instalacji użyj opcji „Czysta instalacja”, aby nadpisać poprzednie ustawienia.

W razie poważnych problemów warto skorzystać z narzędzia typu DDU (Display Driver Uninstaller) w trybie awaryjnym, a następnie wykonać świeżą instalację pobranego sterownika.

Co sprawdzić: ustawienia Windows Update, wersję sterownika w panelu NVIDIA, wynik nvidia-smi uruchomionego z PowerShell/CMD.

Dopasowanie wersji sterownika do CUDA i frameworków

NVIDIA publikuje minimalne wersje sterowników wymagane przez konkretne wersje CUDA. Z kolei TensorFlow i PyTorch podają, z jakimi wersjami CUDA są zgodne. Kluczem jest zgodność w górę sterownika.

• Sterownik GPU musi być co najmniej tak nowy, jak wymaga tego wersja CUDA „dołączona” do PyTorch/TensorFlow.
• Framework zainstalowany z wbudowaną biblioteką CUDA (np. binarki PyTorch z +cu118) nie wymaga ręcznej instalacji systemowego CUDA, ale nadal wymaga odpowiednio nowego sterownika.

Typowy błąd: instalacja starego sterownika z repozytorium dystrybucji i nowej wersji PyTorch/TensorFlow. Efekt to błędy przy ładowaniu bibliotek CUDA lub brak widoczności GPU przez framework.

Co sprawdzić: wersję sterownika (nvidia-smi), dokumentację wybranej wersji frameworka (sekcja „CUDA compatibility”), informacje o minimalnej wersji sterownika wymaganej przez daną wersję CUDA.

CUDA, cuDNN i wersje frameworków: jak to ze sobą zgrać

Architektura zależności: kto od kogo zależy

Trenowanie na GPU opiera się na trzech głównych warstwach oprogramowania:

1. Sterownik NVIDIA – komunikuje się bezpośrednio z GPU.
2. CUDA Toolkit + cuDNN – dostarcza API do obliczeń na GPU i zoptymalizowane prymitywy dla sieci neuronowych.
3. Framework ML (PyTorch, TensorFlow, JAX) – korzysta z CUDA/cuDNN, ale najczęściej dostarcza własne, skompilowane wersje tych bibliotek.

Obecnie PyTorch i TensorFlow zazwyczaj są dystrybuowane w wariantach „z wbudowaną CUDA”. W praktyce oznacza to, że nie trzeba instalować systemowego CUDA Toolkit, o ile sterownik GPU jest wystarczająco nowy.

Co sprawdzić: czy projekt naprawdę wymaga systemowego CUDA (np. do własnych rozszerzeń C++/CUDA), czy wystarczy wariant binary frameworka z dołączoną CUDA.

Strategia 1: korzystanie z binarek frameworka z dołączoną CUDA

Ta strategia jest najprostsza dla większości użytkowników.

Krok 1: wybór wersji frameworka

• Sprawdź dokumentację PyTorch/TensorFlow dla interesującej wersji (np. 2.x) i wypisz obsługiwane kombinacje Python + CUDA.
• Wybierz kombinację, która pasuje do posiadanej wersji sterownika lub wymusi tylko niewielką aktualizację.

Krok 2: instalacja z poprawnym „cuxxx”

Dla PyTorch:

Instalacja PyTorch z odpowiednią wersją CUDA

Dla PyTorch najbezpieczniej trzymać się oficjalnych komend z konfiguratora na stronie pytorch.org.

Krok 1: sprawdź wersję sterownika i GPU

nvidia-smi

Zwróć uwagę na:

• wersję sterownika (np. 535.xx),
• model GPU (np. RTX 4090, A5000),
• wersję CUDA raportowaną przez nvidia-smi (np. CUDA Version: 12.2) – to wersja zgodna ze sterownikiem, niekoniecznie zainstalowany toolkit.

Krok 2: wybierz binarkę z odpowiednim „+cuXXX”

Na stronie PyTorch wybierz:

• system (Linux/Windows),
• menedżer pakietów (pip/conda),
• CUDA – np. CUDA 11.8 lub CUDA 12.1.

Następnie wykorzystaj podaną komendę. Przykład dla pip i CUDA 11.8:

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

Po instalacji sprawdź:

import torch
print(torch.__version__)
print(torch.version.cuda)
print(torch.cuda.is_available())

Typowy błąd: instalacja domyślnej wersji CPU (pip install torch bez wskazania repozytorium z CUDA). Efekt: torch.cuda.is_available() zwraca False, mimo działającego GPU.

Co sprawdzić: czy nazwa pakietu zawiera odpowiednie cuXXX, wynik torch.cuda.is_available(), zgodność wersji CUDA w torch.version.cuda z dokumentacją.

Instalacja TensorFlow z wbudowaną CUDA

TensorFlow 2.x w najnowszych wydaniach na Linuxie również dostarcza własne biblioteki CUDA/cuDNN, ale wymaga dopasowanego sterownika.

Krok 1: dobór wersji TensorFlow

• W dokumentacji TensorFlow sprawdź tabelę „Tested build configurations”.
• Wybierz wersję TF, która wspiera Twoją wersję CUDA lub niższą; kluczowa jest kolumna „Minimum driver version”.

Krok 2: instalacja z pip

pip install "tensorflow<2.16"  # przykład, konkretną wersję dobierz z tabeli zgodności

Weryfikacja:

import tensorflow as tf
print(tf.__version__)
print(tf.config.list_physical_devices("GPU"))

Jeśli lista GPU jest pusta, przyczyna zwykle leży w:

• zbyt starym sterowniku NVIDIA,
• konflikcie z inną instalacją CUDA w systemie,
• instalacji TensorFlow w środowisku bez dostępu do systemowych bibliotek.

Co sprawdzić: komunikaty przy imporcie TensorFlow (ostrzeżenia o wersjach CUDA/cuDNN), wynik tf.config.list_physical_devices(), zgodność wersji sterownika z tabelą w dokumentacji TF.

Strategia 2: własne CUDA Toolkit i cuDNN w systemie

Ten wariant jest potrzebny, gdy:

• kompilujesz własne rozszerzenia C++/CUDA,
• korzystasz z bibliotek, które oczekują systemowego CUDA (np. niektóre narzędzia RL, wizualizacji),
• chcesz mieć jedną, spójną wersję CUDA dla kilku frameworków i narzędzi.

Krok 1: wybór wersji CUDA Toolkit

Najpierw sprawdź:

• jaką wersję CUDA wspiera framework (PyTorch/TensorFlow/JAX) w Twoim wydaniu,
• jaką wersję CUDA wspierają zewnętrzne biblioteki (np. xformers, flash-attn).

Następnie wybierz najniższą wspólną wersję, która spełnia te wymagania. Zbyt nowa CUDA gdzieś w łańcuchu może wymusić aktualizację sterownika lub złamać binarne rozszerzenia.

Krok 2: instalacja CUDA Toolkit na Linuxie

Bezpieczniej używać paczek z repo NVIDIA, a nie przypadkowych .run.

# przykład dla Ubuntu, CUDA 11.8 – sprawdź aktualną instrukcję na developer.nvidia.com
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-ubuntu2204.pin
sudo mv cuda-ubuntu2204.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/11.8.0/local_installers/cuda-repo-ubuntu2204-11-8-local_*.deb
sudo dpkg -i cuda-repo-ubuntu2204-11-8-local_*.deb
sudo cp /var/cuda-repo-ubuntu2204-11-8-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt update
sudo apt install cuda-toolkit-11-8

Po instalacji dodaj CUDA do ścieżki (np. w ~/.bashrc):

export PATH=/usr/local/cuda-11.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-11.8/lib64:$LD_LIBRARY_PATH

Krok 3: instalacja cuDNN

cuDNN musi pasować do wersji CUDA Toolkit. Na koncie NVIDIA pobierz archiwum lub paczki dla konkretnej wersji CUDA.

Przykład dla archiwum tar:

tar -xzvf cudnn-linux-x86_64-8.x.x.x_cuda11-archive.tar.xz
sudo cp cuda/include/cudnn*.h /usr/local/cuda/include/
sudo cp -P cuda/lib/libcudnn* /usr/local/cuda/lib64/
sudo chmod a+r /usr/local/cuda/include/cudnn*.h /usr/local/cuda/lib64/libcudnn*

Weryfikacja:

nvcc --version          # wersja CUDA Toolkit
ls /usr/local/cuda/lib64 | grep cudnn

Typowy błąd: nadpisanie istniejącej instalacji CUDA inną wersją bez zmiany ścieżek. Frameworky widzą wtedy nie to, czego oczekują ich binarki.

Co sprawdzić: ścieżki w PATH/LD_LIBRARY_PATH, zgodność numerów wersji CUDA i cuDNN z wymaganiami frameworków, brak „duplikatów” CUDA w kilku lokalizacjach.

Równoległe wersje CUDA i frameworków na jednej maszynie

Na serwerach często trzeba utrzymać kilka projektów z różnymi wersjami CUDA. Da się to zrobić, ale wymaga dyscypliny.

Krok 1: instalacja wielu wersji CUDA w różnych katalogach

Przykładowe układy:

• /usr/local/cuda-11.8,
• /usr/local/cuda-12.1.

Symboliczny link /usr/local/cuda może wskazywać jedną z nich, ale dla porządku lepiej w środowisku projektu wskazywać pełną ścieżkę.

Krok 2: per-projektowe ustawianie zmiennych środowiskowych

Wewnątrz aktywowanego środowiska (Conda/pipenv) dodaj skrypt inicjalizacyjny, np. env.sh:

export CUDA_HOME=/usr/local/cuda-11.8
export PATH=$CUDA_HOME/bin:$PATH
export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH

Uruchamiaj trening komendą:

source env.sh
python train.py

Takie podejście pozwala dwóm projektom z różnym CUDA działać na tym samym serwerze bez konfliktów.

Co sprawdzić: jaka wersja CUDA jest używana w danym terminalu (nvcc --version), wynik echo $CUDA_HOME, brak mieszania ścieżek do różnych wersji CUDA w jednym środowisku.

Debugowanie błędów „CUDA not found” i „unsatisfied dependency”

Problemy z zależnościami często objawiają się dopiero przy imporcie frameworka lub przy pierwszym użyciu GPU.

Krok 1: przechwycenie pełnego komunikatu błędu

Nie obcinaj stack trace. Znaczenie ma konkretny symbol lub nazwa biblioteki, np. libcudart.so.11.0: cannot open shared object file albo cuDNN version mismatch.

Krok 2: sprawdzenie bibliotek dynamicznych

ldd $(python -c "import torch, os; print(os.path.dirname(torch.__file__))")/lib/libcudart.so

lub dla TensorFlow – na konkretnej bibliotece z katalogu site-packages. Brakujące zależności pojawią się jako not found.

Krok 3: test prostego skryptu GPU

import torch
x = torch.rand((1024, 1024), device="cuda")
y = torch.mm(x, x)
print(y[0, 0])

Jeśli import działa, ale pierwsze użycie GPU zgłasza błąd, zwykle chodzi o konflikt wersji CUDA/cuDNN lub za mało pamięci VRAM.

Co sprawdzić: pełny komunikat błędu, wynik ldd na bibliotekach CUDA w katalogu frameworka, aktualność sterownika względem wersji CUDA w komunikacie.

Środowiska Python/Conda i izolacja projektów

Dlaczego izolacja środowisk jest kluczowa przy trenowaniu na GPU

Frameworki ML mają skomplikowane zależności: konkretne wersje CUDA, cuDNN, NumPy, kompilerów. Instalowanie wszystkiego globalnie prędzej czy później kończy się konfliktem i niestabilnością.

Rozdzielenie projektów na osobne środowiska:

• pozwala utrzymać różne wersje frameworków na jednym serwerze,
• ułatwia odtwarzanie konfiguracji (np. na innej maszynie czy w chmurze),
• chroni przed „psuciem” działających projektów przez testowanie nowych bibliotek.

W praktyce najlepszy efekt daje połączenie: izolowane środowiska (Conda/pip + venv) + spójna konfiguracja GPU (sterownik, niskopoziomowe biblioteki).

Co sprawdzić: czy każdy projekt ma własne środowisko, czy na maszynie jest tylko jedna globalna instalacja Pythona z frameworkami ML.

Conda vs venv/pip – co wybrać pod GPU

Przy pracy z GPU Conda ma kilka przewag, ale nie zawsze jest konieczna.

• Conda/Miniconda/Mambaforge – potrafi zarządzać binarnymi zależnościami (CUDA, cuDNN, MKL), łatwo używać różnych wersji Pythona; dobre na serwery i złożone projekty.
• venv + pip – lżejsze, wystarczające, gdy korzystasz z binarek frameworków z dołączoną CUDA i nie potrzebujesz systemowego CUDA w środowisku.

Na start z GPU najwygodniejsze jest Conda lub Mambaforge (Conda z szybszym resolverem mamba).

Co sprawdzić: który menedżer pakietów jest zalecany przez zespół/projekt, czy projekt wymaga specyficznych pakietów systemowych, które Conda ułatwi dostarczyć.

Instalacja i podstawy pracy z Condą

Krok 1: instalacja Miniconda lub Mambaforge

# przykład dla Mambaforge (Linux x86_64)
wget https://github.com/conda-forge/miniforge/releases/latest/download/Mambaforge-Linux-x86_64.sh
bash Mambaforge-Linux-x86_64.sh
# zaakceptuj licencję, wskaż katalog instalacji

Po instalacji dodaj inicjalizację do shella:

conda init bash

Krok 2: tworzenie środowiska pod konkretny projekt

Załóżmy, że projekt wymaga Pythona 3.10 i PyTorch z CUDA 11.8.

mamba create -n proj-ml python=3.10
conda activate proj-ml
# następnie użyj oficjalnej komendy PyTorch (pip lub conda)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

Dla TensorFlow można użyć:

mamba create -n tf-gpu python=3.10
conda activate tf-gpu
pip install "tensorflow<2.16"

Co sprawdzić: nazwy środowisk i ich Pythona (python --version), czy aktywacja środowiska jest wyraźnie widoczna w promptcie, czy w katalogu projektu nie ma przypadkowych venv kolidujących z Condą.

Tworzenie środowisk z plików specyfikacji (environment.yml)

Na serwerach i w zespołach przydaje się deklaratyjne opisanie środowiska.

Przykładowy environment.yml dla projektu PyTorch:

name: proj-ml
channels:
  - pytorch
  - nvidia
  - conda-forge
dependencies:
  - python=3.10
  - pytorch=2.1
  - torchvision
  - torchaudio
  - pytorch-cuda=11.8
  - cudatoolkit=11.8
  - pip
  - pip:
      - numpy==1.26
      - hydra-core

Tworzenie środowiska:

Najczęściej zadawane pytania (FAQ)

Jaka karta graficzna jest najlepsza do trenowania modeli ML w domu?

Do domowego trenowania większości modeli DL wystarcza karta gamingowa ze średniej lub wyższej półki, np. z serii RTX z minimum 8–12 GB VRAM. Przy projektach z wizji komputerowej na większych obrazach lub średnich transformerach lepiej celować w 12–24 GB VRAM, bo to pamięć, a nie same „TFLOPS”, najczęściej ogranicza rozmiar modelu i batch size.

Krok 1: określ typ zadań (małe CNN vs BERT vs modele generatywne). Krok 2: sprawdź, ile VRAM zużywa Twój obecny model na mniejszym batchu. Krok 3: dodaj zapas 30–50% pod większy batch i rozwój projektu. Co sprawdzić: czy wybrana karta fizycznie wejdzie do obudowy i czy zasilacz ma odpowiedni zapas mocy.

Dlaczego GPU nie przyspiesza mojego treningu tak bardzo, jak się spodziewałem?

Najczęstszy powód to wąskie gardło poza GPU: wolny CPU, pojedynczy wątek w DataLoaderze, mała liczba workerów, dysk HDD zamiast SSD albo ciężka augmentacja danych liczona na CPU. Efekt widać w monitoringu: GPU usage niskie (np. 10–30%), a CPU blisko 100% lub wysoki czas oczekiwania na I/O.

Krok 1: uruchom monitoring (nvidia-smi + htop + iotop). Krok 2: jeśli CPU jest zapchany, zwiększ num_workers w DataLoaderze i przenieś cięższą logikę wczytywania/augmentacji na osobne procesy. Krok 3: przenieś dane na szybki dysk SSD. Co sprawdzić: czy batch size jest wystarczająco duży, by „nakarmić” GPU i czy model faktycznie działa na cuda(), a nie na CPU.

Jak dobrać odpowiedni rozmiar VRAM do moich modeli ML?

Minimalnie: 8–12 GB VRAM starcza na małe CNN i proste projekty. Dla wizji komputerowej (YOLO, U-Net, ResNet na większych obrazach) oraz średnich transformerów sensowny zakres to 12–24 GB. Przy dużych modelach NLP, LLM-ach i zaawansowanych modelach generatywnych często potrzeba więcej niż 24 GB lub kilku GPU.

Praktyczny sposób: krok 1 – uruchom model na dostępnej karcie i stopniowo zwiększaj batch size, obserwując zużycie VRAM w nvidia-smi. Krok 2 – zapisz maksymalny stabilny batch size. Krok 3 – zdecyduj, czy taki batch jest wystarczający dla Twoich eksperymentów. Co sprawdzić: czy używasz mixed precision (FP16/bfloat16), bo może „uwolnić” kilka dodatkowych GB VRAM.

Jakie sterowniki i biblioteki muszę zainstalować, żeby GPU działało z PyTorch/TensorFlow?

Podstawowy zestaw na NVIDIA to: aktualny sterownik GPU, zgodna wersja CUDA oraz cuDNN. Wiele problemów bierze się z mieszania wersji. Najbezpieczniej korzystać z gotowych środowisk Conda lub kontenerów (Docker), gdzie wersje PyTorch/TensorFlow są już dopasowane do konkretnej wersji CUDA.

Krok 1: sprawdź wersję sterownika GPU (nvidia-smi) i systemu. Krok 2: przy instalacji PyTorch/TensorFlow użyj oficjalnego konfiguratora na stronie projektu i skopiuj dokładnie podaną komendę (z odpowiednią wersją CUDA). Krok 3: po instalacji uruchom w Pythonie krótki test (torch.cuda.is_available() lub tf.config.list_physical_devices(’GPU’)). Co sprawdzić: czy nie masz kilku sprzecznych instalacji CUDA w systemie i czy środowisko wirtualne używa właściwych bibliotek.

Dlaczego dostaję błąd „CUDA out of memory” mimo niewielkiego modelu?

Przyczyną często nie jest sam model, ale zbyt duży batch size, trzymanie niepotrzebnych tensorów w pamięci (np. logów, historii lossów na GPU), brak torch.no_grad() przy ewaluacji albo kilka procesów używających tej samej karty. Czasem VRAM jest też „pofragmentowany” przez poprzednie uruchomienia i wymaga ręcznego czyszczenia.

Krok 1: zmniejsz batch size o połowę i sprawdź, czy problem znika. Krok 2: upewnij się, że przy ewaluacji używasz z torch.no_grad() / tf.no_gradient() i nie przechowujesz całych batchy predykcji na GPU. Krok 3: po zakończonym treningu lub przy pętli eksperymentów dodaj czyszczenie pamięci (torch.cuda.empty_cache()). Co sprawdzić: czy inne procesy (np. Jupyter, drugi trening) nie zużywają VRAM-u na tej samej karcie.

Jak zoptymalizować DataLoader, żeby GPU nie czekało na dane?

Kluczowe jest równoległe wczytywanie i przygotowanie danych. Pojedynczy wątek i wolny dysk HDD powodują „schodki” w czasie batchy oraz niskie wykorzystanie GPU. Dobry DataLoader powinien ładować kolejne batchy w tle, podczas gdy GPU liczy poprzedni.

Krok 1: zwiększ num_workers stopniowo (np. 0 → 2 → 4 → 8) i obserwuj, kiedy GPU usage się stabilizuje, a CPU nie jest jeszcze przeciążony. Krok 2: włącz pin_memory=True (w PyTorch) przy trenowaniu na GPU. Krok 3: przechowuj dane na SSD, a nie na HDD lub zewnętrznym dysku USB 2.0. Co sprawdzić: czy augmentacje nie są zbyt ciężkie na CPU – w razie potrzeby przenieś część z nich na GPU lub uprość pipeline.

Skąd mam wiedzieć, czy moje środowisko GPU jest dobrze skonfigurowane?

Po dobrze ustawionym środowisku widać stabilnie wysokie użycie GPU, równomierne czasy batchy oraz brak dziwnych pauz w logach. VRAM jest wykorzystany w sensowny sposób (nie „pusty” przy dużych modelach, ale też nie na 100% z częstymi crashami), a trening bez problemów rozpoznaje i używa kartę.

Krok 1: monitoruj trening przez kilka epok (nvidia-smi, wykresy czasu batchy, zużycie CPU/RAM/dysku). Krok 2: eliminuj po kolei wąskie gardła: dysk → DataLoader → CPU → parametry modelu/batch. Krok 3: przetestuj prosty benchmark (np. standardowy model z tutoriala) i porównaj czas epok z typowymi wartościami dla Twojej klasy GPU. Co sprawdzić: czy jakakolwiek zmiana (większy batch, mixed precision, więcej workerów) faktycznie skraca czas epoki – jeśli nie, wróć do profilowania krok po kroku.

Kluczowe Wnioski

• GPU dramatycznie skraca czas treningu głębokich modeli (z godzin do minut), ale nie zastępuje CPU: przy złej konfiguracji dane przygotowywane przez procesor i dysk sprawiają, że karta graficzna bezczynnie „czeka”.
• O wydajności decydują trzy filary działające razem: krok 1 – sensowny dobór sprzętu (GPU, CPU, RAM, dysk), krok 2 – poprawne sterowniki i biblioteki (NVIDIA, CUDA, cuDNN, BLAS), krok 3 – dopracowana konfiguracja środowiska i kodu (batch size, num_workers, mixed precision, wielo‑GPU).
• GPU wpływa głównie na: czas pojedynczego batcha, maksymalny rozmiar modelu i efektywny batch size; ilość VRAM wyznacza granicę tego, jak duże modele i z jakim batchem da się realnie trenować.
• Mieszana precyzja (FP16, bfloat16) i wyspecjalizowane jednostki typu tensor cores potrafią dać odczuwalne przyspieszenie, ale wymagają spójnych wersji frameworków i bibliotek – bez tego potencjał sprzętu zostaje zmarnowany.
• Typowe sygnały złej konfiguracji to: niskie użycie GPU przy wysokim obciążeniu CPU, prawie pusty VRAM przy dużym treningu, „schodki” w czasie batchy przez I/O, częste CUDA out of memory oraz sytuacja, w której framework w ogóle nie widzi GPU.
• Krok 1 przed zakupem GPU: określ typ modeli (małe CNN vs duże transformatory); krok 2: sprawdź aktualne wąskie gardło (CPU, GPU, dysk, RAM); krok 3: zaplanuj zapas VRAM pod przyszłe projekty; krok 4: oceń, czy faktycznie potrzebujesz multi‑GPU, czy jedno mocne GPU wystarczy.