TL;DR: MIG partitions GPU compute and memory resources for predictable sharing. MPS lets cooperative processes run kernels concurrently; A100 clients have separate GPU virtual address spaces but share execution resources. Time-slicing shares device capacity without per-tenant memory quotas. For untrusted tenants, assess the host, driver and virtualization boundary as well as the GPU sharing mode.
How to approach it
Establish the tenants first, because the answer is decided by whether they trust each other and whether any of them owns a latency SLO. Then ask what the workloads look like: notebooks and CI jobs behave nothing like a production inference replica. The three mechanisms share a name and almost nothing else, so answering "we use GPU sharing" describes none of the properties that matter.
A strong answer
Time-slicing is context switching. The driver interleaves work from multiple processes onto the whole GPU, one at a time. Memory is not partitioned, so any tenant can allocate until the device is full and the others hit out-of-memory errors that look like their own bug. Device-level faults can affect every user. Use it for cooperative development workloads with explicit memory budgets and an acceptable contention risk.
MPS (Multi-Process Service) lets kernels from multiple clients execute concurrently on the SMs. On Volta and later GPUs, including A100, each client has its own GPU virtual address space. Active-thread percentages constrain execution resources; configured device-memory limits constrain allocations. These controls do not create MIG-style hardware partitions. Fatal GPU faults can affect other clients sharing the affected device, so MPS suits cooperative workloads. See the NVIDIA MPS guide.
MIG (Multi-Instance GPU) partitions the physical device. An A100 80GB splits into up to seven instances, each with its own SM slice, its own L2 cache ways and its own memory controllers. A noisy neighbour cannot steal memory bandwidth it was not given, and many instance-local faults are contained. The host and driver remain shared, and a device reset or hardware failure can still interrupt multiple instances. MIG alone is not a complete security boundary for arbitrary hostile code. The price is rigidity, and it is quantifiable rather than aesthetic. Profiles come in fixed sizes, so on an A100 80GB you choose between seven instances of 10GB, three of 20GB, two of 40GB or one whole device. A model needing 12GB does not fit a 1g.10gb slice and must take a 2g.20gb, stranding 20 − 12 = 8 GB that no other workload can reach, a 40 percent loss on that partition. Sizes also cannot be mixed freely, and changing the layout interrupts the workloads on the affected GPU, so partitioning is a scheduling decision made hours or days ahead rather than per job.
That is the real trade against time-slicing: MIG gives isolation you can rely on and takes away the ability to fit whatever arrives, so it pays off when the workload mix is known and stable and costs you when it is not. A 1g.10gb instance is a small GPU whether or not its neighbours sit idle.
| Time-slicing | MPS | MIG | |
|---|---|---|---|
| Memory capacity isolation | No per-tenant quota | Configurable client limits | Hardware partition |
| Fault isolation | Device faults shared | Limited, device faults can spread | Instance isolation; shared device risks |
| Concurrency | Interleaved | Concurrent kernels | Parallel partitions |
| Reconfiguration cost | Plugin configuration rollout | Configuration dependent | Stop affected GPU workloads |
| Fit | Dev, notebooks | One team, small kernels | Multi-tenant, SLO-bearing |
For twelve A100s and four teams, the shape that survives contact: MIG the inference nodes into profiles sized from measured model memory, leave the training nodes whole because distributed training wants full devices and NVLink bandwidth, and give the notebook fleet two time-sliced nodes where cheap and messy is correct. Advertise each pool as a distinct Kubernetes resource (nvidia.com/mig-3g.40gb alongside nvidia.com/gpu) so scheduling is explicit rather than accidental, then put quota on top with Kueue so an idle team's allocation can be borrowed and reclaimed.
What interviewers probe next
"How do you know a MIG profile is right-sized?" From measured peak memory including KV cache and activation spikes, plus headroom, not from the model's parameter count. A 7B model in FP16 is 14GB of weights and can still need a 20GB instance under real concurrency.
"What breaks when you change profiles?" Workloads using the affected GPU must stop before their instances are destroyed. An operator may drain GPU workloads across the node, depending on its workflow. Plan profile changes as maintenance and check the MIG deployment requirements.
"Can you do fractional GPUs on managed cloud nodes?" Yes, and the mechanism differs by provider. The question underneath is which mechanism, isolation guarantees and supported profiles the provider actually exposes.
Common mistakes
Choosing the mode that maximises the utilisation graph. Time-slicing makes utilisation look wonderful because contention counts as busy.
Claiming MIG is always better. It strands memory when profiles do not match workloads, and it is the wrong answer for a single-tenant training node.
Forgetting that none of these solve the scheduler problem. Sharing changes what one node offers, and quota and fairness across teams still need Kueue or an equivalent above it.