What is GPU virtualisation and how do vGPU, MIG and passthrough differ?

GPU virtualisation comprises three fundamental approaches. With GPU passthrough, a complete physical GPU is assigned exclusively to a single VM. In contrast, vGPU solutions typically share GPU resources between several VMs using time-slicing and scheduler mechanisms. Multi-Instance GPU (MIG) partitions supported NVIDIA GPUs into fixed, mutually isolated hardware instances.

Key Takeaways ⓘ

The key points about GPU virtualisation at a glance:

• GPU passthrough: Assigns a complete physical GPU exclusively to a single VM — maximum performance, but no sharing.
• Virtual GPU (vGPU): Shares one GPU between several VMs through time-slicing and schedulers — high utilisation, but only logical isolation.
• Multi-Instance GPU (MIG): Partitions supported NVIDIA GPUs at the hardware level into up to seven isolated instances with fixed resources.
• Technical limitations: Passthrough restricts live migration, vGPU requires a licence and is susceptible to the noisy neighbour effect, and MIG cannot burst across profile boundaries.
• 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 predictable performance.

GPUs as a central computing resource in the data centre

Through AI training, inference and GPU-accelerated high-performance computing, GPUs have become a central computing resource in modern data centres. What was once mainly used for graphics, rendering and specialised applications is now often essential for the performance of entire platforms.

Providing GPU resources efficiently in virtual environments is, however, more challenging than with traditional CPU workloads. GPUs operate massively in parallel, have their own high-speed memory such as VRAM or HBM, and are closely integrated into the system via PCIe as well as vendor-specific driver and runtime environments. As a result, they cannot be shared as flexibly as CPU cores or RAM.

In practice, three key approaches have become established:

• 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 hypervisor mechanisms.
• 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 partitioned and how strongly individual workloads are isolated from one another.

GPU passthrough with direct GPU assignment to a VM

With GPU passthrough, a complete physical GPU is assigned exclusively 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 Assignment (DDA)
• VMware vSphere/ESXi: VMDirectPath I/O or PCI passthrough
• Linux/KVM: PCI passthrough via the VFIO framework

Technically, this is enabled by the IOMMU (Input-Output Memory Management 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.

Advantages and disadvantages of GPU passthrough

The main advantage of this approach is its very high performance. As the GPU is neither emulated nor shared through an additional abstraction layer, performance is, depending on the workload, very close to that of a system running directly on physical hardware.

The downside is limited flexibility: A GPU assigned via passthrough is available exclusively 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 limitations of GPU passthrough

The high performance of GPU passthrough comes with some practical limitations, mainly resulting from the exclusive binding of the GPU to a single VM:

• No concurrent resource sharing: A physical GPU is assigned exclusively to one VM. Any unused GPU capacity cannot be dynamically shared with other VMs.
• Low cost efficiency 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 restricted. In some cluster scenarios, an automatic restart on another host is possible, but not true live migration.
• Dependence on platform and IOMMU: The host must properly support PCIe passthrough. This includes enabled virtualisation extensions such as Intel VT-d or AMD-Vi, as well as a suitable PCIe/IOMMU topology. On Linux/KVM, it is particularly important that the GPU is in a sufficiently isolated IOMMU group.
• Support and driver dependencies: Not every GPU, motherboard and hypervisor version supports passthrough reliably. In production environments, you should therefore always check the hardware compatibility lists and driver requirements of the respective vendor.

Virtual GPU (vGPU)

Virtual GPU, or vGPU for short, solves a key limitation of GPU passthrough: A physical GPU no longer has to be assigned exclusively to a single VM but can be shared between several virtual machines.

A special virtualisation component is used on the host for this purpose, such as the NVIDIA Virtual GPU Manager. It runs on the respective hypervisor, 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 configurations, sharing is mainly based on time-slicing. The GPU is therefore not permanently divided into fixed hardware sections. Instead, its compute and graphics engines are shared between VMs over time. Individual workloads then run in rapid succession 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 framebuffer memory is available to a VM and which use case the profile is designed for. Examples include:

• Q profiles for virtual workstations
• B profiles for virtual desktops
• A profiles for app streaming
• C profiles for compute workloads

With classic vGPU profiles, compute performance is not physically partitioned. Instead, it is allocated through a scheduler. NVIDIA supports several scheduling modes, including Best Effort, Equal Share and Fixed Share:

• Best Effort enables the most flexible use of GPU resources but can lead to performance variations when workloads fluctuate significantly.
• Equal Share and Fixed Share provide a more balanced or strictly defined allocation of GPU time.

Advantages and disadvantages of vGPU

The advantage of vGPU lies in the significantly better utilisation of the hardware. Several VMs can share an expensive GPU instead of each VM needing its own card. This is particularly useful for virtual desktops, CAD workstations, rendering environments, light AI inference or other workloads that do not constantly use a full GPU.

The downside is the lower level of hardware isolation compared to MIG or passthrough. Although the allocated framebuffer of the individual 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 limitations of vGPU

vGPU offers significantly more flexibility when it comes to sharing a GPU, but it also involves additional operational effort and limitations in performance isolation:

• Licensing required: NVIDIA vGPU is a paid, licence-based product. Depending on the profile and use case, different licensing models are used, for example vWS, vPC, vApps or NVIDIA AI Enterprise for compute scenarios. Without a valid licence, performance or functionality will be restricted after a certain period.
• Possible noisy neighbour effect: As the GPU compute resources are time-shared, a heavily loaded VM can affect the performance of other VMs on the same GPU. Schedulers such as Equal Share or Fixed Share can limit this effect, but they do not replace full hardware partitioning.
• Compatible drivers required: The host-side vGPU manager and the guest driver must fall within the compatibility ranges defined by NVIDIA. An exact version match is not always necessary. However, if they are updated independently of each other, vGPU may no longer start correctly in the affected VMs.
• More operational effort: vGPU requires a coordinated combination of supported GPU, hypervisor version, vGPU manager, guest driver, licence server and profile configuration. This makes operation and updates more complex than with simple GPU passthrough.
• Moderate scheduling overhead: As GPU time is scheduled and switched between several vGPUs, additional management overhead is created. This is acceptable in many scenarios, but can play a role in particularly latency- or performance-critical workloads.
• No strict physical isolation as with MIG: Classic vGPU shares compute resources logically via software and scheduling. Anyone needing fixed GPU shares that are physically 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 virtualisation models based on time-slicing. NVIDIA introduced Multi-Instance GPU with the Ampere architecture, including the A100. Since then, MIG has been extended to selected data centre and professional GPUs. The technology is therefore particularly relevant for data centre environments 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 partitioned into fixed segments. Each instance receives a clearly defined share of compute performance, memory and memory bandwidth.

Depending on the GPU model, a physical GPU can be divided into several isolated GPU instances. With many data centre models, up to seven instances are possible. Each instance receives statically assigned hardware resources:

• Streaming Multiprocessors
• Memory regions
• Memory bandwidth
• L2 cache shares
• Data paths through the memory system

The size of an instance is defined using predefined 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 represents a small instance, whereas 7g.40gb uses the entire A100 with 40 GB as a single instance.

Advantages and disadvantages of Multi-Instance GPU

The key advantage of MIG is the strong hardware isolation. Because compute and memory resources are statically assigned, workloads can be separated much more effectively from each other than with purely time-based GPU sharing. A heavily utilised 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 particularly suitable for predictable, multi-tenant environments 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 partitions created by MIG are integrated into a virtualised environment. This makes it possible to combine the benefits of fixed GPU partitions with VM-based operating models.

Technical limitations of Multi-Instance GPU

MIG significantly improves isolation and predictability compared with classic vGPU, but it is tied to specific hardware, fixed profiles and some architectural limitations:

• Only available on certain GPUs: MIG is not supported by every NVIDIA GPU. In particular, consumer GPUs and many older workstation cards do not offer this feature. MIG is available only on selected data centre and newer professional GPUs.
• Fixed profile sizes: The division cannot be chosen with arbitrary granularity. Administrators 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.
• Reconfiguration only partially dynamic: MIG instances can be managed and recreated, but changes to the partitioning require that the affected instances are not in active use. Enabling MIG mode may additionally require a GPU reset, depending on the GPU generation and platform.
• No bursting across profile boundaries: A MIG instance can only use the resources assigned to its profile. Free capacity from another instance is not automatically available to it.
• Limited communication 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 restricted as well: since NCCL 2.31, there is experimental 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 distributed 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 performance of an entire GPU required?
• Do workloads or tenants need reliable isolation from each other?
• Should a GPU be shared as efficiently as possible between multiple VMs or users?

As a rule of thumb:

• Maximum performance for a single VM: GPU passthrough
• Many parallel users with moderate GPU requirements: vGPU
• Several AI, inference or HPC workloads with predictable performance: MIG or MIG-backed vGPU

When is GPU passthrough suitable?

GPU passthrough is particularly suitable when a single VM requires the full performance of a physical GPU. Typical examples include:

• High-end workstations
• GPU-intensive rendering
• CAD and CAE applications
• Individual training jobs that fully utilise a single GPU

In these scenarios, performance is the main priority, while sharing plays no role or only a minor one.

The downside is that the GPU is tied exclusively 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 performance. This is often the case with:

• Virtual desktops
• Knowledge worker environments
• Technical workstations with moderate graphics requirements or light AI inference

vGPU increases tenant density and improves the utilisation of expensive GPU hardware. Its main advantage is flexibility: multiple VMs can use the same physical GPU. The downside is that, in classic vGPU configurations, compute resources are shared through time-slicing. Under high concurrent load, this can lead to competition for GPU time. Schedulers such as Equal Share or Fixed Share can help manage resource allocation, but they do not provide complete hardware isolation.

When is Multi-Instance GPU suitable?

Multi-Instance GPU (MIG) is particularly interesting when several workloads need to run on a single GPU while still requiring fixed and predictable resources. Typical use cases include:

• Multi-tenant AI inference
• Development and test environments for multiple teams
• Smaller training sandboxes
• Cloud offerings with guaranteed GPU profiles

MIG partitions supported NVIDIA GPUs at the hardware level. Each instance receives statically assigned compute and memory resources. This allows workloads to be separated more effectively than with classic time-slicing. MIG is therefore particularly suitable for environments where both high utilisation and strong isolation are essential.

In virtualised environments, MIG can also be combined with GPU virtualisation. With MIG-backed vGPU, the hardware partitions created by MIG are assigned to VMs. This combines fixed GPU profiles with a virtualised operating model.