Is this page helpful?

Deployment Considerations#

MIG functionality is provided as part of the NVIDIA GPU driver. The minimum driver versions are listed below:

GPU

CUDA Version

NVIDIA Driver Version

A100

CUDA 11

R450 (>= 450.80.02) or later

A30

CUDA 11

R460 (>= 460.73.01) or later

H100

CUDA 12

R525 (>= 525.85.12) or later

H20

CUDA 12

R535 (>= 535.161.07) or later

H200

CUDA 12

R550 (>= 550.90.07) or later

B200, GB200

CUDA 12

R570 (>= 570.133.20) or later

B300

CUDA 12.9

R580 (>= 580.82.07) or later

RTX PRO 6000 Blackwell (all editions)

CUDA 12

R575 (>= 575.51.03) or later

RTX PRO 5000 Blackwell

CUDA 12

R575 (>= 575.57.08) or later

RTX PRO 4500 Blackwell

CUDA 12

R575 (>= 575.64) or later

GB300 (DGX Station)

CUDA 13

R595 (>= 595.58.03) or later

Thor iGPU (Jetson T5000)

CUDA 13

R595, as shipped in JetPack 7.2 (Jetson Linux 39.2), or later

System Considerations#

The following system considerations are relevant for when the GPU is in MIG mode.

  • MIG is supported only on Linux operating system distributions supported by CUDA. It is also recommended to use the latest NVIDIA Datacenter Linux. Refer to the Driver Installation Guide.

    Note

    Also note the device nodes and nvidia-capabilities for exposing the MIG devices. The /proc mechanism for system-level interfaces is deprecated as of 450.51.06 and it is recommended to use the /dev based system-level interface for controlling access mechanisms of MIG devices through cgroups. This functionality is available starting with 450.80.02+ drivers.

  • Supported configurations include:

    • Bare-metal, including containers

    • GPU pass-through virtualization to Linux guests on top of supported hypervisors

    • vGPU on top of supported hypervisors

    MIG allows multiple vGPUs (and thereby VMs) to run in parallel on a single A100, while preserving the isolation guarantees that vGPU provides. For more information on GPU partitioning using vGPU and MIG, refer to the technical brief.

  • Setting MIG mode on the A100/A30 requires a GPU reset (and thus super-user privileges). Once the GPU is in MIG mode, instance management is then dynamic. Note that the setting is on a per-GPU basis.

  • On NVIDIA Ampere architecture GPUs, similar to ECC mode, MIG mode setting is persistent across reboots until the user toggles the setting explicitly

  • All daemons holding handles on driver modules need to be stopped before MIG enablement. This includes monitoring daemons such as DCGM and nvsm, and on workstations, the desktop session (display manager / Xorg), which nvidia-smi might not list as a GPU process.

  • This is true for systems such as DGX which may be running system health monitoring services such as nvsm or GPU health monitoring or telemetry services such as DCGM.

  • Toggling MIG mode requires the CAP_SYS_ADMIN capability. Other MIG management, such as creating and destroying GPU and compute instances, requires the mig-config capability, which root holds by default. To delegate it to a group of non-privileged users:

    1. Stop the NVIDIA tools from resetting the permissions of the mig-config device node:

      $ echo "DeviceFileModify: 0" | sudo tee /proc/driver/nvidia/capabilities/mig/config

    2. Give the group read access to that device node. Its minor number is the DeviceFileMinor value in /proc/driver/nvidia/capabilities/mig/config (1 by default):

      $ sudo chgrp <group> /dev/nvidia-caps/nvidia-cap1
$ sudo chmod 0440 /dev/nvidia-caps/nvidia-cap1

    Both settings are lost when the driver reloads or the system reboots, so reapply them at boot. Refer to CUDA Device Enumeration for details on device nodes and capabilities.

Application Considerations#

Users should note the following considerations when the GPU is in MIG mode:

  • No graphics APIs are supported, except on +gfx profiles of RTX PRO 6000 Blackwell (all editions), RTX PRO 5000 Blackwell, RTX PRO 4500 Blackwell, and Thor iGPU (technology preview). Non-+gfx profiles, and all other GPUs, have no graphics support. On +gfx profiles:

    • OpenGL and Vulkan are supported, including headless use through EGL. For graphics in virtual machines (vWS profiles), refer to the vGPU documentation.

    • The minimum driver is the same as the GPU’s row in the minimum driver table above.

    • MIG instances have no display output.

    • On Workstation and Max-Q editions, switch the GPU to compute display mode with DisplayModeSelector first.

    • Bare-metal MIG is Linux only.

    • Video encode/decode is set by +me/-me, not +gfx.

  • With driver R570, only P2P between MIG instances on the same GPU is supported. P2P between MIG instances on different GPUs, or between MIG instances to non-MIG mode GPU devices are not supported.

  • CUDA IPC across GPU instances is not supported. CUDA IPC across Compute instances is supported.

  • CUDA debugging (e.g. using cuda-gdb) and memory/race checking (for example, using cuda-memcheck or compute-sanitizer) is supported.

  • CUDA MPS is supported on top of MIG. The only limitation is that the maximum number of clients (48) is lowered proportionally to the Compute Instance size.

  • GPUDirect RDMA is supported when used from GPU Instances.

  • NCCL 2.31 and later provide experimental support for MIG. Each rank must use a distinct MIG instance, the CUDA driver must be version 13.0 or later, and Multi-Node NVLink must be disabled (NCCL_MNNVL_ENABLE=0). For details, refer to Using MIG instances in the NCCL User Guide.

  • Profiling of shared GPU resources is not supported. This is an existing limitation.