Multi-Instance GPU (MIG) is a hardware-level partitioning capability available on NVIDIA architectures starting with the A100. It allows a single physical GPU to be securely divided into up to seven separate GPU Instances, each appearing to software as an independent, smaller GPU with its own dedicated high-bandwidth memory, streaming multiprocessors, and L2 cache slices. This is achieved through a combination of on-die crossbar partitioning and memory controller isolation, ensuring strict fault isolation and quality-of-service guarantees between instances.
Glossary
Multi-Instance GPU (MIG)

What is Multi-Instance GPU (MIG)?
Multi-Instance GPU (MIG) is a hardware virtualization feature that partitions a single physical NVIDIA data center GPU into multiple isolated, fully independent GPU instances with dedicated compute, memory, and cache resources.
MIG is fundamentally distinct from software-based time-slicing or Multi-Process Service (MPS) because the isolation is enforced entirely in hardware. Each instance has its own memory path, error correction domain, and control plane, meaning a cache thrash or memory error in one instance cannot impact another. This makes MIG ideal for GPU bin packing in cloud and enterprise environments, where multiple smaller inference, training, or rendering workloads must run concurrently on shared hardware without resource contention or security boundary violations.
Key Features of MIG
Multi-Instance GPU (MIG) is a hardware-based partitioning feature that allows a single physical NVIDIA data center GPU to be securely divided into multiple isolated, smaller GPU instances. Each instance operates with its own dedicated compute, memory, and cache resources, enabling concurrent workload execution with guaranteed quality of service.
Hardware-Level Isolation
MIG partitions a single physical GPU into up to seven independent instances at the hardware level, not through software virtualization. Each instance receives dedicated streaming multiprocessors (SMs), GPU memory slices, and L2 cache partitions. This physical separation ensures that workloads running on different instances cannot interfere with each other—a fault or memory leak in one instance has zero impact on others. Unlike time-slicing or process-level isolation, MIG provides deterministic latency and throughput for each partition, making it suitable for multi-tenant environments where strict SLAs must be enforced.
Flexible Instance Profiles
MIG supports configurable instance profiles that define the exact fraction of GPU resources allocated to each partition. On an NVIDIA A100 40GB GPU, available profiles range from a 1g.5gb slice (1/7th of compute, 5GB memory) to a 7g.40gb full-GPU instance. Administrators can mix and match profiles—for example, combining three 2g.10gb instances with one 1g.5gb instance on a single GPU. This granularity allows infrastructure teams to right-size GPU allocations for diverse workloads, from lightweight inference tasks to demanding training jobs, maximizing utilization without over-provisioning.
Concurrent Workload Execution
Each MIG instance presents as a fully independent CUDA-capable GPU to the host operating system and applications. This means multiple users, containers, or Kubernetes pods can simultaneously execute different workloads on the same physical GPU without any awareness of each other. A data science team can run a training job on a 4g.20gb instance while the production serving layer handles inference requests on two separate 1g.5gb instances—all on a single A100. This concurrency dramatically improves GPU utilization in shared clusters, reducing idle time and lowering the total cost of ownership for on-premises deployments.
Quality of Service Guarantees
MIG enforces strict resource boundaries at the hardware level, providing predictable performance for each instance. Key QoS mechanisms include:
- Dedicated memory bandwidth: Each instance has guaranteed DRAM bandwidth allocation, preventing noisy-neighbor memory contention
- Isolated error handling: ECC errors or page faults in one instance are contained and reported only to that instance
- Independent GPU reset: A single instance can be reset without affecting others, enabling rapid recovery from hung workloads This deterministic behavior is critical for production AI services where latency percentiles must remain stable regardless of co-located workloads.
Supported GPU Architectures
MIG is available on NVIDIA GPUs based on the Ampere architecture and newer, including:
- NVIDIA A100: Up to 7 MIG instances (40GB and 80GB variants)
- NVIDIA A30: Up to 4 MIG instances (24GB)
- NVIDIA H100: Up to 7 MIG instances with second-generation MIG enhancements
- NVIDIA H200: Extended MIG capabilities with larger HBM3e memory pools
The feature is exclusive to data center GPUs and is not available on consumer-grade GeForce or professional RTX/Quadro cards. MIG must be explicitly enabled via
nvidia-smior the GPU Operator before instances can be created.
MIG vs. GPU Virtualization vs. Time-Slicing
A technical comparison of hardware partitioning, virtual GPU abstraction, and temporal multiplexing for concurrent workload isolation on NVIDIA data center accelerators.
| Feature | Multi-Instance GPU (MIG) | GPU Virtualization (vGPU) | Time-Slicing |
|---|---|---|---|
Isolation Mechanism | Hardware-level electrical isolation via SM and memory partitioning | Hypervisor-mediated virtual GPU with driver-level separation | Software scheduler interleaving processes at context-switch boundaries |
Fault Containment | Complete; a fault in one instance cannot propagate to others | Partial; driver crash may affect all virtual functions on the physical GPU | None; a misbehaving process can corrupt shared GPU state |
Memory Bandwidth QoS | Dedicated HBM partitions with guaranteed bandwidth per instance | Configurable rate limiting via vGPU manager profiles | Best-effort; contention degrades all concurrent workloads |
Security Boundary | Physical address space isolation enforced by GPU memory management unit | Logical separation enforced by hypervisor; vulnerable to side-channel attacks | No security boundary; processes share the same GPU context |
Supported GPU Architectures | NVIDIA A100, A30, H100, H200 (Ampere and Hopper only) | Most NVIDIA data center GPUs (T4, V100, A100, H100, L40S) | All NVIDIA GPUs with compatible driver |
Instance Granularity | Fixed profiles: 1g.5gb to 7g.80gb on A100; 1g.10gb to 7g.80gb on H100 | Fractional frame buffer allocation with configurable display heads | Arbitrary; scheduler allocates time quantum per process |
Concurrent Workload Limit | Up to 7 isolated instances per A100/H100 GPU | Up to 16 virtual GPUs per physical GPU (profile-dependent) | Theoretically unlimited; bounded by scheduler overhead and memory |
Overhead | Negligible; hardware-native partitioning with zero hypervisor tax | 5-10% performance overhead from driver virtualization layer | Context-switch latency proportional to GPU state size |
Frequently Asked Questions
Addressing the most common technical questions about NVIDIA's Multi-Instance GPU technology for secure hardware partitioning and workload isolation in enterprise AI infrastructure.
Multi-Instance GPU (MIG) is a hardware-based partitioning feature available on NVIDIA data center GPUs (starting with the A100 architecture) that allows a single physical GPU to be securely divided into multiple isolated, smaller GPU instances, each with its own dedicated compute cores, memory, cache, and memory bandwidth. Unlike software virtualization, MIG operates at the silicon level: the GPU's Streaming Multiprocessors (SMs) and High Bandwidth Memory (HBM) are physically partitioned into separate instances. Each MIG instance presents as a fully independent CUDA-capable device to the operating system, with hardware-enforced fault isolation ensuring that a workload crash or memory error in one instance cannot affect others. The GPU's internal crossbar switch and memory controllers are configured to dedicate specific L2 cache slices and DRAM partitions to each instance, eliminating noisy-neighbor interference. This enables concurrent execution of diverse workloads—such as inference, training, and streaming analytics—on a single physical GPU with guaranteed Quality of Service (QoS).
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Key technologies and concepts that interact with or are foundational to understanding Multi-Instance GPU partitioning in modern AI infrastructure.
GPU Bin Packing
The scheduling strategy of efficiently placing multiple containerized GPU workloads onto a single physical GPU or node. MIG provides the hardware-level isolation that makes bin packing deterministic and secure, allowing a scheduler to allocate precisely sized GPU slices to different jobs without resource contention. This maximizes utilization and minimizes costly GPU fragmentation in shared clusters.
GPU Operator
A Kubernetes operator by NVIDIA that automates the lifecycle management of GPU software components. For MIG, the GPU Operator is critical as it can programmatically configure and manage MIG partitions across a cluster. It handles the complex device plugin logic required to expose individual MIG instances as schedulable resources to Kubernetes, abstracting the underlying hardware configuration.
NVIDIA Multi-Process Service (MPS)
An alternative, software-based technology for sharing a GPU among multiple processes. Unlike MIG, MPS does not provide hardware-level fault isolation or dedicated memory partitions. A crash in one MPS client can affect others. MIG is the superior choice for multi-tenant environments requiring guaranteed Quality of Service and security, while MPS is suited for cooperative processes from a single user.
Confidential GPU
A GPU implementing a hardware-based Trusted Execution Environment (TEE) to encrypt data in use. When combined with MIG, confidential computing extends the isolation model. Each MIG instance can be treated as a separate trust domain, ensuring that even the hypervisor or infrastructure owner cannot access the data or models running within a specific, encrypted GPU slice.
CUDA Streams
A software abstraction within the CUDA programming model that allows for concurrent execution of operations on a single GPU. While MIG partitions the hardware into isolated instances, CUDA streams manage concurrency within a single instance or a non-partitioned GPU. They are a complementary mechanism for maximizing utilization through overlapping kernel execution and data transfers.
NVIDIA Container Toolkit
A utility that enables containers to leverage NVIDIA GPUs. For MIG, the toolkit's runtime must be configured to request specific MIG devices. This is done by specifying the exact MIG UUID or using resource labels in the container request, ensuring a container is bound to a precise, isolated GPU partition rather than the entire physical GPU.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us