What MIG Is: Hardware Partitioning Explained, and What It Does and Does Not Guarantee
For executives
Multi-Instance GPU (MIG) is NVIDIA's technology for partitioning a single A100 or H100 into multiple isolated GPU instances, each with dedicated compute resources, memory, and cache. MIG is the strongest isolation mechanism available on NVIDIA data centre GPUs — stronger than time-slicing (which provides no isolation) and stronger than vGPU (which is software-isolated). But strong is not the same as absolute. This article explains what MIG isolation provides and where its limits are.
Why MIG was created
Before MIG, the options for sharing an expensive GPU between multiple users were time-slicing (no isolation, no guaranteed resource allocation) and vGPU (software virtualisation with the vGPU Manager as trust boundary). MIG addresses both limitations with hardware partitioning.
How MIG partitions a GPU
An H100 GPU contains 132 streaming multiprocessors (SMs). MIG divides these SMs into GPU Instances (GIs). Each GPU Instance has: a fixed allocation of SMs, a fixed allocation of HBM memory, a dedicated slice of the L2 cache, and a dedicated memory controller partition.
The hardware enforces these boundaries. A CUDA context in one MIG partition cannot schedule work on another partition's SMs. It cannot access another partition's HBM memory via the normal memory address space. The L2 cache slices do not overlap.
MIG isolation profiles
An H100 supports different MIG profiles:
1g.10gb: 1/7 of the GPU (19 SMs, 10GB HBM). Up to 7 partitions. 2g.20gb: 2/7 of the GPU. Up to 3 partitions. 3g.40gb: 3/7 of the GPU. Up to 2 partitions. 7g.80gb: the full GPU as a single partition.
What MIG does guarantee
Compute isolation: code running in partition A cannot schedule work on partition B's SMs. Hardware enforced.
Memory isolation: code in partition A cannot read or write partition B's HBM memory through normal CUDA memory addressing. Hardware enforced at the memory controller level.
Cache isolation: each partition has a dedicated L2 cache slice that does not overlap with other partitions' slices. This eliminates the L2 cache side-channel that exists on non-MIG GPUs.
What MIG does not guarantee
Complete side-channel elimination: MIG partitions share the PCIe bus to the host CPU. Bandwidth utilisation patterns on the PCIe bus are shared across all MIG partitions, creating a potential bandwidth side-channel. Research on NVLink fabric suggests shared interconnect resources may also provide side-channel opportunities.
Inter-partition isolation after session end: VRAM within a MIG partition is not automatically cleared when one user's session ends and a new user begins. The HBM memory used by User A's partition is not zeroed before User B gets access to the same partition.
Container-to-partition mapping verification: MIG assigns partitions to containers via the GPU Operator's MIG Manager. The mapping between which container runs on which MIG partition is managed in software. Software misconfigurations, misassignments, or deliberate mismapping are not prevented by MIG's hardware isolation.
Kernel-level bypass: an attacker who achieves kernel-level code execution on the host operates at the level of the driver's memory management structures. Kernel-level access bypasses MIG hardware isolation by manipulating the driver structures that enforce it.