How MIG works
NVIDIA MIG, short for Multi-Instance GPU, is a hardware feature that divides one GPU into several smaller, fully separate GPUs. NVIDIA introduced it with the A100 in 2020, and it is part of the Hopper and Blackwell data centre GPUs and some Blackwell professional cards.
Without MIG, several jobs sharing a GPU compete for the same cores, cache and memory bandwidth, so one heavy job can slow every other one down. MIG instead carves the GPU into slices along hardware lines. Each instance gets its own streaming multiprocessors, its own share of the L2 cache, its own memory controllers and a fixed block of memory. A fault or a memory-hungry job in one instance cannot affect the others.
To software, each instance looks like a separate GPU with its own device ID. CUDA applications run on it unchanged, and container platforms can hand out instances just as they would whole GPUs.
MIG profiles and instances
A GPU is divided into seven compute slices and a matching number of memory slices. An administrator combines them into instances using fixed profiles, named for the compute slices and memory they include.
-
//
Profile names. On an 80 GB H100, 1g.10gb is one-seventh of the GPU with 10 GB, 3g.40gb is three-sevenths with 40 GB, and 7g.80gb is the whole GPU.
-
//
Mixing sizes. Profiles can be combined on one GPU, for example one 3g.40gb instance for a larger model alongside several 1g.10gb instances for small ones, within the GPU’s placement rules.
-
//
GPU and compute instances. A GPU instance owns the memory; it can be split again into compute instances that share that memory, which suits closely related jobs.
-
//
Media engines. On Hopper, instances can include their own video and JPEG decoders, so several camera analytics pipelines can share a GPU without contending for decode.
-
//
Reconfiguration. Instances can be rebuilt while the GPU is idle, for example seven small instances for daytime inference and one large one for overnight training. Turning MIG mode on or off requires a GPU reset.
Which GPUs support MIG
MIG is limited to certain data centre and professional GPUs. The maximum number of instances, and the memory each gets, depends on the card.
| GPU | Architecture | Max instances | Smallest instance memory |
|---|---|---|---|
| A100 80 GB | Ampere | 7 | 10 GB |
| A30 | Ampere | 4 | 6 GB |
| H100 PCIe 80 GB | Hopper | 7 | 10 GB |
| H100 NVL | Hopper | 7 | 12 GB |
| H200 NVL | Hopper | 7 | 16.5 GB |
| RTX PRO 6000 Blackwell Server Edition | Blackwell | 4 | 24 GB |
| RTX PRO 5000 Blackwell 48 GB | Blackwell | 2 | 24 GB |
| RTX PRO 4500 Blackwell Server Edition | Blackwell | 2 | 16 GB |
| L4, L40, L40S | Ada Lovelace | Not supported | Not supported |
Among the cards we list, the H100 PCIe card and the H200 NVL card divide into up to seven instances. The RTX PRO 6000 Blackwell Server Edition splits into four 24 GB instances, and the RTX PRO 4500 Blackwell Server Edition into two of 16 GB. Some cards from the same family, such as the RTX PRO 4000 and 4500 workstation cards, do not list MIG, so check the datasheet for the exact model.
MIG vs time-slicing vs vGPU
MIG is one of three common ways to share a GPU, and they solve different problems.
-
//
Time-slicing. Jobs take turns on the whole GPU. It works on almost any NVIDIA GPU and needs no partitioning, but there is no memory isolation and performance varies with what else is running.
-
//
MIG. Hardware partitions with dedicated resources and predictable performance. Instance sizes are fixed by the profiles, and compute workloads are the main use.
-
//
NVIDIA vGPU. Software that shares a GPU between virtual machines, often for virtual desktops. It can run on top of MIG on supported GPUs, combining virtual machines with hardware isolation.
Where MIG is useful
MIG pays off wherever a large GPU would otherwise sit partly idle running one small job. Typical uses include serving several AI inference models from one card, giving developers or students their own isolated GPU, running many video analytics streams on an on-premises server, and consolidating mixed workloads onto fewer data centre GPUs to save power and rack space.
It is less useful when one job needs the whole GPU, or when GPUs must work together over NVLink, because MIG instances do not communicate with each other directly.
Setting up MIG
MIG is configured from the host with NVIDIA’s standard tools, and the steps are the same on every supported GPU. An administrator first enables MIG mode on the GPU with nvidia-smi, which needs the GPU to be idle and reset. GPU instances are then created from the chosen profiles, followed by compute instances inside them.
MIG mode stays set across reboots, but the instances themselves do not, so most sites define it in a configuration file and apply it at boot with NVIDIA’s MIG partition editor. NVIDIA’s Data Center GPU Manager (DCGM) reports utilisation, memory and errors for each instance, so each workload can be monitored separately.
Quick answers on NVIDIA MIG
These are the questions people most often ask before relying on MIG.
NVIDIA MIG: common questions
Does the L40S support MIG?
No. The L40S, L40 and L4 do not support Multi-Instance GPU. They can be shared through time-slicing or vGPU instead.
Does the H200 support MIG?
Yes. The H200 divides into up to seven instances, with about 16.5 GB each on the H200 NVL and 18 GB each on the SXM version.
How many MIG instances can a GPU have?
Up to seven. The A100, H100 and H200 support seven; the A30 and some Blackwell professional cards support two or four.
Is MIG the same as vGPU?
No. MIG partitions the GPU in hardware. vGPU is software for sharing a GPU between virtual machines, and the two can be used together.
Does MIG work with Kubernetes?
Yes. NVIDIA’s GPU Operator and device plugin expose MIG instances as schedulable resources, so pods can request a specific instance size.
We fit MIG-capable GPUs in the servers we build as standard, with the drivers installed and MIG profiles set up to suit your workloads before the system ships.