MIG vs Time-Slicing vs Full GPU: How to Choose the Right GPU Sharing Strategy
A practical comparison of NVIDIA MIG, GPU time-slicing, and full GPU dedication on Kubernetes.
If you're running AI workloads on Kubernetes, you've probably hit this problem: your GPUs sit at 15-20% utilization most of the day, but you're paying for 100% of the hardware. The fix is GPU sharing — but there are three fundamentally different ways to do it, and picking the wrong one causes real production problems (unpredictable latency, noisy neighbors, or jobs that silently fail to schedule).
This guide breaks down when to use each.
The three approaches, in one line each
- Full GPU dedication — one workload gets one entire GPU. Simple, wasteful for small jobs, correct for large ones.
- Time-slicing — multiple workloads share a GPU by taking turns on the compute, similar to how a CPU context-switches between processes. No hardware isolation.
- MIG (Multi-Instance GPU) — the GPU is physically partitioned into isolated instances, each with dedicated compute and memory, at the hardware level.
Comparison table
| Time-slicing | MIG | Full GPU | |
|---|---|---|---|
| Isolation | Compute shared, no hard boundary | Hardware-isolated, dedicated memory | Full isolation, dedicated hardware |
| Hardware support | Any NVIDIA GPU | A100, H100, H200 | Any NVIDIA GPU |
| Max instances / GPU | Configurable, software-limited | Up to 7 | 1 |
| Setup complexity | Low — device plugin config | Moderate — may require node reboot | None |
| Noisy-neighbor risk | Possible under contention | None — guaranteed QoS | None |
| Best for | Dev, test, bursty workloads | Multi-tenant production inference | Large training runs |
When to use time-slicing
Time-slicing is the right call when:
- You're running dev/test workloads where perfect isolation doesn't matter.
- You want to share GPUs that don't support MIG — RTX 4090, L40S, and most consumer/prosumer cards work fine with time-slicing but can't do MIG at all.
- Your workloads are bursty rather than sustained — short inference calls, batch jobs, notebook sessions.
The tradeoff: workloads share the same memory pool and compute context-switches add latency. If one job spikes, others feel it. This is fine for a shared dev cluster; it's a real risk for anything with a latency SLA.
How it works under the hood: NVIDIA's device plugin exposes multiple virtual "replicas" of a physical GPU to Kubernetes via a ConfigMap — you're telling the scheduler "this one GPU can be requested by up to N pods," and the driver handles time-division of the actual compute.
When to use MIG
MIG is the right call when:
- You're running production, multi-tenant inference where one team's traffic spike shouldn't degrade another team's latency.
- You need guaranteed memory and compute per workload, not best-effort sharing.
- You're on Ampere-generation-or-newer datacenter GPUs (A100, H100, H200) — MIG isn't available on older or consumer cards.
The tradeoff: setup is more involved. Enabling MIG mode on a node typically requires cordoning it and, on several cloud providers, a full reboot. MIG partitions also do not persist across a reboot or a MIG mode toggle — if the node restarts, you need to recreate the partition geometry, which is a common operational gotcha teams miss until it bites them in production.
How it works under the hood: the NVIDIA GPU Operator's mig-manager component applies a partition geometry (e.g., seven 1g.5gb slices on an A100) via the mig-parted tool, then labels the node so Kubernetes can schedule pods against specific MIG device UUIDs.
When to use full GPU dedication
Simple: large training runs, workloads that genuinely need the full memory and compute budget of a GPU, or anything where the cost of sharing (setup complexity, even minimal isolation risk) outweighs the utilization gain. Don't over-engineer this — if a job needs 70GB+ of GPU memory, sharing isn't on the table anyway.
A quick decision framework
Ask these three questions in order:
- Does the workload need the whole GPU's memory/compute? If yes → full GPU, stop here.
- Does it run in production with a latency SLA, or serve multiple tenants? If yes → MIG, assuming you're on supported hardware.
- Is it dev/test/bursty, or on hardware that doesn't support MIG? → time-slicing.
Most teams end up running a mix of all three across their cluster — MIG for production inference, time-slicing for the dev cluster, full GPUs for training. That's normal, not a sign you picked wrong somewhere.
What this actually saves you
A concrete example: four small inference services, each needing roughly 5GB of memory and modest compute, running on four separately-allocated A100s at ~15% utilization each, cost the same as one A100 split into MIG partitions running all four services at ~70-80% utilization each. Same workloads, one-quarter the GPU spend.
Related reading: MIG Configuration · GPU Time-Slicing · GPU Observability
Not sure which setup fits your workloads? Run the numbers in our cost calculator or talk to us — we configure and manage MIG, time-slicing, and observability on your existing GPU provider, so you don't have to reverse-engineer the GPU Operator docs yourself.