GPU Time-Slicing vs MIG on Kubernetes: When to Use Which

Both let several pods share one physical GPU through the NVIDIA GPU Operator, so they get lumped together — but they are not interchangeable. The difference is isolation, and choosing wrong shows up as wasted money or a production incident.

Why share a GPU at all

Kubernetes hands out whole GPUs: nvidia.com/gpu is integer-only and the request must equal the limit, so a pod needing 10% of a card still reserves it all — and it bills at 100% whether it runs at 100% or 0%. Both mechanisms advertise one GPU as several schedulable units so low-utilization workloads stop hogging whole cards — same goal, different guarantees.

Time-slicing: shared SM time, no isolation

Time-slicing advertises a physical GPU as N replicas; pods scheduled onto them take turns on the streaming multiprocessors (SMs). It is pure oversubscription, and the critical property is what it does not provide: no memory isolation (every pod sees the full framebuffer, so one pod's over-allocation causes OOM errors for its neighbors) and no fault isolation (a fatal Xid from one tenant can reset the GPU and take every pod on that card down). You get maximum density on almost any GPU, via config:

sharing:
  timeSlicing:
    resources:
      - name: nvidia.com/gpu
        replicas: 4        # 4 units per GPU

It suits dev, CI and light inference — not isolated production tenants.

MIG: hardware-partitioned, isolated instances

Multi-Instance GPU (MIG) is a hardware feature on select data-center GPUs — the A100, A30, H100 and H200 among them (many cards, e.g. the A40, L4 and L40S, have no MIG). It physically carves a card into GPU instances, each with dedicated memory and compute — a smaller standalone GPU with real memory and fault isolation, so one instance erroring does not touch the others. The tradeoff is rigidity: profiles are a fixed set, <compute>g.<memory>gb. An A100 has seven compute slices, so geometries are constrained — an A100-80GB offers 1g.10gb (up to 7), 3g.40gb, or the full 7g.80gb. List supported profiles with nvidia-smi mig -lgip; reconfiguring requires draining the GPU. The GPU Operator exposes instances as resources like nvidia.com/mig-1g.10gb.

The decision: reason from the blast radius

Use time-slicing for trusted, bursty, low-utilization work where a shared failure is a shrug — dev, CI, notebooks, light inference — most packing, least effort. Use MIG when tenants must not affect each other — multiple teams on one card, latency-sensitive serving with an SLO, untrusted workloads — and your GPUs support it. The two also combine — MIG for isolated production, time-slicing for the dev pool — and for a job that saturates a whole GPU, use neither. Whichever you pick, measure utilization from DCGM first so you share the underused cards.

Related reading

Measure first with DCGM, Prometheus & Grafana, then right-size GPU requests, understand why clusters sit 30–50% idle, and reduce LLM inference cost.