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

„Failed to initialize NVML: Driver/library version mismatch”

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

Failed to initialize NVML: Driver/library version mismatch
NVML library version: 580.65

CUDA driver version is insufficient for CUDA runtime version

Który to przypadek?

Jeśli widzisz	Przyczyną jest	Przejdź do
Niedawno wykonało się `apt upgrade` albo `dnf update`, a ty nie restartowałeś	Biblioteki przestrzeni użytkownika są nowsze niż moduł jądra wciąż siedzący w pamięci	Rozwiązanie 1: zrestartuj — to 40 sekund
Nie możesz zrestartować (współdzielona maszyna, długie zadanie w tmuksie)	Ta sama przyczyna, ale moduł trzeba podmienić na żywo	Rozwiązanie 2: wyładuj i załaduj moduły ponownie
`rmmod` mówi, że moduł jest w użyciu	Menedżer logowania, X/Wayland albo jakiś proces wciąż trzymają GPU	Rozwiązanie 3: znajdź, co go trzyma
Pojawiło się po uśpieniu i wybudzeniu, a nie po aktualizacji	Wykrywanie GPU zawiodło przy wybudzaniu; moduł UVM wymaga przeładowania	Rozwiązanie 4: przeładuj nvidia_uvm
`modinfo` i `nvidia-smi` podają tę samą wersję, a mimo to zawodzi	Walczą ze sobą dwie instalacje sterownika — pakiety dystrybucji plus plik .run	Rozwiązanie 5: zdecyduj się na jedną metodę instalacji

Kiedy się pojawia

Ten przypadek niepokoi ludzi, bo pozornie nic się nie wydarzyło. Żadnej aktualizacji jądra, żadnego restartu, żadnej zmiany konfiguracji — a nvidia-smi przeszło w trakcie sesji od poprawnej pracy do błędu o niezgodności wersji.

Menedżer pakietów zaktualizował sterownik NVIDII w tle, być może przy okazji niepowiązanej aktualizacji.
Automatyczne aktualizacje wykonały się, gdy pracowałeś.
Godzinę temu zainstalowałeś CUDA albo nowy sterownik i pracowałeś dalej bez restartu.
Maszyna wróciła z uśpienia i GPU przestało być widoczne.
Masz na jednej maszynie i pakiety sterownika z dystrybucji, i instalator .run.

Co się właściwie dzieje

Sterownik NVIDII to dwie połowy, które muszą do siebie pasować: moduł jądra załadowany do działającego jądra oraz biblioteki przestrzeni użytkownika na dysku, które z nim rozmawiają. Aktualizacja pakietu podmienia biblioteki natychmiast, ale nie potrafi podmienić modułu, który jest właśnie załadowany i używany — więc stary moduł zostaje w pamięci, a nowe biblioteki leżą na dysku. nvidia-smi linkuje się z nową biblioteką NVML, pyta stary moduł o wersję i odmawia dalszej pracy. Nic nie jest uszkodzone i nic nie przepadło. Działające jądro po prostu trzyma nieaktualny moduł — dlatego restart naprawia to całkowicie i dlatego ręczne rozwiązanie sprowadza się do podmiany modułu. Wariant tego samego błędu po stronie CUDA — „CUDA driver version is insufficient for CUDA runtime version” — to ta sama usterka widziana z innej biblioteki.

Jak to naprawić

1. Zrestartuj komputer

Uczciwa pierwsza odpowiedź. Restart ładuje nowy moduł przy nowych bibliotekach, zajmuje jakieś czterdzieści sekund i i tak zrobisz to samo, jeśli ręczna droga poniżej się nie powiedzie. Cała reszta tej strony istnieje dla maszyn, których naprawdę nie możesz zrestartować — współdzielonego serwera, treningu, którego nie chcesz stracić, maszyny z innymi użytkownikami. Jeśli nic z tego cię nie dotyczy, przestań czytać i zrestartuj.

bash

# bash
sudo reboot

Czy zadziałało? Po restarcie nvidia-smi wypisuje normalną tabelę, a zgłoszona wersja sterownika zgadza się z tym, co zainstalował menedżer pakietów.

nvidia-smi --query-gpu=driver_version --format=csv
modinfo nvidia | grep ^version

2. Wyładuj i załaduj moduły w kolejności zależności

Bez restartu musisz usunąć nieaktualny moduł i załadować nowy. Kolejność ma znaczenie: nvidia jest trzymany przez nvidia_uvm, nvidia_drm i nvidia_modeset, więc te wychodzą pierwsze, a moduł podstawowy na końcu. Na maszynie z pulpitem zrzuci cię to do konsoli tekstowej, bo stos graficzny jest jedną z rzeczy trzymających moduł — zaplanuj uruchomienie tego z TTY (Ctrl+Alt+F3), a nie z terminala w sesji, którą właśnie zamierzasz ubić.

⚠️ Na maszynie z sesją graficzną kończy to twój pulpit. Najpierw zapisz pracę. Na serwerze bez monitora jest to bezpieczne i nie przeszkadza niczemu, co nie korzysta z GPU.

bash

# bash — as root, ideally from a TTY on a desktop machine
sudo rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia
sudo modprobe nvidia
sudo modprobe nvidia_uvm

nvidia-smi

Czy zadziałało? nvidia-smi znów działa, a modinfo nvidia zgłasza teraz tę samą wersję co biblioteki przestrzeni użytkownika.

modinfo nvidia | grep ^version
nvidia-smi --query-gpu=driver_version --format=csv,noheader

3. Znajdź to, co wciąż trzyma GPU

Jeśli rmmod zgłasza, że moduł jest w użyciu, coś ma otwarte urządzenie. fuser -v /dev/nvidia* nazywa te procesy; lsof /dev/nvidia* jest alternatywą tam, gdzie fusera nie ma. Typowi lokatorzy to twój serwer wnioskowania, proces Pythona, który nie zakończył pracy, kontener oraz — na maszynie z pulpitem — menedżer logowania. Zatrzymaj te, które możesz, i pogódź się z tym, że na pulpicie stos graficzny do nich nie należy; o tym właśnie mówi uwaga o TTY w rozwiązaniu 2.

bash

# bash
sudo fuser -v /dev/nvidia*
sudo lsof /dev/nvidia* 2>/dev/null | head -20

# Common holders, stopped politely
sudo systemctl stop ollama
docker ps -q | xargs -r docker stop

# Desktop only: stop the display manager (this ends your GUI session)
sudo systemctl stop gdm3     # or lightdm, sddm

Czy zadziałało? sudo fuser -v /dev/nvidia* nic nie wypisuje. Dopiero wtedy rmmod się powiedzie.

sudo fuser -v /dev/nvidia*

4. Po uśpieniu i wybudzeniu przeładuj konkretnie moduł UVM

Istnieje udokumentowany wariant tego problemu, który nie ma nic wspólnego z aktualizacjami: po uśpieniu i wybudzeniu wykrywanie GPU potrafi zawieść z tą samą klasą objawów. Dokumentacja rozwiązywania problemów Ollamy podaje jako obejście przeładowanie samego modułu Unified Memory, co jest znacznie mniej inwazyjne niż pełne wyładowanie z rozwiązania 2 — nie rusza stosu graficznego. nvidia-modprobe -u to udokumentowana alternatywa do załadowania sterownika UVM.

bash

# bash — the documented suspend/resume workaround
sudo rmmod nvidia_uvm
sudo modprobe nvidia_uvm

# Or, equivalently
sudo nvidia-modprobe -u

sudo systemctl restart ollama

Czy zadziałało? Moduł jest załadowany, a twój serwer wnioskowania znów widzi GPU.

lsmod | grep nvidia_uvm
ollama ps

5. Zdecyduj się na jedną metodę instalacji sterownika

Jeśli problem wraca albo jeśli modinfo i nvidia-smi zgadzają się co do wersji, a mimo to zawodzi, prawdopodobnie masz na maszynie dwie instalacje sterownika — pakiety dystrybucji oraz instalator .run od NVIDII, z których każdy jest przekonany, że to on jest właścicielem /usr/lib/x86_64-linux-gnu/libnvidia-*. Wybierz jedną. Pakiety dystrybucji to właściwy domyślny wybór dla niemal każdego, bo uczestniczą w DKMS i w aktualizacjach; instalator .run jest dla przypadków, gdy naprawdę potrzebujesz wersji, której twoja dystrybucja nie niesie.

⚠️ Usunięcie instalacji sterownika zostawia maszynę bez działającego sterownika GPU, dopóki nie pojawi się zamiennik. Zrób to z TTY, mając pakiety zastępcze już pobrane, a nie przez SSH na maszynie, do której nie masz fizycznego dostępu.

bash

# bash — remove a previous .run install, then use distro packages
sudo /usr/bin/nvidia-uninstall
sudo apt install --reinstall -y nvidia-driver-580   # your recommended version
sudo reboot

6. Poznaj kody błędów NVML, które mogą się przy tym pojawić Najczęstsze rozwiązanie

NVML pokazuje niewielki zestaw liczb, które szybko zawężają problem: 3 (nie zainicjowano) i 999 (nieznany) zwykle towarzyszą tej niezgodności; 46 (urządzenie niedostępne) wskazuje na GPU w złym stanie, często po zadaniu, które się wywróciło; 100 (brak urządzenia) znaczy, że nie znaleziono żadnego GPU, a to już historia o DKMS albo Secure Boot, nie o tej stronie. Odczytanie kodu najpierw oszczędza ci prób stosowania rozwiązań z tej strony do problemu należącego do innej.

bash

# bash — the full error text, and what is loaded right now
nvidia-smi 2>&1 | head -5
lsmod | grep -E "^nvidia"
cat /proc/driver/nvidia/version 2>/dev/null

Sprawdź, co zmieści się na twoim sprzęcie — sprawdź, co uciągnie twoja karta, gdy sterownik znów z nią rozmawia
Otwórz kalkulator VRAM →

Jeśli nic z tego nie pomogło

Jeśli wersje już się zgadzają, a GPU wciąż nie da się użyć w kontenerze, następną warstwą niżej jest środowisko kontenerowe. Jeśli nvidia-smi zawodzi z błędem komunikacji, a nie z niezgodnością wersji, moduł nie jest nieaktualny, tylko go brakuje — a to strona o aktualizacji jądra.

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

Pełne pierwsze pięć linii wyjścia nvidia-smi
modinfo nvidia | grep ^version oraz cat /proc/driver/nvidia/version
Wynik lsmod | grep nvidia i sudo fuser -v /dev/nvidia*
Czy sterownik pochodzi z pakietów dystrybucji, repozytorium CUDA czy instalatora .run

Powiązane

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

Zobacz model i wymagania →

Najczęstsze pytania

Co właściwie znaczy „Driver/library version mismatch”?

Biblioteki NVIDII w przestrzeni użytkownika zostały zaktualizowane na dysku, gdy stary moduł jądra wciąż był załadowany, więc obie połowy sterownika przestały zgadzać się co do wersji. To nieaktualny moduł w pamięci, a nie uszkodzenie — restart rozwiązuje sprawę całkowicie.

Czy da się to naprawić bez restartu?

Tak. Zatrzymaj wszystko, co trzyma GPU, a potem sudo rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia i sudo modprobe nvidia. Na maszynie z pulpitem kończy to sesję graficzną, bo stos wyświetlania trzyma moduł, więc uruchom to z TTY.

Dlaczego rmmod mówi, że moduł jest w użyciu?

Bo coś nadal ma otwarty węzeł urządzenia GPU — serwer wnioskowania, proces Pythona, kontener albo menedżer logowania. sudo fuser -v /dev/nvidia* je nazywa. Modułu nie da się usunąć, dopóki ta lista nie będzie pusta.

Moje GPU zniknęło po uśpieniu, a nie po aktualizacji. To samo rozwiązanie?

Pokrewne, ale węższe. Ollama dokumentuje przeładowanie samego modułu Unified Memory — sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm albo sudo nvidia-modprobe -u — co nie rusza stosu graficznego. Potem zrestartuj swój serwer wnioskowania.

Co oznaczają numery błędów NVML?

Kod 3 to „nie zainicjowano”, a 999 „nieznany” — oba typowe dla tej niezgodności. Kod 46 to „urządzenie niedostępne”, zwykle GPU pozostawione w złym stanie. Kod 100 to „brak urządzenia”, czyli modułu brakuje w ogóle, a nie jest nieaktualny.