NVIDIA vGPU is usually filed next to MIG under ‘ways to share a GPU’, and that filing hides the interesting fact: they are structurally different machines. MIG is a hardware feature that carves one physical GPU into smaller physical GPUs. vGPU is a hypervisor feature that lets several virtual machines each believe they own a GPU while a host-side manager arbitrates between them. Everything else follows. vGPU shares the engine in time, not in silicon, so isolation is softer and utilization higher. It splits exactly one resource for real — the frame buffer. And because the guest never touches the physical device, a running vGPU can be migrated to another host, the capability that decides most real deployments.
Mediated passthrough — what the guest driver really talks to
There are three ways to give a virtual machine a GPU. Emulation gives a software device with no acceleration. Full passthrough hands the physical PCIe function to one VM outright: full speed, no sharing, no host visibility. vGPU takes the third route, mediated passthrough.
A vGPU host runs a vGPU manager inside the hypervisor, which creates virtual device functions and assigns one per VM. Inside the VM an ordinary-looking NVIDIA driver enumerates that virtual device, so CUDA and the graphics stack initialise normally. The design splits fast paths from privileged paths: command submission and the guest’s frame buffer are mapped through, so work is pushed without trapping on every operation, while context setup, engine configuration and interrupts are intercepted by the host. The guest never programs the whole device — which is what makes the rest of the model possible.
Time-sliced sharing, not hard partitioning
Here vGPU parts company with MIG most sharply. MIG’s proposition is that a slice owns its own SMs and memory path — concurrent execution on disjoint hardware. vGPU does not do that. In its default configuration the GPU’s engines belong to one vGPU at a time: the host scheduler grants a time slice, that vGPU’s work runs on the full engine, then a context switch hands the engine to the next vGPU with pending work.
The trade is the inverse of MIG’s. During its slice a vGPU gets the whole GPU, so a burst finishes at full speed rather than on a fixed fraction of the SMs. That suits the interactive workloads vGPU targets, where a desktop needs a lot of GPU for 30 ms, then nothing for a second. What you surrender is simultaneity and predictability: two vGPUs never run at once, and your latency now includes however long you waited for your turn.
The frame buffer is the one hard split
Exactly one resource in the vGPU model behaves like a real partition, and it is memory. Assigning a profile carves out a fixed amount of frame buffer at VM start, and it stays carved out for that vGPU’s life. It is not overcommitted, not ballooned, not borrowed from an idle neighbour. A vGPU that allocates past its profile size gets an out-of-memory error even with gigabytes free in the VM next door.
So profile size, not compute share, determines density: a board hosts roughly its usable frame buffer divided by the profile size, minus host-side overhead (less again with ECC enabled). Choosing a profile is a capacity decision made once, up front, per VM — and expensive to get wrong either way. Oversize it and you strand memory and cut VMs per board; undersize it and users hit hard allocation failures that spare host capacity cannot rescue.
Noisy neighbours move into the time domain
Because only the frame buffer is partitioned, everything else is genuinely shared. The L2 cache, the memory controllers and HBM bandwidth all serve whichever vGPU currently holds the engine, with no per-tenant reservation. The context switch between vGPUs is not free either: state must be saved and restored, and a workload with a large working set pays for the eviction on the way back in.
vGPU noisy neighbours therefore appear as latency variance rather than a flat throughput haircut. Aggregate sharing is usually fair; the tail is where you feel other tenants. A neighbour submitting long-running kernels stretches the interval before your turn arrives, so your p99 moves while your average looks fine. The honest framing: vGPU delivers fair sharing, not isolation. If you need a hard performance floor no neighbour can perturb, time slicing is the wrong mechanism at any policy setting.
Three scheduling policies, one trade
The host scheduler is configurable, set on the physical GPU so it governs every vGPU on that board. The three behaviours sit on one axis, utilization to predictability.
| Policy | Behaviour | Cost |
|---|---|---|
| Best effort | Work-conserving; any vGPU with work absorbs idle time | Best utilization, weakest isolation, most latency variance |
| Equal share | Engine time divided evenly among powered-on vGPUs | Your share shifts as VMs boot and shut down |
| Fixed share | A fixed fraction set by how many vGPUs of that profile the board holds | Stable regardless of neighbours; idle capacity wasted |
Best effort is the right default for VDI, where most desktops idle and letting an active user absorb the slack is the point. Fixed share is right when consistency is contractual: the same responsiveness on a full host as on an empty one, paid for in idle silicon. Equal share is the compromise that surprises people — performance improves when colleagues log off and degrades when they log on, which users experience as unexplained flakiness.
Live migration — the reason to choose vGPU at all
If you take one operational fact from this article, take this one. Because the guest never programs the physical device and the host manager holds the privileged state, the host can suspend a vGPU, serialise its state, and restore it elsewhere — a running, GPU-accelerated VM migrated off a host with its workload intact. Hard partitioning cannot do this: a slice of physical silicon has no portable representation to move.
That makes GPUs first-class citizens of a virtualized datacentre rather than pets. You can patch a hypervisor, replace a failing node or rebalance load without downtime for every GPU tenant on the box; the same mechanism underpins suspend-and-resume across host reboots. The constraints are real: the destination needs a compatible GPU and a matching software stack, and migration time scales with the frame buffer to be copied, so large profiles migrate more slowly and generate more network traffic.
Driver pairing and licensing are the operational tax
vGPU is not a hardware capability you switch on; it is a licensed software product with a supported-configuration matrix, and that is where the day-two pain lives. Host manager and guest driver come from paired releases, and although documented windows allow mixed versions, upgrading the host eventually forces a coordinated driver upgrade across the whole guest fleet. For a few dozen VMs that is an afternoon; for a few thousand desktops, a project.
Licensing is enforced at runtime, not install time, making it a boot-path dependency rather than a procurement footnote. The guest driver acquires a license from a license service when the VM starts and renews periodically; if that service is unreachable, guests degrade or lose acceleration on a timer. The license service therefore inherits the availability requirements of the GPU fleet itself — worth rehearsing, because ‘every desktop went slow at once’ is a confusing symptom to debug cold.
Profiles are a density decision, not a performance dial
A profile is chosen per VM and defines two things: how much frame buffer the vGPU gets, and what kind of device the guest sees. The memory dimension is the density lever already described. The second trips people up: profile families differ in whether they expose a full professional-graphics device with multiple virtual display heads and workstation features, or a display-light device meant for compute. Picking the wrong family produces puzzling failures: an app that refuses to launch, or a resolution ceiling that looks like a broken driver.
Note what a profile does not do: it does not buy a larger share of the engine. Compute share comes from the scheduling policy and from how many vGPUs contend, not from the profile’s memory size. The exception is the whole-GPU profile, where one VM takes the entire board and time slicing becomes moot — the usual shape for a virtualized training node that wants hypervisor-level management.
The workloads vGPU actually targets
vGPU was built for VDI and virtualized workstations, and the fit is excellent. Modern desktops need GPU acceleration just to composite a window manager, run a browser and decode video; CAD and visualization need far more. All of it is bursty and interactive — the profile time slicing serves well. Idle users cost nothing, active users get the full engine while they hold it, and the frame-buffer split matches the genuinely per-user resource.
The second home is the virtualized datacentre, where the unit of management is a VM and the surrounding machinery — snapshots, high availability, live migration, existing hypervisor tooling — is worth more than the last few percent of throughput. For sustained ML training or latency-sensitive serving the calculus flips: those workloads want the engine continuously and a tail-latency floor time slicing cannot give. They are also usually container-scheduled, bypassing the hypervisor layer vGPU exists to serve.
MIG-backed vGPU — and the capability it costs
The two models are not strictly either/or. On GPUs supporting both, a vGPU can be backed by a MIG instance instead of a time slice: the VM still gets a virtual device and lives inside the hypervisor’s management model, but its compute comes from a hardware partition rather than a turn in the queue. That combines VM packaging with a hard performance floor.
It is not free, and the cost is the thing that made vGPU worth choosing. Bind a vGPU to a physical partition and the portable-state property that made migration possible weakens; support matrices have historically reflected that, not offering live migration for MIG-backed vGPUs as they do for time-sliced ones. The clean way to hold the picture: hardware partitioning buys isolation, hypervisor mediation buys mobility and management, and combining them makes you pick which you value more.