A MIG slice on an H100, what is it and what is it good for?

**MIG** stands for Multi-Instance GPU. It is a feature on NVIDIA A100 and H100 datacenter GPUs that lets you split one physical card into up to seven smaller logical GPUs. Each smaller GPU, called a MIG instance or 'slice', looks to software like its own dedicated GPU. Unlike older sharing techniques, MIG enforces isolation in hardware. Each slice gets its own set of streaming multiprocessors (SMs), its own chunk of HBM memory, its own slice of the L2 cache, and its own portion of the memory bandwidth. If you give tenant A two-sevenths of the card and tenant B one-seventh, tenant A's workload cannot spill over and slow down tenant B. The hardware enforces the split. You would use MIG when you want to run several smaller workloads on one large GPU and they must not interfere with each other. Common cases include hosting several small models on the same card to save cost, giving each developer their own GPU slice for experiments, or running per-tenant inference where each customer gets a guaranteed slice of capacity.

**MIG** (Multi-Instance GPU) is NVIDIA's hardware-level GPU partitioning, available on A100, H100, and successor data-center cards. It splits a single physical GPU into up to seven independent instances, each with its own dedicated SMs, HBM memory partition, L2 cache slice, and memory bandwidth quota. The partition is configured statically before workloads start. A 7-slice A100 40 GB, for instance, gives each slice one-seventh of the SMs but one-eighth of the memory and its bandwidth (5 GB). Different profiles exist (1g.5gb, 2g.10gb, 3g.20gb, 4g.20gb, 7g.40gb on A100; analogous profiles on H100), so you can mix slice sizes. Once configured, each slice appears as its own CUDA device with a separate UUID, separate driver context, and complete fault isolation from siblings. MIG is the right tool when you need strict performance and security isolation between workloads sharing one GPU. Multi-tenant inference platforms use it so one tenant's load cannot slow another. ML platform teams use it to split H100s into smaller dev environments. CI systems use it to run many short jobs in parallel on one card. The tradeoff is rigidity. You cannot grow a slice at runtime. Changing a slice's profile means stopping its workloads first. MIG also limits some features. NCCL does not support MIG, and CUDA IPC across GPU instances is not supported. So tensor parallelism across slices does not work. MIG suits many tenants, not one large job that needs the whole GPU.