Tenant Isolation on Shared GPUs: MIG, vGPU and Time-Slicing Compared

Overview

Isolation on a shared GPU is a spectrum, not a checkbox. NVIDIA Multi-Instance GPU (MIG) is the only sharing mechanism that partitions memory, L2 cache and compute in hardware with fault containment; vGPU adds hypervisor-mediated separation whose strength depends on how it is backed; time-slicing and MPS are scheduling conveniences that share a single memory space and should never cross a trust boundary. For a CISO reviewing a multi-team or multi-entity GPU cluster in India – where DPDP-grade security safeguards must be evidenced – the question is not “is the GPU shared” but “which failure and disclosure paths remain shared”. This article sets out what each mechanism actually isolates, the residual risks partitioning does not remove, and the cases where dedicated hardware is the defensible answer.

Why GPU sharing is a security question

GPU economics push hard toward sharing: a 96 GB card serving one small inference workload is wasted capital, and utilisation pressure grows with cluster cost. But the moment two workloads with different data classifications – or two departments, subsidiaries or customers – land on one GPU, the sharing mechanism becomes part of your security-safeguard story. Under the DPDP Act’s requirement for reasonable security safeguards, and under sector expectations such as those discussed in BFSI Private AI GPU Server Controls and Auditability, you should be able to state precisely what separates tenant A’s data in GPU memory from tenant B’s code.

MIG: partitioning in hardware

Multi-Instance GPU, available on A100, H100, H200 and Blackwell-class data-centre GPUs, divides a physical GPU into up to seven instances. As documented in the NVIDIA MIG user guide, each instance receives dedicated streaming multiprocessor slices, its own memory slice with separate memory bandwidth, and an isolated portion of L2 cache, so a noisy or crashing workload in one instance does not stall or corrupt another. Faults such as ECC errors are attributed and contained per instance. MIG is the strongest sharing primitive available: tenants get predictable performance and a hardware-enforced memory boundary. Its limits are granularity (fixed profile sizes), no NVLink peer-to-peer between instances, and the operational need to drain workloads when reconfiguring geometry.

vGPU: hypervisor-mediated sharing

NVIDIA vGPU presents virtual GPUs to virtual machines, with framebuffer statically partitioned per profile and the hypervisor mediating access. Two very different modes hide under one brand name. MIG-backed vGPU maps each VM onto a MIG instance and inherits its hardware isolation. Time-sliced vGPU gives each VM a private framebuffer allocation but schedules compute serially across VMs, so performance isolation is weaker and the isolation guarantee leans on the driver and hypervisor rather than hardware partitions. vGPU adds the general benefits of VM isolation – separate kernels, IOMMU-mediated DMA, snapshotting – which containers on a shared host do not provide. When evaluating a vGPU-based offering, ask which mode is in use; the answer changes the assurance story materially.

Time-slicing and MPS: scheduling, not isolation

Kubernetes device-plugin time-slicing lets multiple pods share one GPU by interleaving their CUDA contexts. There is no memory partitioning: allocations coexist in one address space protected only by ordinary CUDA process separation, an out-of-memory event or Xid error can take down co-resident workloads, and fault attribution is poor. CUDA MPS (Multi-Process Service) merges work from cooperating processes to raise utilisation; post-Volta MPS provides per-client address spaces and limited protection, but it is explicitly designed for mutually trusting processes. Both are excellent tools for one team sharing its own GPU. Neither is a tenant boundary, and neither should appear in a compliance narrative as an isolation control.

What none of these mechanisms isolate

Partitioning does not remove every shared element, and an honest architecture review names the residuals:

• The driver and firmware stack. All tenants on a GPU share one kernel driver and GPU firmware; a driver CVE or malicious escape affects every instance. Patch cadence is part of tenant isolation.
• Side channels. Academic work has demonstrated timing, cache-based and power-related side channels on shared GPUs. These are hard to exploit but should be treated as open risk where tenants are adversarial.
• Reset and reconfiguration behaviour. A full-GPU reset affects all instances; MIG reconfiguration requires draining; memory is scrubbed on instance teardown, but the operational procedure must guarantee that step.
• Host-level visibility. Cluster administrators can observe process names, memory usage and utilisation across tenants via management tooling – an insider-risk consideration, not a hardware flaw.

Where the data itself must be protected even from the infrastructure operator, hardware TEE modes are the relevant control – see Confidential Computing on GPUs.

When separate hardware is the only honest answer

Dedicated GPUs, dedicated nodes, or a dedicated cluster are the defensible choice when tenants are distinct legal entities with separate regulatory exposure; when the threat model assumes a hostile co-tenant; when data falls into categories a regulator or contract requires to be segregated; or when incident response must be able to seize and image a machine without collateral damage to another tenant. This is the same control logic that drives the private-cluster argument in Training Behind Your Own Firewall: sharing is an efficiency decision that must survive a security review, not the default.

Isolation mechanisms at a glance

Frequently asked questions