GPUs in Kubernetes: was der GPU Operator installiert, und vier Wege, eine Karte zu teilen

Was der GPU Operator installiert

NVIDIAs GPU Operator nutzt das Operator-Framework von Kubernetes, „um die Verwaltung aller NVIDIA-Softwarekomponenten zu automatisieren, die zur Bereitstellung der GPU nötig sind“. Dieser Leitfaden folgt dem Release v26.7.0, dem am 21. September 2026 aktuellen in NVIDIAs Release Notes. Auf GPU-Nodes stellt der Operator diese Komponenten bereit, jede als Container.

Dokumentation des NVIDIA GPU Operators: Release Notes, Installationsoptionen und Plattformunterstützung, aktualisiert am 21. September 2026; Dokumentation des NVIDIA DCGM Exporters, Mai 2026.

Node Feature Discovery und Validator-Pods runden das Paket ab, und toolkit.enabled=false behält eine Container-Runtime bei, die bereits für NVIDIA konfiguriert ist. Unser Monitoring-Leitfaden behandelt, worauf Sie in den DCGM-Metriken achten sollten. Prüfen Sie zuerst NVIDIAs Supportliste für den Operator: Sie nennt Rechenzentrumskarten wie die H200 NVL, L40S und L4 und unter den Blackwell-PCIe-Karten die Server Editions der RTX PRO 6000 und RTX PRO 4500. Für die RTX PRO 6000 als Workstation Edition oder Max-Q und für die RTX PRO 5000 haben wir keinen Eintrag gefunden. Für die RTX PRO 6000 Server Edition verlangt die Liste Treiber 575.57.08 oder neuer und vermerkt, dass MIG auf dem Treiber-Release 575.57.08 selbst nicht unterstützt wird.

Vier Wege, eine GPU zu vergeben

Ein Pod fordert eine ganze Zahl von GPU-Ressourcen an; was eine Einheit ist, entscheidet das Device-Plugin: eine physische Karte, eine MIG-Instanz oder ein Replikat einer geteilten Karte. Die vier Methoden unterscheiden sich vor allem in einer Hinsicht, nämlich darin, was ein Pod seinen Nachbarn antun kann.

MIG-Benutzerhandbuch von NVIDIA (11. September 2026), Dokumentation des GPU Operators (21. September 2026), README des NVIDIA k8s-device-plugin und Dokumentation zu CUDA MPS, abgerufen im September 2026.

Ganze GPUs: der Standard

Ohne weitere Konfiguration meldet das Device-Plugin jede physische Karte als ein nvidia.com/gpu, und ein Pod fordert sie in seinen Ressourcenlimits an, zum Beispiel mit nvidia.com/gpu: 1. Die Karte gehört dann diesem Container, bis der Pod endet. Das ist die richtige Einheit für Training, für Modelle, die den größten Teil des Speichers einer Karte brauchen, und für Dienste, die eine GPU auslasten. Das README des Device-Plugins, das die NVIDIA-Runtime als Standard-Runtime des Nodes voraussetzt, fügt eine Warnung hinzu: Fordert ein Pod keine GPUs an, stellt das Plugin „alle GPUs der Maschine in Ihrem Container bereit“. Seit v25.10.0 bindet der Operator GPUs standardmäßig über CDI ein und macht die Runtime-Klasse nvidia nicht mehr zum Standard-Handler; prüfen Sie also, welche Konfiguration auf Ihren Nodes läuft.

MIG: Partitionen in Hardware

MIG unterteilt eine Karte in GPU-Instanzen mit eigenen Streaming-Multiprozessoren, eigenem Speicher und eigenen Speicherpfaden. In NVIDIAs Worten sind „die Crossbar-Ports auf dem Chip, die L2-Cache-Bänke, die Speichercontroller und die DRAM-Adressbusse alle eindeutig einer einzelnen Instanz zugewiesen“, was jeder Instanz eine definierte Quality of Service „mit Fehlerisolierung“ gibt. Von den Karten, die wir liefern, führt NVIDIAs MIG-Leitfaden vom 11. September 2026 die RTX PRO 6000 Workstation Edition und Max-Q mit bis zu vier Instanzen zu 24 GB, die RTX PRO 5000 mit zwei, die RTX PRO 4500 mit zwei zu 16 GB und die H200 NVL mit sieben, deren kleinstes Profil 1g.18gb ist. Für die RTX PRO 4500 nennt der Leitfaden keine Edition und gibt Profile, aber keine Voraussetzungen an: Treiber 575.51.03 oder neuer, ein Mindest-vBIOS und die Umschaltung des Anzeigemodus dokumentiert NVIDIA nur für die RTX PRO 6000 und 5000, und Datenblatt und Produktseite der Workstation-Karte erwähnen MIG nicht; lassen Sie sich die MIG-Unterstützung für diese Karte also schriftlich bestätigen. Der Leitfaden behandelt die RTX PRO 5000 mit 48 GB, aufgeteilt in zwei zu 24 GB; für die Karte mit 72 GB nennt NVIDIAs Datenblatt zwei zu 36 GB. Die RTX PRO 5500 ist mit zwei Instanzen zu bis zu 42 GB angekündigt und steht noch nicht im Leitfaden. Die L4, L40S, RTX PRO 4000 und RTX PRO 2000 stehen nicht auf NVIDIAs MIG-Liste. Unser Vergleich von MIG und vGPU behandelt die Seite der virtuellen Maschinen.

Das Device-Plugin stellt MIG über eine von zwei Strategien bereit, festgelegt durch den Wert mig.strategy des Operators, der standardmäßig auf single steht. Mit single werden MIG-Instanzen unter dem üblichen Namen nvidia.com/gpu gemeldet, und die Ressource steht dann für die MIG-Geräte auf dem Node statt für die ganzen GPUs. Mit mixed wird jedes Profil zu einem eigenen Ressourcentyp. Nach NVIDIAs Namensschema erscheint ein Viertel einer RTX PRO 6000 dann als nvidia.com/mig-1g.24gb und die kleinste Instanz einer H200 NVL als nvidia.com/mig-1g.18gb. NVIDIAs Regeln für die Wahl sind kurz: single ist für Nodes gedacht, auf denen MIG auf allen GPUs aktiviert ist, mixed für Nodes, auf denen das nicht der Fall ist oder deren Layout mehr als ein Profil nutzt. Ein Node, der eine zweite NVIDIA-GPU aus MIG heraushält, etwa eine Karte für die Anzeige, braucht also mixed. Device-Plugin v0.20.0, die Version in Operator v26.7.0, hat seinen Abgleich der Profile korrigiert, sodass Varianten mit Suffixen wie -me, +me.all und +gfx als eigene Kubernetes-Ressourcen bereitgestellt werden.

Der MIG Manager setzt das Layout um. Ein Node-Label, nvidia.com/mig.config, benennt es, zum Beispiel all-disabled oder ein Layout mit durchgehend einem Profil wie NVIDIAs Beispiel all-1g.10gb; seit Operator v26.3.0 erzeugt der MIG Manager die verfügbaren Layouts für jeden Node aus den GPUs, die er vorfindet, und meldet den Fortschritt in nvidia.com/mig.config.state. Ein Wechsel des Layouts unterbricht den Betrieb: NVIDIA schreibt, dass der MIG Manager voraussetzt, dass auf den zu konfigurierenden GPUs keine Benutzer-Workloads laufen, und dass der Node eventuell per Cordon gesperrt und auf manchen Plattformen neu gestartet werden muss. Eine größere GPU entsteht mit MIG auch nicht, denn NCCL wird mit MIG nicht unterstützt, wie unser Artikel zum Nutanix-Cluster für verteiltes Training erklärt.

Drei der Workstation-Karten brauchen einen weiteren Schritt, den der Operator nicht übernimmt. Auf der RTX PRO 6000 Workstation Edition und Max-Q sowie auf der RTX PRO 5000 lässt sich MIG erst aktivieren, nachdem der Anzeigemodus mit NVIDIAs Werkzeug DisplayModeSelector von Grafik auf Compute umgestellt wurde, was die Displayausgänge abschaltet; die RTX PRO 6000 Server Edition liefert NVIDIA ab Werk mit abgeschalteter Displayausgabe aus. In der Dokumentation des GPU Operators haben wir zu dieser Umschaltung nichts gefunden; auf diesen Karten ist sie also ein manueller Schritt für jede einzelne Karte, beschrieben in unserem MIG-Runbook für RTX PRO Blackwell.

Time-Slicing: mehr Pods, keine Isolierung

Beim Time-Slicing wechseln sich mehrere Pods auf einer GPU ab. Eingestellt wird es in einer ConfigMap für das Device-Plugin: Unter sharing.timeSlicing erhält eine Ressource wie nvidia.com/gpu einen Wert replicas, „die Zahl der geteilten Zugriffe, die für eine GPU gewährt werden“, und die ClusterPolicy verweist über devicePlugin.config.name auf die ConfigMap. Das Feld devicePlugin.config.default benennt den Eintrag für alle Nodes, und das Label nvidia.com/device-plugin.config wählt für einen einzelnen Node einen anderen aus; ohne Standardeintrag, so NVIDIA, erreicht die Konfiguration nicht automatisch alle Nodes. Mit vier Replikaten wird jede Karte als vier GPUs gemeldet. renameByDefault meldet die Replikate als nvidia.com/gpu.shared; bleibt es auf false, bleibt der Ressourcenname gleich, und stattdessen erhält das Produkt-Label des Nodes das Suffix -SHARED. failRequestsGreaterThanOne lehnt jede Anforderung von mehr als einem Replikat mit einem UnexpectedAdmissionError ab. Der Operator überwacht die ConfigMap nicht, eine Änderung greift also erst, wenn Sie die Pods des Device-Plugins neu starten; bestehende Workloads laufen weiter, und NVIDIA empfiehlt, das in einem Wartungsfenster zu tun.

Der Preis dafür ist die Isolierung. NVIDIAs Dokumentation zum Operator sagt, dass es anders als bei MIG „keine Speicher- oder Fehlerisolierung zwischen Replikaten gibt“, und das README des Device-Plugins formuliert es drastischer: Jeder Workload „hat Zugriff auf den GPU-Speicher und läuft in derselben Fehlerdomäne wie alle anderen (das heißt, wenn ein Workload abstürzt, stürzen alle ab)“. Ein Pod, der zwei Replikate anfordert, bekommt auch nicht garantiert die doppelte Rechenleistung. Time-Slicing eignet sich für Entwicklung, Notebooks und leichte Jobs, die einen störenden Nachbarn vertragen. Es lässt sich auch mit MIG kombinieren, damit sich mehrere Pods jede Instanz teilen.

MPS: feste Anteile, eine Fehlerdomäne

Der Multi-Process Service von CUDA führt über einen Control-Daemon die Arbeit mehrerer Prozesse gleichzeitig auf einer GPU aus. Das Device-Plugin unterstützt ihn mit einem Abschnitt sharing.mps, der wie beim Time-Slicing replicas annimmt, aber mit Grenzen: Der Speicher, den jeder Client nutzen darf, ist „auf einen gleich großen Anteil des gesamten Gerätespeichers begrenzt“, und der Control-Daemon deckelt außerdem den Anteil jedes Clients an der Rechenleistung. Das README nennt die Einschränkungen ohne Umschweife: „Ab v0.15.0 des Device-Plugins gilt die MPS-Unterstützung als experimentell“, Sharing mit MPS wird auf Geräten mit aktiviertem MIG nicht unterstützt, und nur Ressourcen nvidia.com/gpu auf ganzen GPUs lassen sich auf diese Weise teilen.

NVIDIAs MPS-Dokumentation vervollständigt das Bild bei Fehlern. MPS-Clientprozesse „haben vollständig isolierte GPU-Adressräume“, aber ein fataler GPU-Fehler „wird allen Clients gemeldet, die auf der Teilmenge der GPUs laufen, auf die der fatale Fehler beschränkt ist“, sodass ein fehlerhafter Prozess jeden Pod auf dieser Karte unterbricht. NVIDIA beschreibt MPS als nützlich, wenn „kein einzelner Anwendungsprozess genug Arbeit erzeugt, um die GPU auszulasten“, was auf viele kleine Inferenzdienste passt.

Virtuelle Maschinen und DRA

Der Operator kann GPUs auch virtuellen Maschinen unter KubeVirt zuweisen, als ganze Karten per Passthrough oder als vGPUs, gewählt Node für Node mit dem Label nvidia.com/gpu.workload.config; das ist eine vom hier beschriebenen Container-Sharing getrennte Konfiguration. Die größere Veränderung ist Dynamic Resource Allocation. Release v26.7.0 kann NVIDIAs DRA-Treiber v0.5.0 verwalten, der Kubernetes v1.34.2 oder neuer braucht. Die Zuweisung ganzer GPUs und bestehender MIG-Geräte ist allgemein verfügbar; das Anlegen von MIG-Geräten bei Bedarf, MPS und eigene Time-Slicing-Einstellungen sind Alpha-Funktionen. Unter dem Operator hat ein Cluster entweder eine Ressource GPUCluster für den DRA-Treiber oder eine ClusterPolicy für das Device-Plugin, nicht beides.

Die Wahl der Methode

Ganze GPUs für Training und für jeden Dienst, der eine Karte allein auslastet.

MIG, wenn sich mehrere Dienste oder Teams eine Karte teilen und jeder garantierten Speicher und Schutz vor den anderen braucht: vier Instanzen zu 24 GB auf einer RTX PRO 6000, bis zu sieben auf einer H200 NVL. Von den hier genannten Karten stehen die H200 NVL und die RTX PRO 6000 Server Edition sowohl auf NVIDIAs MIG-Liste als auch auf der Supportliste des Operators; die RTX PRO 6000 Workstation Edition und Max-Q sowie die RTX PRO 5000 stehen nur auf der MIG-Liste und brauchen den manuellen Schritt beim Anzeigemodus.

Time-Slicing für Entwicklung und leichte Jobs, bei denen ein Absturz, der die Nachbarn mitreißt, hinnehmbar ist.

MPS für viele kleine Inferenzprozesse auf einer ganzen GPU, mit dem oben genannten Vorbehalt bei Fehlern und nicht auf Karten mit aktiviertem MIG.

Was wir liefern

Eurokommerz liefert die MIG-fähigen Modelle RTX PRO 6000 Workstation Edition und Max-Q, RTX PRO 5000 und H200 NVL sowie die L40S und L4 für den Einsatz als ganze GPU und mit Time-Slicing, EU-weit mit Herstellergarantie; wir liefern auch die RTX PRO 4500, doch NVIDIA dokumentiert nicht, was MIG auf ihr voraussetzt. Wir bauen KI-Server nach Auftrag mit den Karten, die ein Cluster braucht; nennen Sie uns Ihre Kubernetes-Umgebung und die Workloads, und wir stimmen die Karte auf die Sharing-Methode ab.

FAQ