MIG on RTX PRO Blackwell workstation cards: step by step, and back again

What each card needs

NVIDIA’s MIG user guide, last updated on 11 September 2026, lists all three RTX PRO 6000 editions, the RTX PRO 5000 and the RTX PRO 4500 as MIG-capable. MIG runs only on Linux: “MIG is supported only on Linux operating system distributions supported by CUDA.” For the RTX PRO 6000 and 5000 the guide sets driver R575, 575.51.03 or later, and 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 11 September 2026; NVIDIA RTX PRO 5000 datasheet (June 2026) for the 72 GB card. Every profile listed also exists as a +gfx variant.

The 72 GB RTX PRO 5000 is not yet in the guide’s tables; its datasheet gives two instances of 36 GB, and NVIDIA staff confirmed in May 2026 that it needs DisplayModeSelector 1.76 or later. For the RTX PRO 4500 the guide lists profiles but no prerequisites of its own, NVIDIA’s DisplayModeSelector page does not name it, and the workstation card’s datasheet and product page do not mention MIG, unlike the Server Edition’s page. We found no NVIDIA statement on what a workstation RTX PRO 4500 needs for MIG, so ask for written confirmation before you plan on it.

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. The case is real: owners reported RTX PRO 6000 cards on vBIOS 98.02.52.00.02, below the 98.02.55.00.00 the Workstation Edition requires, on NVIDIA’s developer forum in 2025 and again in June 2026.

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. Afterwards 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; an answer on NVIDIA’s developer forum in January 2026 adds that such a workstation needs another GPU for its display.

The card also claims far more address space. The same answer explains that the switch changes BAR1 on RTX PRO 6000 workstation boards from 256 MB to 64 GB and that whether a system can provide that range is up to its BIOS, adding that systems certified for the Server Edition will manage it. The answer also calls 64 GB the Server Edition’s default, but NVIDIA’s Server Edition product brief of June 2025 gives “BAR1: 128 GiB (Display Off mode; default)”. In the same thread, a user reported POST failures on incompatible platforms, where the cards had to be moved to a compatible system to be switched back, 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 from that forum answer: the BAR1 range comes from the system BIOS, which assigns it at start-up. After the restart, the Total under BAR1 Memory Usage in nvidia-smi -q shows whether the change took effect.

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. 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 gives CUDA nothing to run on. 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.all variant 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: NCCL is not supported with MIG, 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 undoes, and how to make it stick

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 does not stay. 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. We found no mention of the display mode in the documentation of either tool, so that step stays manual.

Errors and their documented causes

Two messages are worth recognising: “Unable to enable MIG Mode for GPU …: Not Supported” from the enable command, and “Specified GPU mode not supported on this device 0x2BB3” from DisplayModeSelector.

NVIDIA MIG user guide and DisplayModeSelector page (September 2026); NVIDIA developer forum threads of 2025, January 2026, April to May 2026 and June 2026, with NVIDIA staff replies where marked.

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

Eurokommerz supplies the RTX PRO 6000 Workstation Edition and Max-Q, the RTX PRO 5000 in 48 and 72 GB and the RTX PRO 4500 EU-wide with manufacturer warranty, as cards or in configured workstations. Tell us which card should run MIG and in which machine, and ask us for the cards’ vBIOS version in writing before you order.

FAQ