Wer heute einen NVIDIA B200 mietet oder kauft, zahlt für Rechenleistung, die in den meisten Fällen ungenutzt bleibt. Ein einzelner Blackwell-Beschleuniger kostet je nach Anbieter rund 10,60 Dollar pro Stunde, bringt aber genug Speicher und Rechenleistung für mehrere kleinere KI-Workloads gleichzeitig. Genau hier setzt Multi-Instance GPU (MIG) an: Die Technik teilt einen physischen B200 in bis zu sieben isolierte, hardwareseitig getrennte GPU-Instanzen auf. Dieser Artikel zeigt Schritt für Schritt, wie die Einrichtung in der Praxis funktioniert, von der Firmware-Prüfung bis zum laufenden LLM-Inferenz-Workload auf einer MIG-Partition.
Der Hintergrund: NVIDIA hat den B200 als Nachfolger von H100 und H200 positioniert, und viele Rechenzentren in Österreich und Deutschland stehen aktuell vor der Frage, wie sie die teure Blackwell-Hardware effizient auslasten. Eine frühere Analyse zu B200 gegen H200 in Österreich hat bereits gezeigt, wie groß der Leistungssprung ausfällt. Dieser Tutorial-Artikel geht einen Schritt weiter und behandelt die praktische Inbetriebnahme, MIG-Profile, Kubernetes-Integration und die typischen Stolperfallen.
Für IT-Teams in Wien, Linz oder München stellt sich die Frage meist nicht abstrakt, sondern sehr konkret: Ein Forschungsprojekt, ein Kundensupport-Chatbot und ein internes RAG-System sollen alle auf derselben angemieteten B200-Kapazität laufen, ohne dass sich die Budgets für drei separate GPUs summieren. MIG ist dafür der naheliegende Hebel, weil die Partitionierung direkt im Treiber verankert ist und keine Zusatzsoftware von Drittanbietern braucht. Wer die folgenden zehn Schritte einmal sauber durchgeht, kann das Setup danach als Vorlage für jeden weiteren B200-Knoten wiederverwenden, ob als einzelner Server im eigenen Rechenzentrum oder als Teil eines gemieteten Kubernetes-Clusters bei einem Cloud-Anbieter.
Warum sich MIG-Partitionierung beim B200 jetzt lohnt
Der B200 ist der erste Rechenzentrums-Beschleuniger auf Basis der Blackwell-Architektur und markiert einen deutlichen Sprung gegenüber H100 und H200. Er bringt laut NVIDIA und mehreren unabhängigen Anbietern rund 180 GB HBM3e-Speicher bei bis zu 8 TB/s Bandbreite mit, manche Hersteller-Datenblätter nennen sogar 192 GB. Zum Vergleich: Ein H200 kommt auf 141 GB bei 4,8 TB/s, ein H100 auf 80 GB bei 3,35 TB/s. Diese Sprünge bedeuten, dass ein einzelner B200 oft schon ausreicht, um ein 70-Milliarden-Parameter-Modell inklusive vollständigem Key-Value-Cache zu halten, wofür früher mehrere H100-Karten nötig waren.
Das Problem dabei: Nicht jeder Workload braucht die volle Leistung eines B200. Ein Inferenz-Endpoint für ein 7-Milliarden-Parameter-Modell nutzt vielleicht ein Fünftel der verfügbaren Rechenleistung, der Rest liegt brach. MIG löst das, indem es die GPU auf Hardware-Ebene in mehrere Instanzen mit eigenem Speicher, eigenen Streaming-Multiprozessoren und eigenen Cache-Bereichen aufteilt. Jede Instanz läuft komplett isoliert, ein Absturz in einer Partition wirkt sich nicht auf die anderen aus. Für Teams, die mehrere kleinere Modelle parallel betreiben oder GPU-Ressourcen zwischen Abteilungen aufteilen müssen, ist das der wirtschaftlich sinnvollere Weg, statt für jeden Workload eine eigene GPU zu reservieren.
Technisch möglich wird das durch das Dual-Die-Design des B200: Der Chip besteht laut NVIDIA-Datenblatt aus zwei über einen schnellen Interconnect verbundenen Dies mit zusammen 208 Milliarden Transistoren, die sich für das Betriebssystem und den Treiber wie ein einzelner logischer Prozessor verhalten. MIG setzt genau an dieser Architektur an und schneidet definierte Anteile aus Streaming-Multiprozessoren, L2-Cache und Speicher-Controllern heraus, statt Rechenzeit nur software-seitig zu takten. Das unterscheidet den Ansatz grundlegend von simplem Prozess-Scheduling: Eine MIG-Instanz sieht für den Kernel wie eine eigenständige, kleinere GPU aus, inklusive eigener PCI-Device-ID.
B200 vs. H100 und H200: Die technischen Eckdaten im Überblick
Bevor es an die Konfiguration geht, lohnt sich ein nüchterner Blick auf die Zahlen. Die folgende Tabelle fasst die wichtigsten Spezifikationen der drei aktuell relevanten NVIDIA-Rechenzentrumsbeschleuniger zusammen, basierend auf den öffentlich verfügbaren Datenblättern und Anbieterangaben von NVIDIA, Spheron und GPU.fm.
| Merkmal | H100 | H200 | B200 |
|---|---|---|---|
| Architektur | Hopper | Hopper | Blackwell |
| Speicher | 80 GB HBM3 | 141 GB HBM3e | 180 GB HBM3e (teils 192 GB angegeben) |
| Speicherbandbreite | 3,35 TB/s | 4,8 TB/s | 8 TB/s |
| NVLink-Generation | NVLink 4 (900 GB/s) | NVLink 4 (900 GB/s) | NVLink 5 (bis 1,8 TB/s pro GPU) |
| FP4-Leistung (sparse) | nicht unterstützt | nicht unterstützt | ca. 20 PetaFLOPS |
| Typische TDP | ca. 700 W | ca. 700 W | ca. 1.000 W |
| MIG-Unterstützung | Ja, bis zu 7 Instanzen | Ja, bis zu 7 Instanzen | Ja, bis zu 7 Instanzen |
Der Sprung bei der Speicherbandbreite fällt besonders auf: 8 TB/s beim B200 sind mehr als das Doppelte eines H200 und rund 2,4-mal so viel wie beim H100. Für speichergebundene Workloads wie die Inferenz großer Sprachmodelle wirkt sich das direkt auf den Durchsatz aus, weil die Tensor-Cores schneller mit frischen Daten versorgt werden. NVIDIA gibt für ein komplettes DGX-B200-System mit acht GPUs eine aggregierte HBM-Bandbreite von 64 TB/s an, gekoppelt über NVLink der fünften Generation mit 14,4 TB/s Bandbreite zwischen den Karten.
Voraussetzungen: Hardware, Treiber und Software-Versionen
Bevor der erste Befehl eingetippt wird, sollten folgende Voraussetzungen erfüllt sein. Eine fehlende oder zu alte Komponente ist der häufigste Grund, warum eine MIG-Einrichtung beim ersten Versuch scheitert.
| Komponente | Mindestanforderung | Hinweis |
|---|---|---|
| GPU | NVIDIA B200 (Blackwell), alternativ H100/H200 | MIG funktioniert nur auf Rechenzentrums-GPUs, nicht auf Consumer-Karten wie der RTX 5090 |
| NVIDIA-Treiber | Datacenter-Treiber Serie 570 oder neuer | Über nvidia-smi --version prüfen |
| CUDA-Toolkit | CUDA 12.6 oder neuer | Blackwell-Support erfordert aktuelle Toolchain |
| Betriebssystem | Ubuntu 22.04 LTS oder 24.04 LTS | Alternativ RHEL 9.x mit aktuellem Kernel |
| Kubernetes (optional) | Version 1.29 oder neuer | Nur nötig für Cluster-Betrieb mit GPU Operator |
| NVIDIA GPU Operator | Aktuelle Helm-Chart-Version | Automatisiert Treiber- und MIG-Rollout im Cluster |
| Systemrechte | Root-Zugriff bzw. sudo | MIG-Modus-Wechsel erfordert privilegierte Befehle |
Wichtig: MIG ist eine Funktion für Rechenzentrums-GPUs. Wer stattdessen mit einer Consumer-Karte lokal experimentieren will, findet in unserem Artikel zur lokalen KI-Einrichtung mit der RTX 5090 den passenden Einstieg. Für den produktiven Rechenzentrumsbetrieb mit B200, H100 oder H200 gilt dagegen dieser Leitfaden.
Schritt 1: Firmware und Treiber vorbereiten
Zuerst wird geprüft, ob das System die GPU erkennt und welche Treiberversion aktiv ist. Ein veralteter Treiber ist die häufigste Fehlerquelle bei der MIG-Aktivierung auf Blackwell-Hardware, da die Serie 570 und neuer zwingend nötig ist, damit der Kernel-Treiber die neuen Partitionierungsprofile des B200 überhaupt kennt.
# GPU-Erkennung und Treiberversion prüfen
nvidia-smi
# Ausführliche Firmware- und VBIOS-Informationen anzeigen
nvidia-smi -q | grep -A 3 "VBIOS Version"
# CUDA-Version des installierten Toolkits prüfen
nvcc --versionFalls der Treiber zu alt ist, muss er vor dem nächsten Schritt aktualisiert werden. Auf Ubuntu-Systemen geschieht das in der Regel über das offizielle CUDA-Repository von NVIDIA, nicht über die Standard-Paketquellen, da diese oft veraltete Versionen enthalten. Wer generell mit NVIDIA-Treibern arbeitet, findet in unserer Anleitung zur Nvidia-Treiber-Installation die grundlegenden Schritte, die hier als Basis dienen.
Schritt 2: MIG-Modus auf dem B200 aktivieren
Der MIG-Modus ist standardmäßig deaktiviert und muss pro GPU einzeln eingeschaltet werden. Das geschieht über nvidia-smi mit der Option -mig 1. Der Befehl setzt die GPU in einen Reset, danach steht sie im partitionierbaren Zustand bereit.
# MIG-Modus für GPU 0 aktivieren
sudo nvidia-smi -i 0 -mig 1
# Bei mehreren GPUs im System: MIG für alle aktivieren
sudo nvidia-smi -mig 1
# Aktivierung bestätigen
nvidia-smi -i 0 --query-gpu=mig.mode.current --format=csvNach der Aktivierung zeigt nvidia-smi die GPU nicht mehr als einzelnes Gerät, sondern als Container für mehrere mögliche Instanzen. Auf manchen Systemen ist danach ein vollständiger Neustart nötig, weil der Reset über nvidia-smi allein nicht ausreicht, wenn andere Prozesse noch Zugriff auf die GPU halten. Das ist einer der häufigsten Stolperpunkte, mehr dazu im Abschnitt zu den typischen Fehlern weiter unten.
Schritt 3: Die passenden MIG-Profile auswählen
MIG unterteilt die GPU nicht beliebig, sondern nach festen Profilen, die NVIDIA vorgibt. Jedes Profil definiert, wie viel Speicher und wie viele Compute-Slices eine Instanz erhält. Beim B200 mit rund 180 GB Speicher ergeben sich dadurch spürbar großzügigere Profile als bei einem H100 mit 80 GB. Praxisberichte, unter anderem eine Session auf der FOSDEM-Konferenz 2026, empfehlen für Modelle zwischen 5 und 14 Milliarden Parametern in der Regel zwei bis drei sinnvolle Partitionen pro B200, statt die volle Sieben-Instanzen-Aufteilung auszureizen, weil kleinere Slices sonst zu wenig Speicher für den KV-Cache übrig lassen.
# Verfügbare MIG-Profile für GPU 0 auflisten
nvidia-smi mig -i 0 -lgip| Profilname (Beispiel) | Compute-Slices | Speicher pro Instanz | Typischer Einsatzzweck |
|---|---|---|---|
| 1g.23gb | 1/7 | ca. 23 GB | Kleine Modelle, Dev/Test, bis 7B Parameter quantisiert |
| 2g.45gb | 2/7 | ca. 45 GB | Mittlere Modelle, 7B–13B Parameter |
| 3g.90gb | 3/7 | ca. 90 GB | Größere Modelle mit vollem KV-Cache, 13B–34B |
| 4g.90gb | 4/7 | ca. 90 GB | Batch-Inferenz mit hohem Durchsatz |
| 7g.180gb | 7/7 (voll) | ca. 180 GB | Volle GPU, z. B. für Fine-Tuning oder 70B-Modelle |
Die genauen Profilnamen und Speichergrößen unterscheiden sich je nach Treiberversion und GPU-Variante geringfügig, das Prinzip bleibt aber gleich: kleinere Slices für viele parallele leichte Workloads, größere Slices für speicherhungrige Modelle. Wer bereits mit Multi-GPU-Setups experimentiert hat, kennt das Abwägen zwischen Isolation und Auslastung aus unserem Artikel zur Multi-GPU-Workstation für KI, dort allerdings ohne hardwareseitige Partitionierung.
Schritt 4: GPU-Instanzen erstellen
Mit einem gewählten Profil lässt sich jetzt die erste GPU-Instanz (GI) anlegen. Der Befehl -cgi steht für “create GPU instance” und akzeptiert entweder den Profilnamen oder die zugehörige Profil-ID.
# Zwei GPU-Instanzen mit Profil-ID 9 anlegen (Beispiel: 2x 3g.90gb)
sudo nvidia-smi mig -i 0 -cgi 9,9 -C
# Alternativ mit Profilnamen statt ID
sudo nvidia-smi mig -i 0 -cgi 3g.90gb,3g.90gb -C
# Angelegte GPU-Instanzen auflisten
nvidia-smi mig -i 0 -lgiDas Flag -C am Ende erstellt direkt auch die passende Compute-Instanz mit, was den nächsten Schritt in vielen Fällen überflüssig macht. Für mehr Kontrolle, etwa wenn eine GPU-Instanz später mit unterschiedlichen Compute-Profilen genutzt werden soll, empfiehlt es sich, GPU- und Compute-Instanzen getrennt anzulegen.
Schritt 5: Compute-Instanzen zuweisen und verifizieren
Jede GPU-Instanz benötigt mindestens eine Compute-Instanz (CI), damit ein Prozess sie tatsächlich nutzen kann. Der Befehl -cci übernimmt das.
# Compute-Instanz für GPU-Instanz 0 erstellen
sudo nvidia-smi mig -i 0 -gi 0 -cci
# Alle Compute-Instanzen auflisten
nvidia-smi mig -i 0 -lci
# MIG-Geräte-UUIDs für spätere Zuweisung anzeigen
nvidia-smi -LDer letzte Befehl liefert UUIDs im Format MIG-GPU-xxxxxxxx/0/0, die später verwendet werden, um einen Container oder Prozess gezielt an eine bestimmte MIG-Instanz zu binden, etwa über die Umgebungsvariable CUDA_VISIBLE_DEVICES. Ein einfacher Smoke-Test mit nvidia-smi innerhalb der Instanz bestätigt, dass Speicher und Compute-Ressourcen korrekt zugewiesen sind, bevor produktive Workloads darauf laufen.
Schritt 6: NVIDIA GPU Operator für Kubernetes einrichten
Wer die MIG-Instanzen nicht manuell auf einem einzelnen Server verwaltet, sondern in einem Kubernetes-Cluster ausrollen will, braucht den NVIDIA GPU Operator. Er automatisiert Treiber-Rollout, MIG-Konfiguration und das Device-Plugin, das die Instanzen als Kubernetes-Ressourcen sichtbar macht.
# NVIDIA Helm-Repository hinzufügen
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
# GPU Operator mit MIG-Unterstützung installieren
helm install gpu-operator nvidia/gpu-operator \
-n gpu-operator --create-namespace \
--set mig.strategy=mixedDie Strategie mixed erlaubt es, unterschiedliche MIG-Profile gleichzeitig auf einem Knoten zu betreiben, während single nur ein einheitliches Profil pro Knoten zulässt. Für heterogene Workloads, wie sie in den meisten produktiven Umgebungen vorkommen, ist mixed fast immer die richtige Wahl.
Schritt 7: MIG-Slicing im Cluster ausrollen
Nach der Operator-Installation wird das gewünschte MIG-Profil per ConfigMap definiert und dem Knoten über ein Label zugewiesen. Dieser Ansatz folgt dem Muster, das auch Cloud-Anbieter wie UpCloud in ihrer Dokumentation zur MIG-Konfiguration auf Kubernetes beschreiben.
# Knoten mit dem gewünschten MIG-Profil labeln
kubectl label node gpu-node-01 \
nvidia.com/mig.config=all-3g.90gb --overwrite
# Rollout-Status des MIG-Managers prüfen
kubectl get pods -n gpu-operator -w
# Verfügbare MIG-Ressourcen im Cluster anzeigen
kubectl describe node gpu-node-01 | grep -A 5 "nvidia.com/mig"Der MIG-Manager im Cluster kümmert sich automatisch darum, laufende Pods auf dem Knoten zu leeren (Drain), bevor er die Partitionierung anwendet, und startet die GPU danach neu. Das dauert je nach Cluster-Größe zwischen 30 Sekunden und wenigen Minuten. Wichtig: Während dieses Vorgangs sollten keine neuen Pods auf den betroffenen Knoten geplant werden, sonst kommt es zu Startfehlern.
Schritt 8: NVLink-Topologie und Multi-Node-NCCL konfigurieren
Für Workloads, die mehrere B200-GPUs oder gar mehrere Knoten gleichzeitig ansprechen, etwa beim Sharding eines 405-Milliarden-Parameter-Modells über vier statt acht GPUs, zählt die Verbindungsqualität zwischen den Karten. Ein DGX-B200-System mit acht GPUs nutzt NVLink der fünften Generation mit 14,4 TB/s aggregierter Bandbreite, zusätzlich sind ConnectX-7- und BlueField-3-Netzwerkkarten mit bis zu 400 Gb/s pro Port für die Kommunikation zwischen Knoten verbaut.
# NVLink-Topologie zwischen den GPUs im System prüfen
nvidia-smi topo -m
# NCCL-Bandbreitentest zwischen zwei GPUs ausführen
all_reduce_perf -b 8 -e 4G -f 2 -g 8
# InfiniBand-Verbindungsstatus prüfen (bei Multi-Node-Clustern)
ibstatDer nvidia-smi topo -m-Befehl zeigt eine Matrix, in der jede Zeile-Spalten-Kombination angibt, wie zwei GPUs verbunden sind, etwa direkt über NVLink oder über den langsameren PCIe-Bus. Bei MIG-partitionierten GPUs gilt zu beachten, dass einzelne MIG-Instanzen keinen direkten NVLink-Zugriff auf Instanzen einer anderen physischen GPU haben, NVLink verbindet nur ganze GPUs miteinander. Für Multi-GPU-Training über NVLink muss deshalb entweder der volle 7g-Modus verwendet werden, oder die Kommunikation läuft über den Host.
Wer ein komplettes DGX-B200-System betreibt statt einzelner Karten, arbeitet zusätzlich mit der restlichen Systemarchitektur. NVIDIA verbaut in einem DGX B200 zwei Intel-Xeon-Platinum-8570-Prozessoren mit zusammen 112 Kernen, dazu zwischen 2 und 4 Terabyte System-RAM sowie ConnectX-7- und BlueField-3-DPUs für die Netzwerkanbindung. Für die Praxis heißt das: Die GPU-Partitionierung über MIG betrifft nur die acht Blackwell-GPUs selbst, CPU-Kerne und Systemspeicher werden davon unabhängig über das Betriebssystem beziehungsweise die Kubernetes-Ressourcen-Limits zugeteilt. Wer also eine MIG-Instanz für einen Inferenz-Pod reserviert, sollte im selben Atemzug auch CPU- und RAM-Limits im Pod-Manifest setzen, sonst kann ein einzelner Workload trotz sauber partitionierter GPU den restlichen Host durch exzessive CPU-Preprocessing-Last ausbremsen.
Schritt 9: Ein LLM-Inferenz-Workload auf MIG-Partitionen deployen
Jetzt folgt das komplette Praxisbeispiel: ein Inferenz-Server für ein mittelgroßes Sprachmodell, der gezielt an eine einzelne MIG-Instanz gebunden wird. Als Serving-Framework eignet sich vLLM, weil es MIG-Geräte über Standard-CUDA-Umgebungsvariablen erkennt, ohne zusätzliche Patches.
# UUID der Ziel-MIG-Instanz ermitteln
nvidia-smi -L | grep MIG
# vLLM-Server an eine konkrete MIG-Instanz binden
export CUDA_VISIBLE_DEVICES=MIG-GPU-a1b2c3d4-5e6f-7890-abcd-ef1234567890/0/0
python3 -m vllm.entrypoints.openai.api_server \
--model mistralai/Mistral-7B-Instruct-v0.3 \
--gpu-memory-utilization 0.85 \
--max-model-len 8192 \
--port 8000Bei einem Kubernetes-Deployment übernimmt das Device-Plugin des GPU Operators die Zuweisung automatisch, sobald der Pod eine MIG-Ressource wie nvidia.com/mig-3g.90gb: 1 im Ressourcen-Limit anfordert. Der große Vorteil dieses Aufbaus: Ein zweites, drittes und viertes Modell kann parallel auf denselben physischen B200 deployed werden, jedes in seiner eigenen isolierten Partition, ohne dass ein Absturz oder Memory-Leak eines Modells die anderen beeinträchtigt. Für ein Team, das etwa ein 7B-Chat-Modell, ein 13B-Embedding-Modell und einen Test-Endpunkt parallel betreiben will, ersetzt eine einzige B200-Karte mit MIG so schnell drei bis vier kleinere GPUs.
Schritt 10: Monitoring einrichten und MIG sauber zurücksetzen
Ohne Monitoring bleibt unklar, ob die MIG-Partitionierung tatsächlich die erhoffte Auslastung bringt. Der DCGM-Exporter von NVIDIA liefert pro-Instanz-Metriken, die sich in Prometheus und Grafana weiterverarbeiten lassen.
# DCGM-Exporter mit MIG-Unterstützung starten (Docker-Beispiel)
docker run -d --gpus all --cap-add SYS_ADMIN \
-p 9400:9400 nvcr.io/nvidia/k8s/dcgm-exporter:latest
# Auslastung pro MIG-Instanz live beobachten
nvidia-smi mig -i 0 -lgi
watch -n 2 nvidia-smi
# MIG-Modus vollständig zurücksetzen (alle Instanzen löschen)
sudo nvidia-smi mig -i 0 -dci
sudo nvidia-smi mig -i 0 -dgi
sudo nvidia-smi -i 0 -mig 0Die letzten drei Befehle sind wichtig, wenn eine GPU von MIG-Betrieb zurück in den Standardmodus wechseln soll, etwa für ein Fine-Tuning-Projekt, das die volle Karte ohne Partitionierung braucht. Erst werden alle Compute-Instanzen gelöscht (-dci), dann die GPU-Instanzen (-dgi), erst danach lässt sich der MIG-Modus insgesamt deaktivieren.
Häufige Fehler bei der B200-MIG-Konfiguration
- MIG-Aktivierung ohne Neustart: Der Befehl
nvidia-smi -mig 1meldet oft Erfolg, greift aber erst nach einem vollständigen Reboot, wenn noch Prozesse auf die GPU zugreifen. Ein reiner GPU-Reset reicht dann nicht. - Zu kleine Partitionen für den KV-Cache: Wer ein 13B-Modell in ein 1g.23gb-Profil zwängt, erlebt Out-of-Memory-Fehler während längerer Konversationen, weil der Key-Value-Cache mit der Kontextlänge wächst.
- NVLink-Erwartung bei MIG-Instanzen: Multi-GPU-Training über NVLink funktioniert nicht zwischen zwei MIG-Instanzen auf verschiedenen physischen Karten, NVLink verbindet nur vollständige GPUs.
- Fehlende Root-Rechte in CI/CD-Pipelines: Automatisierte Deployment-Skripte scheitern häufig, weil
nvidia-smi mig-Befehle privilegierten Zugriff brauchen, den ein Standard-Service-Account nicht hat. - Veraltete Container-Images: Container, die auf einer alten CUDA-Basis gebaut wurden, erkennen MIG-UUIDs teils nicht korrekt und fallen auf die volle GPU zurück, was zu Ressourcenkonflikten führt.
- MIG-Profile nach Treiber-Update verändert: Nach einem Major-Treiber-Update können sich Profil-IDs verschieben, wodurch Skripte, die feste IDs statt Profilnamen verwenden, plötzlich das falsche Profil anlegen.
Die meisten dieser Fehler entstehen nicht durch fehlerhafte Hardware, sondern durch Annahmen, die aus dem Betrieb einer ungeteilten GPU stammen und sich auf MIG-Instanzen nicht übertragen lassen. Wer ein bestehendes Deployment-Skript von einer vollen GPU auf MIG umstellt, sollte deshalb jede Umgebungsvariable und jeden Ressourcen-Grenzwert einzeln prüfen, statt sie unverändert zu übernehmen. Ein zweiter Testlauf in einer Staging-Umgebung mit realistischer, aber kleinerer Last deckt die meisten dieser Probleme auf, bevor sie im produktiven Betrieb zu Ausfällen führen.
Troubleshooting: Die häufigsten Probleme und Lösungen
Selbst bei sorgfältiger Vorbereitung tauchen in der Praxis wiederkehrende Fehler auf. Die folgende Liste sammelt die häufigsten Meldungen und ihre Lösung.
- “Unable to set MIG mode, GPU is currently in use”: Alle Prozesse, die die GPU nutzen, müssen beendet werden, inklusive Display-Manager oder laufender Container. Mit
fuser -v /dev/nvidia*lassen sich blockierende Prozesse identifizieren. - “Insufficient resources to create GPU instance”: Meist bereits belegter Speicher durch andere Instanzen. Mit
nvidia-smi mig -i 0 -lgiprüfen, ob noch freie Slices verfügbar sind, oder bestehende Instanzen zuerst löschen. - CUDA_VISIBLE_DEVICES erkennt die MIG-UUID nicht: Häufig ein Tippfehler in der UUID oder eine veraltete CUDA-Runtime im Container. Version mit
nvcc --versionim Container selbst prüfen, nicht nur auf dem Host. - Kubernetes-Pod bleibt im Status “Pending”: Der Knoten hat die angeforderte MIG-Ressource nicht mehr frei.
kubectl describe nodezeigt die aktuelle Allokation und etwaige Events zur Fehlerursache. - GPU Operator rollt MIG-Konfiguration nicht aus: Oft liegt es an einem falschen Node-Label. Der Wert muss exakt einem der von NVIDIA definierten Profile entsprechen, Tippfehler führen zu einem stillen Fehlschlag ohne Fehlermeldung.
- Niedrigere Performance als erwartet trotz MIG: MIG teilt auch die Speicherbandbreite anteilig auf. Wer volle Bandbreite braucht, sollte größere Profile wählen oder MIG für diesen Workload ganz deaktivieren.
- NCCL-Test schlägt mit Timeout fehl: Häufig eine falsch konfigurierte Netzwerkschnittstelle. Die Umgebungsvariable
NCCL_SOCKET_IFNAMEexplizit auf die richtige InfiniBand- oder Ethernet-Schnittstelle setzen. - MIG-Modus lässt sich nicht deaktivieren: Es existieren noch aktive Compute- oder GPU-Instanzen. Erst mit
-dciund-dgialle Instanzen entfernen, dann erst-mig 0ausführen. - DCGM-Exporter zeigt keine Metriken pro Instanz: Der Exporter muss mit dem Flag für MIG-Unterstützung und den passenden Systemrechten (
SYS_ADMIN-Capability) gestartet werden, sonst liefert er nur aggregierte Werte für die ganze GPU.
Wer diese neun Punkte vorab kennt, spart sich in der Praxis meist mehrere Stunden Fehlersuche. Die Mehrzahl der Support-Anfragen zu MIG-Setups, die in Foren und bei Cloud-Anbietern auftauchen, lässt sich auf eine Handvoll dieser Ursachen zurückführen, vor allem auf falsch gesetzte Umgebungsvariablen und auf Zustände, in denen alte Instanzen nicht vollständig entfernt wurden, bevor neue angelegt werden sollten.
Sicherheit und Isolation im Multi-Tenant-Betrieb
Für Unternehmen in Österreich, die MIG-Partitionen an unterschiedliche interne Abteilungen oder sogar externe Kunden vermieten, stellt sich zusätzlich die Frage nach der Datenisolation. MIG trennt Speicher und Compute-Ressourcen auf Hardware-Ebene, ein Prozess in einer Instanz kann technisch nicht auf den Speicherbereich einer anderen Instanz zugreifen, selbst wenn beide auf demselben physischen Chip laufen. Das unterscheidet sich von reinem Software-Scheduling, bei dem theoretisch Seitenkanal-Angriffe zwischen Prozessen auf derselben GPU denkbar wären. Für regulierte Branchen, etwa Finanzdienstleister oder Gesundheitsanbieter, die im Rahmen von NIS2 oder branchenspezifischen Vorgaben eine nachvollziehbare Trennung von Verarbeitungsressourcen dokumentieren müssen, liefert die MIG-Architektur damit ein belastbares technisches Argument, das über reine Kostenersparnis hinausgeht.
Trotzdem bleibt eine Einschränkung: MIG isoliert Compute und Speicher, nicht aber notwendigerweise die Stromversorgung und Kühlung der gesamten Karte. Ein extrem lastintensiver Prozess in einer Instanz kann in seltenen Fällen die Taktrate der gesamten GPU über das Power-Management beeinflussen, wenn das Gesamtsystem an sein thermisches Limit stößt. Wer harte Performance-Garantien für einzelne Mandanten vertraglich zusichert, sollte deshalb zusätzlich Monitoring-Schwellenwerte für die Gesamtauslastung der Karte einrichten, nicht nur für die einzelnen MIG-Instanzen.
Fortgeschrittene Tipps für den Produktionsbetrieb
Für den Dauerbetrieb lohnt sich ein zweiter Blick auf die Quantisierung. Der B200 unterstützt nativ FP4 über die Tensor-Cores der fünften Generation, mit bis zu 9.000 TFLOPS dense- beziehungsweise rund 20 PetaFLOPS sparse-Leistung. Wer Modelle in FP4 statt FP8 oder FP16 quantisiert, reduziert den Speicherbedarf erheblich und kann dadurch mit kleineren MIG-Profilen auskommen, ohne Qualitätseinbußen bei den meisten Inferenz-Aufgaben. Die Transformer Engine der zweiten Generation schaltet dabei dynamisch zwischen den Präzisionsstufen um, je nachdem, welche Layer im Modell empfindlicher auf Rundungsfehler reagieren.
Ein zweiter Punkt betrifft die Kapazitätsplanung: Weil HBM3e-Speicher laut mehreren Marktanalysen bis Ende 2026 weitgehend ausgebucht ist, Micron etwa spricht von einer vollständig reservierten Kapazität für 2025 und 2026, wird zusätzliche B200-Hardware kurzfristig schwerer verfügbar. Wer MIG von Anfang an einplant, muss seltener neue Karten nachbestellen, weil sich bestehende Hardware effizienter ausnutzen lässt. Parallel dazu hat NVIDIA im August 2026 die HGX-Rubin-NVL8-Plattform vorgestellt, die im Marketing bis zu zehnmal höheren Token-Durchsatz gegenüber HGX B200 verspricht, allerdings bei vergleichbarer Trainingsleistung mit einem Viertel der GPU-Anzahl. Bis Rubin-Systeme breit verfügbar sind, bleibt der B200 in vielen europäischen Rechenzentren die Referenz-Plattform für produktive LLM-Workloads.
Drittens: MIG-Profile sollten nicht statisch bleiben. Wer Lastspitzen kennt, etwa tagsüber viele kleine Inferenz-Anfragen und nachts ein großes Batch-Fine-Tuning, kann per Cronjob oder Kubernetes-CronJob die MIG-Konfiguration automatisch umschalten. Das erfordert zwar jedes Mal einen kurzen Drain-Zyklus, spart aber gegenüber separater Hardware für Tag- und Nachtbetrieb deutlich Kosten.
Viertens lohnt sich ein Blick auf Batching-Strategien innerhalb einer MIG-Instanz. Weil jede Partition ihren eigenen, festen Speicherbereich erhält, profitieren Inferenz-Server wie vLLM besonders stark von kontinuierlichem Batching, bei dem mehrere Anfragen unterschiedlicher Nutzer in denselben Forward-Pass gebündelt werden. Auf einer 90-GB-Partition lässt sich dadurch ein deutlich höherer Durchsatz erzielen als bei einer naiven Ein-Anfrage-nach-der-anderen-Verarbeitung, ohne dass der reservierte Speicherbereich der Instanz überschritten wird. Fünftens sollten Teams, die mehrere B200-Knoten betreiben, die MIG-Profile über alle Knoten hinweg konsistent halten, damit ein Kubernetes-Scheduler Workloads bei Bedarf nahtlos zwischen Knoten verschieben kann, statt durch uneinheitliche Partitionsgrößen künstliche Engpässe zu erzeugen.
Kosten in Österreich: Miete, ROI und Marktlage
Für die meisten Teams in Österreich ist der Kauf eines eigenen DGX-B200-Systems keine realistische Option, die Anschaffung mehrerer Blackwell-GPUs plus Infrastruktur bewegt sich im hohen sechsstelligen Bereich. Praktikabler ist die stundenweise Miete über Cloud-Anbieter. Laut aktuellen Anbieterangaben liegt der Einstiegspreis für einen einzelnen B200 bei rund 10,60 Dollar pro Stunde, wobei die genauen Konditionen je nach Anbieter, Region und Vertragslaufzeit stark schwanken.
| Szenario | Ohne MIG | Mit MIG (3 Partitionen) |
|---|---|---|
| Anzahl paralleler Modelle pro Karte | 1 | bis zu 3 |
| Stundenkosten pro Modell (rechnerisch) | ca. 10,60 $ | ca. 3,50–4,00 $ |
| Isolation zwischen Workloads | Nicht nötig (1 Workload) | Hardwareseitig garantiert |
| Geeignet für | Große Einzel-Workloads, Fine-Tuning | Mehrere kleine bis mittlere Inferenz-Endpunkte |
Die Rechnung zeigt den Kernvorteil: Wer ohnehin mehrere kleinere Modelle betreibt, senkt die Kosten pro Modell deutlich, wenn eine B200-Karte über MIG aufgeteilt wird, statt für jedes Modell eine separate Instanz zu mieten. Der Speicherengpass bei HBM3e wirkt sich zusätzlich auf die Preise aus, viele Anbieter haben ihre Rabattstaffeln für Langzeitbuchungen seit Mitte 2026 verschärft, weil die Nachfrage nach Blackwell-Kapazität das Angebot übersteigt.
Bei der Anbieterwahl lohnt sich neben dem reinen Stundenpreis ein Blick auf drei weitere Faktoren. Erstens die Abrechnungsgranularität: Manche Anbieter berechnen volle Stunden, andere minutengenau, was bei kurzen Testläufen oder sporadischen Batch-Jobs den Unterschied zwischen wirtschaftlichem und unwirtschaftlichem Betrieb ausmachen kann. Zweitens der Datenstandort: Für Unternehmen mit DSGVO-Anforderungen ist relevant, ob der Anbieter EU-Rechenzentren anbietet und wie transparent er das in seinen Vertragsunterlagen dokumentiert. Drittens die MIG-Unterstützung selbst, denn nicht jeder Cloud-Anbieter erlaubt Kunden, den MIG-Modus eigenständig zu konfigurieren, manche liefern nur vorkonfigurierte, feste Partitionsgrößen aus, was die in diesem Artikel gezeigte Flexibilität einschränkt.
Für ein österreichisches Startup mit einem Team von fünf Entwicklern, das drei parallele Modelle betreibt, ein Chat-Modell, ein Embedding-Modell und ein Klassifikationsmodell für die Content-Moderation, ergibt sich durch MIG eine spürbare Ersparnis gegenüber drei separaten GPU-Mietverträgen. Statt drei vollen B200-Instanzen zu je rund 10,60 Dollar pro Stunde reicht häufig eine einzige Karte mit drei MIG-Partitionen, was die monatlichen Infrastrukturkosten bei durchgehendem Betrieb um einen niedrigen fünfstelligen Betrag senken kann. Die genaue Ersparnis hängt naturgemäß von der Auslastung der einzelnen Modelle und den jeweiligen Vertragskonditionen ab und sollte vor einer Entscheidung immer anhand der eigenen Nutzungsdaten durchgerechnet werden.
MIG im Vergleich zu anderen Partitionierungsansätzen
MIG ist nicht die einzige Möglichkeit, eine GPU zwischen mehreren Workloads aufzuteilen. Software-basiertes Time-Slicing, wie es NVIDIA ebenfalls über den GPU Operator anbietet, lässt mehrere Prozesse nacheinander auf derselben GPU laufen, ohne echte Speicher-Isolation. Das ist einfacher einzurichten, bringt aber keine Garantie gegen gegenseitige Beeinträchtigung, ein speicherhungriger Prozess kann die anderen ausbremsen oder zum Absturz bringen. MIG dagegen reserviert Speicher und Compute-Ressourcen fest pro Instanz, was in produktiven Multi-Tenant-Umgebungen der deutlich robustere Ansatz ist, auch wenn die Einrichtung komplexer ausfällt und die Granularität auf die vordefinierten Profile begrenzt bleibt.
Für Teams, die zusätzlich mit anderen Beschleuniger-Architekturen experimentieren, etwa Googles TPU-Familie, lohnt sich ein Blick auf unseren Artikel zur Einrichtung von TPU Ironwood, der ein alternatives Partitionierungsmodell für KI-Workloads zeigt. Die grundsätzliche Überlegung, wie viel Isolation ein Workload wirklich braucht, bleibt dabei über Hardware-Generationen hinweg gleich.
Eine dritte Alternative, virtuelle GPUs über NVIDIA vGPU-Software, setzt noch eine Ebene tiefer an und richtet sich vor allem an virtualisierte Umgebungen mit VMware oder KVM, in denen ganze virtuelle Maschinen statt einzelner Container GPU-Zugriff brauchen. Für containerisierte KI-Workloads auf Kubernetes, wie sie in diesem Artikel im Mittelpunkt stehen, ist MIG in der Regel die direktere und ressourcenschonendere Lösung, weil sie ohne zusätzliche Virtualisierungsschicht auskommt. Wer beide Ansätze kombinieren will, etwa vGPU auf Hypervisor-Ebene und MIG innerhalb der virtuellen Maschine, sollte vorher in einer Testumgebung prüfen, ob die jeweilige Treiberversion diese Kombination überhaupt unterstützt, da nicht jede Firmware-Revision beide Modi parallel erlaubt.
Das komplette Projekt: Alle Schritte in einem Deployment-Skript
Zum Abschluss lässt sich der gesamte Ablauf aus den zehn Schritten in ein einziges, wiederverwendbares Setup-Skript packen. Das folgende Beispiel richtet einen B200 mit drei MIG-Partitionen im Profil 3g.90gb ein, startet den DCGM-Exporter für das Monitoring und deployt anschließend einen vLLM-Server auf der ersten Instanz. Das Skript eignet sich als Ausgangspunkt für ein eigenes Ansible-Playbook oder eine Cloud-Init-Konfiguration.
#!/bin/bash
set -euo pipefail
GPU_ID=0
PROFILE="3g.90gb"
INSTANCES=3
echo "1. Treiber- und CUDA-Version prüfen"
nvidia-smi --query-gpu=driver_version,name --format=csv,noheader
echo "2. MIG-Modus aktivieren"
sudo nvidia-smi -i $GPU_ID -mig 1
echo "3. Bestehende Instanzen bereinigen"
sudo nvidia-smi mig -i $GPU_ID -dci || true
sudo nvidia-smi mig -i $GPU_ID -dgi || true
echo "4. GPU-Instanzen im gewünschten Profil anlegen"
PROFILE_LIST=$(printf "%s," $(seq 1 $INSTANCES) | sed "s/[0-9]*/$PROFILE/g" | sed 's/,$//')
sudo nvidia-smi mig -i $GPU_ID -cgi $PROFILE_LIST -C
echo "5. Ergebnis verifizieren"
nvidia-smi -L
echo "6. DCGM-Exporter für Monitoring starten"
docker run -d --gpus all --cap-add SYS_ADMIN \
-p 9400:9400 nvcr.io/nvidia/k8s/dcgm-exporter:latest
echo "Setup abgeschlossen. MIG-Instanzen bereit für Workload-Zuweisung."Ein Beispiel für die erwartete Ausgabe nach einem erfolgreichen Durchlauf, mit gekürzten UUIDs zur besseren Lesbarkeit:
GPU 0: NVIDIA B200 (UUID: GPU-1a2b3c4d-...)
MIG 3g.90gb Device 0: (UUID: MIG-a1b2c3d4-.../0/0)
MIG 3g.90gb Device 1: (UUID: MIG-e5f6a7b8-.../1/0)
MIG 3g.90gb Device 2: (UUID: MIG-c9d0e1f2-.../2/0)
Setup abgeschlossen. MIG-Instanzen bereit für Workload-Zuweisung.Ab diesem Punkt lässt sich jede der drei Instanzen unabhängig ansteuern, etwa Instanz 0 für den produktiven Chat-Endpoint, Instanz 1 für eine Staging-Umgebung und Instanz 2 für Batch-Verarbeitung über Nacht. Wer das Skript in eine CI/CD-Pipeline einbaut, sollte den Aufruf idempotent halten, also bestehende Instanzen vor dem Neuanlegen immer erst löschen, wie im Beispiel mit den beiden || true-Absicherungen gegen bereits leere Zustände gezeigt.
Häufig gestellte Fragen
Wie viele MIG-Instanzen kann ein einzelner B200 maximal haben?
Technisch sind bis zu sieben Instanzen möglich, in der Praxis empfehlen Anbieter für Modelle zwischen 5 und 14 Milliarden Parametern meist zwei bis drei größere Partitionen, weil kleinere Slices zu wenig Speicher für den Key-Value-Cache lassen.
Funktioniert MIG auch auf der RTX 5090 oder anderen Consumer-Karten?
Nein, MIG ist auf NVIDIA-Rechenzentrums-GPUs wie B200, H100 und H200 beschränkt. Für lokale Consumer-Hardware gibt es andere Ansätze, etwa Time-Slicing oder virtuelle GPU-Profile über vGPU-Software.
Verliert man Leistung, wenn man einen B200 per MIG aufteilt?
Jede Instanz erhält proportional zu ihrem Profil Speicher, Rechenleistung und Bandbreite. In Summe bleibt die Gesamtleistung der Karte erhalten, einzelne Workloads mit sehr hohem Bandbreitenbedarf profitieren aber stärker von der vollen, unpartitionierten GPU.
Kann ich zwischen MIG-Instanzen auf verschiedenen physischen GPUs per NVLink kommunizieren?
Nein. NVLink verbindet vollständige physische GPUs miteinander, nicht einzelne MIG-Partitionen. Für Multi-GPU-Training über NVLink muss die GPU im vollen, unpartitionierten Modus laufen.
Wie lange dauert die MIG-Konfiguration in einem laufenden Kubernetes-Cluster?
Je nach Cluster-Größe und Anzahl betroffener Knoten zwischen etwa 30 Sekunden und wenigen Minuten pro Knoten, da der Knoten zuerst geleert (Drain) und die GPU danach zurückgesetzt wird.
Was kostet die Miete eines B200 mit MIG im Vergleich zur vollen Karte?
Der Stundenpreis für die physische Karte ändert sich durch MIG nicht, rund 10,60 Dollar pro Stunde laut aktuellen Anbieterangaben. Der Vorteil liegt darin, dass sich diese Kosten auf mehrere parallele Workloads aufteilen lassen, wodurch die Kosten pro einzelnem Modell sinken.
Ist MIG für ein einzelnes großes Fine-Tuning-Projekt sinnvoll?
In der Regel nicht. Für ein einzelnes speicherhungriges Training profitiert man mehr von der vollen, unpartitionierten GPU mit maximaler Speicherbandbreite und NVLink-Anbindung. MIG lohnt sich vor allem bei mehreren parallelen, kleineren Workloads.
Was passiert mit laufenden Workloads, wenn der MIG-Modus geändert wird?
Jede Änderung am MIG-Modus erfordert einen GPU-Reset. Laufende Prozesse auf der betroffenen GPU müssen vorher beendet werden, in Kubernetes-Umgebungen übernimmt der GPU Operator das automatische Draining des Knotens.
