How to Split One GPU Between Workloads with NVIDIA MIG (Multi-Instance GPU) on a Dedicated Server

A single data-center GPU is often far more than one workload needs. A small inference model might use 8 GB of an 80 GB card, while the rest of the GPU, which you are paying for, sits idle. NVIDIA Multi-Instance GPU (MIG) solves that by partitioning one physical GPU into several smaller, fully isolated GPUs, each with its own dedicated compute, memory and memory bandwidth.

This tutorial shows you how to do it on a GPU dedicated server running Linux: check support, enable MIG mode, choose profiles, create instances, run containers on them, make the setup survive reboots, and monitor it. Every command comes from NVIDIA's MIG documentation and works the same on bare metal, which is why MIG is a natural fit for dedicated servers, where you control the driver and the host.

Short answer: enable MIG with sudo nvidia-smi -i 0 -mig 1, create instances with sudo nvidia-smi mig -cgi <profiles> -C, then point each workload at its own MIG device using the MIG-<UUID> shown by nvidia-smi -L. On Hopper and newer GPUs, MIG mode does not persist across reboots, so automate it with NVIDIA's mig-parted tool.

Last updated October 2026 and checked against NVIDIA's Multi-Instance GPU User Guide (revised September 2026). Profile names, driver minimums and supported GPUs change with new hardware, so confirm them on your own server with nvidia-smi mig -lgip.

In this tutorial

What MIG is and why use it

MIG is a hardware feature of NVIDIA data-center GPUs, introduced with the Ampere generation. It divides one GPU into as many as seven independent GPU instances. Each instance gets its own streaming multiprocessors (SMs), its own slice of memory, and its own paths through the memory system. A job running in one instance cannot read another instance's memory, and a crash or memory overrun in one instance does not take down its neighbors.

That hardware-level isolation is what separates MIG from software sharing. It gives you predictable performance (quality of service) and clean separation between tenants, teams or services.

Common reasons to partition a GPU dedicated server this way:

MIG needs administrator access to the host, because you enable it at the driver level. That is trivial on a dedicated server with root access, and usually not possible on shared or virtualized GPU services where the provider controls the hardware. If you are weighing server options, our GPU dedicated servers for AI workload-matching guide explains how to match GPU memory and compute to your workload.

Which GPUs support MIG

MIG works only on GPUs starting with the NVIDIA Ampere generation (compute capability 8.0 or higher), and only on products NVIDIA lists as supported. According to NVIDIA's current documentation:

GeForce RTX cards and GPUs that are not on NVIDIA's supported list, as of this writing, cannot use MIG. If you plan to buy or rent hardware specifically for partitioning, compare options in our guides to B200 vs H100 dedicated servers and the NVIDIA RTX PRO 6000 Blackwell on dedicated servers.

MIG vs time-slicing vs MPS

MIG is one of several ways to share a GPU. Picking the right one depends on how much isolation you need.

MIG and MPS can also be combined: NVIDIA documents running one MPS server per MIG instance for workloads that benefit from it.

Before you start

You need:

If you have an RTX PRO 6000 or RTX PRO 5000 Blackwell workstation-class card, there are two extra requirements: the GPU's vBIOS must meet NVIDIA's minimum version, and for the Workstation and Max-Q Workstation editions the display mode must be switched from graphics to compute with NVIDIA's DisplayModeSelector tool before MIG can be enabled. On a single-card system that disables physical display output, so make sure you have SSH access first.

Step 1: Confirm your GPU and driver

Check that the driver sees your GPU and shows the MIG mode state:

You should see your GPU model, a driver version that meets the minimum above, and Disabled in the MIG column. MIG is off by default.

If nvidia-smi is not found or reports no devices, finish your driver and CUDA installation first. A step-by-step driver setup is the first prerequisite for every other GPU tutorial.

Step 2: Enable MIG mode

Enable MIG on a specific GPU by index (here, GPU 0):

A successful run prints Enabled MIG Mode for GPU .... Confirm it:

Omit -i to apply the change to every GPU in the server. Behavior differs by GPU generation, and the difference matters later:

If the command warns that MIG mode is "in pending enable state" because the GPU is in use by another client, stop whatever is using the GPU (CUDA jobs, monitoring agents such as DCGM, or even another nvidia-smi session), then retry. Rebooting also makes the change take effect.

Step 3: Choose your MIG profiles

A profile defines the size of a GPU instance. Names follow the pattern Ng.Mgb, where N is the number of compute slices and M is the memory in gigabytes. So 3g.40gb means three compute slices and roughly 40 GB of memory.

List the profiles your GPU supports:

The output shows each profile's ID, how many instances you can create, its memory, and its SM count. To see how instances can physically be placed on the GPU, list the placements:

For reference, the main profiles on an H100 80 GB look like this. Other GPUs use different sizes, so always trust -lgip on your own machine:

How to pick sizes. Memory is usually the limiting factor, so size by VRAM first:

Step 4: Create GPU instances and compute instances

Creating MIG devices takes two layers: GPU instances (GIs), which carve out memory and SMs, and compute instances (CIs), which are the schedulable compute inside a GI. The -C flag creates a default compute instance for each GPU instance automatically.

You can name profiles by ID (for example 9), by short name (3g.40gb), or by full name (MIG 3g.40gb). Create two equal halves on an H100 80 GB:

Or seven small instances for lightweight inference:

Or a mixed layout:

Two practical notes from NVIDIA's documentation:

Step 5: Verify the MIG devices

List the MIG devices and their UUIDs:

You will see the parent GPU followed by one MIG ... Device N: (UUID: MIG-xxxxxxxx-...) line per instance. Copy these UUIDs, because that is how you assign workloads.

To inspect the layers separately:

Step 6: Run workloads on MIG devices

Directly on the host

Select a MIG device with the CUDA_VISIBLE_DEVICES environment variable, using the MIG UUID:

Each process sees only its own slice and its own memory limit. A single CUDA process works with one MIG device, so you cannot combine slices into one larger device. If a job needs more memory or compute, choose a bigger profile instead.

In Docker containers

With the NVIDIA Container Toolkit installed, give each container its own MIG device with the --gpus flag, using either the MIG UUID or the GPUindex:MIGindex format:

Replace <tag> with a current CUDA image tag from Docker Hub. Inside each container, nvidia-smi -L lists exactly one MIG device. This is the cleanest way to hand a dedicated slice to each tenant, team or service. For larger container platforms, see our guide to dedicated servers as the foundation for Kubernetes clusters.

Step 7: Make your MIG layout persistent

This is the step most tutorials skip, and it is why a working MIG setup can seem to vanish after a reboot. Two separate things are involved:

So after a reboot you must re-enable MIG mode (on Hopper+) and recreate the layout. NVIDIA's recommended tool for this is MIG Partition Editor (mig-parted), which applies a declarative layout and can run as a systemd service at startup.

A minimal configuration file looks like this:

Apply a named layout:

Install mig-parted from NVIDIA's repository at github.com/nvidia/mig-parted, and follow its README to run the layout as a boot-time service. After a reboot, run nvidia-smi -L and confirm the MIG devices are back before starting any workload.

Note that MIG UUIDs can change when instances are recreated. Scripts and container definitions that hard-code a MIG-<UUID> need to look it up again, or use the stable GPUindex:MIGindex form where it fits.

Step 8: Monitor MIG devices

Plain nvidia-smi shows per-instance memory and which process is running where, but it does not attribute GPU utilization to individual MIG devices, and utilization often shows N/A. For real per-instance metrics, NVIDIA recommends DCGM (Data Center GPU Manager) version 3 or later.

A common production setup is DCGM exporting metrics to Prometheus, with Grafana dashboards per MIG instance, so you can see which tenant is saturating its slice. For tooling options and how GPU metrics fit into the rest of your server monitoring, see our overview of dedicated server management tools.

Step 9: Change or remove your MIG layout

You can reconfigure MIG dynamically while the GPU stays in MIG mode, but only when no workload is using the instances you are changing. Stop jobs and containers first. Then destroy the compute instances, followed by the GPU instances:

Create a new layout with Step 4, or return the GPU to normal operation:

MIG on Kubernetes and Slurm

If you schedule workloads rather than assigning them by hand, MIG integrates with the common orchestrators:

Both are best set up after you have the single-server workflow in this guide working.

Troubleshooting

When MIG is not the right tool

MIG is excellent for isolation, but it is not always the best choice:

If you are still choosing hardware for AI work, our guide to choosing GPU dedicated servers for machine learning covers memory, bandwidth and workload fit in more depth.

FAQ

Conclusion

MIG turns one expensive GPU into several right-sized, isolated ones, so each workload gets guaranteed memory and compute and your hardware stays busy. The workflow is short: enable MIG mode, pick profiles, create GPU and compute instances, assign each workload its own MIG-<UUID>, and automate the layout with mig-parted so it survives reboots.

Start with a simple layout, such as two halves or seven small slices, verify it with nvidia-smi -L, and add DCGM monitoring before you put real tenants on it. If you are planning a deployment, you can compare GPU dedicated server options at COLO BIRD, where you get full root access to configure MIG, containers and monitoring your way.

Last reviewed: October 2026. This tutorial is revisited when NVIDIA changes MIG-supported GPUs, driver requirements or nvidia-smi mig behavior. For the full reference, see NVIDIA's Multi-Instance GPU User Guide.