How can multiple workloads share one GPU: MIG, time slicing or MPS?
NVIDIA GPUs can be shared between Kubernetes workloads in three ways. Multi-Instance GPU (MIG) splits a supported GPU in hardware into up to seven instances, each with its own memory and compute. Time slicing lets several Pods take turns on the whole GPU, with no memory or fault isolation between them. Multi-Process Service (MPS) runs work from several processes on the GPU at the same time and can cap each one’s memory and compute.
Why share a GPU
Kubernetes allocates GPUs as whole units: a Pod that requests nvidia.com/gpu: 1 holds the entire card, as explained in how GPUs work in Kubernetes. An embedding model, a small LLM or a notebook rarely needs a full H100. Sharing lets several such workloads use one physical GPU, which raises utilization and cuts the number of GPUs you pay for.
The three methods compared
| MIG | Time slicing | MPS | |
|---|---|---|---|
| How it shares | Partitions the GPU in hardware | Workloads take turns on the whole GPU | Work from several processes runs concurrently |
| Memory isolation | Dedicated memory per instance | None, any Pod can use all memory | Isolated address spaces; per-client memory limit |
| Fault isolation | Yes, between instances | None, one fault domain | A fatal fault affects the other clients on that GPU |
| Performance isolation | Dedicated SMs, L2 cache and memory bandwidth | None | Compute limit per client |
| Kubernetes resource | nvidia.com/mig-1g.10gb and similar, or nvidia.com/gpu | nvidia.com/gpu | nvidia.com/gpu |
| Supported GPUs | A100, A30, H100, H200, B200, B300 and RTX PRO 6000 Blackwell, among others | Most NVIDIA data center GPUs | Volta generation and newer |
| Typical use | Multi-tenant serving, predictable latency | Development, notebooks, bursty services | Many small inference processes |
MIG partitions the GPU in hardware
MIG divides a GPU into instances that each get their own streaming multiprocessors (SMs), L2 cache banks, memory controllers and DRAM. NVIDIA’s MIG user guide describes each instance as having separate and isolated paths through the memory system, with fault isolation between clients. A workload in one instance cannot read another instance’s memory or slow it down by thrashing the cache.
Partitions come in fixed profiles. On an 80 GB H100, 1g.10gb is one-seventh of the compute with 10 GB of memory, and 3g.40gb is three-sevenths with 40 GB. The supported GPUs list allows up to seven instances on A100, H100, H200, B200 and B300, and up to four on the A30 and RTX PRO 6000 Blackwell. The L4, L40S and T4 do not support MIG.
In Kubernetes, the NVIDIA device plugin exposes MIG instances in one of two ways. With the single strategy, every GPU on a node uses the same profile and Pods keep requesting nvidia.com/gpu. With the mixed strategy, each profile becomes its own resource, such as nvidia.com/mig-1g.10gb, and Pods request it by name. Changing the profile layout requires stopping the workloads on that GPU. The GPU Operator’s MIG Manager applies a layout chosen through a node label.
Time slicing takes turns
Time slicing makes the device plugin advertise each physical GPU as several replicas. Pods request nvidia.com/gpu: 1, get a replica, and the GPU switches between their processes. The GPU Operator documentation is direct about the limits: unlike MIG, there is no memory or fault isolation between replicas. One Pod can allocate all GPU memory and cause the others to fail, and a request for two replicas does not guarantee twice the compute.
Time slicing needs no application changes and works on GPUs without MIG, such as the L4 and L40S. It fits notebooks, test environments and services that are idle most of the time.
MPS runs processes concurrently
MPS runs CUDA work from several processes on the GPU at once through a control daemon, instead of switching between them. That removes the context-switching overhead of time slicing and lowers latency for small inference batches. According to NVIDIA’s MPS documentation, clients on Volta and newer GPUs have fully isolated GPU address spaces, and each MPS server supports up to 60 client CUDA contexts per device by default. A fatal fault in one client still affects the other clients on the same GPU.
In the NVIDIA device plugin, MPS shares full GPUs only. Each client gets an equal fraction of device memory, and the daemon limits the compute each one can use. The plugin’s README still labels MPS support experimental.
Can you combine them?
Partly. The GPU Operator documentation states that you can combine MIG and time slicing to share access to MIG instances, so several Pods can take turns on one 1g.10gb slice. MPS cannot be combined with MIG: the device plugin README states that MPS sharing is not supported on devices with MIG enabled.
Which one to choose
- Choose MIG when workloads belong to different teams or customers, or need predictable latency, and the GPU supports it. See Kubernetes multi-tenancy for the rest of the isolation picture.
- Choose MPS for several trusted inference processes that each need a small, steady share of compute.
- Choose time slicing for development, notebooks and bursty internal services, or on GPUs without MIG.
- Share nothing for training. Training keeps a GPU busy on its own and depends on full memory and bandwidth.
For a worked setup with whole-GPU training next to shared inference in one cluster, see training and inference in one Kubernetes cluster. For how batching on a single GPU compares with sharing it, see how to run LLM inference on Kubernetes.
Where sharing is heading
Dynamic Resource Allocation lets several containers or Pods share one device by referencing the same resource claim, and lets drivers describe devices in more detail than a count. NVIDIA’s DRA driver for GPUs lists dynamic MIG allocation as a goal, but as of November 2026 its GPU allocation features are not yet officially supported. The device plugin with MIG, time slicing or MPS remains the production path.
GPU sharing on Cloudfleet
Cloudfleet Kubernetes Engine supports time slicing and MPS as a cluster-level setting on the Pro and Enterprise tiers. You choose the strategy and the maximum number of Pods per GPU in the Console, CLI or Terraform provider, and Pods keep requesting nvidia.com/gpu: 1, as the GPU workloads documentation describes.