MIG: An Old Idea in New Silicon
October 24, 2026
When I first read about Multi-Instance GPU (MIG), it felt familiar. I’ve spent 21 years partitioning large physical resources into smaller, isolated environments — that’s what IBM LPARs and HPE Superdome nPartitions do. MIG is the same idea applied to a new layer: LPARs partition a server, nPartitions partition a system, and MIG partitions one GPU. I’m comparing the three because the comparison explains what MIG is, and what it isn’t.
IBM Power LPAR
I’ve carved up IBM Power servers into logical partitions (LPARs) for years. A hypervisor does the dividing: each LPAR gets CPU cores, memory and I/O adapters from the server underneath. In my diagram the four LPARs run AIX, Linux, a database and an application.
An LPAR can hold dedicated cores, or draw from shared capacity with an entitlement — capped or uncapped. I/O can be virtualized. I manage all of it through the Hardware Management Console (HMC), and I can usually tune resources while the partition keeps running. That live tuning makes LPARs the most dynamic of the three.
HPE Superdome nPartitions
On an HPE Superdome system (Superdome Flex, for example), I divide the machine into multiple nPartitions with dedicated resources. Each partition owns its CPU sockets and cores, memory and I/O domains — nothing is shared between them. The isolation comes from the hardware boundary, not from a hypervisor.
I show four partitions here: mission-critical work, a database, an application and analytics. I create, modify and remove them through HPE RMC, the Rack Management Controller. How disruptive a change is depends on the model and the configuration.
NVIDIA MIG
With MIG, I divide each GPU in a server into multiple instances with isolated compute and memory resources. There is no hypervisor — the GPU’s own hardware is cut along its slice boundaries, and each instance gets dedicated SMs, GPU memory (HBM) and a share of the copy engines and video decoders, depending on the profile.
My diagram shows one H100 split into four instances: 1g.10gb, 2g.20gb, 3g.40gb and 1g.10gb. What MIG partitions is the GPU’s compute and memory — not a full server. The PCIe link, power and clocks stay shared across the whole GPU. I manage MIG with nvidia-smi or the NVIDIA GPU Operator.
Side by side
| Aspect | IBM Power LPAR | HPE Superdome nPartitions | NVIDIA MIG |
|---|---|---|---|
| What is partitioned? | Physical IBM Power server | Physical HPE Superdome system | GPU(s) inside a server (e.g., with A100/H100) |
| Partition name | LPAR (Logical Partition) | nPartition (hard partition) | MIG (Multi-Instance GPU) |
| Main resources | CPU cores, memory, I/O adapters | CPU sockets/cores, memory, I/O domains | SMs (compute), GPU memory (HBM), copy engines, video decoders |
| Isolation mechanism | Hypervisor-based isolation | Hardware-based hard partitioning (no shared CPU, memory, or I/O) | Hardware-based isolation with quality of service (QoS) within the GPU |
| Resource allocation | Dedicated or shared (entitled/uncapped) | Dedicated (hard partitioning) | Fixed profiles (e.g., 1g.5gb, 1g.10gb, 1g.20gb, 2g.20gb, 3g.40gb, etc.) |
| Management | HMC (Hardware Management Console) | HPE RMC (Rack Management Controller) | nvidia-smi or NVIDIA GPU Operator (MIG management) |
| Typical use cases | Multiple AIX/Linux partitions, enterprise applications | Mission-critical workloads, databases, SAP, etc. | Multiple AI/ML workloads sharing a GPU |
| Granularity | Server-level (CPU, memory, I/O) | System-level (CPU, sockets, memory, I/O domains) | GPU-level (compute and memory) |
| Flexibility | Dynamic LPAR, resource tuning | Configurable nPartitions; changes are model/configuration dependent | Predefined profiles (layout can be changed when instances are idle) |
| Key benefit | Higher utilization, workload isolation | Strong isolation and predictable performance | Multiple isolated GPU workloads, better GPU utilization |
| Key difference | Partitions CPU/memory/I/O resources | Partitions entire system resources (sockets, memory, I/O) | Partitions GPU compute and memory (not a full server) |
The row I think matters most is the isolation mechanism. LPARs rely on a hypervisor, which makes them flexible but means resources can be shared and overcommitted. nPartitions rely on hardware boundaries, which makes them firm and predictable. MIG sits closer to nPartitions: the boundaries are in hardware, the profiles are fixed, and no instance can take resources from another.
Reliability, availability and serviceability
Each platform handles RAS differently — and this is where two decades of 2 AM pages shapes how I read a spec sheet.
- IBM Power LPAR: RAS is a core part of the architecture. Errors are isolated between LPARs, Live Partition Mobility (LPM) can move a running partition, resources can be reconfigured dynamically, and the platform has advanced error detection and recovery.
- HPE Superdome nPartitions: designed for mission-critical RAS. Hardware isolation sits between partitions, power, cooling and I/O components are redundant, and the platform targets high availability for critical workloads. I service and manage it through HPE RMC.
- NVIDIA MIG: errors are contained per MIG instance, performance is predictable with QoS, and MIG builds on the GPU’s own RAS features, such as ECC and row remapping. It holds up for production AI workloads. But the isolation stops at the GPU — I still count on the server underneath for overall RAS.
MIG compared with other GPU sharing methods
MIG is one of three ways I can share a GPU, and I treat them as different tools.
MIG (hardware partitioning) gives each instance its own SMs, memory and engines. Isolation is in hardware, performance is predictable with QoS, and noisy neighbors are far less of a problem. It’s my choice for multi-tenant production. Enabling MIG mode may require a GPU reset. Changing the layout later requires the instances to be idle, but no reset.
GPU time-slicing (software scheduling) lets multiple processes take turns on the GPU. Processes have separate address spaces, but there is no hardware isolation and no memory limits, so one process can use most of the GPU’s memory. It’s simple to enable or disable, and it suits development, testing and non-critical workloads. It can also be applied on top of MIG instances.
MPS (Multi-Process Service) allows concurrent execution through a shared software layer. Isolation is limited, and clients share one fault domain, though they keep separate address spaces. It improves utilization for many small jobs and suits development or inference workloads. It can also be applied on top of MIG instances.
MIG profile sizes
When I first saw a profile name like 3g.40gb, I decoded it as Ng.Mgb: N of the GPU’s 7 compute slices and M GB of memory. So 3g.40gb is three compute slices and 40 GB. Not every combination fits, because instances have to be placed on the slice layout. For example, 3g.40gb, 2g.20gb and two 1g.10gb instances together use all 7 compute slices and all 8 memory slices. Here’s that placement on an H100 80 GB — each instance owns its slices exclusively:
Profiles vary by GPU model and total memory. The examples here cover the A100 40 GB, the A100 80 GB and the H100 80 GB. Only compute (SMs), HBM memory, copy engines and video decoders are partitioned. The other resources, such as PCIe, power and clocks, are shared across the whole GPU.
Key takeaway
I’ve watched partitioning reappear across three decades of platforms — from IBM LPARs to HPE Superdome nPartitions to NVIDIA MIG. The implementations are different, but the underlying goal is the same: take a large physical resource and divide it into smaller, isolated environments for different workloads. The names change. The idea doesn’t.
Diagrams are simplified or conceptual, for illustration purposes. Actual hardware and configurations may vary.
See also
- GPU Data Path: Why Your GPU Is Starving — where data moves through the system and where performance gets lost
- GPU Architecture — what’s inside the H100: GPCs, SMs, HBM, and the memory hierarchy