NVIDIA Multi-Instance GPU (MIG) Explained: Profiles, Slice Sizes and Allocation Tradeoffs

NVIDIA Multi-Instance GPU (MIG) partitions a physical GPU into smaller instances with dedicated compute, memory and cache resources. Supported GPUs can provide up to seven instances, allowing independent workloads to share an accelerator without competing for the same assigned compute and memory resources.

The allocation decision is not simply how many instances to create. More instances may leave memory unused, while larger profiles may better fit a workload's memory and compute requirements.

How Does NVIDIA MIG Partition a GPU?

MIG divides GPU resources into predefined hardware partitions. NVIDIA defines five partitioning units:

1. GPU memory slice: A partition of GPU memory, memory controllers and cache.
2. GPU SM slice: A partition of streaming multiprocessors (SMs), which execute compute instructions.
3. GPU slice: A combination of memory and SM slices.
4. GPU instance (GI): One or more GPU slices, with dedicated memory resources and associated hardware engines.
5. Compute instance (CI): A subdivision of a GPU instance's compute resources. CIs have dedicated SM resources but share their parent GI's memory and engines.

On GPUs such as the A100, H100 and B200, a memory slice represents approximately one eighth of GPU memory, and an SM slice approximately one seventh of SM capacity in MIG mode. Other MIG-capable GPUs use different proportions, as NVIDIA's MIG User Guide explains.

Supported partition sizes are defined by MIG profiles, typically written [compute slices]g.[memory capacity]gb. For example, an A100-40GB 1g.5gb instance provides one SM slice and 5 GB of memory. The ratio of compute to memory slices varies by profile; operators cannot choose arbitrary combinations.

Which NVIDIA GPUs Support MIG?

Selected NVIDIA Ampere, Hopper and Blackwell GPUs support MIG. Each model provides a specific set of profiles listed in NVIDIA's Supported MIG Profiles reference.

Profile names omit the `MIG` prefix. Consult NVIDIA's reference for all variants and placement restrictions.

The maximum instance count varies: seven for the listed A100, H100, H200, B200 and GB300 models; four for A30 and RTX PRO 6000 Blackwell; and two for RTX PRO 5000 and 4500 Blackwell.

Profile suffixes identify additional hardware capabilities:

• +me: Media engines such as NVDEC, NVENC, NVJPG or OFA.
• +gfx: Graphics API support on compatible Blackwell profiles.
• +me.all: All available media engines, without graphics API support.
• -me: Media engines excluded.

Other supported configurations include certain H100 and GH200 variants and NVIDIA Thor. Thor uses unified CPU/GPU memory rather than dedicated GPU memory, so its MIG profiles report 0 GB of dedicated GPU memory. It supports at most two simultaneous instances. GPU support, available profiles and minimum driver versions must be checked together.

How Many MIG Instances Can an A100-40GB Create?

An A100-40GB provides eight 5 GB memory slices and seven SM slices in MIG mode. Two supported configurations illustrate the tradeoff.

Seven Small Instances

Seven 1g.5gb instances use all seven SM slices but only 35 GB of memory:

• SM allocation: 7/7 slices.
• Memory allocation: 7 × 5 GB = 35 GB.
• Unused memory: 5 GB, which cannot form an eighth instance because no SM slice remains.

Two Larger Instances

One 4g.20gb and one 3g.20gb instance use all SM and memory slices (supported with driver R510 or later):

• SM allocation: (4 + 3)/7 = 7/7 slices.
• Memory allocation: (4 + 4)/8 × 5 GB = 40 GB.

A mixed configuration—two 1g.5gb, one 2g.10gb and one 3g.20gb—also uses all available memory and SM slices, producing four instances per GPU. Across eight A100s, that becomes 32 instances: 16 small, eight medium and eight large.

Maximizing instance count does not necessarily maximize allocated memory.

Why Does Placement Order Matter?

MIG instances occupy specific physical locations. A requested combination can fail even when its total slices fit. NVIDIA documents placement dependencies for a 3g + 2g + 1g + 1g A100 layout: creating larger instances first can avoid conflicts. Operators must validate supported layouts, not just add up compute and memory slices.

MIG vs Time-Slicing vs MPS: What's the Difference?

All three mechanisms share a GPU, but their resource guarantees differ.

MIG assigns dedicated hardware resources to each GPU instance. Time-slicing exposes multiple logical allocations that share the same physical GPU; adding replicas does not add compute capacity. NVIDIA's GPU Operator documentation also notes that DCGM-Exporter cannot attribute GPU metrics to individual containers when time-slicing is enabled.

CUDA Multi-Process Service (MPS) allows CUDA processes to execute concurrently on shared GPU resources, optionally limiting each client's SM allocation. MPS supports up to 48 clients, with lower limits in smaller MIG compute instances.

MIG and time-slicing can be combined, but workloads time-sharing one MIG instance still share that instance's memory and fault-isolation boundary. Choose MIG for dedicated compute and memory; consider time-slicing or MPS when those guarantees are unnecessary.

What Are MIG's Main Scheduling Tradeoffs?

Fragmentation and Reconfiguration

Fixed instance placement can leave resources unusable for a requested profile. Changing the layout may require stopping or moving workloads.

• Ampere (A100 and A30): Enabling MIG mode requires a GPU reset; the mode setting persists across reboots.
• Hopper and later: MIG mode can be enabled without a GPU reset, but the setting does not persist across reboots or driver unloads.

GPU and compute instances must be recreated after a reset or reboot. NVIDIA's MIG Partition Editor (mig-parted) can automate the process.

For example, an operator could run seven small inference instances during the day and reconfigure the A100 into a larger instance at night. That flexibility comes with workload interruption and scheduler coordination.

Kubernetes Scheduling and Node Pools

NVIDIA's Kubernetes device plugin offers two MIG strategies:

• Single: Exposes MIG devices as equivalent nvidia.com/gpu resources.
• Mixed: Exposes profile-specific resources such as nvidia.com/mig-1g.5gb, allowing workloads to request a particular size.

Managed services impose additional constraints. On Google Kubernetes Engine (GKE), a pod can consume at most one MIG instance, and GPUs in a Standard node pool must use the same partition layout. GKE Autopilot can provision appropriately partitioned nodes. On Azure Kubernetes Service (AKS), changing a node pool's MIG profile requires creating a new node pool.

Multiple node pools may be needed for different profiles. MIG also does not replace the host and orchestration controls discussed in Zettabyte's guide to Kubernetes GPU tenant isolation.

Which Workloads Are Suitable for MIG?

MIG best suits independent jobs that fit within a supported partition, including smaller inference services, development environments and compute tasks. Six restrictions affect compatibility:

1. Distributed training and NCCL: NCCL 2.31 introduced experimental support for multiple MIG instances. It requires a CUDA 13.0-compatible driver, separate MIG instances for each rank and disabled Multi-Node NVLink. NVLink SHARP is unsupported; large-scale configurations need validation.
2. CUDA Inter-Process Communication (IPC): CUDA IPC works between compute instances within one GPU instance, but not between separate GPU instances. Driver R570 introduced P2P support between MIG instances on the same physical GPU, not across different GPUs.
3. Graphics: Most MIG configurations do not support OpenGL or Vulkan; compatible RTX PRO Blackwell +gfx profiles are exceptions.
4. Metrics: Managed platforms may omit per-instance metrics. GKE, for example, does not expose certain duty-cycle metrics for MIG GPUs.
5. Profiling: Some profilers cannot inspect shared resources while MIG is enabled; such jobs may need an unpartitioned GPU.
6. Media processing: Encoding and decoding require profiles with the necessary NVENC, NVDEC or other media engines.

These restrictions are especially relevant to distributed training, GPU-level observability and video workloads. Validate driver, CUDA, communication and monitoring requirements before assigning a workload to MIG.

Is MIG Secure Enough for Multi-Tenant Clusters?

MIG isolates allocated GPU compute and memory resources, but it is not a complete security boundary for mutually untrusted tenants. Host software, drivers and orchestration components can remain shared. Google's GKE documentation, for example, advises against MIG partitions for untrusted workloads on its platform.

Security assessments should cover four layers: GPU hardware isolation; host and driver access; Kubernetes permissions, runtime and placement policies; and any additional VM or hypervisor boundary. Zettabyte's GPU isolation for multi-tenant AI discusses these decisions in more detail.

How Can MIG Be Deployed?

Containers on bare metal may suit workloads in one trust domain. Separate VMs can add isolation where tenants do not trust each other. For the distinctions, see MIG vs vGPU: How to Split a GPU Between Multiple VMs.

How Should Operators Choose a MIG Configuration?

Start with workload requirements, not the maximum instance count:

1. Memory and compute: Pick profiles that fit each workload.
2. Utilization: Account for stranded memory and SM capacity.
3. Compatibility: Check NCCL, CUDA IPC, graphics, profiling and media engines.
4. Scheduling: Plan supported layouts, node pools and reconfiguration downtime.
5. Isolation: Evaluate whether MIG plus host controls is sufficient or VMs are needed.

The best configuration uses the GPU efficiently without compromising workload compatibility, scheduling flexibility or tenant isolation.