GPU Passthrough is a virtualization technique that assigns a physical graphics processing unit directly and exclusively to a specific virtual machine (VM), granting the guest operating system full, unmediated control over the accelerator's hardware. This is achieved using Input/Output Memory Management Unit (IOMMU) technology, such as Intel VT-d or AMD-Vi, which remaps direct memory access to isolate the device and allow the VM to interact with it securely without hypervisor translation.
Glossary
GPU Passthrough

What is GPU Passthrough?
A hardware acceleration method that dedicates an entire physical GPU to a single virtual machine, bypassing the hypervisor's abstraction layer to achieve near-native computational performance.
By bypassing the hypervisor's software emulation layer, GPU passthrough eliminates the significant latency and performance overhead associated with paravirtualized or fully virtualized graphics drivers. This makes it a critical architectural component for on-premises AI clusters and VDI environments, where workloads like model training or CUDA-based computation demand the full, unshared memory bandwidth and parallel processing capability of a physical accelerator.
Key Characteristics of GPU Passthrough
GPU Passthrough is a hardware-assisted virtualization technique that assigns an entire physical GPU to a single virtual machine via the IOMMU, granting the guest OS direct, exclusive access to the accelerator for near-native computational performance.
Direct Hardware Assignment
The hypervisor uses IOMMU (Input-Output Memory Management Unit) to map a physical GPU's PCIe address space directly into a VM's memory. This bypasses the hypervisor's virtual GPU layer entirely, allowing the guest OS to communicate with the GPU as if it were bare metal. VFIO (Virtual Function I/O) is the Linux kernel framework that enables this secure device assignment, isolating the GPU's DMA and interrupt remapping to prevent memory corruption.
Single-Tenant Exclusivity
Unlike Multi-Instance GPU (MIG) or vGPU partitioning, passthrough grants one GPU to one VM. The guest has full control over the entire framebuffer, compute units, and NVENC/NVDEC encoders. This is critical for workloads requiring deterministic latency or access to GPU features not exposed through virtualized interfaces. The trade-off is reduced hardware density—you cannot share a single physical GPU across multiple VMs simultaneously.
IOMMU Group Isolation
The physical GPU and all associated PCIe functions (HDMI audio controller, USB-C ports) must reside in a single IOMMU group for safe passthrough. An IOMMU group is the smallest set of devices that can be isolated for assignment. If the GPU shares a group with other devices (e.g., a PCIe bridge), all devices in that group must be passed through together or none at all. ACS (Access Control Services) on the PCIe root complex enables finer-grained isolation.
Reset and State Management
A GPU must support Function-Level Reset (FLR) or a bus-level reset to be safely passed through. Without proper reset capability, the GPU retains state from a previous VM or host driver, causing initialization failures. Many consumer GPUs have notoriously broken reset mechanisms, requiring vendor-specific workarounds or kernel patches. Data center GPUs like the NVIDIA A100 and H100 implement robust FLR for clean re-assignment.
Vendor Driver Transparency
The guest VM installs the native, unmodified GPU driver (e.g., NVIDIA CUDA driver, AMD ROCm). The hypervisor does not intercept or translate driver commands. This means any GPU feature—CUDA, Vulkan, DirectX, NVENC—works without paravirtualized shims. However, the vendor driver may detect it is running in a virtualized environment and refuse to load. NVIDIA's consumer driver enforcement requires hiding the hypervisor CPUID leaf via libvirt's kvm=off or hypervisor_vendor_id settings.
NUMA and PCIe Topology Awareness
For optimal performance, the passed-through GPU must be attached to the same NUMA node as the VM's vCPUs and memory. A GPU on NUMA node 0 accessed by a VM pinned to NUMA node 1 incurs cross-node memory latency penalties. libvirt's numatune and CPU pinning directives ensure the VM's resources align with the GPU's physical PCIe root complex, preserving local memory bandwidth and minimizing DMA latency.
GPU Passthrough vs. vGPU vs. MIG
A technical comparison of the three primary methods for partitioning and sharing physical GPU resources across virtual machines or workloads in an on-premises AI cluster.
| Feature | GPU Passthrough | vGPU (Virtual GPU) | MIG (Multi-Instance GPU) |
|---|---|---|---|
Partitioning Method | Full physical GPU assignment to a single VM via IOMMU/VT-d | GPU time-slicing managed by a hypervisor driver and GRID software | Hardware-level spatial partitioning of GPU compute units and memory |
Performance Overhead | < 1% | 5-15% | < 1% |
GPU Memory Isolation | Dedicated, full VRAM | Shared VRAM with software-enforced limits | Dedicated, hardware-enforced VRAM slices |
Fault Isolation | Full; GPU fault affects only the assigned VM | Partial; driver fault can impact all sharing VMs | Full; MIG instance fault is hardware-contained |
Concurrent Workloads per GPU | 1 | Up to 32 (vendor-dependent) | Up to 7 (A100/H100) |
Live Migration Support | |||
CUDA API Visibility | Full, unmodified | Full, unmodified | Subset; limited to compute-only, no display or graphics APIs |
Licensing Model | None (native kernel feature) | Perpetual or subscription license per concurrent user | None (native hardware feature) |
Frequently Asked Questions
Direct answers to the most common technical questions about assigning a physical GPU exclusively to a virtual machine for near-native performance in virtualized environments.
GPU passthrough is a virtualization technique that assigns an entire physical GPU directly to a single virtual machine (VM), granting the guest operating system exclusive, low-level access to the hardware. This is achieved using an Input/Output Memory Management Unit (IOMMU) , such as Intel VT-d or AMD-Vi, which remaps device DMA addresses to isolate the GPU from the host and other VMs. The hypervisor—typically KVM, VMware ESXi, or Xen—unbinds the GPU from the host driver and attaches it to the VM via VFIO (Virtual Function I/O) on Linux. Once passed through, the VM can load the GPU's native vendor driver (e.g., NVIDIA CUDA or AMD ROCm), enabling near-bare-metal performance for AI training, inference, and rendering workloads without the overhead of paravirtualized graphics drivers.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Core concepts and technologies that intersect with or enable GPU passthrough in virtualized and bare-metal environments.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us