September 11, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
MIG: Partition NVIDIA GPUs is how you turn one expensive datacenter card into several isolated GPU slices. A single idle A100 wastes money fast when three teams share one node. Multi-Instance GPU (MIG) fixes that by carving fixed hardware partitions with their own memory, compute engines, and bandwidth. If you run inference, batch jobs, or tenant workloads on shared clusters, this guide covers the commands, profiles, and production traps I watch for on real deployments.
Start with our GPU basics for AI developers if MIG terminology feels unfamiliar. The rest assumes Linux, a supported NVIDIA datacenter GPU, and driver 535 or newer on the host.
Quick answer: MIG: Partition NVIDIA GPUs by enabling MIG mode on supported A100/H100 cards, creating GPU instances from fixed profiles with nvidia-smi, then assigning containers or Kubernetes pods to each slice via the NVIDIA device plugin.
What Is MIG and When Should You Use It to Partition NVIDIA GPUs?
MIG stands for Multi-Instance GPU. NVIDIA built it for Ampere datacenter GPUs and extended it on Hopper. Each MIG instance behaves like a smaller standalone GPU. Tenants cannot read each other's VRAM. Scheduler faults stay inside the slice.
You get hard isolation, not soft sharing. That differs from time-slicing or MPS, where workloads interleave on the same memory space. MIG trades flexibility for predictability. Profile sizes are fixed. You cannot resize a running instance without destroying and recreating it.
MIG fits these cases well:
- Multi-tenant SaaS inference where each customer needs a guaranteed slice
- Platform teams packing many small models on one physical card
- Development clusters where several engineers need GPU access without queue wars
- Cost control when a full 80 GB GPU is overkill for 7B-parameter models
Skip MIG when you need one job to use the entire GPU dynamically. Training large models, video rendering, and bursty workloads that spike VRAM usually want the whole device. For those cases, see rent vs buy GPUs for AI workloads before you commit to hardware.
Which NVIDIA GPUs Support MIG Partitioning?
Not every NVIDIA card supports MIG. Consumer GeForce and most RTX workstation cards do not. You need datacenter SKUs with the MIG hardware block enabled.
| GPU Family | MIG Support | Typical Use | Max Instances (approx.) |
|---|---|---|---|
| NVIDIA A100 (40/80 GB) | Yes | Inference, fine-tuning | Up to 7 on 80 GB |
| NVIDIA H100 (80 GB) | Yes | LLM inference, HPC | Up to 7 on PCIe/SXM |
| NVIDIA A30 | Yes | Edge inference | Up to 4 |
| NVIDIA H200 | Yes | Large-model serving | Profile-dependent |
| RTX 4090 / L40S | No | Local dev only | N/A |
| Time-slicing (K8s) | Software share | Dev clusters | Many logical slots |
Cloud providers expose MIG on select instance types. Always confirm the SKU before you design tenancy around fixed profiles. On bare metal you control the full stack through Linux system administration and driver pinning.
Driver and firmware requirements
Install a recent datacenter driver on the host. NVIDIA documents MIG under the datacenter driver branch. Pair it with a matching CUDA toolkit inside containers only if your app needs it. The host driver matters most.
Verify the GPU is visible and MIG-capable:
nvidia-smi -q | grep -i "MIG Mode"
nvidia-smi -q | grep -i "Product Name"If MIG Mode shows Disabled and the SKU is supported, you can proceed. If the field is absent, the card likely does not support MIG.
How Do You Enable MIG Mode and Create GPU Instances?
Enabling MIG is a host-level change. Running workloads must stop first. The GPU enters a configuration state where you define GPU instances (GIs) and optional compute instances (CIs).
Step 1: Enable MIG mode on the GPU
- Drain or stop all processes using the GPU.
- Enable MIG mode on GPU index 0:
sudo nvidia-smi -i 0 -mig 1Confirm the change:
nvidia-smi -L
nvidia-smi mig -lgipThe second command lists supported GPU instance profiles for that device. Profile names encode size, like 1g.10gb or 3g.40gb.
Step 2: Create GPU instances from profiles
List available profiles, then create instances. Example for an A100 80 GB with two 3g.40gb slices:
nvidia-smi mig -lgip
sudo nvidia-smi mig -cgi 9,9 -C
sudo nvidia-smi mig -lgiProfile IDs vary by SKU and driver version. Always read -lgip output on your host. Do not copy IDs from a blog post blindly.
Destroy instances when rebalancing:
sudo nvidia-smi mig -dgi -gi 0,1
sudo nvidia-smi -i 0 -mig 0Disabling MIG removes all instances. Plan maintenance windows accordingly.
Step 3: Optional compute instances
Compute instances (CIs) subdivide a GPU instance further. Most inference stacks use GPU instances alone. CIs help when you need finer SM partitioning inside one GI.
nvidia-smi mig -lcip
sudo nvidia-smi mig -cci 19,19,19,19 -gi 0Again, profile numbers are device-specific. Treat NVIDIA's MIG user guide as the source of truth for your exact card.
How Do MIG Profiles Compare for Real AI Workloads?
Profile choice is the main capacity-planning decision. You cannot grow a slice later. Pick sizes that match model VRAM plus KV-cache headroom.
Rough sizing guidance for 2026 inference stacks:
- 1g.5gb / 1g.10gb: Small classifiers, embedding models, lightweight NLP
- 2g.20gb: 7B–13B models at moderate context with quantisation
- 3g.40gb: 30B–40B models or 7B at long context without aggressive quant
- 7g.80gb (full card): Single large tenant or training job
These numbers shift with quantisation format and batch size. Validate with your actual model weights before you lock profiles in production.
For cost math on shared infrastructure, pair this with AI rate limits and cost optimization. MIG often pays back when utilisation would otherwise sit below 30% on whole-GPU allocation.
How Do You Run Containers and Kubernetes Pods on MIG Slices?
Containers see a MIG device as a normal GPU with a shorter UUID. The NVIDIA Container Toolkit for Docker GPU passes the correct device node when you set environment variables.
Docker example
List MIG device UUIDs:
nvidia-smi -LRun a container bound to one MIG instance:
docker run --rm -it \
--gpus '"device=MIG-GPU-abc12345-0-0"' \
nvcr.io/nvidia/cuda:12.6.0-base-ubuntu22.04 \
nvidia-smiReplace the UUID with output from your host. A common mistake is requesting device=0, which grabs the parent GPU and fails when MIG mode is active.
Kubernetes with the NVIDIA device plugin
Production teams usually schedule MIG workloads on Kubernetes. Enable MIG on nodes, configure the NVIDIA GPU Operator or device plugin with MIG strategy, and expose resources like nvidia.com/mig-1g.10gb.
Example pod fragment requesting one 1g.10gb slice:
resources:
limits:
nvidia.com/mig-1g.10gb: 1Node labels help pin inference pools separately from training nodes. Read the full pattern in run AI/ML workloads on Kubernetes with GPUs.
Monitor per-slice utilisation with DCGM exporters. Wire alerts through patterns like Prometheus Alertmanager alerting. Idle MIG slices still cost money even when labelled free.
What Production Mistakes Break MIG GPU Partitions?
MIG is stable when configured once and left alone. It breaks when teams treat slices like elastic cloud volumes.
Profile fragmentation
Mixing many small profiles can leave unusable gaps on the GPU. Plan the partition layout like disk partitioning. Draw it on paper first. Recreating instances requires downtime.
Driver upgrades without a runbook
Driver updates sometimes reset MIG mode or change profile IDs. Automate post-upgrade checks in your support and maintenance playbook. Confirm -lgip output before you declare the node ready.
Wrong resource requests in CI
Integration tests that request nvidia.com/gpu: 1 on MIG nodes will pend forever. Align Helm charts and CI manifests with MIG resource names. Validate JSON pod specs with the JSON formatter tool before you apply them.
Security assumptions
MIG isolates memory and engines at the hardware level. It does not replace network policy, secrets management, or API auth. Treat each slice as a separate tenant boundary in your enterprise application design. Pair GPU isolation with standard app-layer controls.
On platforms I have integrated LLM APIs into, the GPU layer is rarely the only trust boundary. Document what MIG does and does not guarantee for compliance reviewers.
Observability gaps
Standard nvidia-smi on the host shows parent and child devices. Inside containers, verify the pod sees one device with expected memory. Mismatch often means the wrong UUID was injected.
For broader ops context, see AIOps explained for modern infrastructure. GPU scheduling is one slice of the full stack.
Key Takeaways
- MIG: Partition NVIDIA GPUs only on supported datacenter SKUs (A100, H100, A30) with recent drivers and a planned maintenance window.
- Pick GPU instance profiles from
nvidia-smi mig -lgipbased on model VRAM, not guesswork from blog examples. - Bind Docker containers and Kubernetes pods to MIG UUIDs or
nvidia.com/mig-*resources, never the parent GPU index. - Use MIG for multi-tenant inference isolation; use full GPUs for large training jobs that need elastic VRAM.
- Automate post-driver-upgrade MIG checks and monitor per-slice utilisation so idle partitions do not silently burn budget.
- Combine hardware isolation with normal app security—MIG is not a substitute for auth, network policy, or secrets control.
People Also Ask
Can you run MIG on GeForce or RTX cards?
No. MIG requires datacenter GPUs with dedicated MIG hardware. GeForce and most RTX cards support neither MIG mode nor GPU instance profiles. Use time-slicing or separate cards for development instead.
Does MIG reduce performance compared to a full GPU?
Each slice gets a fixed share of SMs and memory bandwidth. A 1g.10gb instance will not match full-card throughput for one job. Total throughput across all slices often beats a single underutilised full GPU in multi-tenant inference.
Can you change MIG profile sizes without downtime?
No. Changing the partition layout requires destroying existing GPU instances. Drain workloads, delete instances, recreate with new profiles, then reschedule pods. Treat layout changes as planned maintenance.
How does MIG relate to Kubernetes GPU sharing?
Kubernetes can expose MIG profiles as distinct extended resources through the NVIDIA device plugin. Time-slicing is a separate software mechanism that oversubscribes whole GPUs. MIG gives hard isolation; time-slicing gives higher density with softer guarantees.
Put MIG to Work on Your AI Stack
MIG: Partition NVIDIA GPUs when you need predictable, isolated slices on shared datacenter hardware. Enable MIG mode, create instances from verified profiles, and wire your orchestrator to the correct device UUIDs. That three-step loop is the core of every production layout I have seen work.
If you are building inference platforms, tenant APIs, or internal AI services and want the application layer designed alongside GPU strategy, review our AI integration and automation services. For reference on shipped systems that combine backends with operational tooling, browse the GulfBizList platform portfolio case or read about Kokil Thapa's background.
Need help sizing profiles, writing Kubernetes manifests, or hardening a multi-tenant inference deployment? Contact us with your GPU SKU, model list, and expected concurrent tenants. We will map a practical MIG layout before you buy hardware you cannot partition cleanly.
Frequently Asked Questions
MIG stands for Multi-Instance GPU. NVIDIA built it for Ampere datacenter GPUs and extended it on Hopper. Each MIG instance behaves like a smaller standalone GPU with its own memory, compute engines, and bandwidth. Tenants cannot read each other's VRAM, and scheduler faults stay inside the slice. You get hard hardware isolation, not soft sharing like time-slicing or MPS. It fits multi-tenant inference, packing many small models on one card, and cost control when a full 80 GB GPU is overkill.
MIG requires datacenter SKUs with the MIG hardware block enabled. Supported families include NVIDIA A100 in 40 GB and 80 GB variants with up to 7 instances on 80 GB, H100 80 GB with up to 7 on PCIe or SXM, A30 with up to 4 instances, and H200 with profile-dependent limits. Consumer GeForce cards and most RTX workstation models including RTX 4090 and L40S do not support MIG mode or GPU instance profiles. Always confirm the exact SKU before designing tenancy around fixed profiles.
Install a recent datacenter driver on the host. NVIDIA documents MIG under the datacenter driver branch, and this guide assumes driver 535 or newer on the host running Linux with a supported datacenter GPU.
Stop or drain all workloads using the GPU first. Enable MIG mode with sudo nvidia-smi -i 0 -mig 1, then confirm with nvidia-smi -L and nvidia-smi mig -lgip to list supported GPU instance profiles. Create instances from verified profile IDs, for example sudo nvidia-smi mig -cgi 9,9 -C followed by nvidia-smi mig -lgi on an A100 80 GB. Profile IDs vary by SKU and driver version, so always read -lgip output on your host rather than copying IDs from documentation or blog posts.
No. MIG requires datacenter GPUs with dedicated MIG hardware. GeForce and most RTX cards support neither MIG mode nor GPU instance profiles.
Use MIG for multi-tenant SaaS inference where each customer needs a guaranteed slice, platform teams packing many small models on one physical card, development clusters where several engineers need GPU access without queue wars, and cost control when a full 80 GB GPU is overkill for 7B-parameter models. Skip MIG when one job must use the entire GPU dynamically. Large model training, video rendering, and bursty workloads that spike VRAM usually want the whole device because MIG profile sizes are fixed and cannot be resized without destroying and recreating instances.
Profile choice is the main capacity-planning decision because you cannot grow a slice later. Rough 2026 guidance from the article: 1g.5gb and 1g.10gb suit small classifiers, embedding models, and lightweight NLP. A 2g.20gb slice handles 7B to 13B models at moderate context with quantisation. A 3g.40gb slice fits 30B to 40B models or 7B at long context without aggressive quantisation. A 7g.80gb profile uses the full card for a single large tenant or training job. Validate with your actual model weights and batch size before locking profiles in production.
No. Changing the partition layout requires destroying existing GPU instances, disabling MIG if needed, and recreating with new profiles before rescheduling workloads.
List MIG device UUIDs with nvidia-smi -L, then bind a container to one slice using the NVIDIA Container Toolkit. Pass the MIG UUID in the device string, for example device=MIG-GPU-abc12345-0-0, not device=0. Requesting the parent GPU index fails when MIG mode is active because the physical GPU is partitioned. Containers see a MIG device as a normal GPU with a shorter UUID and only the memory and compute assigned to that profile.
Enable MIG on cluster nodes, then configure the NVIDIA GPU Operator or device plugin with a MIG strategy so profiles appear as named extended resources like nvidia.com/mig-1g.10gb. Pods request slices in resources.limits rather than nvidia.com/gpu: 1, which will pend forever on MIG nodes. Use node labels to pin inference pools separately from training nodes. Monitor per-slice utilisation with DCGM exporters and wire alerts through Prometheus Alertmanager because idle MIG slices still cost money even when labelled free.
Each slice gets a fixed share of SMs and memory bandwidth, so a 1g.10gb instance will not match full-card throughput for a single job. That is the trade-off for predictability. Total throughput across all slices often beats one underutilised full GPU in multi-tenant inference. MIG pays back when utilisation would otherwise sit below 30 percent on whole-GPU allocation. Pick profiles that match model VRAM plus KV-cache headroom rather than assuming a slice equals proportional peak performance.
MIG carves fixed hardware partitions with dedicated memory, compute engines, and bandwidth at the hardware level. Time-slicing is a separate software mechanism that oversubscribes whole GPUs and interleaves workloads on the same memory space. MPS also shares memory rather than isolating it. MIG trades scheduling flexibility for hard isolation and predictable capacity. Kubernetes can expose MIG profiles as distinct extended resources through the NVIDIA device plugin, while time-slicing creates many logical slots on an unpartitioned GPU with softer guarantees between tenants.
Profile fragmentation is common when teams mix many small profiles and leave unusable gaps on the GPU, so plan the layout like disk partitioning before you create instances. Driver upgrades sometimes reset MIG mode or change profile IDs, so automate post-upgrade checks with nvidia-smi mig -lgip before declaring a node ready. CI manifests that request nvidia.com/gpu: 1 on MIG nodes will pend forever. Align Helm charts with MIG resource names. Observability gaps appear when containers see the wrong device or memory, often because the wrong UUID was injected instead of the MIG slice UUID from nvidia-smi -L.
MIG isolates memory and compute engines at the hardware level, so tenants cannot read each other's VRAM and scheduler faults stay inside the slice. It does not replace network policy, secrets management, or API authentication. Treat each slice as a separate tenant boundary in enterprise application design and pair GPU isolation with standard app-layer controls. Document clearly for compliance reviewers what MIG does and does not guarantee, because on platforms integrating LLM APIs the GPU layer is rarely the only trust boundary you need to enforce.
After creating GPU instances from profiles, you can optionally subdivide a GPU instance further with compute instances using nvidia-smi mig -lcip and nvidia-smi mig -cci. Compute instances provide finer SM partitioning inside one GPU instance. Most inference stacks use GPU instances alone because a GPU instance already behaves like a smaller standalone GPU with fixed memory and engines. Compute instances help when you need additional granularity within a single GPU instance rather than separate tenant boundaries at the GI level. Profile numbers remain device-specific, so verify with -lcip on your host.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
