[email protected] +1 231 500 5711
Contact us Knowledge Base
Client Area

Configuring NVIDIA MIG: A Technical Walkthrough for GPU Partitioning

High-end GPUs—such as the NVIDIA A100, H100, H200, and Blackwell-based enterprise GPUs—are the backbone of modern enterprise AI workloads. However, in real-world data center deployments, many inference, analytics, and database acceleration workloads do not fully utilize the resources of a massive GPU. Leaving these resources underutilized translates directly to wasted compute power and bloated AI infrastructure budgets.

One of the most effective solutions to this inefficiency is NVIDIA Multi-Instance GPU (MIG) technology. MIG allows system administrators to partition a single physical GPU into multiple, fully independent instances at the hardware level.

Each instance created through MIG is allocated its own dedicated compute, memory, and bandwidth reserves. This strict hardware-level isolation ensures that entirely different workloads—such as complex generative AI inference and traditional High-Performance Computing (HPC) tasks—can run simultaneously on the same physical GPU without interfering with one another. Unlike software-based time slicing, CUDA sees each MIG instance as a completely independent GPU, requiring no code changes to your applications.

Table of Contents

Phase 1 Prerequisites for NVIDIA MIG Setup

Before you can partition the GPU, ensure your bare-metal GPU server environment meets the necessary hardware and software baselines.

For this tutorial, we assume you are operating a MIG-capable GPU running on an Ubuntu 24.04 server environment.

1. Install NVIDIA Drivers and Toolkit

MIG requires a modern, stable NVIDIA driver. The exact package depends on your Ubuntu release and repository. The easiest method is to use the built-in Ubuntu driver utility:

Bash 

sudo ubuntu-drivers install
If ubuntu-drivers are unavailable, install the ubuntu-drivers-common package first.

Alternatively, you can install a supported server driver package (such as nvidia-driver-550-server or newer) manually if required by your specific environment.

✅ Crucial Note for Docker users: If you plan to deploy containerized workloads, you must also install the NVIDIA Container Toolkit on the host before running GPU-enabled Docker containers.

2. Verify GPU Initialization and MIG Support

Once the driver installation is complete (a system reboot may be required), verify that the OS correctly recognizes the hardware and supports MIG. Use the NVIDIA System Management Interface (nvidia-smi) tool:

Bash 

nvidia-smi -q

Scroll through the output and locate the MIG Mode section. You should see an output indicating the status:

Plaintext 
   MIG Mode
        Current                 : Disabled
        Pending                 : Disabled

If you see this section, your hardware is initialized, MIG is supported, and you are ready for partitioning.

✅ (Optional): While persistence mode keeps the driver loaded even when no applications are running, it is largely optional on modern driver stacks managed by nvidia-persistenced.

Phase 2 Enable MIG Mode on the GPU

By default, NVIDIA GPUs operate in a standard, single-instance mode. Before creating partitions, MIG mode must be explicitly activated.

⚠️ Important Production Warning: Ensure no CUDA workloads, containers, or graphical sessions are actively using the GPU before enabling or disabling MIG mode. Otherwise, the command will fail with an "In use by another client" error. Additionally, toggling MIG mode destroys existing GPU instances and may interrupt running workloads. Schedule these changes during a maintenance window whenever possible.

To enable MIG mode on the primary GPU (index 0), execute:

Bash 
sudo nvidia-smi -i 0 -mig 1

Expected Output:

Plaintext 
Enabled MIG Mode for GPU 00000000:06:00.0
All done.
✅ Note: Depending on your exact driver and firmware version, enabling MIG mode may require restarting the nv-hostengine daemon or rebooting the server to fully apply the hardware changes.

Phase 3 Understanding MIG Profiles and Resource Layouts

You cannot arbitrarily slice an NVIDIA GPU into random memory sizes. The hardware supports specific MIG profiles, which represent fixed resource layouts combining predefined amounts of GPU memory and GPU slices, which encapsulate compute and memory resources.

Before creating instances, review the available profiles supported by your specific GPU:

Bash 
nvidia-smi mig -lgip

Depending on your GPU model, memory capacity, and supported architecture, the available profile names and IDs will vary. (e.g., configurations for 40GB, 80GB, 96GB, or 144GB variants). Understanding the naming convention is critical for optimal resource scheduling:

  • The first number (e.g., 1g, 2g, 4g): Denotes the number of GPU slices allocated.
  • The second number (e.g., 10gb, 24gb, 48gb): Denotes the allocated GPU memory.

Examples of common profiles include:

  • 1g.10gb (Common on A100 40GB)
  • 1g.20gb (Common on A100 80GB)
  • 2g.48gb (Assuming it is available on newer 96GB/144GB cards)

Phase 4 Create Compute and GPU Instances (Partitioning)

Once you have identified the appropriate profile names or IDs for your workload, you can proceed to partition the GPU. This is done by creating a GPU Instance (GI) and binding it to a Compute Instance (CI).

  • The GI allocates the physical memory and bandwidth.
  • The CI exposes the compute engines to the operating system and CUDA applications.

The -cgi parameter is used to define which instance types to create. You can use the exact profile strings from your lgip output, or use the Profile IDs.

For example, to split a high-capacity GPU into two equal instances (assuming 2g.48gb is available in your lgip output):

Bash 
sudo nvidia-smi mig -cgi 2g.48gb,2g.48gb -C

Understanding the command:

  • -cgi: Instructs the GPU to create separate GPU Instances based on the specified profile.
  • -C: This flag automatically creates the corresponding Compute Instances. Without the CI, your applications cannot utilize the partitioned resources.

From this moment on, the single physical GPU behaves like multiple independent logical GPUs. (You can verify your creations by running nvidia-smi mig -lgi to list GPU instances and nvidia-smi mig -lci to list Compute instances).

Phase 5 Identify and Assign MIG Instances

To actually use your partitioned resources in a multi-tenant GPU environment, you must identify their unique identifiers (UUIDs) assigned by the driver.

Bash 
nvidia-smi -L

Expected Output:

Bash 
GPU 0: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-ad2e909a-16c4-5867-7e0f-c68d696dc0fa)
  MIG 2g.48gb     Device  0: (UUID: MIG-af414487-fcaa-5f42-b210-6f614c9cf780)
  MIG 2g.48gb     Device  1: (UUID: MIG-fcf3ca68-f772-5d84-9d6b-a0e1bcabf88b)

You will use the strings beginning with MIG-... to target these specific partitions for GPU orchestration.

Phase 6 Practical Use Case: Running Docker on a Specific MIG Instance

AI developers rely heavily on Docker to ensure environment consistency. Normally, the --gpus all flag exposes the entire physical GPU. With MIG, you specify exactly which MIG instance the container should use.

To launch a container locked exclusively to the first MIG instance (assuming the NVIDIA Container Toolkit is installed):

Bash 
docker run --rm -it \
  --gpus '"device=MIG-af414487-fcaa-5f42-b210-6f614c9cf780"' \
  nvcr.io/nvidia/pytorch:<supported-tag>  \
  nvidia-smi

Replace <supported-tag> with a currently available PyTorch container tag from the NVIDIA NGC Catalog.

When this container boots, running nvidia-smi inside the container only exposes the assigned MIG instance, maintaining strict GPU resource isolation.

Phase 7 How to Delete or Reconfigure MIG Partitions

If your workload requirements change, you can destroy and recreate layouts dynamically. To revert the GPU back to its unpartitioned state:

Bash 
# 1. Delete all Compute Instances
sudo nvidia-smi mig -dci

# 2. Delete all GPU Instances
sudo nvidia-smi mig -dgi

If you wish to completely disable MIG mode and return to standard GPU operation:

Bash 
sudo nvidia-smi -i 0 -mig 0
✅ Note on Limitations: While MIG is incredibly powerful, it does not support certain features like Peer-to-Peer (P2P) memory access between MIG instances, and NVLink communication between separate MIG instances is restricted. Plan your Kubernetes deployment and NVIDIA GPU Operator configuration accordingly.

Conclusion: Streamlining AI Infrastructure with MIG

By implementing NVIDIA’s Multi-Instance GPU technology, you can significantly increase the hardware efficiency of a single high-end server GPU. Partitioning allows varying workloads to run concurrently, safely, and efficiently on the same physical GPU.

While the actual configuration requires only a few precise CLI commands, managing bare-metal GPU environments, driver lifecycles, and hardware provisioning at scale can be a time-consuming challenge for engineering teams.

For organizations that prefer to focus purely on building and deploying AI models rather than managing data center infrastructure, MIG servers offers a streamlined alternative. We provide pre-configured, dedicated GPU servers that are fully optimized for these partitioned workloads right out of the box.