MIG auf NVIDIA A100/H100/H200: So teilen Sie eine einzelne Grafikkarte zwischen mehreren Aufgaben

MIG wird benötigt, wenn eine einzelne NVIDIA A100, H100 oder H200 für eine Aufgabe zu leistungsstark ist, aber sicher und vorhersehbar zwischen mehreren Nutzern, Services oder Teams aufgeteilt werden soll. Mit MIG wird eine physische Grafikkarte in mehrere isolierte Instanzen unterteilt: Jede Instanz erhält ihren eigenen Anteil an Rechenressourcen und Videospeicher. Das eignet sich gut für Inferenz, Testumgebungen, Notebooks, mehrere kleinere Modelle und ML-Plattformen, aber nicht immer für großes verteiltes Training, bei dem vollständige physische GPUs meist die bessere Wahl sind.

Moderne KI-Beschleuniger werden selten „mit Reserve für ein einzelnes Experiment“ gekauft. Sie werden in Servern eingesetzt, in denen dieselbe Grafikkarte von Entwicklern, Analysten, dem MLOps-Team, einer internen Machine-Learning-Plattform oder mehreren Kunden benötigt werden kann. In einer solchen Situation entsteht schnell ein Problem: Ein Nutzer startet ein kleines Modell und belegt die ganze Karte, obwohl er tatsächlich nur einen Teil des Videospeichers und der Recheneinheiten nutzt.

MIG löst genau diese Aufgabe. Die Technologie ermöglicht es, eine unterstützte GPU in mehrere unabhängige Teile aufzuteilen. Im System erscheinen sie als separate Geräte kleinerer Größe. So lässt sich beispielsweise eine A100 mit 80 GB in mehrere Instanzen mit 10, 20 oder 40 GB aufteilen, während eine H200 mit 141 GB Profile mit größerem Speicher für anspruchsvollere Modelle bereitstellen kann.

Für Unternehmen, die NVIDIA-Grafikkarten für KI und neuronale Netze auswählen, ist MIG nicht weniger wichtig als die gesamte Speicherkapazität oder die GPU-Generation. Die Technologie hilft zu verstehen, wie eine Karte tatsächlich genutzt wird: vollständig von einer einzelnen Aufgabe oder parallel von mehreren Workloads.

Was ist MIG einfach erklärt?

MIG ist eine Technologie zur hardwarebasierten Partitionierung unterstützter NVIDIA-Grafikkarten. Eine physische GPU wird in mehrere GPU-Instanzen aufgeteilt. Jede Instanz erhält einen festen Anteil an Ressourcen:

• Recheneinheiten;
• Videospeicher;
• einen Teil des L2-Caches;
• einen Teil der Speicherbandbreite;
• separate Zugriffspfade zum Speicher;
• eine vom Profil abhängige Auswahl an Hardware-Engines.

Für eine Anwendung sieht eine MIG-Instanz wie eine separate kleinere Grafikkarte aus. Der Nutzer erhält nicht die gesamte A100, H100 oder H200, sondern arbeitet nur mit dem zugewiesenen Teil. Die offizielle Beschreibung der MIG-Architektur findet sich im NVIDIA MIG User Guide.

Ein einfaches Beispiel:

• ohne MIG startet ein Nutzer ein Notebook und belegt die gesamte H100;
• mit MIG teilt der Administrator die H100 in mehrere Profile auf;
• ein Profil erhält ein Notebook, das zweite einen Inferenz-Service, das dritte ein Testmodell;
• die Aufgaben konkurrieren nicht sofort um die ganze Karte, weil jede ihren eigenen zugewiesenen GPU-Bereich hat.

Das ist nicht dasselbe wie „allen Zugriff auf eine Grafikkarte zu geben und zu hoffen, dass sie sich nicht gegenseitig stören“. MIG trennt Ressourcen auf Ebene der GPU selbst, dadurch wird das Verhalten der Aufgaben besser vorhersehbar.

Wo MIG den größten Nutzen bringt

MIG ist besonders nützlich, wenn eine teure Grafikkarte nicht nur für eine große Aufgabe, sondern für mehrere Umgebungen oder Services mit unterschiedlichen Anforderungen arbeiten soll.

Mehrere Teams auf einer GPU

In einem Unternehmen kann dieselbe H100 von mehreren Gruppen gleichzeitig benötigt werden:

• Entwickler testen ein neues Modell;
• Analysten arbeiten in einer Notebook-Umgebung;
• das MLOps-Team testet Inferenz;
• das Engineering-Team debuggt eine Pipeline zur Datenvorbereitung.

Ohne MIG wird eine solche Karte häufig zu einer umkämpften Ressource: Wer die GPU zuerst belegt, kann arbeiten. Alle anderen warten oder starten Aufgaben nachts. Mit MIG lässt sich jedem Team vorab ein eigenes Profil zuweisen, statt die gesamte Karte an eine Aufgabe zu vergeben.

Das ist praktisch für:

• interne ML-Plattformen;
• Forschungsteams;
• Labore;
• Service-Provider;
• Unternehmen, in denen GPUs zentral beschafft und auf Projekte verteilt werden.

Dev-/Testumgebungen

Für die Entwicklung wird fast nie eine ganze H100 oder H200 benötigt. In der Debugging-Phase ist die Verfügbarkeit der Umgebung wichtiger als maximale Performance. MIG ermöglicht es, kleine Profile bereitzustellen für:

• Umgebungsprüfungen;
• Testläufe eines Modells;
• Debugging von Abhängigkeiten;
• Kompatibilitätsprüfungen von CUDA, Treibern und Bibliotheken;
• die Vorbereitung einer Pipeline vor dem Start auf einer vollständigen GPU.

Ein Entwickler muss beispielsweise nicht die gesamte A100 mit 80 GB belegen, wenn er nur das Laden eines Modells und die korrekte Verarbeitung der Eingabedaten prüft. Ein kleines Profil kann ausreichen, während der Rest der Karte für andere Aufgaben verfügbar bleibt.

Inferenz mehrerer Modelle

Inferenz ist eines der naheliegendsten Szenarien für MIG. Auf einer physischen GPU lassen sich mehrere Services betreiben:

• verschiedene Versionen eines Modells;
• mehrere Modelle für unterschiedliche Produkte;
• separate Modelle für verschiedene Kunden;
• eine Test- und eine Production-Version eines Services;
• Batch-Inferenz mit moderater Last.

Wenn jedes Modell nur einen Teil des Videospeichers nutzt, ist es nicht immer sinnvoll, sie auf separaten physischen GPUs zu starten. MIG ermöglicht eine höhere Platzierungsdichte und reduziert Leerlaufzeiten der Hardware.

Wichtig ist jedoch, das Profil nicht nur nach Speicherkapazität auszuwählen. Ein Modell kann zwar in den Videospeicher passen, aber dennoch zu wenig Rechenanteil oder Speicherbandbreite im Profil erhalten. Deshalb müssen für Inferenz immer Antwortlatenz, Batch-Größe und Stabilität unter paralleler Last geprüft werden.

Isolation von Kunden und Projekten

MIG hilft dabei, GPU-Ressourcen zwischen Kunden oder Projekten so aufzuteilen, dass eine einzelne Aufgabe nicht den gesamten Videospeicher der physischen Karte belegen kann. Das ist besonders wichtig für Plattformen, auf denen Nutzer eigene Container, Notebooks oder Modelle starten.

MIG bietet Isolation auf Ebene der GPU-Ressourcen, ersetzt aber keine anderen Schutzebenen. Für eine echte Mehrbenutzerumgebung werden weiterhin benötigt:

• Trennung der Nutzer im Betriebssystem;
• Zugriffsrechte auf Daten;
• Container-Isolation;
• Netzwerkrichtlinien;
• Limits in Kubernetes;
• Prozess-Monitoring;
• Regeln zur Bereinigung hängen gebliebener Aufgaben.

Andernfalls löst MIG nur einen Teil des Problems: Die Grafikkarte wird aufgeteilt, die Plattform ist aber weiterhin nicht vor Fehlern in Zugriffsrechten, Secrets, Container-Images oder der Netzwerkkonfiguration geschützt.

Was in MIG genau aufgeteilt wird

Beim Erstellen einer MIG-Instanz wählt der Administrator ein Profil. Das Profil legt fest, welchen Teil der Grafikkarte eine Aufgabe erhält. Innerhalb des Profils sind Rechenressourcen und Videospeicher fest zugewiesen.

Vereinfacht kann man sich das so vorstellen: Eine große GPU wird in mehrere vordefinierte Abschnitte zerlegt. Ein kleiner Abschnitt eignet sich für leichte Aufgaben, ein größerer für Modelle, die mehr Speicher und Rechenleistung benötigen.

MIG teilt:

• einen Teil der GPU-Recheneinheiten;
• einen Teil des Videospeichers;
• einen Teil des L2-Caches;
• einen Teil der Speicherbandbreite;
• bestimmte Hardware-Engines;
• die Gerätesichtbarkeit für Anwendungen.

Für den Nutzer bedeutet das:

• eine Aufgabe kann den zugewiesenen Videospeicher nicht überschreiten;
• eine benachbarte Instanz sollte keine Ressourcen einer anderen Instanz wegnehmen;
• der Administrator kann im Voraus planen, wem welcher GPU-Umfang zur Verfügung steht;
• das Lastverhalten lässt sich leichter prognostizieren als beim gewöhnlichen gemeinsamen Zugriff auf eine einzelne Karte.

Dieser Ansatz hat aber eine Kehrseite: Freie Ressourcen einer benachbarten Instanz werden nicht automatisch weitergegeben. Wenn einer Aufgabe 10 GB zugewiesen wurden und daneben eine 40-GB-Instanz ungenutzt bleibt, kann die erste Aufgabe diese 40 GB trotzdem nicht verwenden. Um die Aufteilung zu ändern, muss die MIG-Konfiguration angepasst werden.

Was MIG nicht leistet

MIG verwandelt eine physische GPU nicht ohne Einschränkungen in mehrere vollständig unabhängige Grafikkarten. Das ist wichtig, weil falsche Erwartungen häufig zu Planungsfehlern führen.

MIG bedeutet nicht, dass:

• jede Aufgabe schneller läuft;
• ein kleines Profil exakt 1/7 der Leistung einer vollständigen GPU liefert;
• Speicher unbegrenzt flexibel zwischen Aufgaben umverteilt werden kann;
• mehrere MIG-Instanzen mehrere physische GPUs für großes Training ersetzen;
• Live Migration automatisch funktioniert;
• das Monitoring unverändert wie bei einer normalen GPU bleiben kann.

NVIDIA beschreibt MIG-Einschränkungen separat im Abschnitt Deployment Considerations. Für die praktische Einführung sind insbesondere Einschränkungen beim Datenaustausch zwischen Instanzen, beim Profiling und bei verteilten Bibliotheken wichtig.

Einschränkungen für verteilte Aufgaben

MIG eignet sich gut für unabhängige Aufgaben auf einer einzelnen physischen GPU. Wenn eine Workload jedoch aktiven Datenaustausch zwischen mehreren GPUs oder zwischen Instanzen benötigt, ist Vorsicht geboten.

Problematisch können Szenarien sein, in denen genutzt werden:

• großes verteiltes Training;
• Modelle, die mehrere GPUs gleichzeitig benötigen;
• intensiver Austausch zwischen Beschleunigern;
• Bibliotheken für kollektive Kommunikation;
• Aufgaben, die empfindlich auf Latenzen zwischen Geräten reagieren.

Für solche Fälle ist es häufig besser, vollständige physische GPUs ohne MIG zu verwenden. Wenn ein Modell beispielsweise dauerhaft eine ganze H100 belegt und aktiv Daten mit benachbarten GPUs austauscht, kann die Aufteilung der Karte in MIG-Profile die Architektur eher verkomplizieren.

Einschränkungen beim Monitoring

Der übliche Blick auf die physische GPU reicht nicht mehr aus. Der Administrator muss nicht nur die Gesamtauslastung der Karte sehen, sondern auch den Zustand jeder MIG-Instanz.

Sonst entsteht eine typische Situation:

• die physische GPU wirkt ungleichmäßig ausgelastet;
• eine MIG-Instanz ist überlastet;
• eine andere ist im Leerlauf;
• eine dritte Aufgabe ist wegen Speichermangels abgestürzt;
• in der Gesamtmetrik sieht das wie „GPU wird normal genutzt“ aus.

Für den Produktionsbetrieb sollten Metriken pro Instanz gesammelt werden. NVIDIA DCGM kann Kennzahlen sowohl auf Ebene der physischen GPU als auch auf Ebene der MIG-Geräte ausgeben; das ist in der DCGM documentation beschrieben.

Überwacht werden sollten:

• Auslastung der Rechenressourcen;
• belegter Videospeicher;
• Speicherfehler;
• Temperatur;
• Stromverbrauch;
• Throttling;
• Prozessabstürze;
• Verteilung der Aufgaben auf Profile;
• lange Leerlaufzeiten einzelner Instanzen.

MIG-Profile auf A100, H100 und H200

Ein MIG-Profil definiert die Größe einer Instanz. Im Profilnamen gibt es in der Regel zwei Teile: den Anteil der Recheneinheiten und die Menge des Videospeichers. Das Profil 1g.10gb bezeichnet zum Beispiel eine kleine Instanz mit 10 GB Videospeicher, während 7g.80gb nahezu die gesamte H100 mit 80 GB in einem Profil darstellt.

Die vollständige Profilliste sollte in der offiziellen Tabelle Supported MIG Profiles geprüft werden, da die verfügbaren Varianten vom konkreten GPU-Modell, der Speicherkapazität, dem Formfaktor und der Treiberversion abhängen.

Die Zahlen im Profilnamen sollten nicht als exakte Leistungsprognose verstanden werden. Das Profil zeigt die Größe des zugewiesenen GPU-Anteils, die tatsächliche Geschwindigkeit hängt aber vom Modell, der Batch-Größe, der Art der Berechnungen, dem Speicher, den Bibliotheken und der Skalierbarkeit der Aufgabe ab.

Wie wählt man das passende Profil für eine Aufgabe?

Die Profilauswahl beginnt nicht mit der Frage „Wie viele Instanzen kann ich erstellen?“, sondern mit der Frage „Was genau soll auf jeder Instanz laufen?“. Für dieselbe GPU lassen sich unterschiedliche Schemata bauen: viele kleine Profile, mehrere mittlere oder ein großes.

Kleines Modell oder Testservice

Für ein kleines Modell lohnt es sich meist, mit einem 1g-Profil zu beginnen. Diese Variante eignet sich, wenn die Aufgabe:

• wenig Videospeicher nutzt;
• keine hohe Speicherbandbreite benötigt;
• eine moderate Anzahl von Anfragen verarbeitet;
• für Tests oder Entwicklung benötigt wird;
• als separater Service läuft.

Auf einer A100 mit 80 GB kann das zum Beispiel ein 1g.10gb-Profil sein. Auf einer H200 mit 141 GB ist es ein 1g.18gb-Profil. Dieser Unterschied ist wichtig: Auf der H200 bietet selbst das kleinste Profil deutlich mehr Speicher und lässt sich daher besser zwischen schwereren Aufgaben aufteilen.

Notebook für Entwickler oder Analysten

Notebook-Umgebungen nutzen GPUs häufig ineffizient. Ein Nutzer kann eine Sitzung öffnen, ein Modell laden, einige Zellen ausführen und den Prozess mehrere Stunden hängen lassen. Wenn er eine ganze H100 erhält, ist die Karte formal belegt, obwohl sie tatsächlich nur teilweise genutzt wird.

Für Notebooks eignen sich in der Regel:

• 1g-Profile für leichte Experimente;
• 2g-Profile für Aufgaben mit größerem Batch;
• Zeitlimits für Sitzungen;
• automatische Bereinigung inaktiver Prozesse;
• separate Limits für verschiedene Nutzergruppen.

MIG hilft hier weniger dabei, Berechnungen zu beschleunigen, sondern vor allem dabei, den Zugriff auf GPUs fairer zu gestalten.

Batch-Inferenz

Bei Batch-Inferenz muss nicht nur der Speicher, sondern auch die Verarbeitungslatenz betrachtet werden. Ein kleines Profil kann ein Modell zwar aufnehmen, aber die erforderliche Geschwindigkeit dennoch nicht erreichen.

Vor der Profilauswahl sollte geprüft werden:

• maximale Batch-Größe;
• durchschnittliche und Spitzenlatenz;
• Auslastung der Recheneinheiten;
• Speicherauslastung;
• Verhalten unter parallelen Anfragen;
• Reserve für Lastwachstum.

Wenn der Service ein kleines Modell bedient, kann man mit 1g oder 2g beginnen. Ist der Batch groß oder das Modell schwerer, sollten 3g oder 4g getestet werden. Für Aufgaben, bei denen viel Videospeicher entscheidend ist, ist die H200 besonders interessant.

Fine-Tuning

Für Fine-Tuning sind kleine Profile nicht immer geeignet. Selbst wenn das Modell startet, kann es in einem späteren Schritt wegen eines Spitzenverbrauchs an Speicher abstürzen. Besonders sichtbar wird das bei größerer Batch-Größe, längerer Kontextlänge oder weniger sparsamen Trainingseinstellungen.

Für Fine-Tuning werden häufiger benötigt:

• 3g- oder 4g-Profile;
• ein vollständiges Profil, wenn das Modell groß ist;
• eine separate physische GPU, wenn die Aufgabe die ganze Karte dauerhaft auslastet;
• ein vorheriger Test des maximalen Speicherverbrauchs.

Wenn es um ernsthaftes Fine-Tuning eines LLM geht, sollte man nicht mit dem kleinsten Profil beginnen. Besser ist es, zunächst den Verbrauch in einem Testlauf zu messen und erst danach zu entscheiden, ob die Karte geteilt werden kann.

Beispiele für die Aufteilung einer GPU auf mehrere Aufgaben

MIG lässt sich am einfachsten über konkrete Schemata verstehen. Die folgenden Beispiele sind keine universellen Rezepte, sondern typische Varianten, an denen man sich bei der Planung orientieren kann.

A100 80 GB für ein Entwicklungsteam

NVIDIA A100 80Gb PCIE HBM2 OEM kann als gemeinsame Karte für mehrere interne Aufgaben genutzt werden.

Beispielhafte Aufteilung:

• 2 × 1g.10gb — Notebooks für Entwickler;
• 1 × 2g.20gb — Test-Inferenz;
• 1 × 3g.40gb — Experiment mit einem größeren Modell.

Dieses Schema eignet sich, wenn ein Team nicht die maximale Beschleunigung einer einzelnen Aufgabe benötigt, sondern kontinuierlichen Zugriff auf mehrere isolierte Umgebungen. Wenn in einem bestimmten Zeitraum ein größeres Experiment erforderlich ist, kann die Konfiguration neu aufgebaut und vorübergehend mehr Ressourcen einer Aufgabe zugewiesen werden.

H100 80 GB für mehrere Inferenz-Services

NVIDIA H100 80Gb HBM3 OEM wird häufiger für leistungsstärkere KI-Workloads gewählt. In einem MIG-Szenario eignet sie sich gut für mehrere Inferenz-Services.

Ein mögliches Schema:

• mehrere 1g- oder 2g-Profile für kleinere Modelle;
• ein 3g- oder 4g-Profil für einen schwereren Service;
• ein separates kleines Profil zum Testen einer neuen Modellversion.

Hier ist es wichtig, die Karte nicht mit zufälligen Profilen zu überladen. Besser ist es, Serviceklassen vorab zu definieren: klein, mittel, schwer. Dann können Teams Ressourcen einfacher anfragen und Administratoren die Auslastung leichter verfolgen.

H200 141 GB für speicherintensive Aufgaben

NVIDIA H200 ORIGINAL ist dort interessant, wo nicht nur Rechenleistung, sondern auch Videospeicher zum begrenzenden Faktor wird. Die MIG-Profile der H200 sind größer: Selbst ein kleines Profil bietet 18 GB, mittlere Profile können 35 oder 71 GB bereitstellen.

Eine solche Karte kann aufgeteilt werden zwischen:

• mehreren Inferenz-Services mit merklichem Speicherbedarf;
• Batch-Aufgaben;
• Tests von Modellen, denen 10–20 GB nicht ausreichen;
• mehreren Teams, die mit anspruchsvolleren Pipelines arbeiten.

Wenn ein Modell fast den gesamten Speicher der H200 benötigt, ist MIG nicht mehr sinnvoll: Besser ist dann ein vollständiges Profil oder die gesamte physische GPU.

Was vor der MIG-Einführung geprüft werden sollte

Vor der Einführung von MIG sollte nicht nur die Grafikkarte selbst geprüft werden, sondern der gesamte Stack: Treiber, Container, Kubernetes, Monitoring, Zugriffsregeln und Szenarien zur Neuerstellung von Profilen.

Besondere Aufmerksamkeit verdient die Allokationsregelung. Wenn es sie nicht gibt, wird MIG schnell zu einer Sammlung zufällig erstellter Profile: Ein Nutzer fordert „zur Sicherheit“ eine zu große Instanz an, ein anderer belegt ein kleines Profil mit einem schweren Modell, ein dritter lässt eine Sitzung über das Wochenende hängen.

Eine gute Praxis ist es, im Voraus mehrere Standardklassen zu beschreiben:

• kleines Profil für Notebooks und Tests;
• mittleres Profil für Inferenz;
• großes Profil für anspruchsvolle Experimente;
• vollständiges Profil für Aufgaben, die wirklich die ganze Karte benötigen.

MIG in Kubernetes

Beispiel einer Architektur zur Skalierung von Triton Inference Server mit MIG und Kubernetes. Quelle: NVIDIA Developer Blog

In Kubernetes ist MIG besonders nützlich, weil nicht die gesamte physische GPU, sondern ein konkretes Profil an einen konkreten Pod vergeben werden kann. Dafür wird ein zusätzlicher NVIDIA-Stack benötigt: Treiber, Container Toolkit, Device Plugin und in stärker verwalteten Installationen der GPU Operator.

NVIDIA beschreibt MIG-Szenarien für Kubernetes in einer separaten Dokumentation: MIG Support in Kubernetes. In der Praxis sieht das so aus:

• der Administrator aktiviert MIG auf dem GPU-Node;
• er erstellt die benötigten Profile;
• Kubernetes erhält die Liste der verfügbaren MIG-Ressourcen;
• der Pod fordert einen konkreten Ressourcentyp an;
• der Scheduler platziert die Workload auf einem Node, auf dem dieses Profil vorhanden ist.

In Kubernetes ist es besonders wichtig, kein Chaos aus zu vielen Profilvarianten zu erzeugen. Je mehr Optionen es gibt, desto schwieriger wird es für den Scheduler, Aufgaben zu platzieren, und für Teams, die richtige Ressource auszuwählen.

Für ML-Plattformen sind meist folgende Regeln sinnvoll:

• GPU-Nodes nach Typ der verfügbaren Profile kennzeichnen;
• separate Queues für kleine, mittlere und große Aufgaben einrichten;
• Zugriff auf vollständige GPUs einschränken;
• inaktive Notebook-Sitzungen automatisch beenden;
• Nutzungsstatistiken pro Profil sammeln;
• regelmäßig prüfen, welche Profile tatsächlich benötigt werden.

MIG passt gut zu Kubernetes, wenn Aufgaben im Voraus klassifiziert sind. Wenn jedes Team manuell „irgendetwas Größeres“ anfordert, gehen die Vorteile schnell verloren.

Wann MIG besser nicht verwendet werden sollte

MIG ist nicht in jedem GPU-Server notwendig. Manchmal macht die Aufteilung einer Karte den Betrieb nur komplizierter.

Eine ganze physische GPU oder mehrere GPUs ohne MIG sind besser geeignet, wenn:

• eine Aufgabe die gesamte Grafikkarte dauerhaft nutzt;
• ein Modell fast den gesamten Videospeicher benötigt;
• maximale Performance für eine einzelne Aufgabe erforderlich ist;
• Training über mehrere GPUs verteilt wird;
• die Workload aktiv Daten zwischen Beschleunigern austauscht;
• die Anwendung auf einem begrenzten Profil schlecht funktioniert;
• eine flexible Speicherumverteilung zwischen Aufgaben erforderlich ist;
• die Infrastruktur nicht auf Monitoring von MIG-Instanzen vorbereitet ist;
• kein Administrator vorhanden ist, der Profile und Zugriffsregeln verwaltet.

MIG funktioniert besonders gut dort, wo Workloads ähnlich und vorhersehbar sind. Zum Beispiel, wenn es mehrere typische Inferenz-Services, mehrere Notebook-Umgebungen und klare Limits für Teams gibt. Wenn dagegen jeder Start einzigartig ist und der Speicherverbrauch schwer vorherzusagen ist, müssen Profile häufiger geändert und Aufgaben angehalten werden.

A100, H100 oder H200: Was sollte man für MIG wählen?

Quelle: ServerMall

Die Wahl hängt davon ab, welche Aufgaben gestartet werden sollen und wie wichtig Videospeicher ist.

A100

A100 ist eine ausgereifte und weit verbreitete Plattform. Sie eignet sich gut für:

• interne ML-Umgebungen;
• Dev/Test;
• mehrere Notebooks;
• Inferenz kleiner und mittlerer Modelle;
• Teams, die GPU-Zugriff benötigen, aber kein Budget für Topmodelle wie H100/H200 haben.

Wenn eine aktive Aufteilung zwischen Nutzern geplant ist, ist die A100 mit 80 GB praktischer als die 40-GB-Version: Es gibt mehr Speicheroptionen und ein geringeres Risiko, dass jede Aufgabe schnell an ihr Limit stößt.

H100

H100 sollte in Betracht gezogen werden, wenn eine höhere Performance für moderne KI-Workloads benötigt wird. In MIG-Szenarien eignet sie sich für:

• Production-Inferenz;
• mehrere Services auf einer GPU;
• LLM-Tests;
• ML-Plattformen mit unterschiedlichen Aufgabenklassen;
• Teams, die Leistungsreserve benötigen.

H100 kann für kleine Aufgaben überdimensioniert sein. Genau deshalb ist MIG hier besonders nützlich: Es verhindert, dass eine so leistungsstarke Karte vollständig an einen kleinen Prozess vergeben wird.

H200

H200 ist interessant, wenn das Hauptproblem Videospeicher und Speicherbandbreite sind. Die H200-Profile sind größer, daher eignet sich die Karte gut für anspruchsvollere Inferenz-Szenarien und Aufgaben, denen typische 10–20 GB nicht ausreichen.

H200 sollte in Betracht gezogen werden, wenn:

• Modelle häufig an Speichergrenzen stoßen;
• mehrere schwere Services betrieben werden müssen;
• Batch-Inferenz viel Reserve erfordert;
• eine Aufgabe nicht immer den gesamten Umfang von 141 GB nutzt;
• die Karte aufgeteilt werden soll, ohne auf zu kleine Profile auszuweichen.

Wenn es nur eine Aufgabe gibt und sie ständig die gesamte H200 benötigt, bringt die Aufteilung keinen Vorteil. Wenn es jedoch mehrere solche Aufgaben gibt und jede nur einen Teil der Karte benötigt, hilft MIG, die Ressource dichter zu nutzen.

Häufige Fehler bei der Arbeit mit MIG

Fehler hängen meist nicht mit der Technologie selbst zusammen, sondern mit Erwartungen und Betrieb.

Am häufigsten treten folgende Probleme auf:

• das Profil wird nur nach Videospeicherkapazität ausgewählt;
• der Spitzenverbrauch des Modells wird nicht geprüft;
• die Inferenzlatenz unter Last wird nicht gemessen;
• zu große Profile werden „zur Sicherheit“ vergeben;
• Fine-Tuning wird auf einer zu kleinen Instanz gestartet;
• es werden keine Metriken pro MIG-Instanz gesammelt;
• es wird vergessen, dass freier Speicher eines benachbarten Profils nicht automatisch weitergegeben wird;
• es wird nicht dokumentiert, wem welches Profil zu welchem Zweck zugewiesen wurde;
• zu viele Konfigurationen werden auf einem Node vermischt;
• MIG wird als Ersatz für mehrere physische GPUs betrachtet;
• das Anhalten von Aufgaben vor einer Änderung des Schemas wird nicht eingeplant.

Um diese Fehler zu vermeiden, sollte MIG nicht als einmalige Einstellung eingeführt werden, sondern als gesteuerte Richtlinie zur GPU-Nutzung.

Minimaler Regelsatz:

1. Typische Profile und Szenarien beschreiben.
2. Reale Workloads auf einem Teststand prüfen.
3. Monitoring pro Instanz einrichten.
4. Zugriff auf vollständige GPUs einschränken.
5. Regeln zur Bereinigung inaktiver Prozesse einführen.
6. Konfigurationen anhand von Nutzungsstatistiken regelmäßig überprüfen.

Woran erkennt man, ob sich MIG lohnt?

MIG ist sinnvoll, wenn eine teure GPU häufig im Leerlauf ist oder von Aufgaben belegt wird, die nicht die gesamte Karte benötigen. Besonders sichtbar ist das in Teams mit vielen Tests, Notebooks, kleinen Modellen und Inferenz-Services.

MIG ist nützlich, wenn:

• mehrere Nutzer regelmäßig um eine GPU konkurrieren;
• Aufgaben hinsichtlich des Speicherbedarfs vorhersehbar sind;
• es viele kleine Inferenz-Services gibt;
• Kunden oder Teams isoliert werden müssen;
• die GPU häufig belegt ist, aber tatsächlich nicht vollständig ausgelastet wird;
• die Infrastruktur Kubernetes bereits nutzt oder den Wechsel dorthin plant;
• es einen Administrator gibt, der Profile verwaltet.

MIG kann überflüssig sein, wenn:

• die gesamte GPU fast immer von einer großen Aufgabe belegt ist;
• Modelle ständig die volle Speicherkapazität benötigen;
• kein Monitoring vorhanden ist;
• keine klaren Verteilungsregeln existieren;
• das Team nicht bereit ist, seine GPU-Arbeitsprozesse zu ändern.

Am Ende sollte MIG nicht als Möglichkeit verstanden werden, A100, H100 oder H200 zu beschleunigen, sondern als Möglichkeit, ihre Nutzung besser zu steuern. Die Technologie hilft, eine teure Grafikkarte zwischen mehreren Aufgaben aufzuteilen, reduziert Ressourcenkonflikte und erhöht die Hardware-Auslastung. Gute Ergebnisse erfordern jedoch passende Profile, Monitoring und ein Verständnis der Einschränkungen. Ohne das kann MIG leicht zu einer weiteren komplexen Infrastrukturschicht werden, die niemand kontrolliert.