OpenShift AI auf GPU-Servern: GPU Operator, RTX PRO Server Edition und H200 NVL als Worker

Was ein GPU-Knoten für OpenShift AI braucht

Ein GPU-Worker für Red Hat OpenShift AI braucht von NVIDIA-Seite drei Dinge: eine Karte auf der Support-Liste des GPU Operators, den NVIDIA GPU Operator, installiert über den Operator Lifecycle Manager (OLM) mit einer ClusterPolicy, und für NVIDIA NIM oder andere AI-Enterprise-Software eine Lizenz für NVIDIA AI Enterprise je GPU. Im Oktober 2026 ist OpenShift AI Self-Managed 3.5 das aktuelle Release, und NVIDIAs Plattformseite unterstützt OpenShift 4.18 bis 4.22 für den GPU Operator 26.7.x.

Alles Weitere ist gewöhnliches OpenShift: Der Knoten tritt dem Cluster bei, der Node Feature Discovery Operator versieht ihn mit Labels, der GPU Operator betreibt den NVIDIA-Treiber als Container, und das Device Plugin meldet nvidia.com/gpu. OpenShift AI sieht die GPUs dann über Hardware-Profile. Dieser Artikel nennt die Voraussetzungen und die Servergrößen; unser Leitfaden zur privaten LLM-Plattform auf Kubernetes behandelt den Serving-Stack auf Upstream-Kubernetes, VMware Private AI Foundation with NVIDIA den Weg über VCF.

NVIDIA, Plattformseite des GPU Operators (14. Oktober 2026), Support-Matrix von NVIDIA AI Enterprise 8.2 (2. September 2026), Dokumentation zu Red Hat OpenShift AI Self-Managed 3.5; alles gelesen am 24. Oktober 2026.

Welche Karten OpenShift-AI-Worker nutzen können

Die Support-Liste des GPU Operators ist der erste Filter. Von den Karten, die wir liefern, nennt sie die RTX PRO 6000 Blackwell Server Edition, die RTX PRO 4500 Blackwell Server Edition, die H200 NVL, die L40S und die L4. Für die RTX PRO 6000 Server Edition verlangt sie Treiber 575.57.08 oder neuer und vermerkt, dass MIG mit 575.57.08 selbst nicht unterstützt wird. Einen Eintrag für die RTX PRO 6000 Workstation oder Max-Q oder für die RTX PRO 5000 haben wir nicht gefunden; Workstation-Karten gehören also nicht in OpenShift-Worker.

Der zweite Filter ist die Serving-Software. Red Hats unterstützte Konfigurationen für Red Hat AI 3 nennen die NVIDIA-Beschleuniger für den Red Hat AI Inference Server, Red Hats vLLM-Distribution: unter anderem L4 und L40S, H100 und H200 sowie „RTX PRO 6000 Blackwell Server Edition“ und „RTX PRO 4500 Blackwell Server Edition“. Die H200 NVL erscheint nicht unter eigenem Namen; die Liste führt die H200. Lassen Sie bei Knoten mit H200-NVL-Karten von Red Hat bestätigen, dass die NVL-Bauform abgedeckt ist, bevor Sie sich auf diesen Support verlassen.

NVIDIA, Plattformseite des GPU Operators (14. Oktober 2026); Red Hat AI 3, unterstützte Produkt- und Hardwarekonfigurationen (AI Inference Server 3.4.0-ea.1); MIG aus NVIDIAs MIG User Guide vom 13. Oktober 2026, wie in unseren MIG-Leitfäden; alles gelesen am 24. Oktober 2026.

NVIDIAs Plattformseite nennt außerdem die GPUs, die für OpenShift in den großen Public Clouds validiert wurden, von der T4 bis zur H200, und führt die RTX-PRO-Karten dort nicht auf. Beide RTX PRO Server Editions stehen auf der allgemeinen GPU-Liste des Operators und auf Red Hats Beschleunigerliste. Wir liefern alle fünf Karten; nennen Sie uns das OpenShift-Release Ihres Clusters, und wir schlagen Worker vor, deren Karten auf beiden Listen stehen.

Den GPU Operator über OLM installieren

NVIDIAs OpenShift-Anleitung, aktualisiert am 14. Oktober 2026, installiert den zertifizierten Operator aus dem Katalog der Konsole: ab 4.20 unter Ecosystem, System Catalog, davor unter Operators, OperatorHub. Vorgeschlagen ist der Namespace nvidia-gpu-operator; in einem anderen Namespace wird das Monitoring nicht automatisch aktiviert. Auf der Kommandozeile sind die Schritte ein Namespace, eine OperatorGroup, eine Subscription auf das Paket gpu-operator-certified mit installPlanApproval: Manual und die Freigabe des Install Plans. Red Hat merkt für 4.21 und neuer an: Der OLMv1-Katalog ist standardmäßig als Technology Preview aktiv, und wer ihn deaktiviert, erhält das gewohnte Installationsformular zurück.

Mit dem Operator entsteht die Definition der ClusterPolicy. NVIDIAs Anleitung übernimmt die Standardinstanz gpu-cluster-policy aus der Annotation alm-examples der ClusterServiceVersion und warnt, dass eine ClusterPolicy mit leerer Spezifikation „fails to deploy“. Rechnen Sie mit 10 bis 20 Minuten, bevor Sie Fehler suchen; Erfolg zeigt State:ready.

Bei Upgrades zählen drei Punkte. NVIDIAs Plattformseite führt 26.7.x als unterstützt und 26.3.x als veraltet, während das CLI-Beispiel der OpenShift-Anleitung noch den Kanal 26.3 abonniert; lesen Sie die Kanäle aus dem packagemanifest und wählen Sie einen unterstützten. Stand 23. Oktober 2026 rät unser Leitfaden zum GPU-Sharing in Kubernetes zu 26.7.2 oder neuer, weil Releases bis 26.3.1 von CVE-2026-24260 betroffen sind. Und OLM aktualisiert Custom Resources beim Upgrade des Operators nicht: NVIDIAs Hinweise zu 25.10.0 empfehlen aus diesem Grund, nach dem Upgrade cdi.enabled in der ClusterPolicy auf true zu setzen. Vergleichen Sie die ClusterPolicy nach jedem Operator-Upgrade mit den Standardwerten des neuen Releases.

Der GPU Operator 26.7 bietet außerdem Dynamic Resource Allocation über eine GPUCluster-Ressource anstelle der ClusterPolicy, und NVIDIA hat eine DRA-Installationsanleitung für OpenShift ergänzt. Ein Cluster nutzt das eine oder das andere. Red Hats Verfahren für OpenShift AI legt eine ClusterPolicy an, für OpenShift AI bleiben wir daher dabei; unser Leitfaden zu Kubernetes DRA für NVIDIA-GPUs erklärt die Alternative.

Die GPUs in OpenShift AI aktivieren

Red Hats Anleitung „Enable NVIDIA GPUs“ für OpenShift AI 3.5 setzt cluster-admin-Rechte und eine installierte, erkannte GPU voraus. Das Verfahren:

1. Den Node Feature Discovery Operator installieren und eine NodeFeatureDiscovery-Instanz anlegen.
2. Den NVIDIA GPU Operator installieren und eine ClusterPolicy mit Standardwerten anlegen.
3. Die ConfigMap migration-gpu-status im Projekt redhat-ods-applications löschen.
4. Den Rollout des Deployments rhods-dashboard neu starten und warten, bis alle Pods neu gestartet sind.
5. Mit oc describe node prüfen, dass der Knoten nvidia.com/gpu unter Capacity und Allocatable führt.

Red Hat nennt zwei Grenzen: Beschleuniger werden „within the same cluster only“ unterstützt, und seit OpenShift AI 2.19 wird RDMA nur für NVIDIA-GPUs unterstützt. Die Seite Installed Operators sollte danach den NVIDIA GPU Operator, Node Feature Discovery und Kernel Module Management zeigen.

Hardware-Profile verbinden die Nutzer mit den Knoten. Ein Administrator legt sie unter Settings, Environment setup, Hardware profiles an. Jedes Profil enthält Ressourceneinträge mit Standard-, Mindest- und Höchstwert, Node Selectors, Tolerations und, wenn Kueue das Scheduling übernimmt, eine Local Queue. Ein Profil für die Serving-Runtime des Sprachmodells wählt die Knoten mit H200 NVL oder RTX PRO 6000 Server Edition per Label und toleriert deren Taint; ein zweites Profil für Notebooks kann auf L4-Knoten zeigen. Die Labels kommen von GPU Feature Discovery, etwa das GPU-Modell in nvidia.com/gpu.product.

MIG und Time-Slicing auf OpenShift-Workern

MIG unter OpenShift folgt NVIDIAs OpenShift-Anleitung: die ClusterPolicy unter /spec/mig/strategy auf single oder mixed setzen, dann den Knoten mit nvidia.com/mig.config und einer Aufteilung beschriften; Standard ist all-disabled. MIG Manager ermittelt die Profile jeder GPU und schreibt je Knoten eine ConfigMap. Der Knoten muss vorher von GPU-Workloads geleert sein: MIG Manager beendet GPU-Pods während der Änderung selbst, und ist der Knoten nicht geleert, steht das Label nvidia.com/mig.config.state auf failed.

Mit der Strategie single nutzen alle GPUs eines Knotens dieselbe Aufteilung, und die Instanzen erscheinen als nvidia.com/gpu. Mit mixed ist jedes Profil eine eigene Ressource: Ein Viertel einer RTX PRO 6000 erscheint als nvidia.com/mig-1g.24gb, die kleinste Instanz der H200 NVL als nvidia.com/mig-1g.18gb. Ein Hardware-Profil nennt diese Ressource dann als Kennung, nach unserer Lesart der Profilfelder bei Red Hat. Ein über mehrere GPUs verteiltes Modell braucht ganze Karten, weil NCCL mit MIG nicht unterstützt wird; unsere MIG-Profile der RTX PRO 6000 und MIG-Profile der H200 NVL zeigen, was in jede Instanz passt.

Time-Slicing ist die zweite Methode, die Red Hat beschreibt. Eine ConfigMap time-slicing-config im Namespace nvidia-gpu-operator legt je GPU-Modell eine Zahl von Replicas fest, devicePlugin.config der ClusterPolicy verweist darauf, und das Machine Set versieht die Knoten mit nvidia.com/device-plugin.config. Red Hat schreibt „All workloads share GPU memory“ und dass Time-Slicing keine strikte Isolation bietet; es passt also zu Notebooks und leichter Inferenz, MIG zu geteilten Produktiv-Endpunkten.

Model Serving: vLLM-Runtime oder NVIDIA NIM

OpenShift AI 3.5 bringt für NVIDIA-GPUs eine vorinstallierte Serving-Runtime mit, die vLLM NVIDIA GPU ServingRuntime for KServe. Den NVIDIA Triton Inference Server führt Red Hat unter den getesteten und verifizierten Runtimes, die ein Administrator von Hand hinzufügt.

Die NVIDIA-NIM-Serving-Plattform wird auf der Seite Applications, Explore des OpenShift-AI-Dashboards aktiviert. Red Hats Voraussetzungen: aktivierte GPU-Unterstützung, ein NVIDIA Cloud Account mit Zugang zum NGC-Portal, dieses Konto „associated with the NVIDIA AI Enterprise Viewer role“ und ein auf NGC erzeugter persönlicher API-Schlüssel, den Sie in der NIM-Kachel eingeben. Nach einem Upgrade von OpenShift AI ist der Schlüssel erneut einzugeben. Die Berechtigung kommt also von NVIDIA, nicht aus der Red-Hat-Subscription, wie unser Leitfaden zur Lizenzierung von NVIDIA AI Enterprise erklärt: NVIDIAs NIM-FAQ verlangt für NIM im Produktivbetrieb eine AI-Enterprise-Lizenz, gezählt je GPU, und jede H200 NVL enthält ein AI-Enterprise-Abonnement über fünf Jahre. Unser Artikel zum Aktivieren von NVIDIA-AI-Enterprise-Lizenzen behandelt NGC-Organisation und Schlüssel.

Die Images des Red Hat AI Inference Server in dieser Liste sind mit CUDA 13.0 gebaut und laut Red Hat „backward compatible with CUDA 12.9 drivers“. Die Rechenzentrumstreiber R580 und R595, die der GPU Operator ausrollt, liegen über dieser Untergrenze.

Knotengrößen für OpenShift AI

Unsere drei Referenz­konfigurationen passen auf die Rollen von OpenShift-Workern. Sie folgen NVIDIAs Leitfaden für NVIDIA-Certified Systems: zwei Sockel, mindestens sechs Kerne je GPU und mindestens doppelt so viel Arbeitsspeicher wie GPU-Speicher.

Unsere Referenz­konfigurationen auf /de/ai-servers/, jeweils mit zwei AMD-EPYC-Prozessoren: 384 GB, 768 GB und 2,3 TB DDR5 ECC, der H200-NVL-Knoten mit 400G-Netzwerk; nutzbarer Speicher nach unserer Regel für Nutzer je Karte (0,9 × vom Treiber gemeldeter Speicher − 3 GiB je Karte); Leistung an der Steckdose nach unserer Schätzung (Karten mit 600 W, jeweils zwei EPYC 9135, 9355 bzw. 9555 und 15 Prozent für den Rest), bestätigt durch eine Messung am gelieferten System.

Als Beispiele nach unserer Regel für Nutzer je Karte, aus unseren Schwesterseiten: Vier RTX PRO 6000 Server Edition bedienen Llama 3.3 70B in FP8 mit 156 gleichzeitigen Gesprächen zu 8K als zwei Tensor-Parallel-Paare mit FP8-KV-Cache, vier H200 NVL 340 als eine Kopie. Ein Cluster mit einem großen und vielen kleinen Modellen kombiniert oft beides: einen Knoten mit RTX PRO 6000 Server Edition oder H200 NVL für das Hauptmodell und einen L4- oder MIG-geteilten Knoten für Embeddings, Reranker und Notebooks. Die Werte je Aufteilung stehen auf unseren Seiten zum Server mit vier RTX PRO 6000 und zum Server mit acht H200 NVL.

Mit rund 3,4 kW liegt der Knoten mit vier Karten über den 2,94 kW, die wir je 230-V-Anschluss mit 16 A einplanen, und der Knoten mit acht Karten braucht einen Drehstromplatz; unser Leitfaden zum Stromanschluss mit 16 A, 32 A und Drehstrom rechnet das durch. OpenShift ändert am Strombudget nichts, aber Cluster mit drei oder mehr GPU-Workern für die Verfügbarkeit vervielfachen es.

Was wir liefern

Sie können diese Worker bei uns kaufen: Unser Team legt die Konfiguration auf Ihre Arbeitslast und Ihr Budget aus und antwortet innerhalb eines Werktages. Wir bauen KI-Server nach Auftrag mit RTX PRO 6000 oder RTX PRO 4500 Server Edition, H200 NVL, L40S oder L4, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer EU-Rechnung und mit Herstellergarantie auf jede Komponente, geliefert in die ganze EU. Lizenzen für NVIDIA AI Enterprise je GPU können auf derselben Rechnung stehen. Schicken Sie uns Ihre OpenShift-Version, die Zahl der Knoten und die geplanten Modelle, und wir antworten mit einer Knotenkonfiguration. Wenn Sie auch Unterstützung bei Modellen, Retrieval und Serving wünschen, ist das unser Service Private AI/ML.

FAQ