ROCm vs Vulkan dla lokalnego uruchamiania LLM na kartach AMD: przewodnik na 2026 rok

Wybierz odpowiedni backend AMD dla każdego silnika

Page content

ROCm i Vulkan przyspieszają GPU AMD do hostowania lokalnych modeli LLM, ale nie są zamiennymi. Prawidłowy wybór zależy od silnika, GPU i obciążenia.

W hostowaniu lokalnych modeli LLM dwa te backendy znajdują się na różnych warstwach. ROCm to platforma obliczeniowa AMD pod PyTorch, vLLM i SGLang, podczas gdy Vulkan to przenośny interfejs API dla GPU, z którego korzystają silniki w klasie llama.cpp do uruchamiania zkwantyzowanych modeli na szerokiej gamie sprzętu.

Backendy ROCm i Vulkan do lokalnego hostowania LLM na AMD

Ten przewodnik porównuje te dwa rozwiązania silnik po silniku — llama.cpp, Ollama, LM Studio, vLLM, SGLang, TGI oraz LocalAI — wraz z poleceniami do kompilacji, weryfikacją urządzeń i trybami awarii, które maskują się jako problemy wydajnościowe. Jeśli dopiero rozpoczynasz przygodę z krajobrazem hostowania, zacznij od Przeglądu hostowania LLM, który mapuje rodziny narzędzi, które omawia ten artykuł.

ROCm vs Vulkan: krótka odpowiedź

Sytuacja Zalecany punkt startowy Dlaczego
llama.cpp z GGUF na systemie Linux Vulkan Mała powierzchnia instalacji, szerokie pokrycie GPU i łatwy rollback
llama.cpp na wspieranym GPU RDNA 3 lub RDNA 4 Benchmarkuj oba Wydajność kerneli zmienia się w zależności od kształtu modelu, kwantyzacji, kontekstu i wersji kompilacji
Ollama na wymienionym GPU AMD Najpierw ROCm, zweryfikuj też Vulkan Ollama obsługuje oba, ale wybór backendu jest mniej jawny niż w czystym llama.cpp
LM Studio na desktopowym GPU AMD Najpierw Vulkan Przełączanie runtime’u sprawia, że porównanie jest łatwe i unika się systemowego stosu obliczeniowego
vLLM lub SGLang ROCm, ale zweryfikuj pokrycie kerneli dla rodziny GPU To stosy PyTorch/HIP; Vulkan nie jest alternatywnym backendem, a nowość architektoniczna może wciąż brakować zoptymalizowanych kerneli
TGI na wspieranym sprzęcie Instinct ROCm Opublikowana ścieżka kontenerów AMD dotyczy rodzin MI210, MI250 i MI300
Starsze lub niewymienione GPU Radeon Vulkan Sterowniki Vulkan zazwyczaj obejmują więcej sprzętu graficznego niż biblioteki ROCm
Serwer AMD Instinct ROCm Tutaj znajdują się obliczenia wielo-GPU, RCCL, kernle frameworków i narzędzia operacyjne
Lokalna obsługa GGUF na systemie Windows Vulkan To zazwyczaj najmniej restrykcyjna ścieżka dla runtime’ów w klasie llama.cpp
Ryzen AI Max lub inne APU z dużą pamięcią Najpierw Vulkan, potem ROCm, jeśli wymagane Oba mogą działać, ale wspólna pamięć i obsługa kerneli wymagają testów specyficznych dla obciążenia

Ta tabela jest punktem wyjścia, a nie wynikiem benchmarku. Backend, który wykrywa GPU, ale pozostawia niektóre operacje na CPU, może wyglądać na zdrowy, działając słabo, dlatego każda ostateczna decyzja wymaga analizy logów i testu promptu end-to-end.

Czym tak naprawdę są ROCm i Vulkan

ROCm to platforma obliczeniowa

ROCm obejmuje runtime HIP, kompilator, biblioteki matematyczne, komunikację zbiorczą, profiler oraz pakiety frameworków potrzebne do uruchamiania obciążeń obliczeniowych na AMD. To fundament AMD pod kompilacjami PyTorch i silnikami takimi jak vLLM i SGLang, a może również przyspieszać llama.cpp przez jego backend HIP.

Ta różnorodność jest atutem i kosztem ROCm. Sterownik hosta, cel GPU, biblioteki użytkownika, koło (wheel) frameworku, wersja kernela i obraz kontenera muszą tworzyć kompatybilny zestaw; gdy tak jest, ROCm oferuje znacznie więcej niż tylko generowanie tokenów przez jeden lokalny wykonywalnik.

ROCm 10.0.0, wydany 26 sierpnia 2026 roku, jest zbudowany na TheRock (systemie budowania i wydawania AMD od ROCm 7.14), weryfikuje PyTorch 2.13, vLLM 0.27 i SGLang 0.5.15 oraz formalnie dodaje obsługę RDNA 4 dla gfx1200 (RX 9060/9060 XT/9050) i gfx1201 (RX 9070/9070 XT/9070 GRE, seria Radeon AI PRO R9700). Macierz zgodności ROCm wciąż jest autorytetem dla dokładnej kombinacji GPU i systemu operacyjnego, a nie post na forum, który przypadkowo używa tej samej rodziny marketingowej.

Vulkan to przenośny interfejs GPU

Vulkan to API graficzne i obliczeniowe implementowane przez sterownik GPU. W hostowaniu lokalnych modeli LLM oznacza to zazwyczaj, że silnik inferencji dostarcza lub kompiluje szablony obliczeniowe (compute shaders), które wykonują się przez implementację Vulkan, taką jak Mesa RADV na systemie Linux lub sterownik dostawcy na systemie Windows.

Vulkan nie zapewnia platformy PyTorch w formie plug-in porównywalnej z ROCm. Jego praktyczna moc jest węższa, ale przydatna: silnik w stylu llama.cpp może używać tej samej architektury backendu na sprzęcie AMD, Intel, Nvidia i innych kompatybilnych z Vulkan, bez instalowania specyficznego dla dostawcy stosu uczenia maszynowego.

Ta różnica wyjaśnia większość decyzji. Jeśli aplikacja oferuje tylko ścieżkę HIP lub PyTorch, Vulkan nie może jej uratować; jeśli aplikacja jest już oparta na llama.cpp i GGUF, instalacja całego stosu ROCm może rozwiązać problem, którego nie miałeś.

Macierz wsparcia silników w 2026 roku

Silnik ROCm lub HIP Vulkan Typowy format modelu Uwaga praktyczna
llama.cpp / llama-server Tak Tak GGUF Najlepsza platforma do kontrolowanego testu A/B backendów
Ollama Tak Tak Zarządzane modele pochodne GGUF Wygodny, ale wybór backendu i pakietowanie są abstrahowane
LM Studio Tak Tak GGUF i formaty zarządzane produktem Do wyboru runtime’y ułatwiają testowanie desktopowe
vLLM Tak Nie Safetensors i obsługiwane kwantyzacje Użyj dopasowanego obrazu lub zestawu kół ROCm od AMD; najpierw zweryfikuj pokrycie kerneli dla rodziny GPU
SGLang Tak Nie Safetensors i obsługiwane kwantyzacje ROCm jest częścią architektury wdrożenia
TGI Tak Nie Safetensors i obsługiwane kwantyzacje Opublikowana weryfikacja AMD pozostaje skupiona na Instinct
LocalAI Tak Tak Zależne od backendu, zazwyczaj GGUF Używa różnych obrazów kontenerów ROCm i Vulkan

ROCm nie oznacza automatycznie Safetensors, a Vulkan nie formalnie implikuje GGUF. Przydatne skojarzenie wynika z silników: llama.cpp może czytać ten sam GGUF przy użyciu kompilacji HIP lub Vulkan, podczas gdy serwery natywne dla PyTorch używają ROCm i zazwyczaj pobierają repozytoria modeli z Hugging Face.

To czyni inwentarz modeli ograniczeniem architektonicznym. Biblioteka starannie dobranych zkwantyzowanych GGUF naturalnie wskazuje na llama-server, Ollama, LM Studio lub LocalAI; wdrożenie zbudowane wokół równoległości tensorów, ciągłego batchowania i wag natywnych dla frameworku wskazuje na ROCm z vLLM lub SGLang. Dla szerszego krajobrazu silników poza backendami AMD — dojrzałość API, wywoływanie narzędzi i gotowość produkcyjną ponad dziesięciu narzędzi — zobacz nasze porównanie Ollama, vLLM, LM Studio, LocalAI i innych narzędzi do lokalnego hostowania LLM.

llama.cpp: najczystsze porównanie ROCm z Vulkan

llama.cpp wystawia oba backendy bez zmiany pliku modelu lub klienta HTTP. To najbardziej sprawiedliwe miejsce do porównania ROCm i Vulkan, ponieważ tokenizator, ustawienia próbkowania, szablon czatu, kwantyzacja i zachowanie serwera mogą pozostać niezmienione.

Aktualna dokumentacja budowy llama.cpp używa GGML_HIP dla ROCm i GGML_VULKAN dla Vulkan. Stare artykuły zalecające GGML_ROCM lub usunięte flagi Makefile nie powinny być zaufane bez sprawdzenia bieżących opcji CMake projektu.

Budowanie backendu Vulkan na systemie Ubuntu

Zainstaluj nagłówki Vulkan, kompilator shaderów i nagłówki SPIR-V, a następnie zweryfikuj, że sterownik może wyliczyć intended GPU:

sudo apt-get update
sudo apt-get install -y libvulkan-dev glslc spirv-headers vulkan-tools

vulkaninfo --summary

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -S . -B build-vulkan \
  -DGGML_VULKAN=ON \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-vulkan --config Release -j

W systemie z mieszanką iGPU i dedykowanego GPU, kolejność wyliczania zasługuje na uwagę. GGML_VK_VISIBLE_DEVICES może ograniczyć llama.cpp do konkretnego urządzenia Vulkan, a log startowy powinien podać nazwę wybranej karty, a nie tylko raportować, że istnieje urządzenie Vulkan.

Budowanie backendu ROCm lub HIP

Najpierw potwierdź, że ROCm identyfikuje GPU i raportuje oczekiwany cel gfx. Cel można pominąć, aby zbudować dla GPU w bieżącym systemie, ale jego przypięcie zmniejsza pracę kompilacji, gdy znasz sprzęt docelowy.

rocminfo | grep -E 'Name:.*gfx' | head
hipconfig --full

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

HIPCXX="$(hipconfig -l)/clang" \
HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build-rocm \
  -DGGML_HIP=ON \
  -DGPU_TARGETS=gfx1201 \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build-rocm --config Release -j

Zamień gfx1201 na cel raportowany dla faktycznej karty — ta wartość odpowiada rodzinie RX 9070/9070 XT/9070 GRE i Radeon AI PRO R9700 w RDNA 4, podczas gdy gfx1200 obejmuje serię RX 9060, a gfx1100/gfx1101/gfx1102 obejmują linie RX 7900/7800/7700/7600 z RDNA 3. Nie kopiuj HSA_OVERRIDE_GFX_VERSION do usługi produkcyjnej tylko dlatego, że pomógł komuś uruchomić niewspierane GPU; nadpisanie może sprawić, że kod się załaduje, ale nie przekształci tego sprzętu w zwalidowaną platformę.

Benchmarkuj to samo obciążenie, a nie dwa domyślne

Użyj jednego pliku GGUF, tych samych ustawień flash-attention, tego samego offloadu warstw i powtórzonych uruchomień. Przetwarzanie promptu (pp) i generowanie tokenów (tg) obciążają system inaczej, podczas gdy serwer z długim kontekstem dodaje również alokację KV-cache i presję pamięci, których krótki syntetyczny benchmark może przeoczyć.

MODEL=/srv/models/model.gguf

./build-vulkan/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

./build-rocm/bin/llama-bench \
  -m "$MODEL" -ngl 999 -fa 1 -p 512 -n 128 -r 5

Wyniki społeczności ilustrują, dlaczego uniwersalny zwycięzca jest mylący, a cel gfx1201 z RDNA 4 jest najsłynniejszym niedawnym przykładem. W jednym z nadesłanych wyników na RX 9070 XT na tej samej maszynie, Vulkan osiągnął około 143 tokenów/s w porównaniu z 128 tokenów/s ROCm w teście generowania 7B Q4_0, ale późniejsze nadesłania wykazały mniejsze różnice wraz z zmianami kompilacji; dyskusje Vulkan i ROCm zawierają również duże różnice w wynikach przetwarzania promptu i warunkach testowych. Osobny, bardziej szczegółowy test OpenBenchmarking.org na RX 9070 XT z llama.cpp b6401 wykazał, że Vulkan prowadzi w dekodowaniu dla kilku modeli klasy 8B (Qwen3-8B-Q8_0, Llama-3.1-Tulu-3-8B-Q8_0), ale traci do HIP w przetwarzaniu promptu przy dłuższych promptach — dwa backendy wymieniają się prowadzeniem w zależności od tego, którą fazę mierzysz.

Różnica może też działać w drugą stronę, i to znacząco, dla konkretnych kształtów modeli. Otwarty problem w llama.cpp dokumentuje, że Vulkan na gfx1201 staje się 4,7–6,7x wolniejszy niż HIP w generowaniu tokenów, gdy rozmiar ukryty modelu osiąga 4096 lub więcej (skuteczna przepustowość dekodowania spada do około 70–100 GB/s na karcie o przepustowości 640 GB/s), podczas gdy mniejszy model 4B o rozmiarze ukrytym 2560 nie wykazuje takiej regresji w żadnym z backendów. Traktuj każdą liczbę tutaj jako migawkę jednej kompilacji, jednego sterownika i jednego kształtu modelu — nie jako regułę, która uogólnia się na typ kwantyzacji, architekturę modelu, flash attention, rozmiary batchy, wersję sterownika, stan termiczny lub commit llama.cpp.

Ollama na AMD: wygodne, ale zweryfikuj backend

Ollama oficjalnie wspiera wymienione GPU AMD przez ROCm i obecnie dokumentuje dodatkowe pokrycie AMD przez Vulkan na systemach Windows i Linux. Jego aktualna strona wsparcia sprzętowego stwierdza, że Vulkan jest domyślnie włączony, gdy backend jest zainstalowany, obsługuje GGML_VK_VISIBLE_DEVICES do wyboru urządzenia i można go wyłączyć za pomocą OLLAMA_VULKAN=0.

Jest to istotna poprawa w porównaniu z okresem, gdy porady dotyczące Vulkan opierały się na eksperymentalnych kompilacjach. Również sprawia, że niektóre starsze tutoriale stają się nieaktualne: ustawianie niezadokumentowanego przełącznika i zakładanie, że usługa wybrała Vulkan, to słabszy dowód niż czytanie logu serwera.

sudo systemctl edit ollama

W diagnostyce dodaj plik drop-in, zamiast eksportować zmienne tylko w interaktywnym shellu:

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="GGML_VK_VISIBLE_DEVICES=0"

Następnie przeładuj, zrestartuj i sprawdź zarówno rozmieszczenie procesu, jak i komunikaty wykrywania:

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -b --no-pager | tail -n 200

ollama run qwen3:8b "Zwróć dokładnie: test backendu zakończony sukcesem"
ollama ps

Szukaj nazwanego GPU, wybranej biblioteki, alokacji modelu i procentu GPU. Log pokazujący timeout wykrywania, a następnie udaną odpowiedź HTTP, może oznaczać, że Ollama cicho wycofał się na CPU. Dla codziennego zestawu poleceń wokół tej usługi, Ściągawka CLI Ollama jest szybszym źródłem referencyjnym.

Ollama jest świetny, gdy nabywanie modeli i stabilne lokalne API ważą więcej niż kontrola nad backendem. Jeśli celem są powtarzalne testy ROCm-vs-Vulkan, czysty llama-server jest lepszym narzędziem, ponieważ katalog kompilacji czyni backend jawnym.

vLLM i SGLang sprawiają, że ROCm jest decyzją — ale najpierw sprawdź pokrycie kerneli dla rodziny GPU

vLLM i SGLang nie są aplikacjami Vulkan. Ich ścieżki AMD opierają się na ROCm, PyTorch i zoptymalizowanych kernelach HIP, więc wybór jednego z tych silników już wybrał platformę obliczeniową.

Aktualny przewodnik vLLM na ROCm od AMD zaleca gotowy kontener i publikuje dopasowane obrazy dla ROCm, PyTorch, Pythona i vLLM. To sprzężenie jest przydatne: zastępuje duże ćwiczenie w rozwiązywaniu zależności jednostką wdrożenia z wersjonowaniem.

W chwili pisania, AMD dokumentuje ten obraz ROCm 10 dla vLLM 0.27:

docker pull \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0

docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  --group-add video \
  --ipc=host \
  --network=host \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  -v /srv/models:/app/models \
  -e HF_HOME=/app/models \
  rocm/vllm:rocm10.0.0_ubuntu24.04_py3.14_pytorch_2.12.0_vllm_0.27.0 \
  bash

Użyj obrazu wybranego dla dokładnej rodziny GPU w dokumentacji AMD; obrazy RDNA i CDNA nie zawsze były zamiennymi. Dla serwera produkcyjnego przypnij pełny tag lub digest i zwaliduj sterownik hosta, zanim obwinisz vLLM za błąd inicjalizacji.

Nowe generacje GPU to najostrowszy przypadek graniczny, a RDNA 4 to realny, udokumentowany przykład, a nie teoretyczne ryzyko. Niezależne testy na RX 9070 XT (gfx1201) na początku 2026 roku wykazały, że vLLM na ROCm 7.2 cicho wycofuje się na dekwantyzację FP32 dla wag modeli FP8 — ponieważ gfx1201 nie był jeszcze rozpoznawany w wykrywaniu platformy w vLLM — co całkowicie pomijało akceleratory macierzowe GPU i dawało tylko 48 tokenów/s, w porównaniu z 62 tokenami/s z llama-server na Vulkanie uruchamiającego kwantyzację GGUF porównywalnego modelu na tej samej karcie. Lekcja uogólnia się: stos ROCm/PyTorch może się załadować pomyślnie na nowej architekturze, a wciąż uruchamiać niezoptymalizowaną ścieżkę zapasową bez komunikatu o błędzie. Zawsze potwierdzaj, która ścieżka kernela faktycznie się wykonała (za pomocą rocprof, notatek profilingowych dostawcy lub znanego dobrego baseline’u przepustowości dla GPU), zanim zaufasz jednemu wynikowi “uruchomiło się bez problemu” na sprzęcie, który wyszedł w ciągu ostatnich dwóch cykli wydawania.

Powodem, dla którego należy zaakceptować większą powierzchnię operacyjną ROCm, po potwierdzeniu pokrycia kerneli, jest architektura przepustowości — nie tylko kilka dodatkowych tokenów/s w teście jedno-użytkownika. Ciągłe batchowanie, kwantyzacja natywna dla frameworku, równoległość tensorów, zachowanie planisty i otaczające narzędzia PyTorch to prawdziwe uzasadnienie dla przejścia na vLLM, a jeśli rozważasz, czy to przejście jest w ogóle uzasadnione, nasz przewodnik migracji z Ollama na vLLM wymienia sygnały obciążenia.

TGI: wsparcie ROCm z węższym celem

Hugging Face dokumentuje obraz AMD dla Text Generation Inference, ale jego opublikowana walidacja koncentruje się na sprzęcie Instinct MI210, MI250 i MI300. Przewodnik TGI dla AMD używa obrazu 3.3.5-rocm i wymienia niewspierane funkcje ROCm, więc nie powinien być uogólniany jako obietnica dla każdej karty Radeon. Nasz przewodnik instalacji TGI omawia konfigurację tego obrazu ROCm z większą szczegółowością.

Nie ma ścieżki Vulkan TGI do porównania. Jeśli TGI jest stałym wymogiem, wybierz wspierany sprzęt ROCm i odtwórz udokumentowany kontener; jeśli silnik jest negocjowalny, obecne wsparcie vLLM i SGLang zasługuje na ocenę przed rozpoczęciem nowego wdrożenia AMD.

LM Studio: przełączaj runtime’y zamiast ponownie budować

LM Studio pakuje wiele runtime’ów inferencji i wystawia zarządzanie nimi przez polecenie lms. Jego dokumentacja runtime’ów obsługuje listowanie, pobieranie, wybieranie, aktualizowanie i usuwanie runtime’ów, co czyni eksperymenty ROCm-vs-Vulkan dostępnymi bez utrzymania osobnych drzew źródeł.

lms runtime ls
lms runtime get
lms runtime select

Uruchom ten sam GGUF z tą samą długością kontekstu, offloadem GPU, ustawieniem flash-attention i promptem. Porównaj czas do pierwszego tokenu, szybkość generowania, czas ładowania i szczytową pamięć, zamiast sądzić backend na podstawie jednej krótkiej odpowiedzi czatu.

Pakietowanie runtime’ów nie eliminuje błędów specyficznych dla backendu. Na przykład problem LM Studio z R9700 z 2026 roku raportował zawieszenie się dużego modelu w pobliżu końca ładowania ROCm, podczas gdy runtime Vulkan go załadował, podczas gdy osobny problem z zapasem pamięci Vulkan opisywał przeciwny wynik w pobliżu pełnego VRAM. To są indywidualne raporty, ale łącznie stawiają właściwy punkt operacyjny: zachowuj runtime zapasowy i zostawiaj zapas pamięci.

LocalAI: wybierz obraz tak samo jak backend

LocalAI zapewnia osobne warianty kontenerów ROCm lub hipblas oraz Vulkan. Jego przewodnik przyspieszenia GPU dokumentuje obrazy gpu-hipblas do obliczeń AMD i obrazy gpu-vulkan dla przenośnej ścieżki, więc tag kontenera skopiowany z przewodnika CUDA nie wywoła magicznie wykrycia właściwego backendu. Szybki start LocalAI obejmuje ogólną konfigurację; wybór specyficznego dla backendu kontenera to to, co ta sekcja dodaje.

Kontener ROCm wymaga /dev/kfd i /dev/dri, podczas gdy Vulkan zazwyczaj wymaga odpowiedniego urządzenia renderującego pod /dev/dri. Przypnij tag wydania dla realnej usługi; latest i master są przydatne do diagnostyki, ale czynią rollback i porównanie wydajności niepotrzebnie niejednoznacznymi.

# Obraz ROCm lub HIP
docker run --rm -it \
  --device /dev/kfd \
  --device /dev/dri \
  -p 8080:8080 \
  quay.io/go-skynet/local-ai:v4.8.0-gpu-hipblas

# Obraz Vulkan
docker run --rm -it \
  --device /dev/dri \
  -p 8080:8080 \
  localai/localai:v4.8.0-gpu-vulkan

Przykłady tagów odzwierciedlają dokumentację dostępną w chwili publikacji; potwierdź bieżące nazwy rejestru przed automatyzacją pobierania. Co ważniejsze, nie wyciągaj wniosków o przyspieszeniu tylko z nazwy kontenera — sprawdź log debug LocalAI i obserwuj wykorzystanie GPU podczas wysyłania żądań.

Co zmieniło się w pakietowaniu ROCm 10

ROCm 10 to nie tylko kolejna drobna aktualizacja pakietów. Przewodnik przejścia na TheRock od AMD stwierdza, że pakiety ROCm Core SDK używają teraz prefiksu amdrocm-, wersjonowany korzeń instalacji to /opt/rocm/core-10.0, a kilka tradycyjnych pakietów zostało scalonych.

Dlatego polecenie ze starszego artykułu ROCm może zwracać „package not found” nawet na poprawnie skonfigurowanym repozytorium. Na przykład HIPCC pochodzi teraz z amdrocm-llvm, składniki BLAS są połączone w amdrocm-blas, a pełna instalacja systemowa może używać metapakietu Core SDK dla wszystkich architektur lub specyficznego dla rodziny GPU — karty RDNA 4 używają tagu rodziny gfx120X-all (sufiks pakietu -gfx1200-gfx1201), co warto wiedzieć, zanim będziesz szukać nazwy pakietu tylko dla gfx1201, która nie istnieje.

Metapakiet amdrocm konfiguruje alternatywy i linki kompatybilności pod /opt/rocm. Minimalna lub niestandardowa instalacja może nie zapewniać tych samych ścieżek, więc skrypty budujące z twardo zakodowanym /opt/rocm/bin/hipcc powinny albo używać hipconfig, albo jawnie ustawić ROCM_PATH.

Dwie zmiany diagnostyczne łatwo umknąć uwadze. ROCm SMI został usunięty na rzecz AMD SMI, a ROCm Bandwidth Test osiągnął koniec życia; skrypty wywołujące rocm-smi lub rocm-bandwidth-test muszą przejść na amd-smi i narzędzia zastępcze AMD, zamiast ponownie instalować dowolne tradycyjne pakiety.

Kontenery wciąż zależą od hosta

Kontener ROCm niesie biblioteki użytkownika, a nie zamiennik sterownika kernela. Host musi wystawić /dev/kfd i /dev/dri, jego sterownik musi być kompatybilny ze stosem kontenera, a użytkownik usługi potrzebuje uprawnień do otworzenia tych urządzeń.

Kontenery Vulkan mają podobną granicę wokół sterownika Vulkan hosta i węzła renderującego. Pakowanie jest lżejsze, ale nieprawidłowy ICD, brakująca członkostwo w grupie renderingu lub przypadkowo wybrany iGPU może wciąż przekształcić działający obraz kontenera w usługę ograniczoną przez CPU lub niestabilną.

Dedykowane GPU, APU i starsze karty Radeon

Dedykowane GPU RDNA 3 i RDNA 4

Bieżące modele Radeon RX 7000, RX 9000 i Radeon AI Pro mają najsilniejszy przypadek do testowania obu backendów llama.cpp. Wsparcie ROCm jest teraz jawne dla wielu celów gfx110x i gfx120x, podczas gdy Vulkan przez bieżący Mesa RADV lub sterownik dostawcy Windows jest wystarczająco dojrzały, aby być ścieżką główną, a nie rozpaczliwym awaryjnym rozwiązaniem. Po stronie sprzętowej tej decyzji — VRAM, przepustowość, moc i ceny między dostawcami — zobacz nasze porównanie GPU do obciążeń AI w 2026 roku.

Nie przekształcaj benchmarku 7B w regułę dla modelu dense 27B lub modelu mixture-of-experts. Kształty macierzy, aktywne parametry, zkwantyzowane kernle, długość promptu i presja pamięci mogą zmienić kolejność, a wydajność backendów znacznie zmieniła się między rewizjami llama.cpp — regresja rozmiaru ukrytego gfx1201 wspomniana powyżej jest konkretnym przypadkiem właśnie tego rodzaju zmiany.

APU Ryzen i wspólna pamięć

Systemy Ryzen AI Max z dużą pamięcią są niezwykle interesujące, ponieważ GPU może uzyskać dostęp do znacznie większej puli pamięci współdzielonej niż normalna dedykowana karta konsumencka. ROCm 10 wymienia bieżące rodziny Ryzen AI, a kompatybilne z Vulkanem runtime’y llama.cpp mogą również używać iGPU bez budowania środowiska PyTorch.

Pojemność to nie przepustowość. To, że model mieści się w 64 GB lub 96 GB przydzielonej pamięci współdzielonej, nie oznacza, że będzie dekodował jak karta dedykowana 32 GB, a agresywna alokacja kontekstu może ogłodzić system operacyjny, nawet gdy aplikacja raportuje wystarczającą pamięć GPU. Ta sama dyscyplina budżetu VRAM, która dotyczy dedykowanych kart NVIDIA i AMD, dotyczy tutaj również — zobacz [KV Cache na GPU 16 GB](https://www.glukhov.org/pl/llm-performance/optimization/kv-cache-16gb-long-context/ “Umieść kontekst LLM 32K–128K w VRAM 16 GB, obliczając koszt KV cache, wybierając precyzję cache i bezpiecznie strojąc llama.cpp, vLLM lub Ollama.”}, aby poznać podstawowe wyliczenia budżetowe, które są niezależne od backendu.

Maszyny z mieszanym iGPU i dGPU wymagają jawnego wyboru urządzenia. Niedawny raport llama.cpp opisał nadmierną rezerwację systemowej pamięci, gdy niewykorzystywany iGPU pozostał widoczny obok R9700; to niewyjaśniony problem, ale to dobry powód, aby wystawiać tylko urządzenie, którego ma używać usługa.

Starszy i niewspierany sprzęt Radeon

Vulkan jest zazwyczaj pierwszą ścieżką dla starszych Radeonów, ponieważ pokrycie sterowników graficznych jest szersze niż zestaw wspieranych celów obliczeniowych ROCm. Projekty oparte na ROCm notują również, że nowsze wydania rocBLAS usunęły kernle dla niektórych starszych celów, więc wymuszenie pobliskiej wartości gfx nie może przywrócić kodu, który nie jest już dostarczany.

Nadpisanie jest akceptowalne dla eksperymentu laboratoryjnego z jasnymi oczekiwaniami awarii. To słaba podstawa dla niepilnowanego API, ponieważ następna aktualizacja ROCm lub aplikacji może zastąpić tolerowaną nieścisłość błędem startowym lub błędnym wynikiem.

Linux vs Windows dla backendów LLM AMD

Linux to naturalny host ROCm do inferencji produkcyjnej. Oferuje najszersze wsparcie silników, ugruntowane mapowanie urządzeń kontenera, bieżące sterowniki Vulkan Mesa i narzędzia operacyjne oczekiwane przez wdrożenia vLLM i SGLang.

Windows ma prawdziwe wsparcie ROCm dla wymienionego sprzętu, ale ekosystem aplikacji pozostaje węższy. Dla desktopowej inferencji GGUF przez llama.cpp, Ollama lub LM Studio, Vulkan jest zazwyczaj spokojniejszym punktem startowym; używaj ROCm, gdy aplikacja oferuje wspieraną ścieżkę Windows i konkretna funkcja lub benchmark to uzasadnia.

WSL2 należy traktować jako trzecią platformę, a nie synonim natywnego Linuxa. Dopasuj udokumentowany sterownik Windows AMD, dystrybucję WSL, wydanie ROCm i pakiet frameworku jako jedną wspieraną kombinację.

Checklista weryfikacyjna przed obsługą ruchu

Zacznij poniżej aplikacji. Jeśli sterownik nie może wyliczyć prawidłowego urządzenia, zmienianie flag modelu to tylko przestawianie objawu.

lspci -nnk | grep -A3 -E 'VGA|Display'
ls -l /dev/kfd /dev/dri/renderD* 2>/dev/null
id

# Ścieżka ROCm
rocminfo | grep -E 'Marketing Name:|Name:.*gfx' | head -n 20
amd-smi list

# Ścieżka Vulkan
vulkaninfo --summary

Następnie zweryfikuj silnik. Wyjście startowe musi podać nazwę ROCm lub Vulkan, nazwać intended GPU i raportować, że warstwy lub tensory modelu zostały na nim umieszczone; w końcu pamięć i wykorzystanie GPU muszą wzrosnąć, podczas gdy żądanie jest w trakcie.

# Obserwuj GPU AMD, gdy inny terminal wysyła żądania
watch -n1 amd-smi monitor

# Podstawowy sprawdzian API kompatybilnego z OpenAI dla llama-server
curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "local-model",
    "messages": [{"role": "user", "content": "Zwróć dokładnie: gotowe"}],
    "max_tokens": 8,
    "temperature": 0
  }'

Zapisz sterownik, runtime, commit silnika lub digest obrazu, sumę kontrolną pliku modelu, kontekst, ustawienia batcha i linię poleceń przy każdym benchmarku. Bez tych metadanych, liczba tokenów na sekundę to anegdota, która nie przetrwa następnej aktualizacji — i jak pokazuje zarówno fallback vLLM na gfx1201, jak i regresja rozmiaru ukrytego Vulkan powyżej, prawdopodobnie wyglądająca liczba może ukrywać cicho niezoptymalizowaną ścieżkę kodu.

Tryby awarii, które wyglądają jak wydajność backendu

Ciche wycofanie na CPU

Serwer startuje i odpowiada poprawnie, ale generowanie jest nieoczekiwanie powolne, a wykorzystanie GPU pozostaje płaskie. Sprawdź logi wykrywania, uprawnienia urządzenia, offload modelu i urządzenia kontenera przed strojeniem wątków lub parametrów próbkowania.

Ciche wycofanie precyzji (nowy sprzęt, nowe kernle)

Serwer startuje, wykorzystanie GPU wygląda rozsądnie i nie ma błędu — ale framework cicho spadł na niezoptymalizowaną ścieżkę numeryczną, ponieważ zdolność obliczeniowa GPU lub jego ciągła architektura nie były jeszcze rozpoznawane. To dokładnie to, co stało się z kernelami FP8 vLLM na gfx1201; rozwiązaniem jest sprawdzenie kodu wykrywania platformy samego frameworku lub jego śledzika problemów dla dokładnego ciągu GPU, zanim zaufasz jednej liczbie przepustowości na generacji GPU wydanej w ciągu ostatnich dwóch cykli wydawania.

Wybrano nieprawidłowe GPU

Desktop Ryzen może wystawiać iGPU jako urządzenie Vulkan 0, a dedykowanego Radeona jako urządzenie 1. Ogranicz widoczne urządzenia i potwierdź pełną nazwę urządzenia w logu; nie zakładaj, że numeracja jest stabilna po zmianie sterownika lub BIOS-u.

Niedopasowanie celu ROCm

rocminfo raportuje jeden cel gfx, podczas gdy obraz aplikacji zawiera kernle dla innego zestawu. Użyj dopasowanego obrazu lub ponownie zbuduj dla dokładnego celu; zarezerwuj HSA_OVERRIDE_GFX_VERSION dla jawnych eksperymentów z niewspieranymi celami.

Niedopasowanie sterownika i przestrzeni użytkownika

Kontener ma bieżące biblioteki ROCm, ale sterownik hosta należy do starszego strumienia wydawniczego. Timeouts podczas wykrywania, błędy uruchamiania kernela lub wycofanie na CPU są bardziej prawdopodobne niż czysty komunikat wyjaśniający granicę wersji.

Mylenie ICD Vulkan

Zainstalowano więcej niż jedną implementację Vulkan, a loader wybiera nieoczekiwany ICD. Przeszukaj vulkaninfo, usuń przypadkowe duplikaty lub jawnie wybierz intended ICD i urządzenie, zamiast nakładać kolejny SDK na problem.

Szacunki VRAM nie zostawiają marginesu operacyjnego

Model wydaje się mieścić, ale zawodzi podczas rozgrzewki, konfiguracji flash-attention lub pierwszego długiego promptu. Zostaw kilka gigabajtów zapasu przy dużym modelu, a następnie zmniejsz kontekst lub rozmiar batcha, zanim wyciągniesz wniosek, że backend nie może uruchomić kwantyzacji.

Praktyczna procedura wyboru backendu

Krok 1: wybierz zachowanie serwowania

Jeśli celem jest jeden lub dwóch użytkowników lokalnych, pliki GGUF i prosty endpoint kompatybilny z OpenAI, zacznij od llama-server, Ollama lub LM Studio. Jeśli celem jest ciągłe batchowanie, wysoka współbieżność, modele natywne dla frameworku lub równoległość tensorów, zacznij od vLLM lub SGLang i zaakceptuj ROCm jako część projektu.

Krok 2: sprawdź oficjalne wsparcie sprzętowe

Dopasuj dokładny cel GPU, wersję systemu operacyjnego, kernel i sterownik w bieżącej macierzy ROCm. Dla Vulkan, potwierdź intended GPU przez vulkaninfo i użyj bieżącego sterownika, zamiast zakładać, że obecność libvulkan.so dowodzi użytecznego wsparcia obliczeniowego. Jeśli GPU pochodzi z najnowszej generacji architektury, sprawdź również kod wykrywania platformy konkretnego frameworku lub otwarte problemy dla tego dokładnego celu gfx — oficjalne wsparcie i wsparcie zoptymalizowanych kerneli nie zawsze wydają się razem.

Krok 3: ustanów najprostszy działający baseline

Dla GGUF, Vulkan jest zazwyczaj tym baseline’em, ponieważ zmienia mniej składowych systemu. Dla silnika PyTorch, użyj przypiętego kontenera ROCm od AMD, zamiest składać torch, Triton, AITER i vLLM z niezwiązanych najnowszych wersji.

Krok 4: benchmarkuj prompty o kształcie produkcyjnym

Mierz przetwarzanie promptu, czas do pierwszego tokenu, szybkość dekodowania, szczytową pamięć i zachowanie przy współbieżnych żądaniach. Uwzględnij wzorzec kontekstu i wywoływania narzędzi, którego użyje realna usługa; mikro-benchmark 128 tokenów nie przewiduje sesji agenta 100 000 tokenów.

Krok 5: utrzymuj wdrożenie zapasowe w stanie gotowym

Dwa katalogi kompilacji llama.cpp kosztują mało w porównaniu z dniem utraconym na regresję sterownika. Utrzymuj ostatni znany poprawny digest kontenera lub zainstalowany runtime i przechodź do przodu dopiero po tym, jak kandydat przejdzie ten sam zestaw testów.

Ta sama procedura jako przepływ decyzyjny:

flowchart LR A["Wybierz silnik serwowania"] --> B{"Silnik PyTorch/HIP?"} B -- Tak --> C["ROCm: przypięty kontener
+ sprawdzenie pokrycia kerneli"] B -- Nie --> D{"GGUF na GPU AMD?"} D -- Tak --> E["Baseline Vulkan"] E --> F{"Benchmark: ROCm wygrywa
wymierną przewagą?"} F -- Tak --> G["Przejdź na ROCm"] F -- Nie --> H["Zachowaj Vulkan,
zachowaj kompilację ROCm jako zapas"]

Ostateczny werdykt: ROCm czy Vulkan do hostowania LLM na AMD?

Vulkan jest najlepszym domyślnym wyborem dla lokalnej inferencji GGUF, gdy liczy się przenośność, szybkość konfiguracji, wsparcie Windows lub pokrycie starszych Radeonów. Nie jest już rozsądne opisywać go jako inherentnie wolnego; na niektórych niedawnych kombinacjach Radeon i llama.cpp to on jest szybszym backendem, a na innych jest wystarczająco blisko, że niższe tarcie operacyjne wygrywa.

ROCm jest właściwym wyborem, gdy silnik jest zbudowany wokół PyTorch, gdy AMD Instinct i obliczenia wielo-GPU są centralne, lub gdy przetestowana kompilacja HIP wygrywa faktyczne obciążenie modelu. Jego ekosystem jest znacznie silniejszy w 2026 roku, ale nowe pakietowanie i ścisłe warstwy kompatybilności wciąż wynagradzają przypięte wersje i dyscyplinowaną weryfikację — a na najnowszej generacji RDNA konkretnie, weryfikacja, że zoptymalizowana ścieżka kernela faktycznie się wykonała, nie jest opcjonalna.

Dla wspieranego stacji roboczej Radeon, moja rekomendacja jest celowo nie-romantyczna: zainstaluj najpierw Vulkan, dodaj ROCm, gdy silnik lub benchmark uzasadni złożoność, i utrzymuj oba kompilacje llama.cpp, jeśli maszyna regularnie serwuje różne kształty modeli. Najlepszy backend AMD to nie stała własność karty; to własność karty, silnika, modelu, sterownika i obciążenia razem.

Bibliografia

Subskrybuj

Otrzymuj nowe wpisy o systemach, infrastrukturze i inżynierii AI.