A100-MIG-Layouts auf H200 NVL und RTX PRO 6000 übertragen: Profile, GPU Operator, Slurm

Die Zuordnung der Profile

Ein A100-MIG-Layout lässt sich fast eins zu eins auf die H200 NVL übertragen: Beide lassen sich aus acht Speicher- und sieben SM-Slices in bis zu sieben Instanzen aufteilen, und zu jedem Profil der A100 80 GB gibt es ein H200-Profil mit derselben Form und rund 1,75-mal so viel Speicher. Die NVIDIA RTX PRO 6000 Blackwell lässt sich dagegen in Viertel teilen, höchstens vier Instanzen zu 24 GB; ein A100-Layout mit sieben Instanzen hat dort keine direkte Entsprechung, und die Mandanten werden auf weniger, größere Instanzen verteilt.

Die Tabellen stammen aus NVIDIAs MIG User Guide, Stand 13. Oktober 2026, der die drei Editionen der RTX PRO 6000 in einer Tabelle führt.

NVIDIA MIG User Guide, „Supported MIG Profiles“, Tabellen für A100, H200 141GB und RTX PRO 6000 Blackwell, Stand 13. Oktober 2026, gelesen am 24. Oktober 2026. Für die A100 80 GB nennt der Guide die Profile der 40-GB-Tabelle, nach Speicher umbenannt. Die Spalte RTX PRO 6000 ist unsere Zuordnung nach Speicher; die Anzahl ist das Maximum je Karte laut Guide.

Die H200-Zeilen haben denselben Aufbau wie die A100-Tabelle, Achtel des Speichers und Siebtel der SMs: Ein 1g-Profil ist ein SM-Slice, 1g.35gb verbindet zwei Speicher-Slices mit einem SM-Slice, und 3g und 4g nehmen beide die Hälfte des Speichers. Auf der RTX PRO 6000 ist jedes Profil eine ganze Zahl von Vierteln, bei Speicher, L2-Cache und SMs gleichermaßen; jede der drei Größen gibt es zusätzlich als +gfx-Variante für Grafik-APIs, Viertel und Hälfte auch als -me ohne Media-Engines. Unsere Übersichten zu den MIG-Profilen der H200 NVL und den MIG-Profilen der RTX PRO 6000 führen jede Variante; dieser Leitfaden behandelt den Umzug.

Umgebungen mit A100 40 GB brauchen einen Schritt mehr. Für diese Karte führt der Guide 1g.5gb bis zu siebenmal, 1g.10gb bis zu viermal, dann 2g.10gb, 3g.20gb, 4g.20gb und 7g.40gb; der Name 1g.10gb bezeichnet also auf einer 80-GB-Karte die kleinste Instanz und auf einer 40-GB-Karte eine mit doppeltem Speicher. Die ConfigMap des GPU Operator bildet das ab: Ihr Layout all-1g.10gb legt auf der A100 80 GB sieben Instanzen an, auf der A100 40 GB vier. In einer gemischten A100-Umgebung prüfen Sie daher vor der Übertragung, für welche Karte ein Layoutname geschrieben wurde.

Speicher und Instanzen je Server, vorher und nachher

Die Zahl im Profilnamen ist ein Nennwert. Die nvidia-smi-Ausgabe im Guide für die A100 40 GB zeigt 4,75 GiB für 1g.5gb, 9,62 GiB für 1g.10gb und 39,25 GiB für 7g.40gb. NVIDIAs H200-Seite gibt der H200 NVL „Up to 7 MIGs @16.5GB each“. Auf einer RTX PRO 6000 Server Edition zeigte eine von NETWAYS Web Services im Dezember 2025 veröffentlichte nvidia-smi-Ausgabe 23,62 GiB für 1g.24gb, 47,38 GiB für 2g.48gb und 95,00 GiB für 4g.96gb.

Unsere Multiplikation der Höchstzahlen je Karte laut Guide; Speicher wie oben angegeben.

Ein Plattformteam, das je A100 sieben kleine Instanzen vergibt, behält diese Zahl auf der H200 NVL und gewinnt je Instanz 65 Prozent mehr Speicher, nach unserer Division von 16,5 durch 10 GB. Auf der RTX PRO 6000 bietet ein Server mit gleicher Kartenzahl vier Instanzen, wo die A100 sieben bot, jede mit rund dem Zweieinhalbfachen der nominalen 10 GB. Die Rechenleistung je Instanz verschiebt sich ebenso: Eine 1g-Instanz der H200 ist ein Siebtel einer Karte, die das Kempner Institute bei BF16-Matrixprodukten mit 696 TFLOPS gemessen hat, gegenüber 267 für eine A100 40 GB, und eine 1g-Instanz der RTX PRO 6000 ist ein Viertel einer Karte mit gemessenen 386 TFLOPS, laut Handbuch mit Stand 15. Juli 2026.

Welche A100-Mandanten wohin gehören

Die Zuordnung nach Speicher ist ein Ausgangspunkt. Die Wahl je Mandant hängt davon ab, was in der Instanz läuft.

• Notebooks und kleine Experimente auf 1g.10gb: 1g.18gb auf der H200 NVL, wie bisher sieben je Karte.
• Embedding- und Reranking-Dienste: beide Ziele; auf der RTX PRO 6000 lässt eine Instanz 1g.24gb-me die Media-Engines weg, die der Dienst nicht nutzt.
• Ein 14B-Modell in FP8 auf 2g.20gb: 2g.35gb auf der H200 NVL oder 1g.24gb auf der RTX PRO 6000, wo Qwen3-14B in FP8 nach unserer Regel Platz für rund vier Gespräche mit 8K lässt, oder 2g.48gb für rund 39.
• Ein 32B-Modell in FP8 auf 3g.40gb oder 4g.40gb: 3g.71gb oder 4g.71gb auf der H200 NVL, 2g.48gb auf der RTX PRO 6000.
• Rendering oder Visualisierung: nur die +gfx-Profile der RTX PRO 6000; NVIDIAs Guide hält fest, dass MIG-Instanzen keine Grafik-APIs unterstützen, außer auf der RTX PRO 6000 Blackwell.
• Jobs über mehrere GPUs: auf beiden Zielen ganze Karten ohne MIG, da „NCCL is currently not supported with MIG“.

Modellgrößen und Cache-Werte je Instanz stehen in unseren MIG-Übersichten zur RTX PRO 6000 und zur H200 NVL. Wir liefern beide Karten und bauen Server damit; senden Sie uns Ihr heutiges A100-Layout je Knoten und was in jeder Instanz läuft, und unser Team schickt Ihnen das Layout für die neuen Karten mit einer Konfiguration zurück.

Was sich im GPU Operator ändert

Der MIG Manager des GPU Operator wendet das Layout an, das im Node-Label nvidia.com/mig.config steht, und meldet den Fortschritt in nvidia.com/mig.config.state, von pending bis success. NVIDIAs Dokumentation, Stand 14. Oktober 2026 für Operator v26.7.2, hält fest, dass der MIG Manager seit v26.3.0 die Layouts jedes Knotens zur Laufzeit aus dessen Hardware erzeugt, in einer ConfigMap mit dem Namen des Knotens: all-disabled, all-enabled, ein Layout all-<Profil> je Profil und all-balanced. Auf älteren Treibern, etwa aus dem Branch 535, greift der Operator auf die statische default-mig-parted-config zurück.

Für den Umzug folgen daraus drei Dinge.

1. Layoutnamen ändern sich. Ein Node-Label wie all-1g.10gb oder all-3g.40gb hat auf einem Knoten mit H200 NVL oder RTX PRO 6000 keine Bedeutung. Die neuen Namen sind all-1g.18gb, all-3g.71gb, all-1g.24gb, all-2g.48gb usw.; nur all-disabled, all-enabled und all-balanced behalten ihren Namen, mit anderer Aufteilung je Karte.
2. Eigene Layouts brauchen neue Gerätefilter. Eine eigene ConfigMap, gesetzt über migManager.config.name und mit dem Schlüssel config.yaml, wählt Karten nach PCI-Device-ID aus. In NVIDIAs statischer ConfigMap führt der Filter der A100 80 GB 0x20B210DE und 0x20B510DE, der Eintrag für H200 141GB und H200 NVL 0x233510DE und 0x233B10DE und der Eintrag der RTX PRO 6000 0x2BB510DE. Ein Layout, das nur für die A100-IDs geschrieben ist, bewirkt auf den neuen Karten nichts.
3. Ein Layoutwechsel ist Wartung. NVIDIA hält fest: „MIG Manager requires that no user workloads are running on the GPUs being configured“; der Knoten muss unter Umständen gesperrt werden (cordon), und manche Plattformen brauchen einen Neustart, den der MIG Manager ausführt, wenn seine Einstellung WITH_REBOOT auf true steht.

Prüfen Sie auch die Support-Liste des Operator: Unser Leitfaden zum GPU-Sharing in Kubernetes fand dort die H200 NVL und die RTX PRO 6000 Server Edition, für die Server Edition mit Treiber 575.57.08 oder neuer und ohne MIG auf genau diesem Treiber-Release, und keinen Eintrag für die Workstation- und Max-Q-Editionen.

Ressourcennamen, Labels und Quotas

Bei der Strategie mixed ist jedes Profil eine eigene Kubernetes-Ressource; ein Pod, der nvidia.com/mig-1g.10gb angefordert hat, fordert nach dem Umzug nvidia.com/mig-1g.18gb oder nvidia.com/mig-1g.24gb an. GPU Feature Discovery veröffentlicht die Anzahl je Profil in Labels wie nvidia.com/mig-1g.10gb.count, und auch diese ändern sich. Device Plugin v0.20.0 stellt die Varianten mit Suffix, -me, +me.all und +gfx, als eigene Ressourcen bereit, was auf der RTX PRO 6000 zählt.

Bei der Strategie single fordern Pods weiter nvidia.com/gpu an, aber das Label nvidia.com/gpu.product trägt das Profil als Suffix, in NVIDIAs Beispiel NVIDIA-H100-80GB-HBM3-MIG-1g.10gb, und Node-Selektoren, die darauf passen, müssen neu geschrieben werden. Single ist für Knoten gedacht, auf denen MIG auf jeder GPU mit einem Profil aktiv ist; ein Knoten mit gemischten Profilen oder einigen ganzen Karten braucht mixed.

Quotas, Admission Policies, Berichte für die Kostenverrechnung und Dashboards, die eine Ressource oder ein Label nennen, erben dieselbe Änderung. Eine Namespace-Quota, die für den A100-Instanznamen geschrieben ist, begrenzt nichts mehr, sobald der Knoten einen neuen Namen anbietet; übertragen Sie sie daher zusammen mit den Layouts. Unser Leitfaden zur gemeinsamen GPU-Plattform mit Kostenverrechnung behandelt die Abrechnungsseite.

Slurm: GRES-Typen und Startreihenfolge

Slurm unterstützt MIG seit Version 21.08. Seine GRES-Dokumentation (Version 26.05) verlangt AutoDetect=nvml in der gres.conf der MIG-Knoten und die Instanzen in der slurm.conf, als wären es GPUs; ein optionaler Typ unterscheidet die Größen und muss ein Teilstring des „MIG Profile“-Strings sein, den der Knoten auf der Stufe debug2 in seinem slurmd-Log meldet. Im Beispiel von Slurm wird aus dem Profilstring nvidia_a100_3g.20gb der Typ a100_3g.20gb.

Lesen Sie auf den neuen Knoten zuerst die Profilstrings aus dem slurmd-Log, bevor Sie die Typen schreiben, und passen Sie dann jede gres-Zeile, die Einträge in AccountingStorageTRES und die Jobskripte und Limits an, die die alten Typen anfordern. Slurm „expects MIG devices to already be partitioned, and does not support dynamic MIG partitioning“; das Layout muss also bestehen, bevor slurmd startet. Unser Leitfaden zum GPU-Server für ein Forschungslabor behandelt die Slurm-Seite ausführlicher.

Neustarts und Persistenz

Startskripte, die für A100 geschrieben wurden, brauchen einen Schritt mehr. NVIDIAs Guide hält fest, dass der MIG-Modus auf Ampere „is persistent across system reboots (there is a status bit stored in the GPU InfoROM)“, während auf Hopper und neuer „MIG mode is no longer persistent across system reboots“. Auf jeder Karte gilt: „the created MIG devices are not persistent across system reboots“, und NVIDIA verweist auf sein Werkzeug mig-parted, als systemd-Dienst ausgeführt, um das Layout beim Start neu anzulegen. Ein Skript, das auf einer A100 nur die Instanzen neu anlegte, muss auf einem Knoten mit H200 NVL oder RTX PRO 6000 auch den MIG-Modus einschalten. Auf der Workstation- und der Max-Q-Edition der RTX PRO 6000 braucht MIG zusätzlich den Compute-Display-Modus, wie unsere MIG-Anleitung für RTX PRO Blackwell zeigt.

MIG-basierte vGPU

Für virtuelle Maschinen folgen die vGPU-Typen den Profilen. Der Typ, der die kleinste Instanz der A100 80 GB füllt, ist A100D-1-10C; auf der H200 NVL ist es H200-1-18C, bis zu sieben je GPU, und auf der RTX PRO 6000 Server Edition, der einzigen Edition mit MIG-basierter vGPU, füllt DC-1-24C eine Instanz 1g.24gb, mit kleineren Typen im Zeitscheibenverfahren darin. Alle sind Compute-Typen unter NVIDIA AI Enterprise; bei der H200 NVL ist ein Abonnement über fünf Jahre enthalten. NVIDIA weist darauf hin: „The target host must have a matching MIG configuration“ für die Live-Migration; stellen Sie die Hosts eines Clusters daher gemeinsam auf das neue Layout um und lassen Sie die Hypervisor-Unterstützung für die H200 NVL vorher von NVIDIA bestätigen, wie unser Leitfaden zu MIG und vGPU erklärt.

Rechenbeispiel: ein A100-Knoten mit acht Karten

Als Beispiel betreibt ein Knoten mit acht A100 80 GB die Karten 1 und 2 als all-1g.10gb für Notebooks, die Karten 3 bis 6 als all-balanced für Dienste und die Karten 7 und 8 ganz für Jobs über mehrere GPUs: 14 Notebook-Instanzen, 16 Instanzen für Dienste und zwei ganze Karten.

Auf acht H200 NVL lässt sich derselbe Plan mit umbenannten Profilen übernehmen: 14 Instanzen 1g.18gb, 16 Instanzen aus 1g.18gb, 2g.35gb und 3g.71gb im Layout all-balanced und zwei ganze Karten, die in derselben 4-Wege-NVLink-Domäne sitzen können. Auf acht RTX PRO 6000 Server Edition brauchen 14 Notebooks vier Karten in Vierteln, 16 Instanzen; zwei Karten in all-balanced ergeben vier 1g.24gb und zwei 2g.48gb, und zwei Karten bleiben ganz. Das deckt die Notebooks mit zwei freien Vierteln ab und sechs Dienst-Instanzen statt sechzehn; Dienste ziehen also in weniger, größere Instanzen um oder auf ganze Karten mit mehreren Modellen. Beide Knoten brauchen die Strategie mixed. Die Zahlen sind ein Beispiel; entscheidend ist die Spitzenlast in Ihrem Scheduler.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team dimensioniert die Konfiguration nach Ihrer Arbeitslast und Ihrem Budget und antwortet innerhalb eines Werktages. Wir liefern die H200 NVL mit ihren NVLink-Brücken und die RTX PRO 6000 Server Edition, als Karten oder in KI-Servern nach Auftrag mit vier oder acht davon, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung und Herstellergarantie auf jede Komponente, und installieren auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime. NVIDIA-AI-Enterprise- und vGPU-Lizenzen können auf derselben Rechnung stehen. Die A100 liefern wir nicht. Zur Systemseite eines A100-Austauschs siehe 8-GPU-Server mit A100 SXM ersetzen und A100-PCIe-Karten ersetzen.

FAQ