GPU-passthrough op Proxmox voor lokale modelservers

Het virtualiseren van AI-infrastructuur op Proxmox Virtual Environment (VE) vormt tegenwoordig een stabiele basis voor wie flexibiliteit zoekt zonder aan brute rekenkracht in te boeten. Wanneer we inferentieservers zoals vLLM, Ollama, Aphrodite of TGI willen inzetten op consumenten- of enterprise-hardware, willen we niet vastzitten aan één bare-metal installatie. Door middel van PCIe GPU-passthrough via VFIO (Virtual Function I/O) wijzen we een fysieke grafische kaart direct en exclusief toe aan een virtuele machine (VM). Hierdoor behoudt de gast-VM directe toegang tot de CUDA-cores, Tensor-cores en de volledige videogeheugenbandbreedte (VRAM), met een verwaarloosbare virtualisatie-overhead van minder dan één procent ten opzichte van bare-metal inferentie.

In dit artikel analyseren we de technische architectuur achter GPU-passthrough op Proxmox VE 8.x, lopen we de configuratiestappen langs de IOMMU-grenzen en kernel-modules door, en onderzoeken we hoe we een veerkrachtige modelserver opzetten. We kijken hierbij kritisch naar prestatieverliezen, hardwarematige valkuilen en architectuuroverwegingen rondom geheugenbeheer en netwerkdoorvoer.

Architectuur: Bare-metal vs. Virtuele Machine met VFIO

Bij het uitvoeren van grote taalmodellen (LLM's) is de geheugenbandbreedte tussen de GPU-chip en het onboard VRAM de primaire limiterende factor voor de generatiesnelheid (tokens per seconde). Het hosten van modellen op bare-metal Linux biedt de eenvoudigste configuratie, maar introduceert aanzienlijke operationele nadelen: snapshots zijn lastig te realiseren, hardware-allocaties zijn rigide en het gelijktijdig isoleren van netwerken en storage vereist complexe containerconfiguraties. Een vergelijking met bredere homelab-infrastructuren zagen we al terug in de homelab en self-hosted AI signalen, waarin de balans tussen isolatie en compute-dichtheid centraal stond.

Met Proxmox en VFIO-passthrough fungeert de hypervisor puur als arbiter van fysieke PCIe-registers en geheugenpagina's via de IOMMU (Input-Output Memory Management Unit). De host-kernel laadt de driver vfio-pci in plaats van de officiële nvidia of amdgpu drivers. Zodra de VM start, claimt de QEMU/KVM-hypervisor de PCI-geheugenruimte via Direct Memory Access (DMA), waardoor de gast-VM de GPU aanstuurt alsof deze direct op het virtuele moederbord is geprikt. Zolang DMA remapping correct is ingeschakeld, worden alle PCIe-transacties hardwarematig afgehandeld zonder tussenkomst van CPU-contextswitches.

Hardwarevereisten en IOMMU-groepering

Een succesvolle passthrough-configuratie valt of staat met de fysieke PCIe-topologie en het moederbordontwerp. De CPU en het moederbord moeten respectievelijk Intel VT-d of AMD-Vi ondersteunen. Daarnaast is de kwaliteit van de IOMMU-groepering doorslaggevend: de IOMMU groepeert apparaten op basis van elektrische circuits en PCIe-switches. Een GPU kan uitsluitend veilig worden doorgegeven aan een VM als deze zich in een geïsoleerde IOMMU-groep bevindt, of als alle andere apparaten binnen diezelfde groep (zoals de bijbehorende HDMI-audiocontroller of USB-C controllers) gelijktijdig aan dezelfde VM worden toegekend.

Op consumentenmoederborden (zoals B650 of Z790 chipsets) deelt het secundaire PCIe x16-slot (dat elektrisch vaak x4 draait) dikwijls een IOMMU-groep met SATA-controllers, netwerkpoorten of M.2 NVMe-sleuven. Pogingen om een GPU uit zo'n gemengde groep door te geven resulteren zonder uitzondering in kernel panics op de host of foutmeldingen tijdens het booten van de VM. Enterprise- en HEDT-platforms (zoals AMD EPYC, Threadripper of Intel Xeon) bieden over het algemeen strikt gescheiden IOMMU-groepen voor elk individueel PCIe-slot dankzij dedicated PCIe-lanes direct vanaf de CPU-package.

Hostconfiguratie: Kernel-parameters en VFIO-modules

Om Proxmox VE gereed te maken voor passthrough, moeten we specifieke bootflags meegeven aan de Linux-kernel en voorkomen dat de host-drivers het videosignaal opeisen. Afhankelijk van het opstartsysteem (GRUB of systemd-boot) passen we de kernel-commandoregel aan. Voor een gedetailleerd overzicht van de initiële opstartvlaggen en configuratiebestanden verwijzen we naar de handleiding over GPU passthrough configureren in Proxmox VE voor LLM's, waarin de basisparameters stap voor stap zijn gedocumenteerd.

In het configuratiebestand /etc/default/grub of /etc/kernel/cmdline voegen we voor AMD-systemen amd_iommu=on iommu=pt toe, of intel_iommu=on iommu=pt voor Intel-systemen. De parameter iommu=pt (passthrough mode) zorgt ervoor dat de hypervisor alleen IOMMU-vertalingen uitvoert voor apparaten die daadwerkelijk aan gasten worden toegewezen, wat de I/O-prestaties van overige hostapparaten optimaliseert.

Vervolgens configureren we de benodigde kernel-modules in /etc/modules zodat deze tijdens de vroege bootfase worden ingeladen:

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

Om te voorkomen dat de Proxmox-host de GPU initialiseert met de standaard open-source drivers, plaatsen we deze drivers op de zwarte lijst in /etc/modprobe.d/pve-blacklist.conf:

blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist radeon
blacklist amdgpu

Vervolgens binden we de specifieke PCI Vendor- en Device-ID's aan vfio-pci. We achterhalen deze ID's via het commando lspci -nn | grep -E "VGA|Audio". Het resultaat plaatsen we in /etc/modprobe.d/vfio.conf:

options vfio-pci ids=10de:2684,10de:22ba disable_vga=1

Na het bijwerken van het initiële RAM-schijfbestand via update-initramfs -u -k all en een herstart van de host, controleert het commando dmesg | grep -i vfio of het stuurprogramma de videokaart succesvol claimt.

VM-configuratie: QEMU Machine Type, UEFI en PCIe-vlaggen

Binnen de Proxmox webinterface of via het CLI-hulpprogramma qm richten we een virtuele machine in met specifieke hardware-eigenschappen die aansluiten op enterprise AI-workloads. Een verkeerde configuratie van het virtuele BIOS of machine type kan leiden tot foutcodes zoals de beruchte Code 43 in drivers of initialisatiefouten in de CUDA runtime.

De VM moet worden geconfigureerd met het machine type q35 en BIOS OVMF (UEFI). Het moderne q35-chipsetmodel simuleert een native PCIe-busarchitectuur, wat essentieel is voor geavanceerde functionaliteiten zoals PCIe Extended Configuration Space en Resizable BAR. De processor configureren we bij voorkeur als host om alle instructiesets (AVX2, AVX-512, BMI2) direct door te geven naar de gast.

In het configuratiebestand van de virtuele machine (bijvoorbeeld /etc/pve/qemu-server/100.conf) declareren we het PCI-apparaat expliciet:

bios: ovmf
machine: q35
cpu: host
numa: 1
memory: 32768
balloon: 0
hostpci0: 0000:01:00,pcie=1,x-vga=0

Twee instellingen zijn hierbij cruciaal voor AI-servers:
1. balloon: 0: Geheugenballonvaart moet absoluut worden uitgeschakeld. VFIO vereist dat het volledige toegewezen RAM-geheugen van de VM direct en ononderbroken in het fysieke hostgeheugen wordt vergrendeld (pinned) om DMA-corruptie te voorkomen.
2. pcie=1: Hiermee wordt het apparaat aangesloten op een virtuele PCIe-rootport in plaats van een verouderde legacy PCI-bus, wat noodzakelijk is voor maximale PCIe-doorvoersnelheden.

Resizable BAR (ReBAR) en HugePages voor LLM-workloads

Bij het laden van modellen met 70 miljard parameters of meer verplaatst de modelserver tientallen gigabytes aan gewichten (weights) van het systeem-RAM en NVMe-opslag rechtstreeks naar het videogeheugen. Traditionele PCIe-toegang werkt met een venster van slechts 256 MB (het Base Address Register). Resizable BAR (op AMD-platforms bekend als Smart Access Memory) stelt de CPU in staat om het volledige VRAM-geheugen in één aaneengesloten adresruimte te benaderen.

Voor maximale doorvoersnelheid binnen Proxmox moet ReBAR zowel in het UEFI-moederbord-BIOS van de host zijn ingeschakeld (Above 4G Decoding en ReBAR Support) als correct worden geïnitialiseerd binnen de QEMU-configuratie. Zonder ReBAR verloopt de initiële laadtijd van modelbestanden (via mmap of safetensors) merkbaar trager en kunnen er micro-stotteringen optreden tijdens context-swapping bij multi-user batching.

Daarnaast is het gebruik van HugePages op de Proxmox-host en in de VM een beproefde methode om de Translation Lookaside Buffer (TLB) overhead te minimaliseren. Door gebruik te maken van 1 GB of 2 MB HugePages in plaats van de standaard 4 KB geheugenpagina's, vermindert de CPU-belasting tijdens intensieve KV-cache manipulaties drastisch. Dit optimalisatiepatroon sluit aan bij de trends die we eerder analyseerden rondom lokale LLM's en Ollama signaalanalyse, waarbij geheugenlatentie de voornaamste bottleneck vormt.

# Reserveren van 32GB aan 2MB HugePages op de host
echo 16384 > /proc/sys/vm/nr_hugepages
# Toevoegen aan VM-configuratie (/etc/pve/qemu-server/100.conf)
hugepages: 2

Modelserver Deployment: vLLM, Aphrodite en Ollama in een VM

Zodra de VM start met Ubuntu 24.04 LTS of Debian 12 en de officiële Nvidia Data Center of CUDA drivers zijn geïnstalleerd, valideren we de functionaliteit met nvidia-smi. Vanaf dit punt kunnen we de inferentiestack uitrollen. De keuze voor de modelserver hangt af van de beoogde use case:

Voor productie-omgevingen met meerdere gelijktijdige aanroepen biedt vLLM superieure prestaties dankzij PagedAttention, dynamische continuous batching en geoptimaliseerde CUDA-kernels. We starten een vLLM-container via Docker binnen de VM met volledige GPU-ondersteuning:

docker run --gpus all \
  -v /root/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  --ipc=host \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-7B-Instruct \
  --gpu-memory-utilization 0.95 \
  --max-model-len 8192

Voor lichte en lokale ontwikkelscenario's blijft Ollama populair vanwege het eenvoudige modelbeheer. Voor wie geavanceerde container-isolatie en sandboxing wil doorvoeren op het niveau van modelservers en agent-executies, biedt het overzicht over sandboxing van LLM-tools en Docker isolatie een gedetailleerde blik op het inrichten van veilige containergrenzen binnen gevirtualiseerde omgevingen.

Wanneer we deze lokale modellen vervolgens integreren in bredere applicatienetwerken, kunnen we ze ontsluiten via een centrale gateway. Zie hiervoor de architectuurgids over lokale modellen achter je eigen API zelf hosten en hybride routeren voor methoden om interne modelservers naadloos te combineren met publieke cloud-fallbacks.

Metingen: PCIe-bandbreedte, Token Latency en Multi-Tenant Stress

Om te verifiëren of de virtuele passthrough daadwerkelijk de maximale hardwareprestaties benadert, voeren we gerichte benchmarks uit op twee vlakken: PCIe-geheugendoorvoer en daadwerkelijke token-generatie.

Via het Nvidia CUDA-voorbeeldprogramma bandwidthTest meten we de Host-to-Device (H2D) en Device-to-Host (D2H) snelheden over de virtuele PCIe-bus. Op een fysiek PCIe 4.0 x16-slot moet de doorvoersnelheid consistent boven de 25 GB/s liggen. Een daling naar ~6-7 GB/s duidt erop dat het slot elektrisch is teruggeschakeld naar PCIe 3.0 of x4-modus, wat vooral de initiële modelinlaadtijd en prompt-evaluatie (Time To First Token) negatief beïnvloedt.

De meetresultaten tonen aan dat het pure generatieproces (waarbij weights puur in VRAM circuleren) vrijwel identiek presteert tussen bare-metal en Proxmox VFIO. De minimale afwijking in Time To First Token (TTFT) ontstaat door IOMMU-adresvertaling tijdens het inladen van de initiële prompt-tokens in het videogeheugen, maar dit verschil is in de praktijk verwaarloosbaar.

Valkuilen, Probleemanalyse en Beperkingen

Hoewel GPU-passthrough op Proxmox een volwassen technologie is, kent het systeem specifieke operationele risico's en beperkingen die vooraf moeten worden meegewogen:

1. Geen Proxmox Live Migration
Omdat de fysieke PCIe-hardware direct is gekoppeld aan de hardwareregisters van de specifieke host, is het niet mogelijk om een draaiende VM live te migreren naar een andere Proxmox-node in een cluster. Een migratie vereist altijd dat de VM volledig wordt uitgeschakeld, waarna de configuratie op de doelhost over identieke hardware en PCIe-mappings moet beschikken.

2. PCIe Reset Bugs en FLR (Function Level Reset)
Sommige consumentenvideokaarten (met name bepaalde AMD Radeon RX-series en oudere Nvidia GTX-kaarten) ondersteunen Function Level Reset niet correct. Wanneer de virtuele machine herstart, kan de GPU in een ongedefinieerde stroomtoestand (D3-state) blijven hangen. Dit vereist een volledige herstart van de fysieke Proxmox-host om de GPU weer functioneel te krijgen. Enterprise-kaarten (zoals de Nvidia A100, L4, L40S of RTX 6000 Ada) hebben robuuste FLR-ondersteuning en hebben hier geen last van.

3. VRAM-fragmentatie en Host OOM
Omdat VFIO vereist dat het gastgeheugen wordt vergrendeld, mag de Proxmox-host nooit overgecommit worden qua RAM. Als ZFS-geheugencaching (ARC) of andere containers op de host onverwacht geheugendruk veroorzaken, kan de Linux Out-Of-Memory (OOM) killer willekeurige processen beëindigen, inclusief het QEMU-proces dat de GPU aanstuurt, wat leidt tot acute VM-crashes.

Conclusie en Best Practices

GPU-passthrough op Proxmox VE biedt de ideale balans tussen enterprise-beheersbaarheid en bare-metal AI-prestaties. Door de hypervisor correct in te richten met geïsoleerde IOMMU-groepen, q35-chipsets, HugePages en Resizable BAR, bouwen we een veerkrachtige modelserver die nauwelijks onderdoet voor een dedicated bare-metal installatie. Voor wie schaalbare, lokale AI-workloads beheert binnen een gevirtualiseerde infrastructuur, vormt deze setup een toekomstvaste standaard.