GPU Passthrough vs vGPU vs MIG: Which Virtualization Method Should You Choose?

A single physical GPU sitting idle in a hypervisor host is an expensive waste, but the “right” way to virtualize it depends entirely on what you’re running on top of it. A homelab running one Stable Diffusion VM has completely different requirements than a VDI cluster serving 200 CAD users or an enterprise training a fine-tuned LLM. This guide compares GPU passthrough, NVIDIA vGPU (GPU partitioning), and MIG (Multi-Instance GPU), plus where SR-IOV, AMD’s virtualization stack, VMware’s native GPU tooling, and bare-metal servers fit in, so you can pick a method before you touch a BIOS setting.

Quick verdict: If one VM needs the whole GPU (LLM fine-tuning, CAD rendering, single-tenant AI training), use GPU passthrough on Proxmox VE 8.x or Hyper-V Discrete Device Assignment. It’s free and delivers near-bare-metal performance. If you need to share one GPU across many VMs with live migration support (VDI fleets, RDSH, light inference), use NVIDIA vGPU, budgeting for per-CCU (concurrent user) licensing. If you’re running multi-tenant AI inference or dev/test workloads on Ampere-class or newer NVIDIA data center GPUs and need hard isolation between tenants, use MIG layered under vGPU or bare Linux.

Overview

All three approaches solve the same underlying problem, getting a GPU’s compute into a virtual machine, but they trade performance, isolation, and cost against each other in different ways. Passthrough hands the entire device to one guest via IOMMU remapping. vGPU uses a host-side driver to time-slice or partition the GPU across multiple guests. MIG goes a step further on supported data center GPUs by physically carving the silicon into hardware-isolated instances, each with its own dedicated memory and compute cores, rather than scheduling time slices on a shared pool.

What We’re Comparing

Feature Comparison

At a Glance

GPU Passthrough: Maximum Performance, No Sharing

How It Works

Passthrough (called PCI passthrough on Proxmox VE, Discrete Device Assignment on Hyper-V, and DirectPath I/O on VMware) uses the CPU’s IOMMU (Intel VT-d or AMD-Vi) to remap a physical PCIe device directly into a VM’s address space. The guest OS loads the vendor’s native driver and talks to the GPU almost as if it were bare metal. There’s no hypervisor-mediated scheduling layer sitting between the VM and the silicon, which is why passthrough consistently benchmarks closest to bare-metal throughput in vendor and community testing.

The catch is exclusivity. Once a GPU is bound to a VM via vfio-pci (Linux/Proxmox) or DDA (Hyper-V), no other VM, and not even the host, can touch it. That has two direct consequences worth internalizing before you commit to this path:

• No sharing. If you have one RTX 4000 Ada in a box and three VMs that each want GPU access, only one of them gets it. The others need their own physical GPUs or a different virtualization method entirely.
• No live migration. Passthrough binds the VM to specific host hardware. You cannot vMotion, live-migrate, or Quick Migrate a VM with a passthrough GPU attached without first detaching the device, which means downtime for host maintenance.

Winner for raw performance: GPU Passthrough. When a single job, model training, a CAD workstation, a render farm node, needs every CUDA core and every megabyte of VRAM, nothing beats handing over the whole card.

vGPU / GPU Partitioning: Shared Access at Scale

How It Works

NVIDIA vGPU software (and Microsoft’s native Hyper-V GPU partitioning, available on Windows Server 2025 and later) lets a host-side driver expose fractional GPU profiles to multiple VMs concurrently. Each VM gets a slice of the GPU’s frame buffer and a scheduled share of compute time. Because the GPU stays under host driver control rather than being exclusively bound to one guest, vGPU-backed VMs can be live-migrated between hosts on supported hypervisors, a critical feature for maintenance windows on production VDI clusters.

On Hyper-V, checking which GPUs are available for partitioning is a one-line PowerShell command from an elevated session on the host:

Get-VMHostPartitionableGpu

Expected output looks like this, one entry per GPU eligible for partitioning:

Name ValidResourceAmounts
—- ———————
\\?\PCI#VEN_10DE&DEV_20B0&SUBSYS_… {0, 33, 66, 100}

Attaching a partition to a specific VM (after removing any checkpoints, which block GPU partition assignment) uses:

Add-VMGpuPartitionAdapter -VMName YourVMName

For RDSH-style VDI, GPU acceleration inside remote sessions also depends on a Group Policy setting most admins forget to flip: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Use hardware graphics adapters for all Remote Desktop Services sessions, set to Enabled.

vGPU’s isolation model is software time-slicing by default; VMs share the same physical cores and memory bus on a scheduled rotation, not dedicated hardware. That’s fine for VDI and light inference where “noisy neighbor” risk is tolerable, but it’s not the strongest isolation guarantee available (that’s MIG, covered next).

One quirk worth flagging: some NVIDIA data center GPUs ship in compute mode by default and need to be switched to graphics mode with gpumodeswitch before vGPU graphics profiles (vWS, vPC) will work correctly. If your vGPU-backed VM shows no graphics acceleration despite a valid license, this is the first thing to check.

Winner for shared access at scale: vGPU / GPU Partitioning. It’s the only method here that combines multi-VM sharing with live migration support, which is exactly what a 100-seat VDI deployment or an RDSH farm needs.

MIG: Hardware-Isolated Partitioning

How It Works

MIG (Multi-Instance GPU) is available on Ampere-class and newer NVIDIA data center GPUs, think A100, A30, and H100. Instead of scheduling time slices on a shared pool like standard vGPU, MIG physically divides the GPU’s streaming multiprocessors, L2 cache, and memory controllers into fixed instances. Each instance behaves like a smaller, independent GPU with guaranteed compute and memory, no contention with the other instances on the same card, even under heavy load.

This matters most in multi-tenant environments where you can’t tolerate one workload starving another. A noisy training job in one MIG instance won’t steal cycles from an inference workload running in a sibling instance the way it might under time-sliced vGPU sharing. MIG instances can be exposed directly to containers (Kubernetes device plugin) or layered under vGPU for VM-level assignment with live migration support, depending on your stack.

The trade-offs: MIG requires specific hardware (you can’t MIG-partition a consumer or even most workstation-class NVIDIA cards), the number of partitions per GPU is fixed by the card’s architecture (commonly up to 7 instances), and configuring MIG profiles alongside vGPU licensing adds a layer of complexity that’s genuinely harder to troubleshoot than standard passthrough or vGPU alone.

Winner for multi-tenant isolation: MIG. When you’re hosting inference workloads for multiple internal teams or external customers on the same physical card, hardware-level isolation is worth the added setup complexity.

Where the Alternatives Fit

SR-IOV (Hardware-Based Sharing)

Where a GPU natively supports SR-IOV (Single Root I/O Virtualization), it can expose multiple virtual functions directly to VMs at the hardware level, sidestepping the full NVIDIA vGPU software licensing stack in some configurations. This is more common on AMD’s data-center-class cards and certain NVIDIA models in specific deployment scenarios. It’s a middle ground between passthrough’s one-VM exclusivity and vGPU’s full software-managed sharing, but support varies significantly by GPU model and hypervisor; check your card’s spec sheet before planning around it.

AMD GPU Virtualization (Instinct / MxGPU)

AMD publishes its own virtualization path for ESXi passthrough and Instinct-class accelerators, documented separately from NVIDIA’s vGPU stack. If your shop is standardized on AMD hardware for cost or supply-chain reasons, this is worth reviewing directly rather than assuming NVIDIA’s licensing model applies; AMD’s approach to shared GPU access (MxGPU) uses SR-IOV natively rather than a proprietary host driver layer.

VMware vSphere GPU Virtualization

vSphere has its own native GPU profile configuration under Configure > Hardware > Graphics in the vSphere Client, integrating with NVIDIA vGPU licensing for shops already standardized on VMware/Broadcom. Functionally it lands in the same category as vGPU above (shared access, live migration on supported configurations), but the exact UI paths shift periodically post-Broadcom acquisition, so confirm against current VMware documentation before planning a deployment around it.

Bare-Metal GPU Servers (No Virtualization)

Skipping virtualization entirely is still a legitimate option. If you have exactly one GPU workload and no need for VM flexibility, snapshotting, or live migration, bare metal avoids every trade-off discussed here: no IOMMU quirks, no licensing fees, no scheduling overhead. The cost is losing the operational flexibility of running multiple isolated workloads or easily moving that workload to different hardware.

Checking Hardware Support Before You Commit

Before picking a method, verify your hardware actually supports it. This isn’t a full setup walkthrough, just the checks worth running before you buy licenses or reconfigure a production host.

Windows (Hyper-V)

Confirm the host is running Windows Server 2025 or later for native GPU partitioning, then check BIOS/UEFI for IOMMU/VT-d and SR-IOV support if your GPU vendor requires it. From an elevated PowerShell session, list partitionable GPUs as shown earlier with Get-VMHostPartitionableGpu. For centralized management across multiple Hyper-V hosts, install Windows Admin Center with the GPUs extension version 2.8.0 or later, which gives you a GUI view of GPU assignment and partitioning status instead of PowerShell-only visibility.

To verify a guest VM actually sees the accelerated GPU after assignment, run dxdiag inside the VM and check the Driver Model field on the Display tab; it should reflect the assigned adapter, not a generic Microsoft Basic Display Adapter.

Web (Proxmox / vSphere Client / Licensing Portals)

On Proxmox VE 8.x, IOMMU has to be explicitly enabled in host BIOS/UEFI; “Auto” is not the same as “Enabled” on many boards. The host also needs its native GPU driver (nouveau, amdgpu, radeon, or nvidia*) blacklisted so it doesn’t claim the device before vfio-pci can bind to it. From there, GPU assignment happens entirely through the web UI: open the target VM, go to the Hardware tab, click Add, then choose PCI Device.

If you’re licensing NVIDIA vGPU, the graphics-mode requirement is worth checking early: some data center GPUs ship in compute mode and need gpumodeswitch before vGPU graphics profiles activate.

Decision Matrix by Workload Type

Licensing and Cost Considerations

Pricing Comparison

NVIDIA’s vGPU pricing is published per CCU (concurrent user), not per named user or per VM, which matters for capacity planning: a 200-seat VDI deployment where only 80 users are logged in simultaneously at peak only needs 80 CCUs of licensing, not 200. Licenses come in two flavors: a perpetual license plus an annual SUMS (Software, Updates, and Maintenance Subscription) fee, or a straight annual subscription. The perpetual route front-loads cost but avoids re-purchasing the base license each year; the subscription route keeps upfront cost lower but recurs indefinitely. Neither NVIDIA’s public pricing guide nor this research turned up exact perpetual license figures; budget for a quote from an NVIDIA reseller if you’re going the perpetual route.

Passthrough and bare-metal both avoid GPU virtualization licensing entirely; you’re only paying for the hypervisor (which may itself be free, as with Proxmox VE) and the hardware. That’s the single biggest reason homelabbers and small shops default to passthrough: it’s the only method here with zero recurring software cost.

Use Case Recommendations

Choose GPU Passthrough if:

• One VM needs to fully saturate the GPU (LLM training, CAD rendering, single-tenant AI workloads)
• You don’t need to share the GPU across multiple VMs
• Live migration isn’t a requirement for that workload
• You want to avoid vGPU licensing costs entirely
• You’re running a homelab or small business testing environment on consumer or workstation-class hardware

Choose vGPU / GPU Partitioning if:

• You’re serving dozens or hundreds of VDI or RDSH sessions from a shared GPU pool
• Live migration for host maintenance windows is a hard requirement
• Per-CCU licensing cost is acceptable against the alternative of buying one GPU per user
• Your workloads are light-to-moderate GPU consumers (office productivity, light CAD, basic inference)

Choose MIG if:

• You’re hosting multi-tenant AI inference where noisy-neighbor risk between customers or teams is unacceptable
• You have Ampere-class or newer NVIDIA data center GPUs (A100, A30, H100) available
• Dev/test environments need guaranteed, isolated GPU slices without dedicating full physical cards
• You need stronger isolation guarantees than time-sliced vGPU sharing provides

Final Verdict

There’s no single winner here; the right answer depends entirely on whether your bottleneck is raw performance, VM density, or tenant isolation. If you’re forced to pick one default for a general-purpose infrastructure team supporting mixed workloads, vGPU earns the nod for versatility: it’s the only method that combines sharing and live migration, and its tiered licensing lets you scale cost to workload intensity rather than paying a flat per-GPU fee regardless of use.

Overall Winner: NVIDIA vGPU (with Passthrough and MIG as best-fit specialists)

vGPU wins on flexibility and operational fit for the widest range of enterprise scenarios, but Passthrough remains the correct choice whenever a single job needs maximum throughput and licensing cost isn’t worth paying, and MIG is the right call the moment tenant isolation becomes non-negotiable.

Score Summary

Frequently Asked Questions

What’s the real performance difference between passthrough and vGPU?

Passthrough talks nearly directly to the GPU through IOMMU remapping, so it consistently benchmarks closest to bare metal. vGPU introduces a host-side scheduling layer to time-slice the GPU across multiple VMs, which adds overhead proportional to how many VMs are sharing that GPU and how aggressively they’re contending for cycles. For a single demanding workload, passthrough wins outright; for many light workloads, vGPU’s aggregate throughput per dollar often wins even with the per-VM overhead.

Can I live-migrate a VM with a passthrough GPU?

No. Passthrough binds the VM to specific host hardware, so the VM can’t be moved to another host without first detaching the device. This is one of the biggest operational trade-offs versus vGPU, which supports live migration on compatible hypervisors.

Can two VMs share one physical GPU, and how?

Not with standard PCI(e) passthrough; it locks the device to one VM at a time. To share a GPU across VMs, you need vGPU/GPU partitioning, MIG (on supported hardware), or a GPU that natively supports SR-IOV.

When does MIG make more sense than standard vGPU sharing?

When isolation matters more than raw VM density. MIG’s hardware-partitioned instances don’t contend for the same compute cores or memory bus the way time-sliced vGPU VMs do, which matters most in multi-tenant inference hosting or dev/test environments where one workload spiking shouldn’t degrade another’s performance.

How is NVIDIA vGPU licensed, and what does it cost per user?

NVIDIA vGPU is licensed per CCU (concurrent user), not per named user or VM. Published suggested pricing runs roughly $10/CCU/year for the vApps tier (app virtualization), $50/CCU/year for vPC (virtual desktops), and $250/CCU/year for RTX vWS (professional workstation graphics). Licenses are available as a perpetual license plus annual SUMS fee, or as a straight annual subscription; check NVIDIA’s packaging and pricing guide for current figures before budgeting.

Which method is best for LLM training vs. inference vs. VDI vs. dev/test?

Passthrough for training (needs the full card), vGPU or passthrough for inference depending on tenancy and cost sensitivity, vGPU for VDI (density plus live migration), and MIG or vGPU for dev/test where isolated, guaranteed slices matter more than raw throughput. See the decision matrix table above for the full breakdown.

Do I need special hardware (IOMMU, SR-IOV, GPU mode) for each approach?

Yes, and it differs by method. Passthrough requires IOMMU/VT-d support in the CPU and motherboard. vGPU requires a vGPU-capable GPU plus a valid NVIDIA license (and sometimes a GPU mode switch from compute to graphics mode via gpumodeswitch). MIG requires Ampere-class or newer NVIDIA data center GPUs specifically; it’s not available on consumer or most workstation-class cards.

Wrapping Up

If you’re still deciding, start from the workload, not the method: one hungry job wants a whole GPU (passthrough), many light sessions want to share one (vGPU), and multiple tenants that can’t step on each other want hardware isolation (MIG). Most real infrastructure ends up running a mix of all three across different hosts rather than standardizing on just one.

This comparison is based on official NVIDIA and Microsoft documentation, and the Proxmox VE wiki, as of September 2026. Licensing prices are suggested figures published in NVIDIA’s packaging and pricing guide and may vary by reseller and region.

For more information on Windows Server 2025 as an AI Host, Ollama for Self-Hosted AI Code Review, Ollama Docker Troubleshooting, or Docker on Windows Server 2025, visit our website. Consider using a Raspberry Pi for homelab testing or a Mini PC for Homelab for more powerful testing. Don’t forget to protect your setup with a UPS Battery Backup and store your data on a NAS Hard Drive. Connect your devices with a Cat6 Ethernet Cable.