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. What makes MIG different from older sharing techniques is that the isolation is enforced in hardware. Each slice gets its own set of streaming multiprocessors (SMs), its own dedicated 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, there is no way for tenant A's workload to spill over and slow down tenant B. The walls are physical. You would use MIG when you want to run multiple smaller workloads on one large GPU and absolutely cannot have them interfere with each other. Common cases include hosting several small models on the same card for cost reasons, giving each developer in a team their own GPU slice for experimentation, or running per-tenant inference where each customer is guaranteed a fixed slice of capacity regardless of what other customers are doing.

**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, for instance, gives each slice roughly 5 GB of HBM and one-seventh of the SMs and bandwidth. Different profiles exist (1g.5gb, 2g.10gb, 3g.20gb, 4g.20gb, 7g.40gb on A100; analogous profiles on H100), letting you mix slice sizes if the workloads have different needs. 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 a noisy tenant cannot starve a quiet one. ML platform teams use it to carve up expensive H100s into many smaller dev environments. CI systems use it to run many short jobs in parallel on one card. The tradeoff is rigidity. The partition is static, so you cannot scale a slice up at runtime if it runs hot. Switching profiles requires draining the GPU. MIG also limits some features: NVLink between slices is disabled, and tensor parallelism across slices on the same card does not work. It is genuinely for parallel-tenant work, not for one big distributed job that needs all the silicon together.