Start / Poradniki / Rozwiązywanie problemów / Windows

CUDA działa na Windowsie, ale nie w WSL2

WindowsLinux

Autor: Jakub Rusinowski · Ostatnia aktualizacja: 1 września 2026

Edukator AI i prowadzący warsztaty z wdrażania lokalnych modeli LLM

Komunikat błędu

NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.

/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link

>>> torch.cuda.is_available()
False

Który to przypadek?

Jeśli widzisz	Przyczyną jest	Przejdź do
Uruchomiłeś `apt install nvidia-driver-*` albo instalator `.run` wewnątrz WSL	Linuksowy sterownik nadpisał zaślepkę libcuda, którą sterownik Windows rzutuje do WSL	Rozwiązanie 1: usuń linuksowy sterownik z dystrybucji
`nvidia-smi` zgłasza „command not found” wewnątrz WSL	Rzutowany katalog sterownika nie jest w twoim PATH	Rozwiązanie 2: wywołaj go z /usr/lib/wsl/lib/nvidia-smi
Działało, po czym przestało po aktualizacji Windowsa albo po uśpieniu	Maszyna wirtualna WSL trzyma nieaktualne rzutowanie sterownika hosta	Rozwiązanie 3: wsl --shutdown i ponowne uruchomienie
Ostrzeżenie `ldconfig.real ... is not a symbolic link` przy każdym uruchomieniu apt	Rzutowanie WSL jest tylko do odczytu i nie utrzyma prawdziwych dowiązań; większość loaderów to ignoruje, część nie	Rozwiązanie 5: odtwórz dowiązania w katalogu z prawem zapisu
`wsl cat /proc/version` pokazuje jądro starsze niż 5.10.16.3	Jądro WSL jest starsze niż użyteczna parawirtualizacja GPU	Rozwiązanie 4: wsl.exe --update

Kiedy się pojawia

Karta jest sprawna i Windows ją widzi. nvidia-smi w PowerShellu wypisuje normalną tabelę, gry działają, a torch.cuda.is_available() zwraca True w windowsowym Pythonie. Przekraczasz granicę do swojej dystrybucji Ubuntu — i to samo GPU znika.

Instalowałeś CUDA w WSL według poradnika dla natywnego Linuksa, który kazał najpierw zainstalować sterownik.
Wybrałeś z repozytorium apt metapakiet cuda, cuda-13-0 albo cuda-drivers.
Używasz Docker Desktop z backendem WSL2, a --gpus all zawodzi w kontenerach.
Wszystko działało do aktualizacji funkcji Windowsa albo dłuższego uśpienia, a teraz nie działa.
Jesteś na Windowsie 10 ze starszym buildem albo masz kartę generacji Maxwell.

Co się właściwie dzieje

WSL2 nie ma własnego sterownika GPU i nie ma go mieć. Sterownik NVIDII zainstalowany na Windowsie jest rzutowany do linuksowej maszyny wirtualnej w /usr/lib/wsl/lib, gdzie pojawia się jako libcuda.so i pokrewne — zaślepka wspierana przez sterownik hosta. Wskazówka NVIDII jest w tej sprawie nietypowo dosadna: sterownik Windows to jedyny sterownik, jakiego potrzebujesz, i nie wolno instalować żadnego linuksowego sterownika GPU NVIDII wewnątrz WSL 2. Zainstalowanie go nadpisuje rzutowaną zaślepkę linuksowym sterownikiem, który nie ma z jakim sprzętem rozmawiać, a dostęp do GPU pozostaje zepsuty do czasu jego usunięcia. To przyczyna przytłaczającej większości zgłoszeń „CUDA działa na Windowsie, ale nie w WSL” — i dlatego rozwiązanie polega na odejmowaniu, a nie na dodawaniu.

Jak to naprawić

1. Usuń każdy linuksowy sterownik NVIDII zainstalowany w dystrybucji

Zrób to najpierw, zanim cokolwiek zainstalujesz. Jeśli dpkg -l | grep nvidia wypisuje wewnątrz WSL pakiety sterownika — nvidia-driver-*, libnvidia-*, nvidia-dkms-* — to one są problemem. Ich wyczyszczenie pozwala rzutowaniu z hosta znów przejąć rolę przy następnym starcie. Instalator .run wymaga własnego deinstalatora (sudo /usr/bin/nvidia-uninstall).

⚠️ To usuwa pakiety wyłącznie z dystrybucji WSL. Nie rusza twojego sterownika Windows, twojego GPU ani niczego poza WSL — ale przeczytaj listę, którą wypisze apt, zanim ją zatwierdzisz.

bash

# bash, inside WSL — see what is installed
dpkg -l | grep -i nvidia

# Purge Linux driver packages (NOT the CUDA toolkit)
sudo apt-get purge -y "nvidia-driver-*" "libnvidia-*" "nvidia-dkms-*"
sudo apt-get autoremove -y

Czy zadziałało? Uruchom wsl --shutdown w PowerShellu, otwórz dystrybucję ponownie i sprawdź, czy rzutowanie jest na miejscu. Biblioteka powinna być obecna w /usr/lib/wsl/lib.

ls -l /usr/lib/wsl/lib/libcuda.so*
/usr/lib/wsl/lib/nvidia-smi

2. Instaluj wyłącznie wariant toolkitu CUDA dla WSL-Ubuntu

Toolkit CUDA i sterownik graficzny to dwie różne rzeczy, a wewnątrz WSL chcesz toolkit bez sterownika. NVIDIA publikuje wariant pakietu WSL-Ubuntu, który celowo go pomija. Wybierz właśnie ten na stronie pobierania CUDA i nie zaznaczaj metapakietów cuda, cuda-13-x ani cuda-drivers — one wciągają linuksowy sterownik z powrotem i odsyłają cię do punktu wyjścia. Jeśli po instalacji nvidia-smi nie ma w twoim PATH, znajdziesz go w /usr/lib/wsl/lib/nvidia-smi.

bash

# bash, inside WSL — install the toolkit ONLY, never the driver meta-packages
sudo apt-get install -y cuda-toolkit-13-0

# NOT these:
#   sudo apt-get install cuda
#   sudo apt-get install cuda-drivers

Czy zadziałało? Kompilator zgłasza wersję, a środowisko uruchomieniowe widzi urządzenie. Jeśli nvcc działa, a nvidia-smi nie, wciąż masz problem ze sterownikiem, a nie z toolkitem.

nvcc --version
/usr/lib/wsl/lib/nvidia-smi
python3 -c "import torch; print(torch.cuda.is_available())"

3. Zrestartuj całą maszynę wirtualną WSL, zanim zaczniesz cokolwiek debugować

wsl --shutdown to najtańsze rozwiązanie na tej stronie i naprawia realną klasę awarii: maszyna wirtualna WSL trzyma rzutowanie sterownika hosta z chwili swojego startu, więc aktualizacja sterownika Windows zainstalowana przy działającej dystrybucji zostawia maszynę ze starym. Zamknięcie okna terminala tego nie załatwia — maszyna wirtualna działa w tle jeszcze kilka sekund, a często znacznie dłużej.

PowerShell

# PowerShell, on the Windows side
wsl --shutdown
wsl --status

# then reopen your distro

Czy zadziałało? W świeżo uruchomionej dystrybucji nvidia-smi powinno wypisać to samo GPU i tę samą wersję sterownika co w PowerShellu.

nvidia-smi --query-gpu=name,driver_version --format=csv

4. Sprawdź progi platformy — build Windowsa, jądro WSL i generację GPU

Przekazanie GPU wymaga Windowsa 11 albo Windowsa 10 w buildzie 19043 lub nowszym oraz jądra WSL co najmniej 4.19.121 — w praktyce chcesz 5.10.16.3 lub nowsze. Karty generacji Maxwell nie są obsługiwane pod WSL, więc praktycznym wymogiem jest Pascal lub nowszy, a to poprzeczka wyższa niż na natywnym Windowsie. wsl.exe --update pobiera aktualne jądro.

PowerShell

# PowerShell
winver                 # Windows version and build
wsl.exe --update
wsl cat /proc/version  # the WSL kernel version

5. Napraw ostrzeżenie o dowiązaniu libcuda, nie ruszając rzutowania tylko do odczytu

/usr/lib/wsl/lib to rzutowanie sterownika Windows dostępne tylko do odczytu, więc ostrzeżenia is not a symbolic link nie da się naprawić na miejscu — a próby kończą się zepsuciem działającej konfiguracji. Bezpieczna forma to skopiowanie bibliotek gdzieś, gdzie masz prawo zapisu, odtworzenie tam dowiązań i umieszczenie tego katalogu przed ścieżką WSL w konfiguracji loadera. Zauważ, że przy większości zastosowań to kosmetyka: ostrzeżenie jest nieszkodliwe, dopóki loader, z którego korzystasz, faktycznie nie podąża za dowiązaniem.

⚠️ wsl --shutdown resetuje rzutowanie w /usr/lib/wsl/lib, a nie twoją kopię — więc po aktualizacji sterownika Windows twoje skopiowane biblioteki są nieaktualne i trzeba je odtworzyć, inaczej będziesz pracować na starym libcuda.

bash

# bash, inside WSL
sudo mkdir -p /usr/lib/wsl/drivers-copy
sudo cp /usr/lib/wsl/lib/libcuda.so.1.1 /usr/lib/wsl/drivers-copy/
sudo ln -sf /usr/lib/wsl/drivers-copy/libcuda.so.1.1 /usr/lib/wsl/drivers-copy/libcuda.so.1
sudo ln -sf /usr/lib/wsl/drivers-copy/libcuda.so.1   /usr/lib/wsl/drivers-copy/libcuda.so
echo "/usr/lib/wsl/drivers-copy" | sudo tee /etc/ld.so.conf.d/000-wsl-cuda.conf
sudo ldconfig

Czy zadziałało? Ostrzeżenie powinno zniknąć przy następnym sudo ldconfig, a loader powinien rozwiązywać libcuda do twojej kopii.

sudo ldconfig 2>&1 | grep -i libcuda || echo "no libcuda warnings"
ldconfig -p | grep libcuda

6. Zastanów się, czy WSL jest ci w ogóle potrzebny Najczęstsze rozwiązanie

Warto powiedzieć wprost, bo wiele poradników sugeruje coś innego: na maszynie z jednym GPU, do Ollamy albo LM Studio, natywny Windows jest prostszy i mniej więcej tak samo szybki. WSL zarabia na siebie wtedy, gdy potrzebujesz linuksowego toolchainu — vLLM, buildu CUDA, stosu pythonowego, który na Windowsie stawia opór. Kosztuje cię za to Unified Memory, niedostępna pod WSL, oraz przypięta pamięć systemowa, której tam jest niewiele. Jeśli trafiłeś do WSL tylko dlatego, że poradnik używał basha, praca natywna usuwa całą tę stronę z twojego życia. Dopasuj model do karty i gotowe.

Sprawdź, co zmieści się na twoim sprzęcie — sprawdź, które modele pasują do twojej karty, zanim spędzisz wieczór na grzebaniu w sterownikach
Otwórz kalkulator VRAM →

Jeśli nic z tego nie pomogło

Jeśli nvidia-smi działa w WSL, a twoje zadanie wciąż nie widzi GPU, problem przesunął się dalej — do środowiska kontenerowego albo do frameworka. Docker Desktop z backendem WSL2 jedzie dokładnie po tej instalacji, więc naprawa WSL naprawia Dockera — ale kontener potrzebuje jeszcze NVIDIA Container Toolkit.

Dołącz to, zgłaszając problem

Wynik wsl cat /proc/version oraz winver
dpkg -l | grep -i nvidia z wnętrza dystrybucji
Wynik nvidia-smi z PowerShella i dokładny komunikat błędu z wnętrza WSL
Czy instalowałeś CUDA wariantem WSL-Ubuntu, czy zwykłym pakietem linuksowym

Dotyczy także: Linux

Powiązane

Model, który mieści się na większości zestawów:

Zobacz model i wymagania →

Najczęstsze pytania

Czy muszę instalować sterownik NVIDII wewnątrz WSL?

Nie, a zrobienie tego psuje dostęp do GPU. NVIDIA stwierdza, że sterownik graficzny Windows jest jedynym wymaganym sterownikiem i że wewnątrz WSL 2 nie należy instalować żadnego linuksowego sterownika GPU. Sterownik Windows jest rzutowany do dystrybucji w /usr/lib/wsl/lib jako zaślepka libcuda.

Dlaczego brakuje nvidia-smi w WSL, choć GPU działa?

Jest obecny, tylko nie zawsze w twoim PATH. Trafia tam razem z rzutowanym sterownikiem, do /usr/lib/wsl/lib/nvidia-smi. Wywołaj go pełną ścieżką, żeby potwierdzić, że GPU jest widoczne, a potem dodaj ten katalog do PATH, jeśli chcesz używać samego polecenia.

Czy ostrzeżenie „libcuda.so.1 is not a symbolic link” jest poważne?

Zwykle nie. Bierze się z tego, że ldconfig protestuje przeciwko rzutowaniu WSL tylko do odczytu, a większość zadań działa obok niego bez problemu. Ma znaczenie tylko wtedy, gdy loader, od którego zależysz, podąża za dowiązaniem. Rozwiązaniem jest odtworzenie dowiązań w katalogu z prawem zapisu, nigdy edycja samego rzutowania.

Czy WSL2 obsługuje każde GPU, które obsługuje Windows?

Nie. Karty generacji Maxwell nie są obsługiwane pod WSL, więc praktyczną dolną granicą jest Pascal lub nowszy — poprzeczka wyższa niż na natywnym Windowsie, gdzie Ollama obsługuje compute capability 5.0 i wyżej. Pod WSL niedostępna jest też Unified Memory, a przypiętej pamięci systemowej jest niewiele.

Uruchamiać Ollamę w WSL czy natywnie na Windowsie?

Natywnie, przy większości zestawów z jednym GPU: jest prościej, mniej więcej tak samo szybko i omijasz całą tę klasę problemów. Po WSL sięgaj wtedy, gdy potrzebujesz linuksowego toolchainu, który na Windowsie boli — buildu CUDA, vLLM albo stosu pythonowego dostępnego wyłącznie w wheelach linuksowych.