Proxmox GPU Passthrough mit Nvidia: Kompletter Guide 2026 (IOMMU, vGPU, KI-Workloads)

Wer eine leistungsfähige GPU im Homelab betreibt, will sie selten nur einem einzelnen Betriebssystem widmen. Ein Proxmox-Host kann mehrere virtuelle Maschinen parallel versorgen, während die Beschleunigerkarte mal einem Windows-Gast für Spiele oder CAD, mal einer Linux-VM für KI-Inferenz oder Video-Transcoding zugewiesen wird. Mit PCI Passthrough wird die gesamte physische GPU an eine VM durchgereicht — als wäre sie direkt eingebaut. Und mit NVIDIA vGPU lässt sich eine einzelne Karte sogar auf mehrere VMs aufteilen.

Die Umsetzung ist kein Einzeiler. IOMMU-Gruppen, VFIO-Treiber, Kernel-Parameter und GPU-spezifische Eigenheiten verlangen einen systematischen Durchlauf. Dieser Guide dokumentiert den vollständigen Weg unter Proxmox VE 9.x mit aktuellem Stand Juli 2026 — von den BIOS-Einstellungen über die vGPU-Konfiguration bis zum produktiven KI-Workload.

Kurzantwort

Detaillierte Anleitung für Nvidia-GPU-Passthrough unter Proxmox VE 9.x: IOMMU aktivieren, VFIO-Konfiguration, vGPU mit SR-IOV sowie Einsatz für KI-Workloads und lokales LLM-Hosting. Kurz gesagt: Proxmox GPU Passthrough ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

IOMMU: Die hardwarenahe Grundlage

Bevor auch nur der erste Befehl im Terminal läuft, muss die Hardware mitspielen. IOMMU — Input-Output Memory Management Unit — ist die technische Voraussetzung dafür, dass eine VM direkt auf PCIe-Hardware zugreifen darf, ohne dass der Host dazwischenfunkt. Intel nennt das VT-d, AMD spricht von AMD-Vi. Beide Varianten leisten dasselbe: Sie weisen PCIe-Geräten eigene Speicherbereiche zu und verhindern, dass eine VM auf den Speicher einer anderen VM oder des Hosts zugreift.

Im BIOS oder UEFI des Systems müssen folgende Einstellungen aktiv sein: VT-d bzw. AMD-Vi (oft auch schlicht „IOMMU" genannt), SR-IOV (für vGPU ab Ampere-Generation), Above-4G-Decoding und ARI — Alternative Routing ID Interpretation — ebenfalls für neuere GPU-Architekturen.

Ein älteres Mainboard oder ein Consumer-Chipsatz sind nicht zwangsläufig ein Ausschlusskriterium. Die Hardwareunterstützung ist bei den meisten CPUs seit Intels Haswell-Generation (2013) respektive AMDs Bulldozer-Serie gegeben. Aber die Qualität der IOMMU-Gruppierung — also die Frage, welche Geräte im selben isolierten Verbund stecken — unterscheidet sich je nach Board und BIOS-Version teils erheblich. Wer auf Nummer sicher gehen will, greift zu Server- oder Workstation-Hardware mit geprüfter IOMMU-Konformität.

Proxmox-Vorbereitung: Bootloader, Kernel, Module

Nach dem BIOS-Check folgt die Konfiguration des Proxmox-Hosts. Für Intel-Systeme kann es nötig sein, IOMMU explizit im Kernel zu aktivieren. Der Eintrag in /etc/default/grub lautet:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

Der Parameter iommu=pt aktiviert den IOMMU-Passthrough-Modus. VMs umgehen damit die DMA-Translation des Hypervisors und sprechen direkt mit der Hardware-IOMMU — ein messbarer Performancegewinn, besonders bei datenintensiven GPU-Workloads.

Nach der Änderung wird GRUB aktualisiert und das System neu gestartet:

update-grub
reboot

Nach dem Neustart folgt die Erfolgskontrolle. Der Befehl dmesg | grep -e DMAR -e IOMMU -e AMD-Vi muss eine Bestätigung wie „DMAR: IOMMU enabled" oder „AMD-Vi: Interrupt remapping enabled" zeigen. Fehlt die Ausgabe, stimmt etwas im BIOS oder in den Kernel-Parametern nicht.

Als nächstes werden die VFIO-Kernelmodule geladen. Sie sorgen dafür, dass die GPU aus dem Zugriff des Host-Kernels herausgelöst und für die exklusive Nutzung durch VMs freigegeben wird. In /etc/modules kommen folgende Einträge:

vfio
vfio_iommu_type1
vfio_pci

Ein update-initramfs -u -k all und ein weiterer Reboot schließen diesen Schritt ab. Mit lsmod | grep vfio lässt sich prüfen, ob die Module tatsächlich aktiv sind.

Proxmox GPU Passthrough – Illustration 2

GPU-Isolation: Treiber-Blacklisting und VFIO-Bindung

Damit der Host die GPU beim Booten nicht selbst beansprucht, müssen die Open-Source-Treiber blockiert werden. Für Nvidia-Karten sind das nouveau und alle nvidia*-Module. In /etc/modprobe.d/blacklist.conf:

blacklist nouveau
blacklist nvidia
blacklist nvidia_drm
blacklist nvidia_modeset

Zusätzlich muss die GPU an den vfio-pci-Treiber gebunden werden, noch bevor ein anderer Treiber zugreift. Dafür werden die PCI-IDs der GPU und ihrer Audio-Funktion ermittelt:

lspci -nn | grep -i nvidia

Beispielausgabe: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3080] [10de:2206] (rev a1). Die Werte 10de:2206 sind Vendor-ID und Device-ID. Zusammen mit der HDMI-Audio-Funktion (10de:1aef) landen sie in /etc/modprobe.d/vfio.conf:

options vfio-pci ids=10de:2206,10de:1aef

Nach einem weiteren Reboot bestätigt lspci -nnk, dass der Kernel-Treiber für die GPU auf vfio-pci gesetzt ist. Erst dann kann die VM-Erstellung beginnen.

IOMMU-Gruppen und der ACS-Override

Ein häufiges Problem: Die gewünschte GPU teilt sich eine IOMMU-Gruppe mit anderen Geräten — etwa einem USB-Controller oder einer zweiten PCIe-Karte. Passthrough erfordert aber, dass alle Geräte einer Gruppe gemeinsam an dieselbe VM durchgereicht werden. Mit pvesh get /nodes/{nodename}/hardware/pci --pci-class-blacklist "" lässt sich die Gruppenaufteilung der gesamten Hardware inspizieren.

Sind die Gruppen ungünstig durchmischt, hilft manchmal der physische Wechsel des PCIe-Steckplatzes. Wenn das nicht reicht, greift der ACS-Override-Patch, der im Proxmox-Kernel bereits enthalten ist. In der GRUB-Konfiguration wird pcie_acs_override=downstream ergänzt. Die Maßnahme ist wirksam, jedoch mit einem Warnhinweis versehen: Der Patch hebelt die hardwaremäßige Isolation aus, was theoretisch das Risiko birgt, dass eine VM per DMA auf fremde Speicherbereiche zugreifen kann. Für ein abgeschottetes Homelab mit vertrauenswürdigen eigenen VMs ist das in der Praxis akzeptabel; in Produktivumgebungen sollte stattdessen auf sauber isolierte Hardware gesetzt werden.

Nvidia-spezifische Fallstricke: Error 43 und ROM-Dumping

Nvidia treibt seit Jahren ein Katz-und-Maus-Spiel mit Virtualisierern. Unter Windows löst der Treiber den berüchtigten Fehlercode 43 aus, wenn er erkennt, dass er in einer VM läuft. Die gute Nachricht: Seit Treiberversion 465 hat Nvidia den VM-Check für GeForce-Karten offiziell deaktiviert. Wer einen aktuellen Treiber einsetzt, sollte diesen Fehler nicht mehr sehen.

Trotzdem gibt es weitere Hürden. GPUs mit viel VRAM — 24 GB und mehr — können an einem BAR-Adressraumproblem scheitern. OVMF, die UEFI-Firmware für KVM-VMs, reserviert standardmäßig nur 32 GB für den 64-bit-PCI-MMIO-Bereich. Moderne Karten mit 24 GB oder 48 GB VRAM brauchen mehr. Die Lösung mit host-CPU-Typ:

qm set VMID --cpu host

Alternativ kann das MMIO-Fenster manuell vergrößert werden:

qm set VMID --args '-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536'

Der Wert 65536 steht für ein 64-GB-Fenster; für besonders große Karten kann der Wert auf 131072 (128 GB) oder 262144 (256 GB) erhöht werden.

Ein weiterer Stolperstein: Manche Mainboards beschatten das vBIOS der GPU im ersten PCIe-Slot, sodass der Passthrough fehlschlägt. Abhilfe schafft das Auslesen und Bereitstellen des GPU-BIOS als Datei. Dazu wird das ROM unter /sys/bus/pci/devices/0000:01:00.0/ ausgelesen und unter /usr/share/kvm/vbios.bin abgelegt. In der VM-Konfiguration erscheint es als hostpci0: 01:00,x-vga=on,romfile=vbios.bin.

vGPU mit SR-IOV: Eine GPU für mehrere VMs

Richtig interessant wird es, wenn eine GPU nicht nur einer, sondern mehreren VMs gleichzeitig dienen soll. Nvidia nennt das vGPU und setzt dafür auf SR-IOV — Single Root I/O Virtualization. Die Technik stellt auf der Hardwareebene mehrere virtuelle Funktionen (Virtual Functions) bereit, die sich wie eigenständige GPUs verhalten und unabhängig voneinander an VMs durchgereicht werden können.

Seit Proxmox VE 9.2.2 sind die aktuellen NVIDIA vGPU Software-Versionen 20.1 mit Treiber 595.71.03 offiziell getestet und unterstützt. Die Kompatibilitätstabelle der Proxmox-Dokumentation zeigt: Proxmox VE 9.2.2 mit Kernel 7.0.2-6-pve läuft sowohl mit vGPU-Branch 19.5 als auch mit 20.1.

Die Einrichtung erfolgt mit dem pve-nvidia-vgpu-helper, der seit pve-manager 8.3.4 Teil der Proxmox-Installation ist. Der Helfer richtet DKMS ein, installiert Header-Pakete und blacklistet den nouveau-Treiber:

pve-nvidia-vgpu-helper setup

Nach erfolgreichem Setup wird der von Nvidia bezogene Host-Treiber installiert — auf der Nvidia-Downloadseite muss dabei „Linux KVM" als Hypervisor gewählt werden:

chmod +x NVIDIA-Linux-x86_64-595.71.03-vgpu-kvm.run
./NVIDIA-Linux-x86_64-595.71.03-vgpu-kvm.run --dkms

Für GPUs ab der Ampere-Architektur ist ein weiterer Schritt nötig: SR-IOV muss aktiviert werden. Der pve-nvidia-vgpu-helper stellt dafür einen systemd-Service bereit:

systemctl enable --now pve-nvidia-sriov@ALL.service

Nach dem nächsten Reboot zeigt lspci -d 10de: eine Liste von virtuellen Funktionen. Aus einer RTX A5000 werden typischerweise 24 virtuelle Instanzen, jede mit eigener PCI-Adresse, von 01:00.4 bis 01:03.3.

Für die neueste Generation — namentlich die RTX PRO 6000 Blackwell Server Edition — unterstützt Proxmox zusätzlich Multi-Instance GPU (MIG). Dabei wird die GPU hardwaremäßig in Partitionen zerlegt, die jeweils eigene SM-Einheiten, Speicher und Encoder besitzen. vGPUs werden dann innerhalb dieser MIG-Instanzen erzeugt, was höhere Dichte und bessere Isolation zwischen Workloads ermöglicht. Ein nvidia-smi -i 0 -mig 1 aktiviert den MIG-Modus; anschließend lassen sich mit nvidia-smi mig -lgip die verfügbaren Profile auflisten.

Die Lizenzierung bleibt aber ein Punkt: NVIDIA vGPU erfordert eine gültige Lizenz. NVIDIA AI Enterprise ist ein alternatives Produkt mit ähnlichem Treiberverhalten, aber eigener Lizenzstruktur — und derzeit nicht offiziell von Proxmox VE unterstützt.

KI-Workloads: Vom Passthrough zum eigenen LLM-Host

Warum der ganze Aufwand? Die naheliegendste Antwort 2026 lautet: KI-Inferenz im eigenen Rechenzentrum. Wer ein lokales Large Language Model hostet, braucht GPU-Leistung ohne Umwege. Drei Szenarien machen GPU-Passthrough im Homelab besonders attraktiv.

Erstens: Eine Linux-VM als dedizierter KI-Host. Mit durchgereichter Nvidia-GPU laufen Ollama, vLLM oder llama.cpp direkt auf dem Bare-Metal-nahen Treiber — CUDA-Beschleunigung inklusive. Die GPU wird nicht virtualisiert, sondern exklusiv genutzt, was maximale Inferenz-Performance bedeutet. Eine RTX 3090 mit 24 GB VRAM liefert mit llama.cpp unter Q4_K_M-Quantisierung Antwortlatenzen von unter 50 Millisekunden für 7B-Modelle und verarbeitet rund 80 Token pro Sekunde.

Zweitens: vGPU für geteilte KI-Entwicklungsumgebungen. Mehrere Entwickler erhalten einen eigenen GPU-Anteil derselben Karte — die eine VM trainiert Embeddings, die andere betreibt eine RAG-Pipeline. Der vGPU-Ansatz spart Hardwarekosten und vereinfacht die Verwaltung, wenn nicht jedes Modell die volle Kartenleistung braucht.

Drittens: Transcoding und KI parallel. Dasselbe System, das nachts Stapelverarbeitung für KI-Modelle fährt, kann tagsüber als Plex- oder Jellyfin-Server mit NVDEC/NVENC-Hardwarebeschleunigung arbeiten. Im Passthrough-Modus sind die Nvidia-NVDEC-Sessions nicht durch virtuelle Treiber begrenzt.

Entscheidend ist in allen Fällen die Wahl des vGPU-Profils. Die Nvidia-Treiber unterscheiden zwischen Q-Series (Quadro/vWS, für Workstation-Visualisierung) und C-Series (Compute, für reine Rechenlasten). Für KI-Workloads ohne grafische Ausgabe wählt man ein C-Profil; die Profile reichen von 1 GB bis 48 GB VRAM, gestaffelt in definierten Größen.

Performance-Tuning für GPU-nahe Workloads

Der Passthrough allein garantiert noch keine optimale Performance. Einige Tuning-Maßnahmen lohnen sich besonders bei KI- und Compute-Lasten.

CPU-Pinning verhindert, dass der Host-Scheduler vCPUs der VM beliebig zwischen physischen Kernen hin- und herschiebt. Die VM-Konfiguration bindet virtuelle Kerne fest an physische:

qm set VMID --cpu host --numa 1 --cores 8

Hugepages reduzieren den Translation-Lookaside-Buffer-Overhead der VM. 1-GB-Hugepages sind dafür am besten geeignet, erfordern aber reservierten Speicher beim Boot:

GRUB_CMDLINE_LINUX_DEFAULT="... default_hugepagesz=1G hugepagesz=1G hugepages=16"

Die Kombination aus festem CPU-Pinning und großen Speicherseiten kann den Durchsatz von GPU-gebundenen Inferenz-Workloads um zehn bis fünfzehn Prozent steigern — messbar vor allem bei großen Batch-Größen und lang laufenden Pipeline-Stages.

Bei vGPU-Installationen hilft ein Blick auf den SR-IOV-Durchsatz. Der PCIe-Switch im Host-System verteilt die Bandbreite auf die virtuellen Funktionen. Stecken mehrere GPUs am selben PCIe-Root-Port, können sie sich die verfügbare Bandbreite teilen. Für Workloads mit hohem PCIe-Transferaufkommen — etwa beim Laden großer Modelle in den VRAM — sollte jede GPU an einem dedizierten Root-Port mit voller x16-Anbindung sitzen.

Troubleshooting: Die häufigsten Fehlerbilder

Die Proxmox-Dokumentation und die Community-Foren listen eine Reihe wiederkehrender Probleme auf. Hier die häufigsten mit ihren Lösungen:

BAR 3: can’t reserve [mem] — Der Host-Kernel belegt den Speicherbereich der GPU. Abhilfe: video=efifb:off zum Kernel-Kommando hinzufügen, falls der Bootvorgang das EFI-Framebuffer nutzt.

QEMU/KVM: Failed to assign device — IOMMU-Interrupt-Remapping fehlt oder ist deaktiviert. Prüfung mit dmesg | grep 'remapping'. Ohne Hardware-Support hilft zur Not allow_unsafe_interrupts=1 in /etc/modprobe.d/iommu_unsafe_interrupts.conf — die Option ist jedoch mit einem Stabilitätsrisiko verbunden.

Code 43 im Windows-Gast — Trotz aktuellem Nvidia-Treiber kann der Fehler auftreten, wenn Resizable BAR im Host-BIOS aktiviert ist. Resizable BAR funktioniert in VMs derzeit nicht zuverlässig und sollte deaktiviert werden, bis die KVM-Entwicklung das vollständig unterstützt.

vGPU-Profile erscheinen nicht — Bei Ampere-GPUs und neuer muss SR-IOV vor der Profilerstellung aktiviert sein. Ohne die aktivierten virtuellen Funktionen zeigt mdevctl types keine verfügbaren vGPU-Typen an.

Audio-Crackling über HDMI — Die GPU-Audiofunktion profitiert von MSI (Message Signaled Interrupts). Im Linux-Gast erledigt das echo "options snd-hda-intel enable_msi=1" >> /etc/modprobe.d/snd-hda-intel.conf. Unter Windows kann MSI über den Geräte-Manager oder Registry-Einträge aktiviert werden.

Grenzen und Alternativen

GPU-Passthrough ist nicht für jede Hardware und jedes Szenario die optimale Lösung. AMD-GPUs der Navi-Generation (RX 5xxx/6xxx) leiden unter dem AMD-Reset-Bug, bei dem die Karte nach einem VM-Neustart nicht korrekt zurückgesetzt wird und die VM im nächsten Startlauf eine nicht funktionsfähige GPU vorfindet. Die Community-Patches um vendor-reset mildern das Problem, garantieren aber keine Stabilität. In solchen Fällen ist ein reiner Compute-Workload mit PCI-Passthrough ohne Display-Ausgabe oft zuverlässiger.

Consumer-GPUs wie die GeForce-RTX-Serie unterstützen SR-IOV und vGPU von Haus aus nicht — Nvidia reserviert diese Features für professionelle Karten wie die RTX A-Serie oder die RTX PRO-Reihe. Wer mit einer GeForce-Karte mehrere VMs mit GPU-Leistung versorgen will, bleibt auf klassischen 1:1-Passthrough oder auf die experimentellen vGPU-Unlock-Patches aus der Community angewiesen. Letztere sind ein ständiges Wettrennen gegen Treiber-Updates und brechen häufig mit neuen Kernel-Versionen — kein Weg für produktive Umgebungen, aber ein spannendes Experimentierfeld fürs Homelab.

Entscheidungshilfe: Wann ist das sinnvoll?

Eher sinnvoll, wenn du Proxmox GPU Passthrough nicht nur als Nachricht lesen willst, sondern eine praktische Einordnung brauchst: Was ändert sich, wen betrifft es und welche nächsten Schritte sind realistisch?

Eher abwarten, wenn die Quellenlage noch dünn ist, wichtige technische Details fehlen oder der Nutzen nur aus Hersteller- oder Projektversprechen besteht. Dann ist Beobachten besser als vorschnelles Umstellen.

Worauf du achten solltest: konkrete Verfügbarkeit, nachvollziehbare Kosten, offene Einschränkungen, Sicherheits- oder Datenschutzfolgen und belastbare Quellen statt bloßer Ankündigungen.

FAQ

Kann ich die GPU gleichzeitig im Host und in einer VM nutzen? Nein. Passthrough bedeutet exklusive Zuweisung. Sobald eine GPU an vfio-pci gebunden ist, hat der Host keinen Zugriff mehr. Die Alternative für geteilte Nutzung ist vGPU mit SR-IOV-fähiger Hardware.

Brauche ich für Proxmox-GPU-Passthrough zwingend eine zweite GPU? Nicht zwingend, aber es vereinfacht die Einrichtung erheblich. Mit einer GPU für den Host (etwa die integrierte Grafikeinheit der CPU) und einer dedizierten GPU für Passthrough vermeidet man Probleme mit dem Konsolenzugriff und EFI-Framebuffer-Belegung.

Welche Nvidia-Karten unterstützen vGPU? Die offizielle Liste findet sich im NVIDIA Virtual GPU Qualified System Catalog. Faustregel: Professionelle Karten ab der Quadro-RTX-/RTX-A-Serie, alle RTX-PRO-Modelle und ausgewählte Tesla-/Data-Center-Produkte. Consumer-GeForce-Karten sind nicht offiziell unterstützt.

Warum zeigen meine VMs nach dem Passthrough kein Bild? Das ist normal: NoVNC und SPICE können das GPU-Framebuffer nicht anzeigen. Die VM-Ausgabe erscheint ausschließlich an einem physisch angeschlossenen Monitor oder über eine Remote-Desktop-Lösung (RDP, VNC, Parsec) im Gast.

Ist der ACS-Override-Patch sicher? Der Patch hebelt hardwaremäßige Isolationsgarantien aus. In einem kontrollierten Homelab mit vertrauenswürdigen eigenen VMs ist das Risiko überschaubar. Für Mandantenumgebungen oder Hosting-Szenarien sollte auf Hardware mit sauberer IOMMU-Trennung gesetzt werden.

Kann ich mehrere verschiedene vGPU-Profile auf derselben Karte mischen? Ja, solange die Summe der zugewiesenen Ressourcen die Kapazität der physischen GPU nicht übersteigt. Die mdevctl-Verwaltung in Proxmox erlaubt beliebige Kombinationen.

Wie sieht es mit Sicherheitsupdates aus? vGPU-Treiber werden von Nvidia regelmäßig aktualisiert, sowohl für Sicherheitslücken als auch für neue GPU-Generationen. Über DKMS werden sie bei Kernel-Updates automatisch neu gebaut.

Lohnt sich der Aufwand für KI-Workloads? Für ernsthaftes lokales LLM-Hosting: ja. Die Alternative ist eine dedizierte Bare-Metal-Maschine nur für die GPU. Mit Proxmox plus Passthrough bekommt man nahezu die gleiche Performance bei flexiblerer Ressourcenverwaltung.

Zusammenfassung

Proxmox GPU Passthrough ist 2026 kein experimentelles Bastelprojekt mehr, sondern ein ausgereifter, gut dokumentierter Weg, physische GPU-Leistung in virtualisierten Umgebungen nutzbar zu machen. Die offizielle Unterstützung für NVIDIA vGPU ab Software-Version 18 macht Proxmox VE zu einer ernstzunehmenden Plattform auch für professionelle GPU-Workloads.

Der Aufwand konzentriert sich auf die initiale Einrichtung: BIOS-Prüfung, IOMMU-Aktivierung, Treiber-Blacklisting und VFIO-Konfiguration. Danach funktioniert der klassische 1:1-Passthrough mit GeForce- und Profi-Karten gleichermaßen. Wer mehr will — mehrere VMs pro GPU, KI-Entwicklungsumgebungen, MIG-Partitionierung — investiert in SR-IOV-fähige Hardware und die vGPU-Lizenzierung.

Die Kombination aus Proxmox-Virtualisierung und direkt durchgereichter GPU-Leistung schließt die Lücke zwischen Cloud-KI-Diensten und dedizierten Bare-Metal-Servern. Für Homelab-Betreiber, die ihre eigene KI-Infrastruktur betreiben wollen, ist das der pragmatische Mittelweg.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Quellen

Proxmox GPU Passthrough – Illustration 3