Zum Hauptinhalt springen
  1. Posts/

AMD RX 7900 XTX Passthrough in Proxmox VE 9 für ROCm und Ollama

Autor
Detlev Lengsfeld
Seit Jahrzehnten im Unix-Subsystem zu Hause. Entwickler, Systemadministrator und Liebhaber puristischer Terminal-Workflows.

Die meisten GPU-Passthrough-Guides im Netz behandeln NVIDIA. Das ist verständlich — CUDA ist verbreiteter, NVIDIA-Treiber sind länger stabil und die Foren sind voll mit Anleitungen. Aber AMD ist 2026 angekommen: ROCm 6.x läuft auf Consumer-Karten produktiv, die RX 7900 XTX bringt 24 GB VRAM für den halben Preis einer RTX 4090, und der Open-Source-Stack lässt sich sauber in eine Debian-VM unter Proxmox stecken.

Dieser Artikel dokumentiert exakt das Setup, das auf meinem Homelab läuft: eine RX 7900 XTX wird via VFIO an eine Debian-13-VM durchgereicht, ROCm 6.x bedient Ollama, und die Modelle liegen auf einem btrfs-Subvolume das per virtfs/9p in die VM hineingereicht wird. Kein ZFS, kein Cloud-Inferenz, kein NVIDIA-Lock-in.

Warum AMD statt NVIDIA?
#

Drei Gründe, die zusammen genug Gewicht haben:

  1. VRAM pro Euro. Eine RX 7900 XTX kostet aktuell rund die Hälfte einer RTX 4090 bei identischen 24 GB VRAM. Für lokales LLM-Hosting ist VRAM die harte Grenze — Modellgröße × Quantisierung muss reinpassen, sonst geht’s nicht.
  2. Reifegrad von ROCm. Seit ROCm 6.0 (Anfang 2024) ist die RDNA3-Architektur offiziell unterstützt, seit 6.2 läuft rocm-smi, PyTorch-Builds und llama.cpp ohne Workarounds. Ollama unterstützt AMD nativ via HSA_OVERRIDE_GFX_VERSION.
  3. Open-Source-Stack. Der amdgpu-Kernel-Treiber ist Mainline, kein Out-of-Tree-Geraffel. Bei NVIDIA brauchst du proprietäre Treiber, die bei Kernel-Updates regelmäßig Brüche produzieren.

Nachteil: Die Community ist kleiner. Wenn was bricht, findest du seltener fertige Antworten. Dieser Artikel ist mein Beitrag dazu.

Hardware-Setup
#

KomponenteModell
MainboardASRock B650M Pro RS
CPUAMD Ryzen 9 7900 (12C/24T, Zen 4)
RAM32 GB DDR5-5200
GPUAMD Radeon RX 7900 XTX (24 GB GDDR6)
NVMe1 TB (Proxmox Host + System)
SATA5× HDD btrfs RAID für Bulk-Storage
Host-OSProxmox VE 9.x (Debian 13 Trixie base)
Storagebtrfs (kein ZFS)
Guest-VMDebian 13 Trixie, KVM/QEMU

Wichtig für Passthrough: das B650M Pro RS hat separate IOMMU-Groups für GPU und Onboard-Audio, was die Sache erheblich vereinfacht. Bei manchen B650-Boards muss man mit ACS-Override-Patches im Kernel arbeiten — hier nicht nötig.

BIOS-Vorbereitung
#

Drei Settings im UEFI scharf schalten. Pfade können beim ASRock je nach BIOS-Version leicht variieren:

SettingWertPfad (ASRock B650M)
SVM Mode (AMD-V)EnabledAdvanced → CPU Configuration
IOMMUEnabledAdvanced → AMD CBS → NBIO → IOMMU
Above 4G DecodingEnabledAdvanced → PCIe Configuration
Re-Size BAR SupportEnabledAdvanced → PCIe Configuration
Primary DisplayIGD / OnboardAdvanced → Onboard Devices

Letzteres ist der entscheidende Trick: Wenn der Ryzen 9 7900 die iGPU für den Host-Console-Output bekommt, kann die RX 7900 XTX vollständig dem Guest gehören — kein “Host hängt am GPU-Bildschirm”-Konflikt.

Proxmox-Host: Kernel & VFIO
#

IOMMU im Kernel aktivieren
#

Proxmox VE 9 nutzt systemd-boot oder grub je nach Installationsart. Bei UEFI/systemd-boot:

# Boot-Cmdline editieren
nano /etc/kernel/cmdline

Folgende Parameter anhängen:

amd_iommu=on iommu=pt

Bei GRUB stattdessen /etc/default/grub, Zeile GRUB_CMDLINE_LINUX_DEFAULT. Danach jeweils:

# systemd-boot
proxmox-boot-tool refresh

# oder GRUB
update-grub

Reboot, dann Verifikation:

dmesg | grep -i -e iommu -e amd-vi | head

Erwarteter Output enthält AMD-Vi: AMD IOMMUv2 functionality not available on this system (das ist okay, IOMMUv1 reicht) und mehrere AMD-Vi: Found IOMMU Zeilen.

IOMMU-Groups inspizieren
#

for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/*}; n=${n%%/*}
  printf 'IOMMU Group %s ' "$n"
  lspci -nns "${d##*/}"
done | sort -V

Du suchst zwei Zeilen mit demselben Group-Identifier — die GPU und ihr HDMI-Audio-Device. Beispiel-Output (deine Werte werden abweichen):

# TODO: hier deinen echten lspci-Output einfügen, sieht etwa so aus:
IOMMU Group 14 0c:00.0 VGA compatible controller [0300]: AMD Radeon RX 7900 XTX [Navi 31] [1002:744c]
IOMMU Group 14 0c:00.1 Audio device [0403]: AMD Navi 31 HDMI Audio [1002:ab30]

Die beiden Vendor:Device-IDs (1002:744c und 1002:ab30) sind die, die du gleich an VFIO bindest.

VFIO-Module laden
#

cat >> /etc/modules <<'EOF'
vfio
vfio_iommu_type1
vfio_pci
EOF

GPU vom amdgpu-Treiber abklemmen
#

# vfio-pci an die GPU binden (eigene IDs einsetzen)
cat > /etc/modprobe.d/vfio.conf <<'EOF'
options vfio-pci ids=1002:744c,1002:ab30 disable_vga=1
EOF

# amdgpu blacklisten — er soll die Karte nicht greifen
cat > /etc/modprobe.d/blacklist-amdgpu.conf <<'EOF'
blacklist amdgpu
blacklist radeon
EOF

# initramfs neu bauen
update-initramfs -u -k all

Reboot. Danach:

lspci -nnk -d 1002:744c

Erwartet: Kernel driver in use: vfio-pci. Wenn da amdgpu steht, hat das Blacklisting nicht gegriffen — meist ein Tippfehler in den IDs oder die initramfs wurde nicht neu gebaut.

VM erstellen
#

Ich nutze die Proxmox-CLI weil sie reproduzierbar ist. Über die GUI geht es auch, aber dann kein Copy-Paste in einen Artikel.

qm create 200 \
  --name ai-debian \
  --memory 24576 \
  --cores 8 \
  --cpu host,hidden=1,flags=+pcid \
  --machine q35 \
  --bios ovmf \
  --efidisk0 local-btrfs:1,format=raw,efitype=4m,pre-enrolled-keys=1 \
  --scsihw virtio-scsi-single \
  --scsi0 local-btrfs:64,format=raw,discard=on,ssd=1 \
  --net0 virtio,bridge=vmbr0 \
  --ostype l26

Ein paar Punkte, die hier nicht offensichtlich sind:

  • cpu host,hidden=1: Versteckt vor dem Guest dass er virtualisiert ist. Bei AMD-Passthrough seltener nötig als bei NVIDIA (deren Treiber prüfen aktiv darauf), aber schadet nicht.
  • machine q35: Modernes Chipset-Modell, Pflicht für PCIe-Passthrough.
  • bios ovmf: UEFI-Boot, Voraussetzung für Re-Size BAR.

GPU + Audio-Device an die VM hängen
#

qm set 200 -hostpci0 0c:00,pcie=1,x-vga=1

x-vga=1 markiert die Karte als Primary-GPU für den Guest. pcie=1 ist Pflicht damit Re-Size BAR funktioniert.

Hier setzt du die PCI-Adresse ein (z.B. 0c:00), nicht die Vendor-ID. Beide Funktionen .0 (GPU) und .1 (Audio) werden mit der Punkt-losen Schreibweise automatisch zusammen durchgereicht.

Debian 13 im Guest
#

Installation wie üblich via ISO. Beim Login als root:

apt update && apt upgrade -y
apt install -y curl wget gnupg lsb-release software-properties-common

ROCm 6.x installieren
#

AMDs offizielles Repo:

# AMD-GPG-Key
mkdir -p /etc/apt/keyrings
wget -qO - https://repo.radeon.com/rocm/rocm.gpg.key \
  | gpg --dearmor > /etc/apt/keyrings/rocm.gpg

# ROCm-Repository
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com/rocm/apt/6.2.4 jammy main" \
  > /etc/apt/sources.list.d/rocm.list

# Trixie nutzt jammy-Repo — AMD pflegt offiziell Ubuntu, nicht Debian.
# Funktioniert problemlos da Pakete statisch genug sind.
apt update
apt install -y rocm-hip-libraries rocm-smi rocminfo

Validation
#

# GPU sichtbar?
rocm-smi

Erwarteter Output sollte die RX 7900 XTX mit Temperatur, Speicher-Usage und Power-Draw zeigen. Wenn rocm-smi mit Locale not supported aussteigt:

# locale-fix — bekannt, aber selten dokumentiert
echo 'export LC_ALL=C' >> /etc/profile.d/rocm.sh
echo 'export LANG=C'   >> /etc/profile.d/rocm.sh
source /etc/profile.d/rocm.sh

Wenn rocminfo ausgibt Agent 2 — Name: gfx1100, hast du gewonnen. gfx1100 ist der ISA-Identifier für Navi 31.

Ollama installieren und auf AMD scharf schalten
#

curl -fsSL https://ollama.com/install.sh | sh

# AMD-Override für RDNA3, falls Ollama die Karte nicht direkt erkennt
mkdir -p /etc/systemd/system/ollama.service.d
cat > /etc/systemd/system/ollama.service.d/override.conf <<'EOF'
[Service]
Environment="HSA_OVERRIDE_GFX_VERSION=11.0.0"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
EOF

systemctl daemon-reload
systemctl restart ollama

OLLAMA_MAX_LOADED_MODELS=1 ist wichtig wenn du mit großen Modellen arbeitest — sonst versucht Ollama parallel zu laden und du läufst gegen die 24 GB.

Erster Modell-Test
#

ollama pull qwen3-coder:30b
ollama run qwen3-coder:30b "schreibe eine bash-funktion die IOMMU-groups als JSON ausgibt"

Während das Modell läuft, parallel rocm-smi in einem zweiten SSH-Tab:

watch -n 1 'rocm-smi --showmeminfo vram --showtemp --showuse'

VRAM-Usage sollte auf ~18 GB hochgehen (qwen3-coder:30b in Q4_K_M Quantisierung), GPU-Usage Spitzen bis 100 %, Temperatur bei mir typisch 68–75 °C unter Last.

Stolpersteine, die mich Zeit gekostet haben
#

Reset-Bug nach VM-Stop
#

Beim ersten Versuch kam die RX 7900 XTX nach VM-Shutdown nicht sauber zurück — der nächste VM-Start hing beim Bootloader. Lösung: bei aktuellem amdgpu-Kernel (>=6.6) nicht mehr nötig. Bei älteren Kernel-Versionen war vendor-reset als DKMS-Modul der übliche Fix, aber für RDNA3 nicht mehr aktiv gepflegt. Falls dich der Bug erwischt: VM nie hart killen, immer per qm shutdown 200 herunterfahren.

Re-Size BAR aktivieren wirklich
#

Im BIOS aktiviert ≠ im Guest aktiv. Verifikation in der VM:

lspci -vv -s 01:00.0 | grep -i 'BAR.*[0-9]G'

Erwartet: mindestens ein BAR mit Size=16G oder größer. Wenn nur 256M-BARs auftauchen, hängt’s am pcie=1-Flag in der qm set-Zeile oder am OVMF-BIOS der VM.

Locale-Fix für rocm-smi
#

War oben schon — taucht aber so häufig auf, dass es eine eigene Erwähnung verdient. Ohne LC_ALL=C produziert rocm-smi auf manchen Locales kryptische Python-Stacktraces.

Performance, ein Reality-Check
#

ModellQuantisierungVRAMTokens/s (RX 7900 XTX)
qwen3-coder:30bQ4_K_M~18 GB~45
qwen3.5:27bQ4_K_M~16 GB~52
deepseek-r1:14bQ4_K_M~9 GB~88
devstral-small-2Q4_K_M~14 GB~62

Zum Vergleich: vergleichbare Modelle auf einer M2-Max (38-Core GPU) liegen bei ~30–40 Tokens/s. Die RX 7900 XTX ist also keine Krücke — sie ist konkurrenzfähig, bei weniger als der Hälfte des Preises der Apple-Lösung und ohne Vendor-Lock-in.

Wie es weitergeht
#

Damit ist die Hardware-Basis fertig. Worauf das aufbaut:

  • btrfs-Subvolume für Modell-Storage via virtfs/9p — wie ich ~1.6 TB Model-Cache zwischen Host und VM teile, ohne das Disk-Image aufzublähen.
  • Der ai-debian Compose-Stack — Ollama, AnythingLLM, Qdrant, SearXNG und Open-WebUI als zusammenhängendes lokales LLM-Backend.
  • GPU-Monitoring mit Push-Notificationsrocm-smi regelmäßig samplen, Schwellwerte via ntfy auf macOS.

Diese drei Artikel kommen als nächstes. Bis dahin: wenn du Fragen hast oder bei einem Schritt hängst, schick mir gerne eine Mail an info@macdet.de.


Stand: Mai 2026. Getestet auf Proxmox VE 9.0.6, ROCm 6.2.4, amdgpu Kernel 6.8, Ollama 0.3.x.