AMD GPU unter Linux für KI-Bildgenerierung – von 20 Stunden auf 12 Minuten

Vorwort

Das hat mich mehrere Stunden gekostet bis ich die richtige Kombination gefunden hatte. Wer mit einer AMD-GPU unter Linux KI-Bildgenerierung betreiben will, steht vor einem Problem das Nvidia-Nutzer nicht kennen: Es gibt keine offizielle, dokumentierte Lösung die einfach funktioniert. Stattdessen muss man die richtige Kombination aus Kernel, Treiber, ROCm und PyTorch selbst herausfinden. Dieser Artikel zeigt was bei mir funktioniert hat – auf einem Lenovo ThinkPad mit AMD Ryzen 7 PRO 5850U und integrierter Radeon Graphics (gfx900/Vega).

Teil 1: Die Hardware zum Laufen bringen

Warum AMD/ROCm schwieriger ist als Nvidia/CUDA

Nvidia hat mit CUDA seit Jahren einen stabilen, gut dokumentierten Stack. AMDs ROCm ist technisch inzwischen gut, aber der Stack ist empfindlicher: Kernel, Treiber, ROCm-Version und PyTorch-Build müssen exakt zusammenpassen. Eine falsche Kombination führt nicht zu einer klaren Fehlermeldung sondern zu kryptischen Abstürzen oder – schlimmer – zu einem Setup das zwar startet aber die GPU gar nicht nutzt und alles auf der CPU berechnet. Der Unterschied: 20 Stunden statt 12 Minuten für ein Bild.

Die funktionierende Kombination

Debian 13 (Trixie)
Kernel 6.12 (6.12.74+deb13+1-amd64)
amdgpu-Treiber von AMD (nicht der Debian-Stock-Treiber)
Python 3.13
PyTorch 2.9.1+rocm6.3

Warum Kernel 6.12 und nicht neuer?

Kernel 6.13+ hat Änderungen am amdgpu-Stack die noch nicht mit dem AMD-Treiber harmonieren – zumindest für die gfx900-Architektur (Vega). Mit Kernel 6.12 und dem AMD-eigenen amdgpu-Treiber läuft alles stabil.

Warum AMD amdgpu-Treiber statt Debian-Stock?

Der Debian-Stock-Treiber ist für allgemeine Nutzung ausgelegt, nicht für ROCm/Compute. AMDs eigener Treiber bringt die richtigen Userspace-Bibliotheken mit die ROCm braucht.

Warum PyTorch 2.9.1+rocm6.3 mit cp313?

AMD supported gfx900 + Python 3.13 offiziell nicht. Aber PyTorch 2.9.1 hat ein cp313-Build im Index das funktioniert – pip holt es automatisch wenn Python 3.13 aktiv ist.

Die zwei unsichtbaren Schlüssel – ohne die nichts läuft

Das ist der Teil der nirgendwo dokumentiert ist. Für gfx900 (Vega) müssen zwei Umgebungsvariablen gesetzt sein, sonst erkennt ROCm die GPU nicht korrekt:

export HSA_OVERRIDE_GFX_VERSION=9.0.0
export ROCR_VISIBLE_DEVICES=0

Am besten dauerhaft in die ~/.bashrc eintragen:

echo 'export HSA_OVERRIDE_GFX_VERSION=9.0.0' >> ~/.bashrc
echo 'export ROCR_VISIBLE_DEVICES=0' >> ~/.bashrc
source ~/.bashrc

HSA_OVERRIDE_GFX_VERSION=9.0.0 teilt ROCm mit dass es sich um eine gfx900-GPU handelt – ohne diese Variable läuft alles auf der CPU. ROCR_VISIBLE_DEVICES=0 stellt sicher dass ROCm explizit die erste GPU nimmt und bei integrierter GPU + CPU nicht durcheinander kommt.

Installation Schritt für Schritt

1. Kernel auf 6.12 halten

sudo apt-mark hold linux-image-6.12.74+deb13+1-amd64

2. AMD amdgpu-Treiber installieren

Den amdgpu-Installer von AMD herunterladen von https://www.amd.com/en/support/linux-drivers:

sudo apt install ./amdgpu-install_*.deb
sudo amdgpu-install --usecase=rocm
sudo usermod -aG render,video $USER

Danach neu einloggen oder rebooten.

3. ROCm installieren

sudo apt install rocm

Verifizieren:

rocminfo | grep "Name:"

Es sollte gfx900 und die GPU-Bezeichnung erscheinen.

4. PyTorch installieren

pip install torch==2.9.1+rocm6.3 torchvision torchaudio \
  --index-url https://download.pytorch.org/whl/rocm6.3 \
  --break-system-packages --force-reinstall

pip holt automatisch das cp313-Build weil Python 3.13 aktiv ist.

Verifikation:

python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

Ausgabe sollte True und den GPU-Namen zeigen. Wenn False erscheint: prüfen ob die .bashrc-Variablen gesetzt sind und ob man in der render-Gruppe ist (groups | grep render).

Teil 2: ComfyUI

Installation

git clone https://github.com/comfyanonymous/ComfyUI
cd ComfyUI
pip install -r requirements.txt --break-system-packages

Starten

python main.py --use-pytorch-cross-attention

Async weight offloading – warum das der Schlüssel ist

ComfyUI meldet beim Start:

Using async weight offloading with 2 streams
Enabled pinned memory

Das bedeutet Modellgewichte werden parallel zum Compute zwischen RAM und VRAM bewegt – während die GPU rechnet lädt ComfyUI bereits den nächsten Block nach. Das ermöglicht Modelle zu nutzen die größer sind als der verfügbare VRAM. Kein manueller Eingriff nötig – das passiert automatisch. ComfyUI nutzt dabei mehrere CPU-Threads parallel – bei reiner CPU-Last bis zu 800%, bei GPU-Betrieb immer noch 200% – was das Offloading deutlich beschleunigt.

Z-Image/Lumina2 – 12 Minuten für ein Bild

Das Modell in den models/checkpoints/-Ordner legen, in ComfyUI laden:

Requested to load ZImageTEModel_
loaded completely;  7672.25 MB loaded, full load: True
Requested to load Lumina2
loaded partially; 7712.00 MB loaded, 4027.54 MB offloaded
Prompt executed in 00:12:05

Der Transformer wird partiell geladen – 4 GB werden in den RAM ausgelagert während die GPU rechnet. Das ist der entscheidende Unterschied zu InvokeAI.

Teil 3: InvokeAI

Warum die bessere UI aber mehr Aufwand

InvokeAIs Oberfläche ist komfortabler als ComfyUIs Node-Graph für schnelles Arbeiten. Alles an einem Ort, kein Gefummel mit Nodes. Außerdem zeigt InvokeAI während der Generierung eine Live-Vorschau – man sieht wie das Bild Schritt für Schritt entsteht und kann früh abbrechen wenn die Richtung nicht stimmt. Aber InvokeAI bringt sein eigenes Python-venv mit (3.12) und das PyTorch darin ist nicht auf die eigene ROCm-Konfiguration abgestimmt. Zudem nutzt InvokeAI nur einen CPU-Thread – was bei reiner CPU-Nutzung den Unterschied zwischen 30 Minuten und 20 Stunden erklärt.

Das OOM-Problem und warum es ein Bug ist

InvokeAI lädt den Qwen3-4B Text Encoder (7.67 GB) zweimal in den VRAM – ein bekannter Bug (Issue #7513). Mit 16 GB VRAM reicht das nicht für den Rest des Modells:

HIP out of memory. Tried to allocate 20.00 MiB.
GPU 0 has a total capacity of 15.09 GiB of which 19.50 MiB is free.

PyTorch im InvokeAI-venv aktualisieren

InvokeAI kommt mit PyTorch 2.7.1, das für unser Setup nicht optimal ist. Aktualisieren auf 2.9.1:

./launcher-1.8.1/assets/bin/uv pip install torch==2.9.1 torchvision==0.24.1 torchaudio==2.9.1 \
  --index-url https://download.pytorch.org/whl/rocm6.3 \
  --python ~/Invoke/.venv/bin/python

Die yaml-Konfiguration

InvokeAI hat einen Low-VRAM-Modus der standardmäßig deaktiviert ist. In ~/Invoke/invokeai.yaml eintragen:

enable_partial_loading: true
lazy_offload: true
device_working_mem_gb: 8.0
keep_ram_copy_of_weights: true
max_cache_ram_gb: 20.0
max_cache_vram_gb: 12.0
pytorch_cuda_alloc_conf: "expandable_segments:True"

Mit diesen Einstellungen und 32 GB RAM läuft InvokeAI durch ohne OOM-Fehler. Zusätzlich empfiehlt es sich den amdgpu-Treiber auf automatisches GPU-Recovery zu konfigurieren – bei einem GPU-Hang unter Last erholt sich das System dann automatisch ohne harten Reset:

echo 'options amdgpu lockup_timeout=10000 gpu_recovery=1' | sudo tee /etc/modprobe.d/amdgpu.conf

Ergebnis und Vergleich

Testprompt: „Mehrere Kinder, die Fußball spielen auf einem Fußballplatz. Einem Bolzplatz in einer Großstadtumgebung wie München.“ – gleiches Modell (z_image_turbo_bf16.safetensors), gleiche Parameter, gleiche Hardware.

	CPU	GPU ComfyUI	GPU InvokeAI
Zeit	~20 Stunden	12 Minuten	66 Minuten
Faktor	~100x langsamer	Basis	~5,5x langsamer
CPU-Threads	1	8+	1
Offloading	–	async, 2 streams	partiell, lazy
Bildqualität	–	fotorealistisch	stark vereinfacht

Das Qualitätsergebnis ist eindeutig: ComfyUI liefert in 12 Minuten ein fotorealistisches Bild mit echten Kindern, Trikots und städtischem Hintergrund. InvokeAI produziert nach 66 Minuten eine stark vereinfachte Darstellung – grüner Rasen, schwarzer Himmel, Strichmännchen. Gleiche Modelldatei, gleicher Prompt, dramatisch unterschiedliches Ergebnis.

Das Ergebnis mit ComfyUI schaut so aus:

Und das war das was mir InvokeAI mit gleichem Textprompt ausgegeben hat:

InvokeAI kann mit Z-Image auf gfx900/Vega 1024×1024 nicht stabil zu Ende generieren – der VAE-Decode crasht reproduzierbar. ComfyUI macht das problemlos. InvokeAI macht eine Vorschau und schafft auch in 44 Minuten ein fotorealistisches Bild um dann sich bei VAE-Decode mit einem GPU-Hang in das Nirvana zu verabschieden, dass das System neugestartet werden muss. Ausserdem macht InvokeAI kein Multithreading und nützt nur eine CPU statt 8 wie ComfyUI. Die letzte invokeai.yaml sah dann so aus

# Internal metadata – do not edit:
schema_version: 4.0.2

# Put user settings here – see https://invoke-ai.github.io/InvokeAI/configuration/:

enable_partial_loading: true
lazy_offload: true
device_working_mem_gb: 8.0
keep_ram_copy_of_weights: true
max_cache_ram_gb: 28.0
max_cache_vram_gb: 7.0
pytorch_cuda_alloc_conf: „expandable_segments:True“
force_tiled_decode: true
attention_type: sliced
attention_slice_size: 1

half alles nichts.

Die Ursache liegt in der Implementierung: InvokeAI hat mit Z-Image/Lumina2 noch grundlegende Probleme jenseits des OOM-Bugs. Der Bug #7513 ist bekannt und wird gefixt werden – bis dahin ist ComfyUI für dieses Modell die deutlich bessere Wahl.

Fazit

Wer auf AMD/ROCm unter Linux KI-Bildgenerierung betreiben will, kommt ans Ziel – aber der Weg dorthin erfordert die richtige Kombination aus Kernel, Treiber und PyTorch-Build. Die zwei Umgebungsvariablen HSA_OVERRIDE_GFX_VERSION und ROCR_VISIBLE_DEVICES sind dabei der unsichtbare Schlüssel den niemand dokumentiert hat.

Ist die Basis einmal stabil, läuft ComfyUI ausgezeichnet – schnell, stabil, fotorealistische Ergebnisse in 12 Minuten. InvokeAI hat die bessere Benutzeroberfläche und eine praktische Generierungsvorschau, kämpft aber noch mit der Z-Image-Implementierung. Mit dem Fix für Issue #7513 und verbessertem Multithreading könnte InvokeAI deutlich aufholen – momentan ist ComfyUI für dieses Modell auf AMD/Linux die klare Empfehlung.