MIG on the RTX PRO 6000 and other RTX PRO Blackwell cards: step by step, and back again

What each card needs

All three RTX PRO 6000 editions support MIG. To enable it you need Linux, driver 575.51.03 or later and, on the Workstation and Max-Q editions, a minimum vBIOS and the display mode switched to compute; nvidia-smi then splits the card into up to four instances of 24 GB (profile 1g.24gb), two of 48 GB (2g.48gb) or one of 96 GB (4g.96gb). NVIDIA’s MIG user guide, in its version of 4 November 2026, also lists the 48 GB RTX PRO 5000 with two instances of 24 GB and the RTX PRO 4500 with two of 16 GB. The RTX 6000 Ada and the RTX PRO 4000 and 2000 are not on its list of supported GPUs. MIG runs only on Linux: “MIG is supported only on Linux operating system distributions supported by CUDA.” For the RTX PRO 6000 the guide sets driver R575, 575.51.03 or later, as the minimum, for the RTX PRO 5000 575.57.08 and for the RTX PRO 4500 575.64, and it recommends installing the latest data-centre driver. As of 5 November 2026 the newest releases are 580.196.07 on the long-term R580 branch (supported to June 2028), 595.112.07 on the R595 branch (to March 2027) and 620.70.06 of 4 November 2026 on the new long-term R620 branch (to September 2029); on R580 and R595, stay at or above 580.178.04 or 595.91.07, the versions fixed in NVIDIA’s security bulletin of 30 September 2026. For the Workstation and Max-Q editions and the RTX PRO 5000 it adds a minimum vBIOS and the display mode switched from graphics to compute. The RTX PRO 6000 Server Edition comes from the factory in display-off mode and skips that step; our edition comparison explains the other differences.

NVIDIA MIG user guide: supported GPUs, supported MIG profiles and getting started, updated 4 November 2026; NVIDIA RTX PRO 5000 datasheet (July 2026) for the 72 GB card. Every profile listed also exists as a +gfx variant. What fits in each instance is in our RTX PRO 6000 MIG profiles guide.

The 72 GB RTX PRO 5000 is not yet in the guide’s tables; its datasheet gives two instances of 36 GB, and NVIDIA’s DisplayModeSelector page lists the RTX PRO 5000 Blackwell among compatible GPUs without naming a tool version. The same page names the RTX PRO 5500 Blackwell Workstation Edition among the cards with MIG; the MIG user guide does not list that card yet, so its profile names and prerequisites are unpublished. For the RTX PRO 4500 the guide lists profiles and, since its update of 4 November 2026, a minimum driver of 575.64, but no vBIOS minimum and no edition; NVIDIA’s DisplayModeSelector page does not name the card, and the workstation card’s datasheet and product page do not mention MIG, unlike the Server Edition’s page. We found no NVIDIA statement that the workstation RTX PRO 4500 supports MIG, so ask for written confirmation before you plan on it.

We supply all three RTX PRO 6000 editions and the RTX PRO 5000 in 48 and 72 GB. Tell us the card you are considering and the machine it goes into, and we will say which card fits before you order.

Step 1: check the driver and the vBIOS

Plain nvidia-smi prints the driver version in its header, and nvidia-smi -q reports it together with the field VBIOS Version; the current nvidia-smi manual marks Driver Version as deprecated in favour of KMD Version, so look for either name. NVIDIA’s GPU Operator support page also notes, for the Server Edition, that MIG is not supported on the 575.57.08 release. NVIDIA’s MIG guide reads the vBIOS with nvidia-smi and the options --query-gpu=vbios_version and --format=csv. If the card is below the minimum in the table, the guide says to contact your reseller or system provider for the update.

Step 2: switch the display mode to compute

NVIDIA’s guide is explicit: “Display mode by default will be set to graphics, this must be set to compute before MIG can be enabled for Workstation Edition and Max-Q Workstation Edition GPUs.” The tool for this is DisplayModeSelector, 1.72 or later according to the guide, which NVIDIA’s developer site provides after approval. Its FAQ carries three warnings: “A system (workstation or server) needs to be specifically qualified for any non-default mode”, you should confirm with the system maker that the mode is supported, and “Misuse of the tool can permanently damage the GPU without the option to return to the default configuration.”

The guide gives the command as sudo ./DisplayModeSelector with --gpumode=compute and --gpu=<GPU_ID>, but does not say how <GPU_ID> is numbered, so in a machine with more than one NVIDIA GPU, confirm which card the tool selects before you switch. NVIDIA’s vGPU guide writes the tool’s name as displaymodeselector, and Linux file names are case-sensitive, so use the name of the file in your download. After the switch the card drives no displays. Where it is the primary display adapter of a single-card workstation, compute mode “will disable physical display output”, so make sure SSH access works first, as the MIG guide says. Such a workstation then needs another graphics adapter for its monitor.

Compute mode can also change the card’s BAR1 address space. NVIDIA’s Server Edition product brief of June 2025 gives “BAR1: 128 GiB (Display Off mode; default)”; for the Workstation and Max-Q editions NVIDIA publishes no BAR1 figure in either mode. Whether a system can map a large BAR1 range depends on its BIOS, so confirm the mode with the system maker first, as NVIDIA’s FAQ asks. NVIDIA’s MIG guide lists no restart after the switch. We advise one, by our own reasoning: the system BIOS assigns the BAR1 range at start-up. After the restart, the Total under BAR1 Memory Usage in nvidia-smi -q shows whether the change took effect. Before you order, we check the platform, power and cooling of the system the card goes into. Send us the system you plan to switch to compute mode, and our team will help.

Step 3: enable MIG and create the instances

In compute mode, enable MIG with sudo nvidia-smi -i 0 -mig 1, where 0 is the GPU index in this example; without -i it applies to every GPU in the system. The -i option also accepts PCI bus IDs or UUIDs, which the nvidia-smi manual recommends for consistency, because the index order is not guaranteed to stay the same between reboots. From the Hopper generation on, enabling MIG needs no GPU reset. Stop anything that holds the driver first: the guide says all daemons with handles on the driver modules must be stopped, and shows it for NVIDIA’s own nvsm and dcgm services. On workstations this includes the desktop session (display manager or Xorg), which, as the guide notes, nvidia-smi might not list as a GPU process. Then check with nvidia-smi -i 0, adding --query-gpu=pci.bus_id,mig.mode.current and --format=csv: the answer should read Enabled.

MIG mode alone creates no device that CUDA can use. nvidia-smi mig -lgip lists the GPU instance profiles with their IDs, and nvidia-smi mig -lgipp the placements the card accepts. sudo nvidia-smi mig -cgi then creates GPU instances from a comma-separated list of profile IDs, short names such as 1g.24gb or full names such as MIG 1g.24gb, and the option -C creates the corresponding compute instances with them. As examples, four quarters of an RTX PRO 6000 are the short name 1g.24gb listed four times, and the two halves of an RTX PRO 4500 are 1g.16gb listed twice. On the 72 GB RTX PRO 5000, take the names from -lgip on the card itself, since the guide has none yet. sudo nvidia-smi mig -lgi lists the GPU instances that exist.

The profile variants decide what an instance gets besides compute and memory. On the RTX PRO 6000, a plain 1g.24gb has one video decoder, one encoder and one JPEG engine. The +gfx variants add support for graphics APIs, which plain MIG instances lack; NVIDIA’s examples are OpenGL and Vulkan. The +me variant adds the optical flow accelerator to one 1g.24gb instance, +me.all gives a single instance all the media engines, and -me leaves them out for pure compute. A GPU instance can be divided further into compute instances with -cci, but these share the instance’s memory and engines, so separate workloads belong in separate GPU instances.

Step 4: use the instances from CUDA and containers

nvidia-smi -L lists every MIG device with a UUID in the form MIG-<UUID>. CUDA picks devices through CUDA_VISIBLE_DEVICES, which accepts these UUIDs, at most one compute instance per GPU instance; since CUDA 12 and driver R570, one process can use several GPU instances, but only one compute instance in each. For containers, NVIDIA’s guide sets NVIDIA_VISIBLE_DEVICES to the MIG UUID or to the index form GPU:MIG, such as 0:0, and runs Docker with --runtime=nvidia; Docker 19.03 and later also accept these names through the --gpus option. In Kubernetes the device plugin does this for you, with the strategies described in our Kubernetes GPU sharing guide.

The limits matter for planning, as NVIDIA’s MIG guide (updated 4 November 2026) lists them: NCCL support for MIG is experimental, from NCCL 2.31 (one rank per MIG instance, CUDA driver 13.0 or later, NCCL_MNNVL_ENABLE=0), peer-to-peer works only between instances on the same GPU (driver R570), and CUDA IPC does not cross GPU instances. MIG is for workloads that fit into one instance, which is also how our MIG and vGPU comparison sizes them.

What a reboot resets, and how to make MIG persistent

The display mode is a setting on the card and stays until you change it; NVIDIA’s vGPU guide notes that a card supplied in display-off mode might be in a display-enabled mode if its mode was changed before. MIG mode and its instances do not persist in the same way. For Hopper and later GPUs, NVIDIA’s guide says that MIG mode “is only persistent as long as the driver is resident in the system”, so a reboot, or unloading and reloading the kernel modules during a driver update, turns it off, and the GPU and compute instances are gone as well.

NVIDIA’s answer is its MIG Partition Editor, nvidia-mig-parted. It applies a named layout from a YAML file, in which each layout lists the devices, sets mig-enabled and gives the profiles and their counts under mig-devices. The command nvidia-mig-parted apply, with -f for the file and -c for the layout name, puts a layout in place, and a layout with mig-enabled set to false turns MIG off again. The tool alone does not persist anything across reboots; its README points to a systemd service that wraps it, and NVIDIA’s MIG guide suggests the same to recreate the layout at start-up. In Kubernetes, the GPU Operator’s MIG Manager does the job from a node label, but as of October 2026 we found no entry for the RTX PRO 6000 Workstation and Max-Q editions or the RTX PRO 5000 on the Operator’s support list. We found no mention of the display mode in the documentation of either tool, so that step stays manual.

Errors and their documented causes

One message is worth recognising: “Unable to enable MIG Mode for GPU …: Not Supported” from the enable command.

NVIDIA MIG user guide (updated 4 November 2026) and DisplayModeSelector page with its FAQ (read 5 November 2026).

Reverting to a graphics card

Undo the steps in reverse order, with no workloads on the card. Destroy the compute instances with sudo nvidia-smi mig -dci and then the GPU instances with sudo nvidia-smi mig -dgi, a pair NVIDIA’s guide runs together. Disable MIG with sudo nvidia-smi -i 0 -mig 0, NVIDIA’s example for GPU 0 in its AI Enterprise documentation, whose prerequisites ask for root privileges and for no CUDA application, monitoring tool or nvidia-smi command to be using the GPU at that moment. Finally, switch the card back with sudo ./DisplayModeSelector, --gpumode=graphics and --gpu=<GPU_ID>, and restart as after the first switch. Graphics is the default mode, in which the card drives its display outputs again.

What we supply

We supply the RTX PRO 6000 in all three editions (Workstation, Max-Q and Server Edition), the RTX PRO 5000 in 48 and 72 GB, and the RTX PRO 4500, for which NVIDIA’s guide gives MIG profiles and a minimum driver but names no edition, across the EU with manufacturer warranty, as cards or in workstations and AI servers built to order. Quantities and lead time are confirmed in writing with the quote.

FAQ