How Many MIG Instances Can an H100 GPU Support

An NVIDIA H100 with Multi-Instance GPU (MIG) enabled can be partitioned into as many as seven isolated instances, each with guaranteed compute and memory. The maximum is easy to quote; the useful answer requires the profile table, the geometry rules that decide which mixes are valid, and the hosting condition most answers leave out, namely that MIG partitions are configured on the physical GPU by whoever operates the host. This page covers all three so the number turns into a capacity plan.

The Short Answer: Seven Instances, With Geometry Rules

An H100 with MIG enabled supports up to seven instances, reached with the 1g.10gb profile that assigns each instance one compute slice and 10 GB of the 80 GB frame buffer. The count is bounded by the slice geometry: seven compute slices and eight memory slices per GPU, so the seven-instance maximum pairs with specific memory allocations per profile rather than being freely divisible.

That is why the answer is a range in practice rather than a single number: profile choice sets the per-instance allocation, so the same GPU holds seven small development instances, two mid-size serving instances, or one full-GPU production workload. NVIDIA positions MIG for exactly this standardization play, letting infrastructure teams provision GPU resources at fixed fractions instead of negotiating ad hoc sharing.

The Profile Table and Valid Mixes

The supported-profile documentation lists 7g.80gb (full GPU), 4g.40gb, 3g.40gb (up to two), 2g.20gb (up to three), 1g.20gb (up to four), and 1g.10gb (up to seven), with memory-plus variants extending buffer at compute cost; the H100 NVL 94 GB mirrors these as 7g.94gb, 3g.47gb, 2g.24gb, and 1g.12gb. Mixes must tile the slice geometry, so a practical split such as one 3g.40gb plus four 1g.10gb works, while arbitrary combinations that ignore slice boundaries do not.

The table reads as a capacity menu rather than a free-for-all: mixes are valid when they tile the compute and memory slices without remainder, and the driver-level tooling rejects anything else. The H100 NVL 94 GB variant mirrors the set as 7g.94gb, 3g.47gb, 2g.24gb, and 1g.12gb, so fleets mixing both variants need per-SKU profile plans. Profile availability also depends on driver release; confirm against the supported-profiles page for your software version before committing a fleet plan.

Planning the Split: Workloads and the Bare-Metal Requirement

Choose profiles from the workload side: small models and dev environments fit 1g slices, mid-size serving fits 2g or 3g, and latency-critical production keeps a 4g or full GPU. Then host it where partitioning is actually allowed: MIG requires bare metal or vGPU-supported virtualization because partitions are configured on the physical GPU by the host operator, so a dedicated single-tenant server gives your team that control directly, while ordinary VM access does not.

Choose the split from the workload side, then check the hosting:

1. Size per tenant of the GPU: small models and development environments fit 1g slices; mid-size serving fits 2g or 3g; latency-critical production deserves 4g or a full GPU with guaranteed isolation.
2. Check the hosting requirement: MIG requires bare metal or vGPU-enabled virtualization, because partitions are configured on the physical GPU by the host operator; an ordinary virtual machine cannot create them.
3. Plan the reconfiguration window: changing the profile mix drains the instances, so standardize mixes per server group and schedule changes like maintenance.

That second point decides procurement more often than the profile table does. Dedicated single-tenant bare-metal capacity, such as the servers OneSource Cloud provides in secure U.S. data centers, gives your platform team direct control of partition geometry on the servers you run, instead of negotiating sharing through a virtualization layer you do not operate.

FAQ

Can you mix different MIG profile sizes on one H100?

Yes, within the slice-geometry tiling rules. A mix of one 3g.40gb plus four 1g.10gb instances is valid because three plus four compute slices tile the seven available, and two 3g.40gb instances are also a common production split. Mixes that ignore slice boundaries are rejected, and the supported-profiles page for your driver release is the authority on what tiles.

Why does MIG-based GPU sharing need bare-metal access?

MIG partitions are carved on the physical GPU by the host operator, and the feature is supported on bare metal or vGPU-enabled virtualization, not inside an ordinary VM. Single-tenant bare-metal capacity such as OneSource gives your platform team direct control of partition geometry without a virtualization layer restricting what you can configure.