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

Twój kontener Dockera nie widzi GPU

Linux

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

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

Komunikat błędu

docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].

docker: Error response from daemon: unknown or invalid runtime name: nvidia.

bash: nvidia-smi: command not found   (inside the container)

Który to przypadek?

Jeśli widzisz	Przyczyną jest	Przejdź do
„could not select device driver ... capabilities: [[gpu]]”	NVIDIA Container Toolkit nie jest zainstalowany albo nie został zarejestrowany w Dockerze	Rozwiązanie 1: zainstaluj toolkit i skonfiguruj środowisko uruchomieniowe
„unknown or invalid runtime name: nvidia”	Toolkit jest zainstalowany, ale konfiguracja demona Dockera o nim nie wie	Rozwiązanie 2: nvidia-ctk runtime configure
`nvidia-smi: command not found` wewnątrz kontenera	GPU zostało przekazane, ale obraz nie zawiera przestrzeni użytkownika CUDA	Rozwiązanie 3: przetestuj na bazowym obrazie CUDA
Działa z sudo docker, a na twoim koncie nie	Docker w trybie rootless wymaga własnej konfiguracji toolkitu	Rozwiązanie 4: skonfiguruj środowisko rootless
AMD: /dev/kfd istnieje na hoście, ale nie w kontenerze	Nie przekazano grup urządzeń albo dostęp blokuje SELinux	Rozwiązanie 5: --group-add i setsebool

Kiedy się pojawia

Host jest zdrowy. nvidia-smi wypisuje normalną tabelę, GPU się pokazuje, modele działają natywnie. Włóż to samo zadanie do kontenera z --gpus all, a Docker odmówi jego uruchomienia albo uruchomi je i kontener zachowa się tak, jakby w maszynie nie było żadnej karty.

Przenosisz działającą konfigurację natywną do Docker Compose i każda usługa korzystająca z GPU odmawia startu.
Uruchamiasz obraz kontenera Ollamy albo Open WebUI po raz pierwszy.
Przeinstalowałeś Dockera albo przeszedłeś z pakietów docker.io na Docker CE i dostęp do GPU przepadł.
Jesteś na Dockerze w trybie rootless albo na Podmanie i idziesz za instrukcją napisaną dla Dockera z rootem.
Masz Radeona i próbujesz przekazać /dev/kfd do kontenera.

Co się właściwie dzieje

Kontenery Dockera dostają urządzenia tylko wtedy, gdy przekaże je środowisko uruchomieniowe — a domyślne nie wie nic o kartach graficznych. --gpus all jest prośbą, którą musi obsłużyć NVIDIA Container Toolkit: zestaw haków wstrzykujących do kontenera biblioteki i węzły urządzeń ze sterownika hosta przy starcie. Bez niego Docker parsuje flagę, nie znajduje sterownika zdolnego dostarczyć [[gpu]] i odmawia — a dokładnie to mówi ten komunikat, gdy już wiesz, jak go czytać. Sterownik na hoście jest konieczny, ale niewystarczający. Pod spodem czai się druga, cichsza awaria: nawet przy działającym toolkicie obraz bez przestrzeni użytkownika CUDA nie ma czym uruchomić nvidia-smi, więc kontener może mieć GPU i mimo to wyglądać, jakby go nie miał.

Jak to naprawić

1. Zainstaluj NVIDIA Container Toolkit

Dodaj repozytorium NVIDII z podpisanym pękiem kluczy i zainstaluj pakiet. Zanim to uruchomisz, porównaj aktualny adres repozytorium i ścieżkę pęku kluczy z przewodnikiem instalacji NVIDII — ta ścieżka zmieniała się nie raz, a nieaktualna, skopiowana linia to częsty powód, dla którego instalacja pozornie się udaje i nic nie instaluje. Zweryfikowane z przewodnikiem instalacji NVIDIA Container Toolkit, 1 września 2026.

bash

# bash — Ubuntu / Debian
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \
  | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \
  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \
  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit

Czy zadziałało? Pomocniczy plik binarny istnieje i zgłasza wersję. Jeśli nvidia-ctk nie zostaje znaleziony, pakiet się nie zainstalował, a linią do ponownego sprawdzenia jest wpis repozytorium.

nvidia-ctk --version
dpkg -l | grep nvidia-container-toolkit

2. Zarejestruj środowisko uruchomieniowe w Dockerze i zrestartuj demona

Zainstalowanie toolkitu nie każe Dockerowi z niego korzystać — od tego jest drugie polecenie, a jego pominięcie daje błąd unknown or invalid runtime name: nvidia. nvidia-ctk runtime configure edytuje za ciebie /etc/docker/daemon.json; potem trzeba jeszcze zrestartować demona, żeby ponownie odczytał ten plik.

bash

# bash
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# The canonical smoke test
docker run --rm --gpus all ubuntu nvidia-smi

Czy zadziałało? Kontener wypisuje tę samą tabelę GPU, którą dostajesz na hoście. Przejście tego jednego polecenia oznacza, że cały łańcuch — sterownik, toolkit, środowisko uruchomieniowe, demon — działa.

docker run --rm --gpus all ubuntu nvidia-smi
docker info | grep -i runtime

3. Przetestuj na obrazie, który faktycznie zawiera przestrzeń użytkownika CUDA

Jeśli --gpus all przechodzi, a zadanie i tak nie znajduje GPU, obraz może zwyczajnie nie mieć czym z nim rozmawiać. Zwykły obraz ubuntu działa dla nvidia-smi, bo toolkit wstrzykuje plik binarny z hosta, ale framework potrzebuje bibliotek CUDA w samym obrazie. Przetestuj na oficjalnym obrazie bazowym CUDA, żeby oddzielić „GPU nie jest przekazywane” od „mojemu obrazowi brakuje CUDA”. Dla Ollamy publikowany obraz zawiera już wszystko, czego potrzeba.

bash

# bash — is the GPU visible to a real CUDA image?
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

# The Ollama container form
docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 \
  --name ollama ollama/ollama

Czy zadziałało? Kontener Ollamy przy załadowanym modelu zgłasza umieszczenie na GPU, a nie na CPU.

docker exec ollama ollama run gemma3:1b "hi"
docker exec ollama ollama ps

4. Skonfiguruj osobno Dockera w trybie rootless

Docker w trybie rootless trzyma własną konfigurację demona w twoim katalogu domowym, więc runtime configure wycelowane w demona systemowego nic dla niego nie robi. nvidia-ctk runtime configure --runtime=docker --config=$HOME/.config/docker/daemon.json trafia we właściwy plik, a tryb rootless wymaga jeszcze włączenia no-cgroups w konfiguracji container-toolkit. To zwykłe wyjaśnienie sytuacji, w której dostęp do GPU działa spod sudo docker, a na twoim koncie nie.

bash

# bash — rootless Docker
nvidia-ctk runtime configure --runtime=docker \
  --config=$HOME/.config/docker/daemon.json
systemctl --user restart docker

# Rootless also needs no-cgroups in the toolkit config:
sudo nvidia-ctk config --set nvidia-container-cli.no-cgroups --in-place

Czy zadziałało? Test dymny przechodzi na twoim własnym koncie, bez sudo.

docker run --rm --gpus all ubuntu nvidia-smi

5. Kontenery AMD: przekaż grupy urządzeń i sprawdź SELinuksa

AMD nie korzysta z toolkitu NVIDII. Kontenery potrzebują jawnie przekazanych węzłów urządzeń wraz z numerycznymi identyfikatorami grup, które są ich właścicielami — numerycznymi, bo nazwy grup w kontenerze nie będą pasować do tych z hosta. Odczytasz je z ls -lnd. Na systemach z SELinuksem stoi jeszcze druga bramka: dokumentacja Ollamy zauważa, że SELinux potrafi blokować kontenerom dostęp do urządzeń GPU AMD, a rozwiązaniem jest jeden przełącznik logiczny.

⚠️ setsebool -P container_use_devices=1 trwale pozwala każdemu kontenerowi na tym hoście sięgać do węzłów urządzeń, nie tylko temu, który debugujesz. To udokumentowane rozwiązanie i zarazem zmiana zasad dla całego hosta — podejmij ją świadomie.

bash

# bash — find the numeric group IDs for the AMD device nodes
ls -lnd /dev/kfd /dev/dri /dev/dri/*

docker run --rm --device /dev/kfd --device /dev/dri \
  --group-add 44 --group-add 993 \
  rocm/dev-ubuntu-22.04 rocminfo

# SELinux hosts (Fedora, RHEL) only:
sudo setsebool -P container_use_devices=1

Czy zadziałało? rocminfo w kontenerze wypisuje twoje GPU jako agenta. Jeśli wypisuje wyłącznie agenta CPU, urządzenia nadal do niego nie docierają.

docker run --rm --device /dev/kfd --device /dev/dri rocm/dev-ubuntu-22.04 rocminfo | grep -i "Marketing Name"

6. Odpowiedniki w Podmanie

Podman używa CDI, a nie własnego środowiska uruchomieniowego. Wygeneruj raz specyfikację CDI dla kart poleceniem nvidia-ctk cdi generate, a potem przy każdym uruchomieniu odwołuj się do urządzenia po nazwie. Po aktualizacji sterownika wygeneruj specyfikację ponownie — nieaktualny plik CDI wskazuje ścieżki bibliotek, które już nie istnieją, co daje kontener startujący poprawnie i wywracający się przy pierwszym wywołaniu CUDA.

bash

# bash — Podman with NVIDIA
sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml
nvidia-ctk cdi list
podman run --rm --device nvidia.com/gpu=all ubuntu nvidia-smi

# Podman with AMD
podman run --rm --device /dev/kfd --device /dev/dri \
  rocm/dev-ubuntu-22.04 rocminfo

Czy zadziałało? Urządzenie CDI pojawia się w nvidia-ctk cdi list, a kontener wypisuje tabelę GPU.

nvidia-ctk cdi list

7. Dopasuj model do GPU, które przekazujesz Najczęstsze rozwiązanie

Gdy GPU dotrze już do kontenera, wraca zwykła arytmetyka — a kontenery ułatwiają pomylenie się w niej: kusi, żeby uruchomić kilka usług korzystających z karty naraz, a każdy załadowany model trzyma własny VRAM. Kontener, który w testach miał całą kartę dla siebie, w Compose może dzielić ją z dwoma innymi. Sprawdź, co naprawdę się mieści, zanim rozbudujesz stos.

bash

# bash — what is holding VRAM across every container right now?
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

Sprawdź, co zmieści się na twoim sprzęcie — sprawdź, co się zmieści, zanim uruchomisz kilka kontenerów korzystających z GPU naraz
Otwórz kalkulator VRAM →

Jeśli nic z tego nie pomogło

Jeśli kontener widzi GPU, ale nie może dosięgnąć Ollamy na hoście, to problem sieciowy, a nie sprzętowy, i ma własną stronę. Na Windowsie Docker Desktop z backendem WSL2 jedzie po instalacji sterowników WSL, więc naprawa WSL naprawia tam także Dockera.

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

Dokładne polecenie docker run i pełny komunikat błędu
Wynik nvidia-ctk --version oraz docker info | grep -i runtime
Czy Docker działa z rootem, w trybie rootless, czy to Podman
ls -lnd /dev/kfd /dev/dri /dev/dri/* przy problemach z AMD

Powiązane

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

Zobacz model i wymagania →

Najczęstsze pytania

Dlaczego sterownik na hoście nie wystarcza kontenerowi?

Bo kontener potrzebuje bibliotek sterownika i węzłów urządzeń wstrzykniętych do własnego systemu plików i własnej przestrzeni nazw — a robi to przy starcie właśnie NVIDIA Container Toolkit. Bez niego Docker nie ma sterownika zdolnego zaspokoić zdolność [[gpu]] i odmawia uruchomienia kontenera.

Czym różnią się te dwa komunikaty błędu?

„could not select device driver ... [[gpu]]” znaczy, że toolkitu brakuje albo nie został zarejestrowany. „unknown or invalid runtime name: nvidia” znaczy, że jest zainstalowany, ale daemon.json Dockera nie został skonfigurowany — pominąłeś nvidia-ctk runtime configure albo nie zrestartowałeś demona.

Dlaczego działa z sudo, a na moim koncie nie?

Prawie na pewno jesteś na Dockerze w trybie rootless, który czyta własną konfigurację demona z twojego katalogu domowego. Uruchom nvidia-ctk runtime configure na $HOME/.config/docker/daemon.json i ustaw no-cgroups w konfiguracji container-toolkit.

Jak przekazać GPU AMD do kontenera?

Przekaż /dev/kfd i /dev/dri jako urządzenia, a numeryczne identyfikatory grup będących ich właścicielami dodaj przez --group-add — nazwy różnią się między hostem a obrazem, więc użyj liczb z ls -lnd. Na hostach z SELinuksem ustaw dodatkowo przełącznik container_use_devices.

Czy po aktualizacji sterownika trzeba coś z tego powtarzać?

Przy Dockerze zwykle nie. Przy Podmanie tak — wygeneruj ponownie specyfikację CDI, bo zapisuje ścieżki bibliotek, które aktualizacja sterownika zmienia. Nieaktualny plik CDI daje kontener, który startuje i wywraca się przy pierwszym wywołaniu CUDA.