NVIDIA MIG vs MPS: GPU Partitioning and Sharing Explained

GPU partitioning lets a platform serve multiple workloads from expensive accelerators, but “sharing a GPU” can mean either dividing its hardware into independent instances or letting separate processes use the same device concurrently. This explainer compares NVIDIA Multi-Instance GPU (MIG) and Multi-Process Service (MPS), for infrastructure engineers, ML platform teams, and CUDA developers who need to choose a sharing model without confusing device allocation with isolation.

Why GPU Partitioning Is Being Discussed

Training and inference workloads often have uneven resource needs. A service may need only a fraction of a large GPU, while running one process per physical card can leave compute capacity unused. At the other extreme, placing unrelated tenants on one device without understanding memory, scheduling, and failure boundaries can create noisy-neighbor problems.

MIG and MPS address different parts of this problem. MIG partitions supported NVIDIA GPUs into hardware-backed GPU instances. MPS coordinates CUDA processes so their work can share a GPU. A scheduler, device plugin, or application still has to decide which workload gets which resource; neither feature is a complete cluster scheduler or a general-purpose quota system.

What Are MIG and MPS?

Multi-Instance GPU (MIG) divides a supported physical GPU into a set of GPU instances (GIs). Each instance receives a hardware-defined combination of compute and memory-system resources; compute instances can further subdivide the compute resources in a GPU instance. Applications see the resulting MIG devices as CUDA-capable devices. The NVIDIA MIG User Guide describes supported GPUs, instance profiles, and configuration.

Multi-Process Service (MPS) is a CUDA service that lets multiple CUDA processes submit work through an MPS server. It can allow kernels and memory transfers from different processes to overlap on a GPU that might otherwise have idle execution capacity. See the NVIDIA MPS documentation for its control tools, client behavior, and configuration.

The distinction is about the resource boundary: MIG creates separately addressable hardware instances; MPS coordinates multiple processes against a GPU rather than carving it into fixed hardware slices. A workload can also run on an ordinary, unpartitioned GPU without either mechanism.

The Problem Each Approach Solves

Allocating one whole GPU per small inference server is straightforward but can strand memory and compute when the model does not need the entire device. Sharing one whole GPU among processes can improve utilization, yet workloads may contend for memory bandwidth and execution slots, and their demand can vary over time.

MIG is designed for predictable subdivisions and stronger hardware separation when the GPU supports it. An operator selects from available profiles rather than inventing an arbitrary percentage split. This can help make smaller capacity units visible to a scheduler and limit how much one instance can use.

MPS is useful when several CUDA processes are compatible with concurrent execution and their combined demand fits the GPU. It can improve utilization without reconfiguring the card into MIG instances. It does not reserve a fixed memory capacity or a fixed compute slice for each process, so applications can still compete for shared resources. CUDA memory safety mechanisms are not the same thing as a capacity guarantee or a separate hardware fault domain.

How MIG and MPS Work

MIG configuration partitions a supported GPU into predefined profiles. A GPU instance receives a portion of the GPU’s compute and memory-system resources, and it can contain one or more compute instances. The number and shape of instances depend on the GPU model and its supported profiles. The device driver exposes the resulting instances to CUDA applications. Reconfiguring MIG changes the devices available to workloads and may require workloads to be stopped; treat changes as an infrastructure operation, not a per-request scheduling decision.

With MPS, participating CUDA applications connect to an MPS control daemon and server. The server multiplexes client work so that independent processes can share execution resources and, when operations permit, overlap kernels or memory transfers. MPS can expose controls for limiting a client’s active thread percentage, but this is not equivalent to assigning it a MIG profile or guaranteeing a proportion of total GPU throughput. Actual concurrency depends on the hardware, kernels, memory use, and client configuration.

The table describes the basic operating models, not a promise of identical performance across products. MIG profiles, supported combinations, and MPS capabilities are hardware- and driver-dependent. Neither model isolates workloads from every shared dependency: the card, host driver, PCIe path, power, and node remain common failure points.

Components and Key Concepts

• GPU instance (GI): The MIG device boundary that groups a profile’s assigned resources. A GPU instance can contain compute instances.
• Compute instance (CI): A subdivision of a GPU instance’s compute resources. Supported layouts vary by GPU and profile; not every split is possible.
• MIG profile: A predefined size and resource combination advertised for a particular GPU. A name such as 1g.5gb is an example, not a universal profile.
• MPS control daemon and server: The host-side MPS services through which client processes connect and submit work. They coordinate execution, but do not turn processes into separate hardware partitions.
• Device exposure and allocation: A driver or orchestrator makes devices visible and assigns them to workloads. In Kubernetes, this is separate from configuring the hardware: the device plugin documentation describes how plugins advertise devices as node resources. Kubernetes Dynamic Resource Allocation for GPUs covers a claim-based allocation API; neither scheduler API creates MIG instances by itself.

The NVIDIA GPU Operator MIG guide explains how its MIG Manager configures MIG on Kubernetes nodes. Administrators should check the GPU model, driver, operator, and device-plugin configuration together: the resources advertised to Pods depend on that setup.

Real-World Use Cases

Inference pools with different model sizes can use MIG when each service needs a stable, known device-memory capacity and the hardware offers suitable profiles. Teams can map a profile to a node resource and let Kubernetes place Pods against the resources the driver advertises. This is more predictable than treating every workload as an interchangeable fraction of a full GPU.

Development, evaluation, or compatible inference processes may benefit from MPS when jobs are short or underutilize a device and can safely share execution. MPS is most useful when measured workloads leave enough free compute and memory for overlap. Benchmark real request patterns: more concurrency can increase throughput, but it can also increase tail latency or cause memory exhaustion.

Multi-tenant clusters may use MIG to create more explicit device boundaries for teams or services. It does not replace container security, tenant authorization, or cluster admission policy. For workload-level GPU allocation and the distinction between device selection and physical partitioning, see the GPU DRA explainer.

Model-serving platforms need to match partition size and concurrency to the model’s memory footprint and traffic pattern. KServe on Kubernetes explains the serving control plane; MIG and MPS are lower-level choices for how GPU capacity is presented to serving processes.

Getting Started: Inspect and Request GPU Capacity

Start by confirming the GPU model, installed driver, supported MIG profiles, and current configuration. Run inspection commands on the GPU host with NVIDIA’s driver utilities installed:

# List physical and MIG devices visible to the driver.
nvidia-smi -L

# Inspect the current and pending MIG mode.
nvidia-smi -q -d MIG

# List GPU instance profiles supported by GPU 0.
nvidia-smi mig -lgip -i 0

# List GPU instances currently configured on GPU 0.
nvidia-smi mig -lgi -i 0

The output is specific to the hardware and driver. Do not copy a profile name from another GPU generation and assume it is available. On Kubernetes, first confirm the node’s allocatable resource names with kubectl describe node <node-name>; NVIDIA’s device plugin or GPU Operator configuration determines whether the cluster exposes whole GPUs, MIG devices, or another supported resource model.

If the node advertises a resource named nvidia.com/mig-1g.5gb, a Pod can request one such device as follows. Replace the example profile with an exact resource name shown by the target node; the profile and name are not universal.

apiVersion: v1
kind: Pod
metadata:
  name: mig-workload
spec:
  restartPolicy: Never
  containers:
    - name: workload
      image: nvcr.io/nvidia/cuda:12.6.0-base-ubuntu22.04
      command: ["nvidia-smi"]
      resources:
        limits:
          nvidia.com/mig-1g.5gb: 1

Apply and inspect the example only after confirming that the cluster advertises this resource and the image is available to its nodes:

kubectl apply -f mig-workload.yaml
kubectl describe pod mig-workload
kubectl logs mig-workload

For MPS, install a compatible NVIDIA driver and CUDA stack, then configure the daemon and client environment according to the MPS guide. Test representative clients together and monitor device memory, utilization, throughput, and latency. A successful CUDA process launch alone does not demonstrate that the sharing policy meets a service’s performance or isolation requirements.

Common Misconceptions

“MPS is just MIG in software.” MPS coordinates CUDA processes but does not create MIG’s hardware-defined device instances or fixed per-instance memory capacity.

“A Kubernetes GPU request configures the partition.” A resource request selects capacity that a driver or operator has already made available. The cluster scheduler places workloads; it does not decide an arbitrary MIG layout on the card.

“MIG makes tenants completely independent.” MIG offers stronger device-level separation, but tenants still share the physical card, host, driver, and surrounding infrastructure. Isolation requirements need to account for those common components as well as the GPU instance.

Related Articles

• Kubernetes Dynamic Resource Allocation for GPUs
• Container Device Interface for GPUs and Accelerators
• KServe Explained: Serving AI Models on Kubernetes
• Multi-GPU Setup for Machine Learning

Changelog and Last Updated

• First published.

Last updated: 2026-10-16