MIG Explained: Partitioning A100 and H100 GPUs for Better Utilization

A common and costly pattern in GPU infrastructure is a rack of expensive accelerators running at a fraction of their capacity because each job is too small to fill a whole GPU. Multi-Instance GPU, or MIG, is NVIDIA's answer: it lets a single data-center GPU be carved into multiple smaller, fully isolated GPUs. Used well, it can transform the economics of a mixed workload. Used blindly, it can leave performance on the table. This guide covers how it actually works.

What MIG actually does

MIG is a hardware feature on A100, H100, and H200 GPUs that partitions a single physical GPU into as many as seven instances. Each instance gets a dedicated slice of streaming multiprocessors, L2 cache, and memory, with its own paths through the memory system. The isolation is at the hardware level, so one instance cannot starve or interfere with another. To software, each instance presents as a separate GPU with predictable, guaranteed resources.

How partitioning works in practice

You configure MIG using profiles that describe how much compute and memory each instance receives. On an A100 80GB, for example, a profile like 1g.10gb yields a small instance with one compute slice and 10GB of memory, while larger profiles such as 3g.40gb give more of both. You can mix profile sizes on one card, and you reconfigure the layout without rebooting the host — so the same GPU can serve a few large jobs one day and many small ones the next.

Where MIG delivers real value

• Serving many small or mid-size inference models concurrently, each in its own guaranteed slice with no noisy-neighbor effects.
• Multi-tenant clusters where teams need hard isolation and predictable performance rather than best-effort sharing.
• Development and notebook environments that hand each user a right-sized GPU instead of a whole expensive card.
• Raising utilization on workloads that individually cannot fill an 80GB GPU, deferring or avoiding additional purchases.

The trade-offs to understand

MIG instances do not communicate over NVLink, so MIG is for partitioning, not for splitting one large model across slices — a job that needs more than one instance's resources should run on a full GPU or a multi-GPU configuration instead. A single large training run will always be faster on the whole, unpartitioned card. And because each instance is a fixed slice, you trade some peak throughput for isolation and predictability. MIG is a utilization and multi-tenancy tool, not a performance multiplier for any individual job.

MIG does not make a GPU faster. It makes a GPU fuller — and for fleets running many small jobs, fuller is exactly what your budget needs.

Plan MIG into the deployment, not after it

Whether MIG helps depends on your job mix, your scheduler, and your isolation requirements — and it should inform how many GPUs you buy in the first place. Nexus Compute configures A100, H100, and H200 systems with MIG-aware sizing for your workload, validates the partition layout under load, and ships warranty-backed hardware through authorized channels with a quote returned inside 48 business hours.