MIG, or Multi Instance GPUs, is NVIDIA’s hardware feature for partitioning supported GPUs into discrete instances with compute and memory isolation. It is designed for stronger separation than time slicing. The article notes it is available on A100 and H100 GPUs, and each workload receives a configured slice rather than arbitrary fractional sharing.
Expanded Definition
MIG, short for Multi Instance GPUs, is a hardware partitioning feature that divides a supported NVIDIA GPU into discrete slices with separate compute and memory boundaries. The practical point is isolation: each workload gets a configured portion of the device rather than a loosely shared pool of resources.
That makes MIG different from time slicing or software-based sharing, where workloads may still contend for the same underlying GPU capacity. With MIG, the operator defines the instance layout up front, so capacity planning becomes part of the security and performance design. The most common misunderstanding is treating MIG as a generic performance feature only. In practice, it is also a resource-separation control that can reduce noisy-neighbour effects and narrow the blast radius of one workload affecting another.
Usage is straightforward in concept but depends on supported hardware and a compatible driver and orchestration stack. On NVIDIA A100 and H100 GPUs, MIG is typically used when teams want predictable isolation for mixed workloads, especially where one tenant or application should not consume the full card.
Examples and Use Cases
- A cloud platform carves one GPU into several fixed instances so multiple teams can run inference jobs without competing for the same memory pool.
- A data science cluster uses MIG to separate a production model-serving workload from experimental training jobs on the same physical host.
- A virtual desktop or graphics environment allocates smaller GPU slices to different users so one session cannot monopolise device capacity.
- A shared AI platform uses MIG to make GPU allocation more predictable for scheduling, budgeting, and service-level enforcement.
In each case, the tradeoff is that stronger separation usually comes with less flexibility than whole-GPU sharing. You gain clearer boundaries, but you also need to plan instance sizes carefully because the slices are preconfigured rather than elastic.
The operational value is highest where workload mix is stable and the team cares about predictable isolation more than maximum burst efficiency. That is why MIG often shows up in platforms that host multiple model-serving or analytics workloads on the same hardware.
Security Implications
Security issues arise when GPU sharing is assumed to be equivalent to isolation. If workloads are time-sliced on a shared GPU, residual contention, memory pressure, or resource interference can create performance degradation and sometimes visibility gaps for operators trying to reason about tenant separation.
MIG improves the boundary by enforcing hardware-defined partitions, but the security benefit depends on correct configuration. Mis-sized instances, unsupported migration patterns, or accidental mixing of sensitive and non-sensitive workloads can still create governance problems even when the device is partitioned.
Failure mechanism: The main failure mode is overtrusting the partition as a complete security boundary without validating the surrounding orchestration, tenancy model, and administrative access. If the platform treats MIG as a substitute for workload policy, the organisation may preserve shared operational control while assuming stronger isolation than actually exists.
Impact: The result can be cross-workload interference, weaker tenant separation, and poor assurance for environments that rely on GPU boundaries for data or model protection.
Security, Operational and Governance Implications
MIG matters because it changes how teams think about GPU trust boundaries. In shared AI and high-performance computing environments, the question is not only whether a GPU is available, but whether a workload should be allowed to share the same physical device at all, and under what slice size and operating model.
That makes MIG both an infrastructure choice and a governance choice. Capacity teams need to decide which workloads deserve dedicated slices, which can coexist, and how changes to instance layout are approved. The control is especially useful where predictable service quality and separation are more important than maximal utilisation.
It also fits broader security design patterns around least shared state and constrained blast radius. When used well, MIG can support tighter separation for sensitive inference services, staging environments, and multi-tenant platforms. When used loosely, it can create a false sense of isolation because the hardware boundary is stronger than time sharing, but not a replacement for access control, workload policy, or secure administration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC — Cyber Supply Chain Risk Management | MIG shapes shared infrastructure trust and tenant separation in GPU platforms. |
| PR.AC — Identity Management, Authentication and Access Control | MIG access and slice assignment depend on controlled administrative authorization. | |
| Recommendation — Treat GPU partitioning as part of infrastructure risk governance and define ownership for shared-device boundaries. Restrict who can create, resize, or reassign GPU instances and review those privileges regularly. | ||
| CIS Controls v8 | 6 — Access Control Management | MIG allocates discrete compute resources that should be governed as controlled access paths. |
| Recommendation — Apply access control to GPU partition administration and limit shared-device use to approved workloads. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | MIG is strongest when slices and admin rights are limited to the minimum needed by each workload. |
| SC-39 — Process Isolation | MIG is a hardware mechanism for isolating workloads on the same GPU. | |
| CM-2 — Baseline Configuration | MIG requires explicit instance layouts and managed device baselines. | |
| Recommendation — Assign the smallest feasible GPU slice and administrative scope needed for each workload. Use MIG to enforce process isolation where workloads share physical GPU hardware. Document approved GPU partition profiles and control changes through configuration management. | ||
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
