Moving A100 MIG layouts to H200 NVL and RTX PRO 6000: profiles, GPU Operator and Slurm

The profile mapping

An A100 MIG layout moves almost one to one to the H200 NVL: both split into up to seven instances from eight memory slices and seven SM slices, and each A100 80 GB profile has an H200 profile with the same shape and about 1.75 times the memory. The NVIDIA RTX PRO 6000 Blackwell splits into quarters instead, at most four instances of 24 GB, so a seven-way A100 layout has no direct equivalent there and tenants are regrouped into fewer, larger slices.

The tables below come from NVIDIA's MIG user guide, updated on 13 October 2026, which covers the three RTX PRO 6000 editions in one table.

NVIDIA MIG user guide, "Supported MIG Profiles", tables for A100, H200 141GB and RTX PRO 6000 Blackwell, updated 13 October 2026, read on 24 October 2026. The guide gives the A100 80 GB names as the 40 GB table's profiles renamed by memory. The RTX PRO 6000 column is our mapping by memory; counts are the guide's maximum per card.

The H200 rows have the same structure as the A100 table, eighths of the memory and sevenths of the SMs: a 1g profile is one SM slice, 1g.35gb pairs two memory slices with one SM slice, and 3g and 4g both take half of the memory. On the RTX PRO 6000 every profile is a whole number of quarters, of memory, L2 cache and SMs alike, each of the three sizes also exists as a +gfx variant for graphics APIs, and the quarter and the half as -me without media engines. Our references for the H200 NVL MIG profiles and the RTX PRO 6000 MIG profiles list every variant; this guide covers the move.

A100 40 GB estates need one more step. On that card the guide lists 1g.5gb up to seven times, 1g.10gb up to four times, then 2g.10gb, 3g.20gb, 4g.20gb and 7g.40gb, so the name 1g.10gb means the smallest slice on an 80 GB card and a double-memory slice on a 40 GB card. The GPU Operator's ConfigMap reflects this: its all-1g.10gb layout creates seven instances on the A100 80 GB and four on the A100 40 GB. In a mixed A100 fleet, check which card a layout name was written for before you translate it.

Memory and slices per server, before and after

The number in a profile name is nominal. The guide's own nvidia-smi listing for the A100 40 GB shows 4.75 GiB for 1g.5gb, 9.62 GiB for 1g.10gb and 39.25 GiB for 7g.40gb. NVIDIA's H200 page gives the H200 NVL "Up to 7 MIGs @16.5GB each". On an RTX PRO 6000 Server Edition, an nvidia-smi output published by NETWAYS Web Services in December 2025 showed 23.62 GiB for 1g.24gb, 47.38 GiB for 2g.48gb and 95.00 GiB for 4g.96gb.

Our multiplication of the guide's maximum counts per card; memory as stated above.

A platform team that hands out seven small slices per A100 keeps that count on the H200 NVL and gains 65 per cent more memory per slice, by our division of 16.5 by 10 GB. On the RTX PRO 6000, a server with the same card count offers four slices for every seven, each with about two and a half times the nominal 10 GB. Compute per slice moves the same way: an H200 1g slice is one seventh of a card that the Kempner Institute measured at 696 TFLOPS in BF16 matrix products, against 267 for an A100 40 GB, and an RTX PRO 6000 1g slice is a quarter of a card measured at 386 TFLOPS, in the handbook last updated on 15 July 2026.

Which A100 tenants go where

The mapping by memory is a starting point. The choice per tenant depends on what runs in the slice.

• Notebooks and small experiments on 1g.10gb: 1g.18gb on the H200 NVL, seven per card as before.
• Embedding and reranking services: either target; on the RTX PRO 6000 a 1g.24gb-me instance leaves out media engines the service does not use.
• A 14B model in FP8 on 2g.20gb: 2g.35gb on the H200 NVL, or 1g.24gb on the RTX PRO 6000, where Qwen3-14B in FP8 leaves room for about four conversations of 8K by our sizing rule, or 2g.48gb for about 39.
• A 32B model in FP8 on 3g.40gb or 4g.40gb: 3g.71gb or 4g.71gb on the H200 NVL, 2g.48gb on the RTX PRO 6000.
• Rendering or visualisation: only the RTX PRO 6000's +gfx profiles; NVIDIA's guide states that MIG instances support no graphics APIs except on the RTX PRO 6000 Blackwell.
• Jobs that span several GPUs: whole cards with MIG off on either target, since "NCCL is currently not supported with MIG".

Model sizes and cache figures for each slice are in our RTX PRO 6000 and H200 NVL MIG references. We supply both cards and build servers with them; send us your current A100 layout per node and what runs in each slice, and our team returns the layout for the new cards with a configuration.

What changes in the GPU Operator

The GPU Operator's MIG Manager applies the layout named in the node label nvidia.com/mig.config and reports progress in nvidia.com/mig.config.state, from pending to success. NVIDIA's documentation, updated 14 October 2026 for Operator v26.7.2, states that since v26.3.0 MIG Manager generates each node's layouts at run time from its hardware, into a ConfigMap named after the node: all-disabled, all-enabled, one all-<profile> layout per profile and all-balanced. On older drivers, such as the 535 branch, the Operator falls back to the static default-mig-parted-config.

Three consequences for a migration follow.

1. Layout names change. A node label such as all-1g.10gb or all-3g.40gb has no meaning on an H200 NVL or RTX PRO 6000 node. The new names are all-1g.18gb, all-3g.71gb, all-1g.24gb, all-2g.48gb and so on; only all-disabled, all-enabled and all-balanced keep their names, with a different split per card.
2. Custom layouts need new device filters. A custom ConfigMap, set through migManager.config.name and holding the key config.yaml, selects cards by PCI device ID. In NVIDIA's static ConfigMap the A100 80 GB filter lists 0x20B210DE and 0x20B510DE, the H200 141GB and H200 NVL entry 0x233510DE and 0x233B10DE, and the RTX PRO 6000 entry 0x2BB510DE. A layout written only for the A100 IDs does nothing on the new cards.
3. Changing a layout is maintenance. NVIDIA states that "MIG Manager requires that no user workloads are running on the GPUs being configured", the node may need to be cordoned, and some platforms need a reboot, which MIG Manager performs when its WITH_REBOOT setting is true.

Check the Operator's support list as well: our Kubernetes GPU sharing guide found the H200 NVL and the RTX PRO 6000 Server Edition on it, with driver 575.57.08 or later for the Server Edition and no MIG on that driver release itself, and no entry for the Workstation and Max-Q editions.

Resource names, labels and quotas

Under the mixed strategy every profile is its own Kubernetes resource, so a pod that asked for nvidia.com/mig-1g.10gb must ask for nvidia.com/mig-1g.18gb or nvidia.com/mig-1g.24gb after the move. GPU Feature Discovery publishes counts per profile in labels such as nvidia.com/mig-1g.10gb.count, and these change too. Device plugin v0.20.0 exposes the suffixed variants, -me, +me.all and +gfx, as separate resources, which matters on the RTX PRO 6000.

Under the single strategy pods keep requesting nvidia.com/gpu, but the nvidia.com/gpu.product label carries the profile as a suffix, in NVIDIA's example NVIDIA-H100-80GB-HBM3-MIG-1g.10gb, and node selectors that match it must be rewritten. Single is meant for nodes where MIG is enabled on every GPU with one profile; a node that mixes profiles, or keeps some cards whole, needs mixed.

Quotas, admission policies, chargeback reports and dashboards that name a resource or a label inherit the same change. A namespace quota written for the A100 slice name stops limiting anything once the node offers a new name, so translate them together with the layouts. Our guide to a shared GPU platform with chargeback covers the accounting side.

Slurm: GRES types and start-up order

Slurm has supported MIG since version 21.08. Its GRES documentation (version 26.05) asks for AutoDetect=nvml in gres.conf on MIG nodes and for the instances in slurm.conf as if they were GPUs; an optional type distinguishes sizes, and it "must be a substring of the "MIG Profile" string as reported by the node in its slurmd log" at the debug2 level. In Slurm's example, the profile string nvidia_a100_3g.20gb becomes the type a100_3g.20gb.

On the new nodes, read the profile strings from the slurmd log before writing the types, then update every gres line, the AccountingStorageTRES entries that track them and the job scripts and limits that request the old types. Slurm "expects MIG devices to already be partitioned, and does not support dynamic MIG partitioning", so the layout must exist before slurmd starts. Our guide to a GPU server for a university research lab covers the Slurm side further.

Reboots and persistence

Boot automation written for A100s needs one more step. NVIDIA's guide states that on Ampere MIG mode "is persistent across system reboots (there is a status bit stored in the GPU InfoROM)", while on Hopper and later "MIG mode is no longer persistent across system reboots". On every card "the created MIG devices are not persistent across system reboots", and NVIDIA points to its mig-parted tool, run as a systemd service, to recreate the layout at start-up. A script that only recreated instances on an A100 must also enable MIG mode on an H200 NVL or RTX PRO 6000 node. On the Workstation and Max-Q editions of the RTX PRO 6000, MIG further needs compute display mode, as our MIG setup guide for RTX PRO Blackwell shows.

MIG-backed vGPU

For virtual machines the vGPU types follow the profiles. The type that fills the smallest A100 80 GB instance is A100D-1-10C; on the H200 NVL it is H200-1-18C, up to seven per GPU, and on the RTX PRO 6000 Server Edition, the only edition with MIG-backed vGPU, DC-1-24C fills a 1g.24gb instance, with smaller types time-sliced inside it. All are compute types under NVIDIA AI Enterprise; the H200 NVL includes a five-year subscription. NVIDIA notes that "The target host must have a matching MIG configuration" for live migration, so move hosts to the new layout as a cluster, and confirm hypervisor support for the H200 NVL with NVIDIA first, as our MIG and vGPU guide explains.

Worked example: one eight-card A100 node

As an example, an eight-card A100 80 GB node runs cards 1 and 2 as all-1g.10gb for notebooks, cards 3 to 6 as all-balanced for services and cards 7 and 8 whole for multi-GPU jobs: 14 notebook slices, 16 service slices and two whole cards.

On eight H200 NVL the same plan carries over with renamed profiles: 14 slices of 1g.18gb, 16 balanced slices of 1g.18gb, 2g.35gb and 3g.71gb, and two whole cards, which can sit in the same 4-way NVLink domain. On eight RTX PRO 6000 Server Edition, 14 notebooks need four cards in quarters, 16 slices; two cards in all-balanced give four 1g.24gb and two 2g.48gb, and two cards stay whole. That covers the notebooks with two quarters to spare and six service slices instead of sixteen, so services move to fewer, larger instances or to whole cards with several models each. Both nodes need the mixed strategy. The numbers are an example; your scheduler's peak use decides.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We supply the H200 NVL with its NVLink bridges and the RTX PRO 6000 Server Edition, as cards or in AI servers built to order with four or eight of them, assembled and tested before delivery, on one EU contract and invoice with manufacturer warranty on every component, and install the operating system, drivers, CUDA and a container runtime on request. NVIDIA AI Enterprise and vGPU licences can come on the same invoice. We do not supply the A100. For the system side of an A100 replacement, see replacing an eight-GPU A100 SXM server and replacing A100 PCIe cards.

FAQ