ROCm vs. Vulkan für das lokale Betreiben von LLMs auf AMD-Hardware: 2026er Leitfaden

Das passende AMD-Backend für jede Engine auswählen

Inhaltsverzeichnis

Sowohl ROCm als auch Vulkan beschleunigen AMD-GPUs für den lokalen Betrieb von LLMs, aber sie sind nicht austauschbar. Die richtige Wahl hängt von der Engine, der GPU und der Arbeitslast ab.

Beim lokalen Betrieb von LLMs befinden sich die beiden Backends in unterschiedlichen Ebenen. ROCm ist die Compute-Plattform von AMD unter PyTorch, vLLM und SGLang, während Vulkan eine portable GPU-API ist, die Engines vom Typ llama.cpp verwenden, um quantisierte Modelle auf einer breiten Palette von Hardware zu betreiben.

ROCm- und Vulkan-Backends für den lokalen LLM-Betrieb auf AMD

Dieser Leitfaden vergleicht die beiden Engines – llama.cpp, Ollama, LM Studio, vLLM, SGLang, TGI und LocalAI – anhand von Build-Befehlen, Geräteprüfungen und Fehlermodi, die sich als Leistungsschwierigkeiten tarnen. Wenn Sie neu in der Landschaft des Hostings sind, beginnen Sie mit dem Überblick zum LLM-Hosting, in dem die Werkzeugfamilien eingeordnet werden, die dieser Artikel vertiefend behandelt.

ROCm vs. Vulkan: die kurze Antwort

Situation Empfohlener Startpunkt Warum
llama.cpp mit GGUF unter Linux Vulkan Geringe Installationsfläche, breite GPU-Abdeckung und einfache Rückführung
llama.cpp auf einer unterstützten RDNA-3- oder RDNA-4-GPU Beide benchmarken Kernel-Performance ändert sich je nach Modellform, Quantisierung, Kontext und Build
Ollama auf einer gelisteten AMD-GPU Zuerst ROCm, Vulkan ebenfalls prüfen Ollama unterstützt beide, aber die Backend-Auswahl ist weniger explizit als beim reinen llama.cpp
LM Studio auf einer Desktop-AMD-GPU Zuerst Vulkan Runtime-Wechsel erleichtern den Vergleich und vermeiden einen systemweiten Compute-Stack
vLLM oder SGLang ROCm, aber GPU-Familien-Abdeckung der Kernel prüfen Dies sind PyTorch/HIP-Stacks; Vulkan ist kein alternatives Backend, und brandneue Architekturen können noch keine optimierten Kernel haben
TGI auf unterstützter Instinct-Hardware ROCm Der publizierte AMD-Container-Pfad zielt auf die MI210-, MI250- und MI300-Familien ab
Ältere oder nicht gelistete Radeon-GPU Vulkan Vulkan-Treiber decken in der Regel mehr Grafikhardware ab als ROCm-Bibliotheken
AMD-Instinct-Server ROCm Multi-GPU-Compute, RCCL, Framework-Kernel und Betriebswerkzeuge befinden sich hier
Lokale GGUF-Bereitstellung unter Windows Vulkan Es ist allgemein der wenigstens restriktive Weg für Runtime-Engines vom Typ llama.cpp
Ryzen AI Max oder andere APUs mit viel Speicher Zuerst Vulkan, dann ROCm, falls erforderlich Beide können funktionieren, aber Shared Memory und Kernel-Unterstützung erfordern lastspezifische Tests

Diese Tabelle ist eine Ausgangspolitik, kein Benchmark-Ergebnis. Ein Backend, das die GPU erkennt, aber einige Operationen auf der CPU belässt, kann gesund wirken und gleichzeitig schlecht performen; daher benötigt jede finale Entscheidung eine Protokollprüfung und einen End-to-End-Prompt-Test.

Was ROCm und Vulkan tatsächlich sind

ROCm ist eine Compute-Plattform

ROCm umfasst die HIP-Laufzeitumgebung, den Compiler, Mathematikbibliotheken, kolektive Kommunikation, Profiler und Framework-Pakete, die für den AMD-Compute-Workload benötigt werden. Es ist das AMD-Fundament unter PyTorch-Builds und Engines wie vLLM und SGLang und kann auch llama.cpp über seinen HIP-Backend beschleunigen.

Diese Breite ist ROCms Vorteil und zugleich sein Kostenfaktor. Host-Treiber, GPU-Ziel, User-Space-Bibliotheken, Framework-Wheel, Kernel-Version und Container-Image müssen einen kompatiblen Satz bilden; wenn sie das tun, bietet ROCm weit mehr als Token-Generierung durch ein einzelnes lokales Executable.

ROCm 10.0.0, veröffentlicht am 26. August 2026, basiert auf TheRock (AMDs Build- und Release-System seit ROCm 7.14), validiert PyTorch 2.13, vLLM 0.27 und SGLang 0.5.15 und fügt offiziell die RDNA-4-Unterstützung für gfx1200 (RX 9060/9060 XT/9050) und gfx1201 (RX 9070/9070 XT/9070 GRE, Radeon AI PRO R9700-Serie) hinzu. Die ROCm-Kompatibilitätsmatrix bleibt die Autorität für eine exakte GPU- und Betriebssystem-Kombination, nicht ein Forumseinstieg, der zufällig die gleiche Marketing-Familie verwendet.

Vulkan ist eine portable GPU-Schnittstelle

Vulkan ist eine API für Grafik und Compute, die von einem GPU-Treiber implementiert wird. Beim lokalen LLM-Hosting bedeutet es normalerweise, dass eine Inferenz-Engine Compute-Shaders mitliefert oder kompiliert, die über eine Vulkan-Implementierung wie Mesa RADV unter Linux oder den Herstellertreiber unter Windows ausgeführt werden.

Vulkan bietet keine drop-in-PyTorch-Plattform, die mit ROCm vergleichbar wäre. Ihre praktische Stärke ist enger und nützlich: Eine Engine im Stil von llama.cpp kann dasselbe Backend-Design auf AMD-, Intel-, Nvidia- und anderer Vulkan-fähiger Hardware verwenden, ohne einen hersteller-spezifischen Machine-Learning-Stack zu installieren.

Diese Unterscheidung erklärt die meisten Entscheidungen. Wenn die Anwendung nur einen HIP- oder PyTorch-Pfad bietet, kann Vulkan sie nicht retten; wenn die Anwendung bereits auf llama.cpp und GGUF basiert, kann die Installation des gesamten ROCm-Stacks ein Problem lösen, das Sie nicht hatten.

Matrix der Engine-Unterstützung im Jahr 2026

Engine ROCm oder HIP Vulkan Typisches Modellformat Praktischer Hinweis
llama.cpp / llama-server Ja Ja GGUF Beste Plattform für einen kontrollierten A/B-Backend-Test
Ollama Ja Ja Verwaltete, aus GGUF abgeleitete Modelle Bequem, aber Backend-Auswahl und Packaging sind abstrahiert
LM Studio Ja Ja GGUF und produkt-verwaltete Formate Wählbare Runtimes machen Desktop-Tests zugänglich
vLLM Ja Nein Safetensors und unterstützte Quantisierungen AMDs passendes ROCm-Image oder Wheel-Set verwenden; zuerst GPU-Familien-Abdeckung der Kernel prüfen
SGLang Ja Nein Safetensors und unterstützte Quantisierungen ROCm ist Teil der Deployment-Architektur
TGI Ja Nein Safetensors und unterstützte Quantisierungen Die publizierte AMD-Validierung bleibt auf Instinct fokussiert
LocalAI Ja Ja Backend-abhängig, üblicherweise GGUF Verwendet verschiedene ROCm- und Vulkan-Container-Images

ROCm impliziert nicht Safetensors, und Vulkan impliziert formal nicht GGUF. Die nützliche Assoziation kommt von den Engines: llama.cpp kann dasselbe GGUF entweder mit seinem HIP- oder Vulkan-Build lesen, während PyTorch-nativ Server ROCm verwenden und in der Regel Hugging Face-Modell-Repositorien konsumieren.

Das macht das Modell-Inventar zu einer architektonischen Restriktion. Eine Bibliothek sorgfältig ausgewählter GGUF-Quantisierungen weist natürlich auf llama-server, Ollama, LM Studio oder LocalAI hin; ein Deployment, das um Tensor-Parallelität, kontinuierliches Batching und Framework-native Gewichte herum gebaut ist, weist auf ROCm mit vLLM oder SGLang hin. Für die breitere Engine-Landschaft jenseits der AMD-Backends – API-Reifegrad, Tool-Calling und Produktionsbereitschaft über ein Dutzend Werkzeuge hinweg – siehe unseren Vergleich von Ollama, vLLM, LM Studio, LocalAI und anderen lokalen LLM-Hosting-Werkzeugen.

llama.cpp: der klarste ROCm-vs.-Vulkan-Vergleich

llama.cpp stellt beide Backends bereit, ohne die Modeldatei oder den HTTP-Client zu ändern. Dies ist der fairste Ort, um ROCm und Vulkan zu vergleichen, da Tokenizer, Sampling-Einstellungen, Chat-Vorlage, Quantisierung und Serververhalten konstant bleiben können.

Die aktuelle llama.cpp-Build-Dokumentation verwendet GGML_HIP für ROCm und GGML_VULKAN für Vulkan. Ältere Artikel, die GGML_ROCM oder die entfernten Makefile-Flags empfehlen, sollten ohne Überprüfung der aktuellen CMake-Optionen des Projekts nicht vertraut werden.

Vulkan-Backend auf Ubuntu bauen

Installieren Sie die Vulkan-Header, den Shader-Compiler und die SPIR-V-Header, und prüfen Sie dann, dass der Treiber die beabsichtigte GPU auflisten kann:

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

Auf einem System mit gemischter iGPU und diskreter GPU verdient die Auflisterfolge Aufmerksamkeit. GGML_VK_VISIBLE_DEVICES kann llama.cpp auf ein bestimmtes Vulkan-Gerät beschränken, und das Startprotokoll sollte die ausgewählte Karte benennen, anstatt lediglich zu berichten, dass ein Vulkan-Gerät existiert.

ROCm- oder HIP-Backend bauen

Erst bestätigen Sie, dass ROCm die GPU identifiziert und das erwartete gfx-Ziel berichtet. Das Ziel kann weggelassen werden, um für die GPUs im aktuellen System zu bauen, aber die Festlegung (Pinning) reduziert die Kompilierarbeit, wenn die Deployment-Hardware bekannt ist.

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

Ersetzen Sie gfx1201 durch das für die tatsächliche Karte berichtete Ziel – dieser Wert entspricht der RX 9070/9070 XT/9070 GRE- und Radeon AI PRO R9700-Familie in RDNA 4, während gfx1200 die RX 9060-Serie abdeckt und gfx1100/gfx1101/gfx1102 die RDNA-3-Linien RX 7900/7800/7700/7600 abdecken. Kopieren Sie HSA_OVERRIDE_GFX_VERSION nicht einfach in einen Produktionsservice, nur weil es jemandem geholfen hat, eine nicht unterstützte GPU zu starten; ein Override kann den Code laden lassen, macht diese Hardware aber nicht zu einer validierten Plattform.

Dieselbe Arbeitslast benchmarken, nicht zwei Default-Einstellungen

Verwenden Sie eine GGUF-Datei, dieselbe Flash-Attention-Einstellung, dasselbe Layer-Offload und wiederholte Läufe. Prompt-Verarbeitung (pp) und Token-Generierung (tg) beanspruchen das System unterschiedlich, während ein Server mit langem Kontext zusätzlich KV-Cache-Allokation und Speicherdruck hinzufügt, die ein kurzes synthetisches Benchmark verfehlt.

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

Community-Ergebnisse illustrieren, warum ein universeller Gewinner irreführend ist, und das gfx1201-Ziel von RDNA 4 ist das klarste jüngste Beispiel. In einer Einreichung derselben Maschine mit RX 9070 XT erreichte Vulkan etwa 143 Token/s gegenüber 128 Token/s von ROCm im 7B Q4_0-Generationstest, aber spätere Einreichungen zeigten kleinere Lücken, als sich Builds änderten; die Diskussionen zu Vulkan und ROCm enthalten auch große Unterschiede in den Prompt-Verarbeitungs-Ergebnissen und Testbedingungen. Ein separater, detaillierterer Lauf auf OpenBenchmarking.org mit einer RX 9070 XT und llama.cpp b6401 stellte fest, dass Vulkan bei der Decode-Phase mit mehreren 8B-Klasse-Modellen (Qwen3-8B-Q8_0, Llama-3.1-Tulu-3-8B-Q8_0) vorn lag, aber bei der Prompt-Verarbeitung bei längeren Prompt-Längen hinter HIP zurückfiel – die beiden Backends tauschen die Führung, je nach Phase, die gemessen wird.

Die Lücke kann auch in die andere Richtung und um ein Vielfaches laufen, für bestimmte Modellformen. Ein offenes llama.cpp-Issue dokumentiert, dass Vulkan auf gfx1201 bei der Token-Generierung 4,7- bis 6,7-mal langsamer als HIP wurde, sobald die Hidden Size eines Modells 4096 oder mehr erreichte (effektive Decode-Bandbreite, die auf eine 640 GB/s-Karte auf etwa 70-100 GB/s zusammenbrach), während ein kleineres 4B-Modell mit Hidden Size 2560 keine solche Regression auf einem der Backends zeigt. Behandeln Sie jede Zahl hier als einen Schnappschuss eines Builds, eines Treibers und einer Modellform – nicht als eine Regel, die sich über Quant-Typ, Modellarchitektur, Flash-Attention, Batch-Größen, Treiberversion, thermischen Zustand oder den llama.cpp-Commit verallgemeinert.

Ollama auf AMD: bequem, aber Backend prüfen

Ollama unterstützt offiziell gelistete AMD-GPUs über ROCm und dokumentiert jetzt zusätzliche AMD-Abdeckung über Vulkan unter Windows und Linux. Seine aktuelle Hardware-Unterstützungsseite besagt, dass Vulkan standardmäßig aktiviert ist, wenn das Backend installiert ist, GGML_VK_VISIBLE_DEVICES für die Geräteauswahl unterstützt und Vulkan mit OLLAMA_VULKAN=0 deaktiviert werden kann.

Dies ist eine bedeutende Verbesserung gegenüber der Periode, in der Vulkan-Ratschläge von experimentellen Builds abhingen. Es macht auch einige ältere Tutorials überholt: Das Setzen eines nicht dokumentierten Schalter und die Annahme, der Service habe Vulkan ausgewählt, ist ein schwächeres Indiz als das Lesen des Serverprotokolls.

sudo systemctl edit ollama

Für Diagnosen fügen Sie einen Drop-in hinzu, anstatt Variablen nur in einer interaktiven Shell zu exportieren:

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

Dann neu laden, neu starten und sowohl die Prozessaufstellung als auch die Erkennungsmitteilungen inspizieren:

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

ollama run qwen3:8b "Return exactly: backend test passed"
ollama ps

Achten Sie auf die benannte GPU, die ausgewählte Bibliothek, die Modellallokation und den GPU-Prozentsatz. Ein Protokoll, das einen Erkennungs-Timeout gefolgt von einer erfolgreichen HTTP-Antwort zeigt, kann bedeuten, dass Ollama still auf die CPU zurückgefallen ist. Für den alltäglichen Befehlsumfang um diesen Service ist der Ollama-CLI-Spickzettel der schnellere Referenz.

Ollama ist hervorragend, wenn die Modellakquise und eine stabile lokale API wichtiger sind als die Backend-Kontrolle. Wenn reproduzierbare ROCm-gegen-Vulkan-Tests das Ziel sind, ist der reine llama-server das bessere Instrument, da das Build-Verzeichnis das Backend explizit macht.

vLLM und SGLang machen ROCm zur Entscheidung – aber zuerst die GPU-Familien-Abdeckung der Kernel prüfen

vLLM und SGLang sind keine Vulkan-Anwendungen. Ihre AMD-Pfade sitzen auf ROCm, PyTorch und optimierten HIP-Kernels, so dass die Wahl einer dieser Engines bereits die Compute-Plattform ausgewählt hat.

AMDs aktueller vLLM-auf-ROCm-Leitfaden empfiehlt ein vorab gebautes Container-Image und veröffentlicht passende Images für ROCm, PyTorch, Python und vLLM. Diese Kopplung ist nützlich: Sie ersetzt eine große Abhängigkeitslösung durch eine versionierte Deployment-Einheit.

Zum Zeitpunkt des Schreibens dokumentiert AMD dieses ROCm-10-Image für 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

Verwenden Sie das für die exakte GPU-Familie in AMDs Dokumentation ausgewählte Image; RDNA- und CDNA-Images waren nicht immer austauschbar. Für einen Produktionsserver fixieren Sie den vollständigen Tag oder Digest und validieren Sie den Host-Treiber, bevor Sie vLLM für einen Initialisierungsfehler verantwortlich machen.

Brandneue GPU-Generationen sind der schärfste Sonderfall, und RDNA 4 ist ein reales, dokumentiertes Beispiel und kein theoretisches Risiko. Unabhängige Tests auf einer RX 9070 XT (gfx1201) Anfang 2026 stellten fest, dass vLLM auf ROCm 7.2 still auf FP32-Dequantisierung für FP8-Modellgewichte zurückfiel – weil gfx1201 noch nicht in der Plattformerkennung von vLLM erkannt wurde – was die Matrix-Acceleratoren der GPU vollständig umging und nur 48 Token/s produzierte, gegenüber 62 Token/s vom llama-server auf Vulkan, der eine GGUF-Quantisierung eines vergleichbaren Modells auf derselben Karte ausführte. Die Lektion verallgemeinert: Ein ROCm/PyTorch-Stack kann auf einer neuen Architektur erfolgreich geladen werden und dennoch einen nicht optimierten Fallback-Pfad ohne Fehlermeldung ausführen. Bestätigen Sie immer, welchen Kernel-Pfad tatsächlich ausgeführt wurde (via rocprof, Hersteller-Profilierungshinweise oder eine bekannte gute Durchsatz-Grundlinie für die GPU), bevor Sie einem einzelnen „es gestartet sauber“ Ergebnis auf Hardware vertrauen, die innerhalb der letzten ein bis zwei Release-Zyklen ausgeliefert wurde.

Der Grund, ROCms größere operative Oberfläche anzunehmen, einmal die Kernel-Abdeckung bestätigt ist, ist die Durchsatz-Architektur – nicht nur einige wenige zusätzliche Token/s in einem Einzelbenutzer-Test. Kontinuierliches Batching, Framework-native Quantisierung, Tensor-Parallelität, Scheduler-Verhalten und das umgebende PyTorch-Tooling sind der wahre Fall für den Wechsel zu vLLM, und wenn Sie abwägen, ob dieser Wechsel überhaupt gerechtfertigt ist, listet unser Ollama-zu-vLLM-Migrationsleitfaden die Arbeitslast-Signale auf.

TGI: ROCm-Unterstützung mit einem engeren Ziel

Hugging Face dokumentiert ein AMD-Image für Text Generation Inference, aber seine publizierte Validierung ist auf Instinct-MI210-, MI250- und MI300-Hardware zentriert. Der TGI-AMD-Leitfaden verwendet das 3.3.5-rocm-Image und listet nicht unterstützte ROCm-Funktionen auf, so dass es nicht zu einem Versprechen für jede Radeon-Karte verallgemeinert werden sollte. Unser TGI-Installationsleitfaden deckt dieses ROCm-Image-Setup im Detail ab.

Es gibt keinen Vulkan-TGI-Pfad zum Vergleich. Wenn TGI eine feste Anforderung ist, wählen Sie unterstützte ROCm-Hardware und reproduzieren Sie das dokumentierte Container; wenn die Engine verhandelbar ist, verdient die aktuelle vLLM- und SGLang-Unterstützung eine Bewertung, bevor ein neues AMD-Deployment begonnen wird.

LM Studio: Runtimes wechseln, anstatt neu zu bauen

LM Studio packt mehrere Inferenz-Runtimes und stellt das Runtime-Management über den lms-Befehl bereit. Seine Runtime-Dokumentation unterstützt das Auflisten, Herunterladen, Auswählen, Aktualisieren und Entfernen von Runtimes, was ROCm-gegen-Vulkan-Experimente zugänglich macht, ohne separate Quell-Bäume pflegen zu müssen.

lms runtime ls
lms runtime get
lms runtime select

Führen Sie dasselbe GGUF mit derselben Kontextlänge, GPU-Offload, Flash-Attention-Einstellung und Prompt aus. Vergleichen Sie Zeit zum ersten Token, Generierungsraten, Ladezeit und Spitzen-Speicher, anstatt ein Backend von einer kurzen Chat-Antwort zu urteilen.

Runtime-Packaging eliminiert nicht backend-spezifische Fehler. Zum Beispiel berichtete ein LM-Studio-Issue 2026 auf einem R9700 über ein großes Modell, das nahe am Ende eines ROCm-Ladevorgangs hängen blieb, während es vom Vulkan-Runtime geladen wurde, während ein separates Vulkan-Speicher-Schwankungs-Issue das umgekehrte Ergebnis nahe bei vollem VRAM beschrieb. Dies sind individuelle Berichte, aber zusammen machen sie den richtigen operativen Punkt: Halten Sie eine Fallback-Runtime und lassen Sie Speicher-Schwankung.

LocalAI: Wähle das Image sowie das Backend

LocalAI bietet separate ROCm- oder hipblas- und Vulkan-Container-Varianten. Sein GPU-Beschleunigungsleitfaden dokumentiert gpu-hipblas-Images für AMD-Compute und gpu-vulkan-Images für den portablen Pfad, so dass ein von einem CUDA-Leitfaden kopierter Container-Tag das korrekte Backend nicht magisch erkennt. Der LocalAI-Quickstart deckt die allgemeine Einrichtung ab; die backend-spezifische Containerwahl ist das, was dieser Abschnitt hinzufügt.

Der ROCm-Container benötigt /dev/kfd und /dev/dri, während Vulkan normalerweise das geeignete Render-Gerät unter /dev/dri benötigt. Fixieren Sie einen Release-Tag für einen echten Service; latest und master sind nützlich für die Diagnose, machen aber Rollback und Leistungsvergleich unnötig vage.

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

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

Die Tag-Beispiele reflektieren die zum Veröffentlichungszeitpunkt verfügbare Dokumentation; bestätigen Sie die aktuellen Registry-Namen, bevor Sie einen Pull automatisieren. Wichtiger ist es, Beschleunigung nicht nur vom Container-Namen abzuleiten – inspizieren Sie LocalAIs Debug-Log und beobachten Sie die GPU-Auslastung während einer Anfrage.

Was sich im ROCm-10-Packaging geändert hat

ROCm 10 ist nicht nur eine weitere kleinere Paketaktualisierung. AMDs TheRock-Übergangsleitfaden besagt, dass ROCm Core SDK-Pakete jetzt das amdrocm--Präfix verwenden, die versionierte Installationswurzel /opt/rocm/core-10.0 ist und mehrere Legacy-Pakete konsolidiert wurden.

Dies ist der Grund, warum ein Befehl aus einem älteren ROCm-Artikel „Paket nicht gefunden“ zurückgeben kann, selbst auf einem korrekt konfigurierten Repository. Zum Beispiel kommt HIPCC jetzt aus amdrocm-llvm, BLAS-Komponenten sind in amdrocm-blas kombiniert, und eine vollständige Systeminstallation kann ein Meta-Paket des Core SDKs für alle Architekturen oder für eine GPU-Familie-Spezifische verwenden – RDNA-4-Karten verwenden die gfx120X-all-Familien-Tag (Paket-Suffix -gfx1200-gfx1201), was zu wissen ist, bevor man nach einem gfx1201-einzigen Paketnamen sucht, der nicht existiert.

Das amdrocm-Meta-Paket konfiguriert Alternativen und Kompatibilitäts-Symlinks unter /opt/rocm. Eine minimale oder benutzerdefinierte Installation kann die gleichen Pfade nicht bereitstellen, daher sollten Build-Skripte, die /opt/rocm/bin/hipcc hart codieren, entweder hipconfig verwenden oder ROCM_PATH explizit setzen.

Zwei Diagnoseänderungen sind leicht zu übersehen. ROCm SMI wurde zugunsten von AMD SMI entfernt, und ROCm Bandwidth Test erreichte das Ende der Unterstützung; Skripte, die rocm-smi oder rocm-bandwidth-test aufrufen, müssen zu amd-smi und AMDs Ersatzwerkzeugen wechseln, anstatt willkürliche Legacy-Pakete neu zu installieren.

Container hängen immer noch vom Host ab

Ein ROCm-Container trägt User-Space-Bibliotheken, keinen Ersatz-Kernel-Treiber. Der Host muss /dev/kfd und /dev/dri exponieren, sein Treiber muss mit dem Container-Stack kompatibel sein, und der Service-Benutzer benötigt Berechtigung, diese Geräte zu öffnen.

Vulkan-Container haben eine ähnliche Grenze um den Host-Vulkan-Treiber und das Render-Knoten. Das Packaging ist leichter, aber ein falsches ICD, fehlende Render-Gruppen-Mitgliedschaft oder ein versehentlich ausgewählte iGPU kann immer noch ein funktionierendes Container-Image in einen CPU-gebundenen oder instabilen Service verwandeln.

Diskrete GPUs, APUs und ältere Radeon-Karten

RDNA-3- und RDNA-4-diskrete GPUs

Aktuelle Radeon-RX-7000-, RX-9000- und Radeon-AI-Pro-Modelle haben den stärksten Fall für das Testen beider llama.cpp-Backends. ROCm-Unterstützung ist jetzt explizit für viele gfx110x- und gfx120x-Ziele, während Vulkan über einen aktuellen Mesa RADV- oder Windows-Herstellertreiber ausgereift genug ist, um ein primärer Weg und kein verzweilter Fallback zu sein. Für die Hardware-Seite dieser Entscheidung – VRAM, Bandbreite, Leistung und Preise über Hersteller hinweg – siehe unseren GPU-Vergleich für KI-Arbeitslasten im Jahr 2026.

Konvertieren Sie keinen 7B-Benchmark in eine Regel für ein 27B-dichtes Modell oder ein Mixture-of-Experts-Modell. Matrixformen, aktive Parameter, quantisierte Kernel, Prompt-Länge und Speicherdruck können die Reihenfolge ändern, und die Backend-Performance hat sich zwischen llama.cpp-Revisionen wesentlich verändert – die gfx1201-Hidden-Size-Regression oben ist ein konkreter Fall von genau dieser Art von Verschiebung.

Ryzen-APUs und Shared Memory

Ryzen-AI-Max-Systeme mit viel Speicher sind ungewöhnlich interessant, weil die GPU auf einen viel größeren Shared-Memory-Pool zugreifen kann, als eine normale diskrete Consumer-Karte bietet. ROCm 10 listet aktuelle Ryzen-AI-Familien, während Vulkan-fähige llama.cpp-Runtimes auch die iGPU verwenden können, ohne eine PyTorch-Umgebung zu bauen.

Kapazität ist keine Bandbreite. Dass ein Modell in 64 GB oder 96 GB zugewiesenen Shared Memory passt, bedeutet nicht, dass es wie eine 32-GB-diskrete Karte dekodiert, und aggressive Kontext-Allokation kann das Betriebssystem aushungern, selbst wenn eine Anwendung reichlich GPU-Speicher berichtet. Die gleiche VRAM-Budget-Disziplin, die für diskrete NVIDIA- und AMD-Karten gilt, gilt hier auch – siehe KV Cache auf 16-GB-GPUs für die zugrunde liegende Budget-Mathematik, die backend-agnostisch ist.

Maschinen mit gemischter iGPU und dGPU benötigen eine explizite Geräteauswahl. Ein近期的 llama.cpp-Bericht beschrieb excessive System-Speicher-Reservierung, wenn eine ungenutzte iGPU neben einer R9700 sichtbar blieb; es ist ein unbestätigtes Issue, aber es ist ein guter Grund, nur das Gerät zu exponieren, das der Service nutzen soll.

Ältere und nicht unterstützte Radeon-Hardware

Vulkan ist normalerweise der erste Weg für eine ältere Radeon, weil die Grafiktreiber-Abdeckung breiter ist als der unterstützte Compute-Ziel-Satz von ROCm. ROCm-basierte Projekte bemerken auch, dass neuere rocBLAS-Releases Kernel für einige ältere Ziele entfernten, so dass das Erzwingen eines naheliegenden gfx-Werts Code nicht wiederherstellen kann, der nicht mehr ausgeliefert wird.

Ein Override ist für ein Labor-Experiment mit klaren Fehlererwartungen akzeptabel. Es ist eine schlechte Grundlage für eine unbeaufsichtigte API, weil die nächste ROCm- oder Anwendungaktualisierung eine tolerierte Unstimmigkeit durch einen Startfehler oder ein falsches Ergebnis ersetzen kann.

Linux vs. Windows für AMD-LLM-Backends

Linux ist der natürliche ROCm-Host für Produktions-Inferenz. Es bietet die breitesten Engine-Unterstützung, etablierte Container-Geräte-Mapping, aktuelle Mesa-Vulkan-Treiber und die Betriebstools, die vLLM- und SGLang-Deployments erwarten.

Windows hat echte ROCm-Unterstützung für gelistete Hardware, aber das Anwendungssystem bleibt enger. Für Desktop-GGUF-Inferenz über llama.cpp, Ollama oder LM Studio ist Vulkan normalerweise der ruhigere Startpunkt; verwenden Sie ROCm, wenn die Anwendung einen unterstützten Windows-Pfad bietet und eine konkrete Funktion oder Benchmark es rechtfertigt.

WSL2 sollte als dritte Plattform behandelt werden, nicht als Synonym für natives Linux. Passen Sie AMDs dokumentierten Windows-Treiber, die WSL-Distribution, die ROCm-Release und das Framework-Paket als eine unterstützte Kombination an.

Validierungs-Checkliste vor dem Serven von Traffic

Beginnen Sie unter der Anwendung. Wenn der Treiber das korrekte Gerät nicht auflisten kann, ist das Ändern von Modell-Flags nur das Umordnen des Symptoms.

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

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

# Vulkan-Pfad
vulkaninfo --summary

Dann die Engine validieren. Die Startausgabe muss ROCm oder Vulkan benennen, die beabsichtigte GPU benennen und berichten, dass Modell-Layer oder Tensoren darauf platziert wurden; schließlich müssen GPU-Speicher und -Auslastung steigen, während eine Anfrage läuft.

# Beobachte eine AMD-GPU, während ein anderes Terminal Anfragen sendet
watch -n1 amd-smi monitor

# Grundlegender OpenAI-kompatibler API-Check für 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": "Return exactly: ready"}],
    "max_tokens": 8,
    "temperature": 0
  }'

Nehmen Sie mit jedem Benchmark die Treiberversion, die Runtime, das Engine-Commit oder Image-Digest, die Modelldatei-Prüfsumme, den Kontext, die Batch-Einstellungen und die Kommandozeile auf. Ohne diese Metadaten ist eine Token-pro-Sekunde-Zahl eine Anekdote, die die nächste Aktualisierung nicht überleben kann – und wie sowohl der vLLM-auf-gfx1201-Fallback und die Vulkan-Hidden-Size-Regression oben zeigen, kann eine plausible aussehende Zahl einen still nicht optimierten Code-Pfad verbergen.

Fehlermodi, die wie Backend-Leistung aussehen

Stille CPU-Rückführung

Der Server startet und antwortet korrekt, aber die Generierung ist unerwartet langsam und die GPU-Auslastung bleibt flach. Prüfen Sie Erkennungsprotokolle, Geräteberechtigungen, Modell-Offload und Container-Geräte, bevor Sie Threads oder Sampling-Parameter einstellen.

Stille Präzisions-Rückführung (neue Hardware, neue Kernel)

Der Server startet, die GPU-Auslastung sieht vernünftig aus und es gibt keinen Fehler – aber das Framework fiel still auf einen nicht optimierten numerischen Pfad zurück, weil die Compute-Fähigkeit oder der Architektur-String der GPU noch nicht erkannt wurde. Genau das passierte mit vLLMs FP8-Kernels auf gfx1201; die Lösung ist, die Plattform-Erkennungs- oder das Issue-Tracker des Frameworks für Ihre exakte GPU-String zu prüfen, bevor Sie einer einzelnen Durchsatz-Zahl auf einer GPU-Generation vertrauen, die im letzten oder vorletzten Release-Zyklus veröffentlicht wurde.

Die falsche GPU wird ausgewählt

Ein Ryzen-Desktop kann eine iGPU als Vulkan-Gerät 0 und eine diskrete Radeon als Gerät 1 exponieren. Beschränken Sie sichtbare Geräte und bestätigen Sie den vollständigen Gerätenamen im Log; nehmen Sie nicht an, dass die Nummerierung nach einer Treiber- oder BIOS-Änderung stabil ist.

ROCm-Ziel-Unstimmigkeit

rocminfo berichtet ein gfx-Ziel, während das Anwendung-Image Kernel für einen anderen Satz enthält. Verwenden Sie ein passendes Image oder bauen Sie für das exakte Ziel neu; reservieren Sie HSA_OVERRIDE_GFX_VERSION für explizit nicht unterstützte Experimente.

Treiber- und User-Space-Unstimmigkeit

Der Container hat aktuelle ROCm-Bibliotheken, aber der Host-Treiber gehört zu einem älteren Release-Stream. Timeouts während der Erkennung, Kernel-Startfehler oder eine Rückführung auf die CPU sind wahrscheinlicher als eine saubere Meldung, die die Versionsgrenze erklärt.

Vulkan-ICD-Verwirrung

Mehr als eine Vulkan-Implementierung ist installiert, und der Loader wählt ein unerwartetes ICD. Inspeizieren Sie vulkaninfo, entfernen Sie versehentliche Duplikate oder wählen Sie das beabsichtigte ICD und Gerät explizit aus, anstatt ein weiteres SDK über das Problem zu legen.

VRAM-Schätzungen lassen keinen Betriebs-Schwankung

Das Modell scheint zu passen, aber schlägt während des Warmups, der Flash-Attention-Einrichtung oder des ersten langen Prompts fehl. Lassen Sie mehrere Gigabyte Schwankung auf einem großen Modell und reduzieren Sie dann Kontext oder Batch-Größe, bevor Sie zu dem Schluss kommen, dass das Backend die Quantisierung nicht ausführen kann.

Ein praktisches Backend-Auswahlverfahren

Schritt 1: Wähle das Serven-Verhalten

Wenn das Ziel ein oder zwei lokale Benutzer, GGUF-Dateien und ein einfacher OpenAI-kompatibler Endpunkt ist, beginnen Sie mit llama-server, Ollama oder LM Studio. Wenn das Ziel kontinuierliches Batching, hohe Konkurrenz, Framework-native Modelle oder Tensor-Parallelität ist, beginnen Sie mit vLLM oder SGLang und akzeptieren Sie ROCm als Teil des Designs.

Schritt 2: Prüfe die offizielle Hardware-Unterstützung

Passen Sie das exakte GPU-Ziel, die Betriebssystemversion, den Kernel und den Treiber in der aktuellen ROCm-Matrix an. Für Vulkan bestätigen Sie die beabsichtigte GPU über vulkaninfo und verwenden Sie einen aktuellen Treiber, anstatt anzunehmen, dass die Anwesenheit von libvulkan.so nützliche Compute-Unterstützung beweist. Wenn die GPU von der neuesten Architektur-Generation stammt, prüfen Sie auch den Plattform-Erkennungs-Code oder die offenen Issues des spezifischen Frameworks für dieses exakte gfx-Ziel – offizielle Unterstützung und optimierte Kernel-Unterstützung werden nicht immer gemeinsam veröffentlicht.

Schritt 3: Establish the simplest working baseline

Für GGUF ist Vulkan normalerweise diese Grundlinie, weil es weniger Systemkomponenten ändert. Für eine PyTorch-Engine verwenden Sie AMDs fixiertes ROCm-Container-Image, anstatt torch, Triton, AITER und vLLM aus nicht zusammenhängenden letzten Versionen zusammenzustellen.

Schritt 4: Benchmarke produktionsgeformte Prompts

Messen Sie Prompt-Verarbeitung, Zeit zum ersten Token, Decode-Rate, Spitzen-Speicher und das Verhalten bei gleichzeitigen Anfragen. Schließen Sie den Kontext und das Tool-Calling-Muster ein, das der echte Service verwenden wird; ein 128-Token-Mikro-Benchmark sagt nicht über eine 100.000-Token-Agent-Sitzung voraus.

Schritt 5: Halte die Fallback-Deployment-fähig

Zwei llama.cpp-Build-Verzeichnisse kosten wenig im Vergleich zu einem verlorenen Tag durch eine Treiber-Regression. Halten Sie das letzte bekannte gute Container-Digest oder Runtime installiert und rollen Sie nur vor, nachdem der Kandidat denselben Testsatz bestanden hat.

Das gleiche Verfahren als Entscheidungsfluss:

flowchart LR A["Choose serving engine"] --> B{"PyTorch/HIP engine?"} B -- Yes --> C["ROCm: pinned container
+ kernel-coverage check"] B -- No --> D{"GGUF on AMD GPU?"} D -- Yes --> E["Vulkan baseline"] E --> F{"Benchmark: ROCm wins
by a measurable margin?"} F -- Yes --> G["Switch to ROCm"] F -- No --> H["Keep Vulkan,
keep ROCm build as fallback"]

Endgültiges Urteil: ROCm oder Vulkan für AMD-LLM-Hosting?

Vulkan ist die beste Default für lokale GGUF-Inferenz, wenn Portabilität, Einrichtungsgeschwindigkeit, Windows-Unterstützung oder ältere Radeon-Abdeckung wichtig sind. Es ist nicht länger angemessen, sie als inhärent langsam zu beschreiben; bei einigen aktuellen Radeon- und llama.cpp-Kombinationen ist sie das schnellere Backend, und bei anderen ist sie nah genug, dass geringere Reibung im Betrieb gewinnt.

ROCm ist die richtige Wahl, wenn die Engine um PyTorch herum gebaut ist, wenn AMD Instinct und Multi-GPU-Compute zentral sind oder wenn ein getesteter HIP-Build die tatsächliche Modell-Arbeitslast gewinnt. Ökosystem ist 2026 viel stärker, aber das neue Packaging und die strengen Kompatibilitätsschichten belohnen weiterhin fixierte Versionen und disziplinierte Validierung – und auf der neuesten RDNA-Generation speziell ist das Verifizieren, dass der optimierte Kernel-Pfad tatsächlich lief, nicht optional.

Für eine unterstützte Radeon-Workstation ist meine Empfehlung bewusst unromantisch: Installieren Sie Vulkan zuerst, fügen Sie ROCm hinzu, wenn eine Engine oder Benchmark die Komplexität verdient, und behalten Sie beide llama.cpp-Builds, wenn die Maschine regelmäßig verschiedene Modellformen serviert. Das beste AMD-Backend ist keine permanente Eigenschaft der Karte; es ist eine Eigenschaft der Karte, der Engine, des Modells, des Treibers und der Arbeitslast zusammen.

Referenzen

Abonnieren

Neue Beiträge zu Systemen, Infrastruktur und KI-Engineering.