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

ROCm nie obsługuje twojej karty AMD — HSA_OVERRIDE i Vulkan

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

Error: no compatible GPUs were discovered

HSA Error: HSA_STATUS_ERROR_OUT_OF_RESOURCES

hipErrorNoBinaryForGpu: Unable to find code object for all current devices!

Który to przypadek?

Jeśli widzisz	Przyczyną jest	Przejdź do
`rocminfo` wypisuje agenta CPU, ale żadnego agenta GPU	ROCm nie celuje w twoją kartę albo stos sterownika nie jest zainstalowany	Rozwiązanie 1: sprawdź, co widzi ROCm
`hipErrorNoBinaryForGpu` z nazwą celu gfx	ROCm nie dostarcza kerneli skompilowanych dla tej architektury	Rozwiązanie 3: nadpisz na najbliższy obsługiwany cel
`rocminfo` działa spod sudo, a na twoim koncie nie	To uprawnienia do urządzenia, a nie wsparcie ROCm	To strona o /dev/kfd, nie ta
ROCm odmawia karty, a Ollama mimo to znajduje GPU	Robotę wykonuje backend Vulkan	Rozwiązanie 4: postaw na Vulkana, zamiast walczyć z ROCm
Po nadpisaniu działa, a potem zawiesza się albo wypluwa śmieci	Nadpisanie jest niewłaściwe dla tej architektury	Rozwiązanie 6: przeczytaj uczciwie o granicach HSA_OVERRIDE

Kiedy się pojawia

Karta jest zainstalowana, jądro ją widzi, a stos obliczeniowy nie chce się do niej przyznać. W zależności od tego, którą warstwę zapytasz, dostajesz inny wariant tej samej odmowy — pustą listę agentów, błąd o brakujących obiektach kodu albo po prostu komunikat Ollamy, że nie znalazła zgodnych kart.

Masz konsumenckiego Radeona spoza listy obsługiwanej przez ROCm — kartę z serii RX 5000, starszy układ RDNA albo APU.
Zainstalowałeś ROCm z repozytoriów swojej dystrybucji, a nie instalatorem AMD.
Ollama od pierwszego uruchomienia liczy na CPU i nigdy nie użyła GPU.
Poradnik kazał ustawić HSA_OVERRIDE_GFX_VERSION i teraz wnioskowanie się zawiesza albo produkuje bzdury.
Masz dwie karty AMD, a używana jest tylko jedna.

Co się właściwie dzieje

Obliczenia na AMD pod Linuksem idą przez ROCm, który dostarcza wstępnie skompilowane kernele dla konkretnej listy celów LLVM — numerów gfx. Twoja karta zgłasza swoją architekturę, ROCm szuka kerneli zbudowanych dla niej, a gdy żadnych nie ma, stos odmawia, zamiast zejść na coś prostszego. Dokładnie to, niemal dosłownie, mówi hipErrorNoBinaryForGpu. Ollama na Linuksie oczekuje dziś sterownika AMD ROCm v7, instalowanego przez amdgpu-install od AMD, a jej lista obsługiwanego sprzętu obejmuje rodziny Radeon RX, Radeon AI PRO, Radeon PRO, Ryzen AI i Instinct. Karta spoza tej listy nie jest zepsuta i niekoniecznie bezużyteczna — po prostu nie ma dla niej kerneli. Dlatego dwie drogi naprzód to skłamać o architekturze (HSA_OVERRIDE_GFX_VERSION) albo dotrzeć do GPU zupełnie inną ścieżką (Vulkan).

Jak to naprawić

1. Ustal, co ROCm faktycznie widzi i jaki cel zgłasza twoja karta

Wszystko dalej zależy od dwóch faktów: czy ROCm w ogóle wylicza agenta GPU i jaki cel gfx zgłasza karta. rocminfo daje ci oba. Jeśli wypisuje wyłącznie agenta CPU, albo brakuje stosu sterownika, albo karta nie jest obsługiwana. Jeśli podaje numer gfx, zapisz go — to on decyduje, które nadpisanie w ogóle ma szansę zadziałać.

bash

# bash
rocminfo | grep -E "Marketing Name|gfx|Agent"
amd-smi version
amd-smi list

# Which kernel driver is bound to the card?
lspci -k | grep -A3 -iE "vga|display"

Czy zadziałało? Agent GPU z celem gfx oznacza, że ROCm widzi sprzęt. Sam agent CPU oznacza, że nie widzi, i wtedy rozwiązanie 2 wyprzedza wszystko inne.

rocminfo | grep -c gfx

2. Zainstaluj stos ROCm v7 przez amdgpu-install

Ollama oczekuje na Linuksie sterownika ROCm v7, instalowanego przez własne amdgpu-install od AMD. ROCm z pakietów dystrybucji to często starsza wersja główna, a rozbieżność między dołączonymi bibliotekami ROCm a sterownikiem jądra daje awarie przy wykrywaniu GPU, które wyglądają jak nieobsługiwany sprzęt. Po instalacji dopisz ścieżki bibliotek ROCm do ścieżki wyszukiwania loadera — ten krok łatwo pominąć, a jego brak owocuje później błędami linkowania wyglądającymi na niepowiązane. Zweryfikowane z dokumentacją GPU Ollamy i dokumentacją instalacji ROCm od AMD, 1 września 2026.

bash

# bash — follow AMD's current instructions for your distro and release
sudo amdgpu-install --usecase=rocm

# Post-install: put ROCm on the loader path
echo -e "/opt/rocm/lib\n/opt/rocm/lib64" | sudo tee /etc/ld.so.conf.d/rocm.conf
sudo ldconfig

Czy zadziałało? rocminfo nazywa twoją kartę, a amd-smi zgłasza wersję. Jeśli wykrywanie zawodzi także tutaj, karta jest naprawdę poza wsparciem ROCm, a twoimi opcjami są rozwiązania 3 i 4.

rocminfo | grep -i "Marketing Name:"
amd-smi version

3. Wymuś najbliższy obsługiwany cel przez HSA_OVERRIDE_GFX_VERSION

Dla karty, w którą ROCm nie celuje, możesz kazać mu użyć kerneli zbudowanych dla bliskiego krewnego. Własny przykład Ollamy to RX 5400, która zgłasza gfx1034; ROCm tego celu nie obsługuje, a najbliższym obsługiwanym jest gfx1030, co daje HSA_OVERRIDE_GFX_VERSION=10.3.0. Wartość to numer gfx zapisany jak wersja z kropkami. Na maszynie z kilkoma kartami AMD istnieje forma per urządzenie — HSA_OVERRIDE_GFX_VERSION_0, _1 — więc możesz nadpisać jedną kartę, nie ruszając drugiej. Ponieważ Ollama działa jako usługa systemd, ustaw to w drop-inie usługi, a nie w swojej powłoce.

bash

# bash — one GPU
sudo systemctl edit ollama.service
# [Service]
# Environment="HSA_OVERRIDE_GFX_VERSION=10.3.0"

# Several GPUs, overriding only the first
# Environment="HSA_OVERRIDE_GFX_VERSION_0=10.3.0"
# Environment="HSA_OVERRIDE_GFX_VERSION_1=11.0.0"

sudo systemctl daemon-reload && sudo systemctl restart ollama
journalctl -u ollama --no-pager -n 40

Czy zadziałało? Log zgłasza GPU zamiast schodzić na CPU, a załadowany model pokazuje umieszczenie na GPU.

ollama run gemma3:1b "hi" && ollama ps

4. Spróbuj Vulkana — na konsumenckich Radeonach zwykle stabilniejsza ścieżka Najczęstsze rozwiązanie

Ollama dostarcza backend Vulkan, domyślnie włączony na Linuksie i Windowsie, gdy backend jest zainstalowany. Na Linuksie oznacza to zwykle instalację środowiska uruchomieniowego Vulkan dla twojej dystrybucji; sterowniki windowsowe zwykle niosą je w pakiecie. Ta ścieżka często działa na kartach, w które ROCm nie celuje, i to bez kruchości nadpisywania architektury. GGML_VK_VISIBLE_DEVICES wybiera urządzenie (=1 wskazuje kartę dedykowaną na maszynie mającej też zintegrowaną), a OLLAMA_VULKAN=0 albo GGML_VK_VISIBLE_DEVICES=-1 go wyłącza — warto sprawdzić, czy żadna z nich nie jest ustawiona, zanim uznasz, że Vulkan nie działa.

bash

# bash — Ubuntu / Debian
sudo apt install -y libvulkan1 mesa-vulkan-drivers vulkan-tools
vulkaninfo --summary | head -20

# Fedora
sudo dnf install -y vulkan-loader mesa-vulkan-drivers vulkan-tools

# Pick the discrete GPU when an iGPU is also present
sudo systemctl edit ollama.service
# [Service]
# Environment="GGML_VK_VISIBLE_DEVICES=1"

Czy zadziałało? vulkaninfo --summary wypisuje twojego Radeona jako urządzenie fizyczne, a Ollama zgłasza umieszczenie na GPU, a nie na CPU.

vulkaninfo --summary | grep -i -A2 deviceName
ollama ps

Sprawdź, co zmieści się na twoim sprzęcie — sprawdź, które modele działają akceptowalnie na twojej karcie AMD albo na CPU
Otwórz kalkulator VRAM →

5. Napraw uprawnienia i raportowanie VRAM, których potrzebuje Vulkan

Po zainstalowaniu Vulkana gryzą dwa linuksowe szczegóły. Użytkownik usługi ollama musi należeć do grupy render na dystrybucjach, gdzie węzły urządzeń są jej własnością — inaczej usługa nie otworzy GPU, choć twoje własne konto owszem. Poprawne raportowanie VRAM może dodatkowo wymagać uprawnienia cap_perfmon na pliku binarnym; bez niego Ollama potrafi źle ocenić dostępną pamięć i kiepsko rozmieścić warstwy, co wygląda na problem z wydajnością, a nie z uprawnieniami.

⚠️ setcap cap_perfmon+ep przyznaje uprawnienie monitorowania wydajności plikowi ollama dla każdego użytkownika, który może go uruchomić. Jest to udokumentowane w tym celu — przyznaj je świadomie i nadaj ponownie po aktualizacjach, bo podmieniony plik binarny je traci.

bash

# bash
sudo usermod -a -G render,video ollama
sudo setcap cap_perfmon+ep /usr/local/bin/ollama
sudo systemctl restart ollama

# Confirm both took
groups ollama
getcap /usr/local/bin/ollama

Czy zadziałało? groups ollama zawiera render, getcap pokazuje uprawnienie, a log zgłasza wiarygodną ilość VRAM dla twojej karty.

journalctl -u ollama --no-pager -n 30 | grep -i -E "vram|memory|gpu"

6. Powiedz sobie uczciwie, co HSA_OVERRIDE potrafi, a czego nie

Nadpisanie to obejście i udawanie inaczej kosztuje ludzi całe wieczory. Jest niezawodne przy nadpisaniach klasy gfx1030 — czyli w rodzinie RDNA2, na której się przyjęło — i kapryśne poza nią, bo uruchamiasz kernele skompilowane pod inny sprzęt, a nikt nie sprawdza, czy to założenie się trzyma. Praktyczna konsekwencja jest istotna: zawieszenie, awaria albo śmieci na wyjściu po ustawieniu nadpisania to wina nadpisania, a nie modelu. Jeśli widzisz cokolwiek z tego, usuń je, zanim ruszysz szukać problemu z kwantyzacją. Na karcie, której ROCm naprawdę nie obsłuży, stabilniejszą odpowiedzią jest zwykle Vulkan albo CPU — a wybranie tego świadomie bije tydzień walki z nadpisaniem.

bash

# bash — remove the override and re-test cleanly
sudo systemctl edit ollama.service   # delete the HSA_OVERRIDE_GFX_VERSION line
sudo systemctl daemon-reload && sudo systemctl restart ollama
systemctl show ollama --property=Environment

Czy zadziałało? Po usunięciu nadpisania wyjście znów jest spójne — co mówi ci, że przyczyną było właśnie ono, a nie model czy kwantyzacja.

ollama run gemma3:1b "Write one sentence about the sea."

Jeśli nic z tego nie pomogło

Jeśli rocminfo działa spod sudo, a na twoim koncie nie, to problem z uprawnieniami, a nie ze wsparciem — strona o /dev/kfd naprawia to jednym poleceniem. Jeśli uruchamiasz ROCm w kontenerach, szczegóły o grupach urządzeń i SELinuksie znajdziesz na stronie o Dockerze.

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

Wynik rocminfo | grep -E "Marketing Name|gfx" oraz amd-smi version
Model twojej karty i cel gfx, który zgłasza
Wartość ustawionego HSA_OVERRIDE_GFX_VERSION i miejsce, w którym ją ustawiłeś
journalctl -u ollama --no-pager -n 50 z okolic nieudanego wykrywania

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 robi HSA_OVERRIDE_GFX_VERSION?

Każe ROCm traktować twoje GPU jak inny cel LLVM, żeby ładował kernele skompilowane dla tamtej architektury. Udokumentowany przykład Ollamy to RX 5400, która zgłasza gfx1034; najbliższym obsługiwanym celem jest gfx1030, więc wartością jest 10.3.0.

Czy nadpisanie jest bezpieczne?

Jest niezawodne przy nadpisaniach klasy gfx1030 i nieprzewidywalne poza nimi, bo kernele zakładają sprzęt, którego nie masz. Zawieszenia, awarie i śmieci na wyjściu po jego ustawieniu są jego winą. Usuń je, zanim zaczniesz badać cokolwiek innego.

ROCm czy Vulkan na nieobsługiwanym Radeonie?

Zwykle Vulkan. Ollama włącza go na Linuksie domyślnie, gdy backend jest zainstalowany, i często działa na kartach, w które ROCm nie celuje, bez potrzeby kłamania o architekturze. ROCm pozostaje lepszym wyborem na kartach, które faktycznie obsługuje.

Dlaczego Ollama nie widzi GPU, choć rocminfo je widzi?

Najczęściej dlatego, że użytkownik usługi ollama nie należy do grupy render, więc usługa nie otworzy urządzenia, które twoje konto otwiera bez problemu. Poprawne raportowanie VRAM pod Vulkanem może też wymagać cap_perfmon na pliku binarnym. Oba to po jednym poleceniu.

Której wersji ROCm oczekuje Ollama?

ROCm v7, instalowanego na Linuksie przez amdgpu-install od AMD — a na Windowsie stosu sterownika zgodnego z ROCm v7 i HIP7. Pakiety dystrybucji to często starsza wersja główna, a rozbieżność objawia się awariami przy wykrywaniu GPU.