What is GPU vir­tu­al­iza­tion and how do vGPU, MIG and passthrough differ?

GPU vir­tu­al­iza­tion comprises three fun­da­men­tal ap­proach­es. With GPU passthrough, a complete physical GPU is assigned ex­clu­sive­ly to a single VM. In contrast, vGPU solutions typically share GPU resources between several VMs using time-slicing and scheduler mech­a­nisms. Multi-Instance GPU (MIG) par­ti­tions supported NVIDIA GPUs into fixed, mutually isolated hardware instances.

Key Takeaways ⓘ

The key points about GPU vir­tu­al­iza­tion at a glance:

• GPU passthrough: Assigns a complete physical GPU ex­clu­sive­ly to a single VM — maximum per­for­mance, but no sharing.
• Virtual GPU (vGPU): Shares one GPU between several VMs through time-slicing and sched­ulers — high uti­liza­tion, but only logical isolation.
• Multi-Instance GPU (MIG): Par­ti­tions supported NVIDIA GPUs at the hardware level into up to seven isolated instances with fixed resources.
• Technical lim­i­ta­tions: Passthrough restricts live migration, vGPU requires a license and is sus­cep­ti­ble to the noisy neighbor effect, and MIG cannot burst across profile bound­aries.
• Choosing the right approach: Passthrough for a single VM that needs a full GPU, vGPU for many users with moderate demands, and MIG or MIG-backed vGPU for AI, inference and HPC workloads that need pre­dictable per­for­mance.

GPUs as a central computing resource in the data center

Through AI training, inference and GPU-ac­cel­er­at­ed high-per­for­mance computing, GPUs have become a central computing resource in modern data centers. What was once mainly used for graphics, rendering and spe­cial­ized ap­pli­ca­tions is now often essential for the per­for­mance of entire platforms.

Providing GPU resources ef­fi­cient­ly in virtual en­vi­ron­ments is, however, more chal­leng­ing than with tra­di­tion­al CPU workloads. GPUs operate massively in parallel, have their own high-speed memory such as VRAM or HBM, and are closely in­te­grat­ed into the system via PCIe as well as vendor-specific driver and runtime en­vi­ron­ments. As a result, they cannot be shared as flexibly as CPU cores or RAM.

In practice, three key ap­proach­es have become es­tab­lished:

• Exclusive GPU passthrough: A complete physical GPU is assigned to a single virtual machine.
• vGPU solutions: Several virtual machines share a GPU through driver and hy­per­vi­sor mech­a­nisms.
• Multi-Instance GPU (MIG): Supported NVIDIA GPUs are divided into separate GPU instances at the hardware level.

These methods mainly differ in how resources are shared or par­ti­tioned and how strongly in­di­vid­ual workloads are isolated from one another.

GPU passthrough with direct GPU as­sign­ment to a VM

With GPU passthrough, a complete physical GPU is assigned ex­clu­sive­ly to a single virtual machine. The VM thus gains direct access to the GPU, as if it were installed in a physical server.

Depending on the platform, this method goes by different names:

• Microsoft Hyper-V: Discrete Device As­sign­ment (DDA)
• VMware vSphere/ESXi: VMDi­rect­Path I/O or PCI passthrough
• Linux/KVM: PCI passthrough via the VFIO framework

Tech­ni­cal­ly, this is enabled by the IOMMU (Input-Output Memory Man­age­ment Unit), usually referred to as VT-d on Intel and AMD-Vi on AMD. It ensures that the GPU’s memory accesses are correctly mapped to the VM’s memory area and isolated from other system areas. This allows the VM to use the native vendor driver, i.e. the same driver that would be used on a physical system.

Ad­van­tages and dis­ad­van­tages of GPU passthrough

The main advantage of this approach is its very high per­for­mance. As the GPU is neither emulated nor shared through an ad­di­tion­al ab­strac­tion layer, per­for­mance is, depending on the workload, very close to that of a system running directly on physical hardware.

The downside is limited flex­i­bil­i­ty: A GPU assigned via passthrough is available ex­clu­sive­ly to a single VM. Other VMs cannot use this GPU at the same time, even if the assigned VM only requires a small portion of its computing power or memory capacity.

Technical lim­i­ta­tions of GPU passthrough

The high per­for­mance of GPU passthrough comes with some practical lim­i­ta­tions, mainly resulting from the exclusive binding of the GPU to a single VM:

• No con­cur­rent resource sharing: A physical GPU is assigned ex­clu­sive­ly to one VM. Any unused GPU capacity cannot be dy­nam­i­cal­ly shared with other VMs.
• Low cost ef­fi­cien­cy for small workloads: For virtual desktops, light inference, or other low-demand tasks, a full GPU is often oversized.
• Limited VM mobility: Because the VM is directly bound to a specific physical GPU, live migration, snapshots, save/restore and seamless failover are, depending on the platform, either not possible or only very re­strict­ed. In some cluster scenarios, an automatic restart on another host is possible, but not true live migration.
• De­pen­dence on platform and IOMMU: The host must properly support PCIe passthrough. This includes enabled vir­tu­al­iza­tion ex­ten­sions such as Intel VT-d or AMD-Vi, as well as a suitable PCIe/IOMMU topology. On Linux/KVM, it is par­tic­u­lar­ly important that the GPU is in a suf­fi­cient­ly isolated IOMMU group.
• Support and driver de­pen­den­cies: Not every GPU, moth­er­board and hy­per­vi­sor version supports passthrough reliably. In pro­duc­tion en­vi­ron­ments, you should therefore always check the hardware com­pat­i­bil­i­ty lists and driver re­quire­ments of the re­spec­tive vendor.

Virtual GPU (vGPU)

Virtual GPU, or vGPU for short, solves a key lim­i­ta­tion of GPU passthrough: A physical GPU no longer has to be assigned ex­clu­sive­ly to a single VM but can be shared between several virtual machines.

A special vir­tu­al­iza­tion component is used on the host for this purpose, such as the NVIDIA Virtual GPU Manager. It runs on the re­spec­tive hy­per­vi­sor, including platforms such as VMware vSphere/ESXi, Linux/KVM or XenServer, and provides VMs with virtual GPU devices. A suitable NVIDIA vGPU driver is then installed within the guest VM.

In classic vGPU con­fig­u­ra­tions, sharing is mainly based on time-slicing. The GPU is therefore not per­ma­nent­ly divided into fixed hardware sections. Instead, its compute and graphics engines are shared between VMs over time. In­di­vid­ual workloads then run in rapid suc­ces­sion on the same physical GPU.

Each VM receives a defined share of GPU memory through a vGPU profile. These profiles specify, among other things, how much frame­buffer memory is available to a VM and which use case the profile is designed for. Examples include:

• Q profiles for virtual work­sta­tions
• B profiles for virtual desktops
• A profiles for app streaming
• C profiles for compute workloads

With classic vGPU profiles, compute per­for­mance is not phys­i­cal­ly par­ti­tioned. Instead, it is allocated through a scheduler. NVIDIA supports several sched­ul­ing modes, including Best Effort, Equal Share and Fixed Share:

• Best Effort enables the most flexible use of GPU resources but can lead to per­for­mance vari­a­tions when workloads fluctuate sig­nif­i­cant­ly.
• Equal Share and Fixed Share provide a more balanced or strictly defined al­lo­ca­tion of GPU time.

Ad­van­tages and dis­ad­van­tages of vGPU

The advantage of vGPU lies in the sig­nif­i­cant­ly better uti­liza­tion of the hardware. Several VMs can share an expensive GPU instead of each VM needing its own card. This is par­tic­u­lar­ly useful for virtual desktops, CAD work­sta­tions, rendering en­vi­ron­ments, light AI inference or other workloads that do not con­stant­ly use a full GPU.

The downside is the lower level of hardware isolation compared to MIG or passthrough. Although the allocated frame­buffer of the in­di­vid­ual vGPUs is separated from each other, the actual compute resources are shared. If several VMs generate high GPU loads at the same time, they can compete for available compute resources.

Technical lim­i­ta­tions of vGPU

vGPU offers sig­nif­i­cant­ly more flex­i­bil­i­ty when it comes to sharing a GPU, but it also involves ad­di­tion­al op­er­a­tional effort and lim­i­ta­tions in per­for­mance isolation:

• Licensing required: NVIDIA vGPU is a paid, license-based product. Depending on the profile and use case, different licensing models are used, for example vWS, vPC, vApps or NVIDIA AI En­ter­prise for compute scenarios. Without a valid license, per­for­mance or func­tion­al­i­ty will be re­strict­ed after a certain period.
• Possible noisy neighbor effect: As the GPU compute resources are time-shared, a heavily loaded VM can affect the per­for­mance of other VMs on the same GPU. Sched­ulers such as Equal Share or Fixed Share can limit this effect, but they do not replace full hardware par­ti­tion­ing.
• Com­pat­i­ble drivers required: The host-side vGPU manager and the guest driver must fall within the com­pat­i­bil­i­ty ranges defined by NVIDIA. An exact version match is not always necessary. However, if they are updated in­de­pen­dent­ly of each other, vGPU may no longer start correctly in the affected VMs.
• More op­er­a­tional effort: vGPU requires a co­or­di­nat­ed com­bi­na­tion of supported GPU, hy­per­vi­sor version, vGPU manager, guest driver, license server and profile con­fig­u­ra­tion. This makes operation and updates more complex than with simple GPU passthrough.
• Moderate sched­ul­ing overhead: As GPU time is scheduled and switched between several vGPUs, ad­di­tion­al man­age­ment overhead is created. This is ac­cept­able in many scenarios, but can play a role in par­tic­u­lar­ly latency- or per­for­mance-critical workloads.
• No strict physical isolation as with MIG: Classic vGPU shares compute resources logically via software and sched­ul­ing. Anyone needing fixed GPU shares that are phys­i­cal­ly separated in hardware should consider MIG or MIG-backed vGPU.

Multi-Instance GPU (MIG)

Multi-Instance GPU, or MIG for short, takes a different approach to classic GPU vir­tu­al­iza­tion models based on time-slicing. NVIDIA in­tro­duced Multi-Instance GPU with the Ampere ar­chi­tec­ture, including the A100. Since then, MIG has been extended to selected data center and pro­fes­sion­al GPUs. The tech­nol­o­gy is therefore par­tic­u­lar­ly relevant for data center en­vi­ron­ments where several AI, inference or HPC workloads need to run on a single GPU at the same time. Instead of sharing a GPU between several workloads over time, the hardware is par­ti­tioned into fixed segments. Each instance receives a clearly defined share of compute per­for­mance, memory and memory bandwidth.

Depending on the GPU model, a physical GPU can be divided into several isolated GPU instances. With many data center models, up to seven instances are possible. Each instance receives sta­t­i­cal­ly assigned hardware resources:

• Streaming Mul­ti­proces­sors
• Memory regions
• Memory bandwidth
• L2 cache shares
• Data paths through the memory system

The size of an instance is defined using pre­de­fined profiles. For an NVIDIA A100 with 40 GB of memory, for example, profiles such as 1g.5gb, 2g.10gb or 7g.40gb are possible. The first value roughly describes the share of GPU compute resources, while the second indicates the assigned memory. A profile like 1g.5gb therefore rep­re­sents a small instance, whereas 7g.40gb uses the entire A100 with 40 GB as a single instance.

Ad­van­tages and dis­ad­van­tages of Multi-Instance GPU

The key advantage of MIG is the strong hardware isolation. Because compute and memory resources are sta­t­i­cal­ly assigned, workloads can be separated much more ef­fec­tive­ly from each other than with purely time-based GPU sharing. A heavily utilized instance can fully use the resources allocated to it, but should not displace the memory bandwidth, L2 cache share or compute resources of other instances. This makes MIG par­tic­u­lar­ly suitable for pre­dictable, multi-tenant en­vi­ron­ments with several parallel AI, inference or HPC workloads.

MIG can also be combined with NVIDIA vGPU. With a so-called MIG-backed vGPU, the hardware par­ti­tions created by MIG are in­te­grat­ed into a vir­tu­al­ized en­vi­ron­ment. This makes it possible to combine the benefits of fixed GPU par­ti­tions with VM-based operating models.

Technical lim­i­ta­tions of Multi-Instance GPU

MIG sig­nif­i­cant­ly improves isolation and pre­dictabil­i­ty compared with classic vGPU, but it is tied to specific hardware, fixed profiles and some ar­chi­tec­tur­al lim­i­ta­tions:

• Only available on certain GPUs: MIG is not supported by every NVIDIA GPU. In par­tic­u­lar, consumer GPUs and many older work­sta­tion cards do not offer this feature. MIG is available only on selected data center and newer pro­fes­sion­al GPUs.
• Fixed profile sizes: The division cannot be chosen with arbitrary gran­u­lar­i­ty. Ad­min­is­tra­tors must select from the profiles provided by NVIDIA, for example 1g.5gb, 2g.10gb or 7g.40gb for the A100 with 40 GB of memory.
• Limited number of instances: Depending on the GPU, up to seven instances are possible. Some MIG-capable models support fewer parallel instances.
• Re­con­fig­u­ra­tion only partially dynamic: MIG instances can be managed and recreated, but changes to the par­ti­tion­ing require that the affected instances are not in active use. Enabling MIG mode may ad­di­tion­al­ly require a GPU reset, depending on the GPU gen­er­a­tion and platform.
• No bursting across profile bound­aries: A MIG instance can only use the resources assigned to its profile. Free capacity from another instance is not au­to­mat­i­cal­ly available to it.
• Limited com­mu­ni­ca­tion between instances and in multi-GPU setups: CUDA IPC is not available across different GPU instances, although it can be used between certain compute instances. Peer-to-peer (P2P) support is also limited: newer drivers support it between MIG instances on the same GPU, but not between MIG instances on different GPUs. NCCL support with MIG remains re­strict­ed as well: since NCCL 2.31, there is ex­per­i­men­tal support for multiple MIG instances with CUDA driver 13.0 or later, but features such as NVLink SHARP are not available. MIG may therefore not be the right choice for certain dis­trib­uted workloads or multi-GPU setups that depend on these features.

Use cases and decision support

The best fit depends mainly on three questions:

• Is the maximum per­for­mance of an entire GPU required?
• Do workloads or tenants need reliable isolation from each other?
• Should a GPU be shared as ef­fi­cient­ly as possible between multiple VMs or users?

As a rule of thumb:

• Maximum per­for­mance for a single VM: GPU passthrough
• Many parallel users with moderate GPU re­quire­ments: vGPU
• Several AI, inference or HPC workloads with pre­dictable per­for­mance: MIG or MIG-backed vGPU

When is GPU passthrough suitable?

GPU passthrough is par­tic­u­lar­ly suitable when a single VM requires the full per­for­mance of a physical GPU. Typical examples include:

• High-end work­sta­tions
• GPU-intensive rendering
• CAD and CAE ap­pli­ca­tions
• In­di­vid­ual training jobs that fully utilize a single GPU

In these scenarios, per­for­mance is the main priority, while sharing plays no role or only a minor one.

The downside is that the GPU is tied ex­clu­sive­ly to a single VM. As a result, any unused capacity remains idle, and features such as live migration or seamless failover are, depending on the platform, severely limited.

When is virtual GPU suitable?

Virtual GPU (vGPU) makes sense when many users or VMs each require only a portion of the available GPU per­for­mance. This is often the case with:

• Virtual desktops
• Knowledge worker en­vi­ron­ments
• Technical work­sta­tions with moderate graphics re­quire­ments or light AI inference

vGPU increases tenant density and improves the uti­liza­tion of expensive GPU hardware. Its main advantage is flex­i­bil­i­ty: multiple VMs can use the same physical GPU. The downside is that, in classic vGPU con­fig­u­ra­tions, compute resources are shared through time-slicing. Under high con­cur­rent load, this can lead to com­pe­ti­tion for GPU time. Sched­ulers such as Equal Share or Fixed Share can help manage resource al­lo­ca­tion, but they do not provide complete hardware isolation.

When is Multi-Instance GPU suitable?

Multi-Instance GPU (MIG) is par­tic­u­lar­ly in­ter­est­ing when several workloads need to run on a single GPU while still requiring fixed and pre­dictable resources. Typical use cases include:

• Multi-tenant AI inference
• De­vel­op­ment and test en­vi­ron­ments for multiple teams
• Smaller training sandboxes
• Cloud offerings with guar­an­teed GPU profiles

MIG par­ti­tions supported NVIDIA GPUs at the hardware level. Each instance receives sta­t­i­cal­ly assigned compute and memory resources. This allows workloads to be separated more ef­fec­tive­ly than with classic time-slicing. MIG is therefore par­tic­u­lar­ly suitable for en­vi­ron­ments where both high uti­liza­tion and strong isolation are essential.

In vir­tu­al­ized en­vi­ron­ments, MIG can also be combined with GPU vir­tu­al­iza­tion. With MIG-backed vGPU, the hardware par­ti­tions created by MIG are assigned to VMs. This combines fixed GPU profiles with a vir­tu­al­ized operating model.