GPU Passthrough on Proxmox for Local Model Servers

Virtualizing AI infrastructure on Proxmox Virtual Environment (VE) currently provides a solid foundation for those seeking flexibility without sacrificing raw compute power. When deploying inference servers like vLLM, Ollama, Aphrodite, or TGI on consumer or enterprise hardware, you don't want to be locked into a single bare-metal setup. Using PCIe GPU passthrough via VFIO (Virtual Function I/O), a physical graphics card is directly and exclusively assigned to a virtual machine (VM). This gives the guest VM direct access to the CUDA cores, Tensor cores, and full video memory (VRAM) bandwidth, with a negligible virtualization overhead of less than one percent compared to bare-metal inference.

In this article, we analyze the technical architecture behind GPU passthrough on Proxmox VE 8.x, walk through the configuration steps across IOMMU boundaries and kernel modules, and explore how to set up a resilient model server. We take a critical look at performance penalties, hardware pitfalls, and architectural considerations around memory management and network throughput.

Architecture: Bare-metal vs. Virtual Machine with VFIO

When running large language models (LLMs), memory bandwidth between the GPU die and the onboard VRAM is the primary bottleneck for generation speed (tokens per second). Hosting models on bare-metal Linux offers the simplest setup, but introduces significant operational drawbacks: snapshots are difficult to take, hardware allocations are rigid, and isolating networks and storage simultaneously demands complex container configurations. We already saw a comparison with broader homelab infrastructures in the homelab and self-hosted AI signals, where the balance between isolation and compute density was central.

With Proxmox and VFIO passthrough, the hypervisor acts purely as an arbiter of physical PCIe registers and memory pages via the IOMMU (Input-Output Memory Management Unit). The host kernel loads the driver vfio-pci instead of the official nvidia or amdgpu drivers. Once the VM boots, the QEMU/KVM hypervisor claims the PCI memory space via Direct Memory Access (DMA), allowing the guest VM to control the GPU as if it were plugged directly into the virtual motherboard. As long as DMA remapping is correctly enabled, all PCIe transactions are handled in hardware without requiring CPU context switches.

Hardware Requirements and IOMMU Grouping

A successful passthrough configuration hinges entirely on the physical PCIe topology and motherboard design. The CPU and motherboard must support Intel VT-d or AMD-Vi, respectively. In addition, the quality of the IOMMU grouping is decisive: the IOMMU groups devices based on electrical circuits and PCIe switches. A GPU can only be safely passed through to a VM if it resides in an isolated IOMMU group, or if all other devices within that same group (such as the associated HDMI audio controller or USB-C controllers) are assigned to the same VM simultaneously.

On consumer motherboards (such as B650 or Z790 chipsets), the secondary PCIe x16 slot (which electrically often runs at x4) frequently shares an IOMMU group with SATA controllers, network ports, or M.2 NVMe slots. Attempts to pass through a GPU from such a mixed group invariably result in host kernel panics or boot errors within the VM. Enterprise and HEDT platforms (such as AMD EPYC, Threadripper, or Intel Xeon) generally offer strictly separated IOMMU groups for each individual PCIe slot thanks to dedicated PCIe lanes wired directly from the CPU package.

Host Configuration: Kernel Parameters and VFIO Modules

To prepare Proxmox VE for passthrough, we need to pass specific boot flags to the Linux kernel and prevent the host drivers from claiming the video signal. Depending on the bootloader (GRUB or systemd-boot), we adjust the kernel command line. For a detailed overview of the initial boot flags and configuration files, refer to the guide on Configuring GPU Passthrough in Proxmox VE for LLMs, where the baseline parameters are documented step by step.

In the configuration file /etc/default/grub or /etc/kernel/cmdline , we add amd_iommu=on iommu=pt for AMD systems, or intel_iommu=on iommu=pt for Intel systems. The parameter iommu=pt (passthrough mode) ensures that the hypervisor only performs IOMMU translations for devices actually assigned to guests, optimizing I/O performance for remaining host devices.

Next, we configure the necessary kernel modules in /etc/modules so that they load during early boot:

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

To prevent the Proxmox host from initializing the GPU with default open-source drivers, we blacklist these drivers in /etc/modprobe.d/pve-blacklist.conf:

blacklist nouveau
blacklist nvidia
blacklist nvidiafb
blacklist radeon
blacklist amdgpu

Next, we bind the specific PCI Vendor and Device IDs to vfio-pci. We retrieve these IDs using the command lspci -nn | grep -E "VGA|Audio". We place the output in /etc/modprobe.d/vfio.conf:

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

After updating the initial RAM disk image via update-initramfs -u -k all and a reboot of the host, the command checks dmesg | grep -i vfio whether the driver successfully claims the graphics card.

VM Configuration: QEMU Machine Type, UEFI, and PCIe Flags

Within the Proxmox web interface or via the CLI utility qm we set up a virtual machine with specific hardware attributes tailored to enterprise AI workloads. Misconfiguring the virtual BIOS or machine type can lead to error codes such as the infamous Code 43 in drivers or initialization errors in the CUDA runtime.

The VM must be configured with the machine type q35 and BIOS OVMF (UEFI). The modern q35 chipset model simulates a native PCIe bus architecture, which is essential for advanced features such as PCIe Extended Configuration Space and Resizable BAR. We preferably configure the processor as host to pass all instruction sets (AVX2, AVX-512, BMI2) directly through to the guest.

In the virtual machine's configuration file (for example /etc/pve/qemu-server/100.conf) we explicitly declare the PCI device:

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

Two settings here are crucial for AI servers:
1. balloon: 0: Memory ballooning must be completely disabled. VFIO requires the VM's entire allocated RAM to be directly and continuously pinned in physical host memory to prevent DMA corruption.
2. pcie=1: This connects the device to a virtual PCIe root port instead of an outdated legacy PCI bus, which is necessary for maximum PCIe throughput.

Resizable BAR (ReBAR) and HugePages for LLM Workloads

When loading models with 70 billion parameters or more, the model server transfers dozens of gigabytes of weights from system RAM and NVMe storage directly into video memory. Traditional PCIe access operates with a window of only 256 MB (the Base Address Register). Resizable BAR (known as Smart Access Memory on AMD platforms) enables the CPU to access the entire VRAM address space in a single contiguous block.

For maximum throughput within Proxmox, ReBAR must be enabled in both the host's UEFI motherboard BIOS (Above 4G Decoding and ReBAR Support) and correctly initialized within the QEMU configuration. Without ReBAR, the initial load time of model files (via mmap or safetensors) is noticeably slower, and micro-stuttering may occur during context-swapping under multi-user batching.

In addition, using HugePages on the Proxmox host and inside the VM is a proven method for minimizing Translation Lookaside Buffer (TLB) overhead. By utilizing 1 GB or 2 MB HugePages instead of the standard 4 KB memory pages, CPU load during intensive KV-cache manipulations is drastically reduced. This optimization pattern aligns with the trends we previously analyzed regarding local LLMs and Ollama signal analysis, where memory latency represents the primary bottleneck.

# 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

Model Server Deployment: vLLM, Aphrodite, and Ollama in a VM

Once the VM boots with Ubuntu 24.04 LTS or Debian 12 and the official Nvidia Data Center or CUDA drivers are installed, we validate functionality with nvidia-smi. From this point on, we can deploy the inference stack. The choice of model server depends on the intended use case:

For production environments with multiple concurrent requests, vLLM offers superior performance thanks to PagedAttention, dynamic continuous batching, and optimized CUDA kernels. We launch a vLLM container via Docker inside the VM with full GPU support:

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

For lightweight and local development scenarios, Ollama remains popular due to its simple model management. For those looking to implement advanced container isolation and sandboxing at the level of model servers and agent executions, the overview on sandboxing LLM tools and Docker isolation provides a detailed look at setting up secure container boundaries within virtualized environments.

When we subsequently integrate these local models into broader application networks, we can expose them via a central gateway. For this, see the architecture guide on self-hosting local models behind your own API and hybrid routing for methods to seamlessly combine internal model servers with public cloud fallbacks.

Indicative Benchmark Values and Self-Testing: PCIe Bandwidth, Token Latency, and Multi-Tenant Stress

The table below shows indicative benchmark values rather than proprietary measurements. To verify whether the virtual passthrough genuinely approaches maximum hardware performance, you should test this on your own hardware across two areas: PCIe memory throughput via bandwidthTest and actual token generation with your own inference benchmark.

Using the Nvidia CUDA sample program bandwidthTest we measure Host-to-Device (H2D) and Device-to-Host (D2H) speeds across the virtual PCIe bus. On a physical PCIe 4.0 x16 slot, throughput should consistently exceed 25 GB/s. A drop to ~6-7 GB/s indicates that the slot has electrically downshifted to PCIe 3.0 or x4 mode, which primarily impairs initial model loading times and prompt evaluation (Time To First Token).

The benchmark results demonstrate that the pure generation process (where weights circulate exclusively in VRAM) performs virtually identically between bare-metal and Proxmox VFIO. The minimal deviation in Time To First Token (TTFT) stems from IOMMU address translation during the loading of initial prompt tokens into video memory, but this difference is negligible in practice.

Pitfalls, Troubleshooting, and Limitations

Although GPU passthrough on Proxmox is a mature technology, the setup involves specific operational risks and limitations that must be factored in beforehand:

1. No Proxmox Live Migration
Because the physical PCIe hardware is directly bound to the hardware registers of the specific host, it is not possible to live-migrate a running VM to another Proxmox node in a cluster. A migration always requires shutting down the VM completely, after which the target host's configuration must feature identical hardware and PCIe mappings.

2. PCIe Reset Bugs and FLR (Function Level Reset)
Some consumer graphics cards (particularly certain AMD Radeon RX series and older Nvidia GTX cards) do not properly support Function Level Reset. When the virtual machine reboots, the GPU can get stuck in an undefined power state (D3-state). This necessitates a full reboot of the physical Proxmox host to restore GPU functionality. Enterprise GPUs (such as the Nvidia A100, L4, L40S, or RTX 6000 Ada) feature robust FLR support and are unaffected by this issue.

3. VRAM Fragmentation and Host OOM
Because VFIO requires guest memory to be pinned, the Proxmox host's RAM must never be overcommitted. If ZFS memory caching (ARC) or other containers on the host cause unexpected memory pressure, the Linux Out-Of-Memory (OOM) killer may terminate arbitrary processes—including the QEMU process driving the GPU—leading to sudden VM crashes.

Conclusion and Best Practices

GPU passthrough on Proxmox VE strikes an optimal balance between enterprise manageability and bare-metal AI performance. By properly configuring the hypervisor with isolated IOMMU groups, q35chipsets, HugePages, and Resizable BAR, you build a resilient model server that virtually matches a dedicated bare-metal deployment. For anyone managing scalable, local AI workloads within a virtualized infrastructure, this setup represents a future-proof standard.