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.1. Release v26.7.2, in NVIDIAs Release Notes mit Stand 14. Oktober 2026, führt unter den aktualisierten Komponenten nur den DRA-Treiber, jetzt v0.5.1, und behält 595.91.07 als Standardtreiber bei. Installieren Sie 26.7.2 oder neuer (Stand 23. Oktober 2026): Operator-Releases bis 26.3.1 sind von CVE-2026-24260 betroffen (NVIDIA Container Toolkit bis 1.19.0). 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 23. 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.

Von dieser Liste liefern wir die RTX PRO 6000 und die RTX PRO 4500 Server Edition, die H200 NVL, die L40S und die L4, als Karten oder in nach Auftrag gebauten KI-Servern. Nennen Sie uns die Server, auf denen Ihr Cluster läuft, und wir sagen Ihnen, welche dieser Karten hineinpassen.

Vier Wege, eine GPU in Kubernetes zu teilen

Ein Pod fordert eine ganze Zahl von GPU-Ressourcen an; was jede Einheit ist, entscheidet das Device-Plugin: eine physische Karte, eine MIG-Instanz oder ein Replikat einer geteilten Karte. Der wichtigste Unterschied zwischen den vier Methoden ist, wie stark ein Pod seine Nachbarn beeinträchtigen kann.

MIG-Benutzerhandbuch von NVIDIA (4. November 2026), Dokumentation des GPU Operators (23. September 2026), README des NVIDIA k8s-device-plugin und Dokumentation zu CUDA MPS, abgerufen im September und Oktober 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, aktualisiert am 4. November 2026, alle drei Editionen der RTX PRO 6000 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; seit seiner Aktualisierung vom 4. November 2026 gibt er für diese Karte einen Mindesttreiber an, 575.64, aber kein Mindest-vBIOS und keine Umschaltung des Anzeigemodus, die er nur für die RTX PRO 6000 und 5000 beschreibt, mit den Mindesttreibern 575.51.03 und 575.57.08. Im Datenblatt und auf der Produktseite der Workstation-Karte haben wir keinen Hinweis auf MIG gefunden; 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. NVIDIAs Datenblatt vom Oktober 2026 gibt der RTX PRO 5500 zwei Instanzen zu bis zu 42 GB; im Leitfaden steht die Karte noch nicht. 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, das mit Operator v26.7.0 ausgeliefert wurde (v26.7.1 bringt v0.20.1 mit), 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. MIG-Instanzen lassen sich auch nicht zu einer größeren GPU zusammenschließen, und NVIDIAs MIG-Leitfaden (aktualisiert am 4. November 2026) beschreibt die MIG-Unterstützung von NCCL 2.31 und neuer nur als experimentell (ein Rank je MIG-Instanz, CUDA-Treiber 13.0 oder neuer, NCCL_MNNVL_ENABLE=0), 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 ergänzt: 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: „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. Seit Release v26.7.0 kann der Operator NVIDIAs DRA-Treiber verwalten, in v26.7.2 die Version v0.5.1; der Treiber braucht Kubernetes v1.34.2 oder neuer und einen NVIDIA-Treiber ab Branch 580, und da Kubernetes 1.34 am 27. Oktober 2026 das Ende seiner Unterstützung erreicht hat, planen Sie ihn auf 1.35 oder neuer. 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. Auf einem Server mit vier RTX PRO 6000 Server Edition können zwei Karten ganz bleiben, für ein Modell mit Tensor-Parallelismus über beide, während die anderen beiden als acht MIG-Instanzen zu je 24 GB Embedding, Reranking und kleine Modelle übernehmen; da MIG dann nicht auf allen GPUs des Knotens aktiv ist, braucht dieser Aufbau die Strategie mixed. Unser Inferenzknoten mit vier Karten trägt vier RTX PRO 6000 Server Edition, auf Wunsch mit installiertem Betriebssystem, Treibern, CUDA und Container-Runtime; schreiben Sie uns, welche Workloads sich eine Karte teilen sollen, und wir schlagen eine Konfiguration vor.

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

Wir liefern diese Karten EU-weit mit Herstellergarantie: die RTX PRO 6000 in allen drei Editionen, die RTX PRO 5000 und die H200 NVL für MIG, die RTX PRO 4500 als Workstation-Karte, für die NVIDIAs Leitfaden MIG-Profile und einen Mindesttreiber nennt, aber keine Edition, die RTX PRO 4500 Server Edition, die auf der Supportliste des Operators steht, sowie die L40S und L4 für den Einsatz als ganze GPU und mit Time-Slicing. Wir bauen KI-Server nach Auftrag mit den Karten, die ein Cluster braucht, vor der Lieferung montiert und getestet und auf Wunsch mit Betriebssystem, Treibern, CUDA und Container-Runtime. Wenn Sie die Kubernetes-Plattform selbst aufbauen und betreuen lassen wollen, ist das unser Service Private AI/ML, umgesetzt von unserem Engineering-Partner Vixen.UNO.

FAQ