Eine „KI-Fabrik“ besteht nicht aus einem einzelnen Modell oder einem einzelnen Kubernetes-Cluster, sondern aus einem gemeinsam genutzten Pool von Grafikprozessoren (GPUs), den gleichzeitig arbeitende Teams für unterschiedliche Zwecke verwenden: Feinabstimmung, Inferenzbetrieb und Evaluierung. Ein auf dem CNCF-Blog veröffentlichter Artikel vertritt die Ansicht, dass die eigentliche Herausforderung für Unternehmen nicht mehr nur im Training des Modells liegt, sondern darin, jedem Team sicheren und isolierten Zugriff auf dieselbe Hardware zu gewähren und zugleich eine hohe GPU-Auslastung sowie messbare Kosten aufrechtzuerhalten.
Verfasst wurde der Beitrag von Hrittik Roy in seiner Funktion als CNCF Ambassador und Platform Advocate bei vCluster. Er bietet eine praxisorientierte Betrachtung dazu, wie eine solche Umgebung auf Kubernetes aufgebaut werden kann. Die zentrale Aussage des Artikels lautet, dass Kubernetes zwar eine ausgereifte Grundlage für Container, RBAC, automatische Skalierung und Richtlinien bietet, für den Umgang mit Beschleunigern und die Mandantenisolierung auf denselben Knoten jedoch ein zusätzliches Ökosystem benötigt.
Der Engpass ist die Auslastung, nicht allein die Inferenzgeschwindigkeit
GPUs stellen den größten Kapitalaufwand in einer KI-Infrastruktur dar. Daher wird der Auslastungsgrad zu einer wirtschaftlich wichtigeren Kennzahl als das Erreichen einer maximalen Geschwindigkeit in einem einzelnen Lauf. Der Artikel nennt zwei zentrale Probleme: das Modell der Ressourcenzuweisung und das Modell der Isolation.
Beim herkömmlichen Device-Plugin-Modell fordert ein Workload beispielsweise nvidia.com/gpu: 1 an und reserviert eine vollständige Einheit, selbst wenn er nur zehn Prozent davon nutzt. Dynamic Resource Allocation oder DRA, das mit Kubernetes 1.34 allgemein verfügbar wurde, ermöglicht es dem Scheduler dagegen, Beschleuniger als Geräte mit Eigenschaften, Speicher und Topologie zu behandeln. Es teilt eine GPU jedoch nicht automatisch in Kontingente auf; die Dichte kommt aus der Geräteschicht, etwa HAMi. Dabei handelt es sich um ein CNCF-Projekt in der Phase Incubating, das softwarebasierte Grenzen für Speicher und Rechenleistung auf Containerebene durchsetzt und mehrere Anbieter von Beschleunigern unterstützt.
Umgekehrt kann die Zuweisung separater Hardware an jedes Team eine starke Isolation ermöglichen, aber einen großen Teil der Kapazität ungenutzt lassen. Daher unterscheidet der Artikel zwischen der Zuweisung einer vollständigen Einheit, wenn die Vertrauensgrenzen strikt sind, und der Aufteilung einer Einheit innerhalb einer gemeinsamen Vertrauensdomäne, um die Dichte zu erhöhen. NVIDIA MIG bietet Speicher- und Fehlerisolation auf Hardwareebene. Der Artikel weist jedoch darauf hin, dass der Einsatz von MIG als Trennung zwischen feindseligen Mandanten weiterhin diskutiert wird; deshalb bleibt die Zuweisung vollständiger GPUs in Fällen mit geringem Vertrauen die konservative Option.
Die Schichten der Fabrik – von der Hardware bis zum Workload
Das System beginnt mit der Bereitstellung der Rohhardware. Die Knoten werden erkannt und die GPUs, der ECC-Speicherstatus sowie die Identitäten der Netzwerkkarten überprüft. Anschließend wird ein Betriebssystem-Image installiert, das den GPU-Treiber sowie die CUDA- und NCCL-Bibliotheken enthält. Danach werden geeignete BIOS-Einstellungen angewendet, und die Knoten durchlaufen Belastungstests sowie NCCL-Tests, um sicherzustellen, dass die GPUs mit voller Bandbreite miteinander verbunden sind, bevor das Ergebnis in einer Quelle der Wahrheit wie NetBox erfasst wird. Dieser Ablauf kann über einen anbieterspezifischen Hardware-Manager oder mit offenen Werkzeugen wie Metal3 zusammen mit Ironic oder vMetal umgesetzt werden.
Nach der Zuweisung übernehmen Werkzeuge wie KAI Scheduler und Volcano Batch- und topologiebewusstes Scheduling, während Kueue Warteschlangen, Zulassung und Kontingente verwaltet. Auf der Workload-Schicht kann vLLM für Inferenz-Engines und KServe für standardisierte Endpunkte und automatische Skalierung eingesetzt werden, ergänzt durch NVIDIA Dynamo und llm-d für entkoppelte Inferenz in größeren Umgebungen. Die Gateway API stellt das Routing bereit, während LiteLLM ein mit der OpenAI-Schnittstelle kompatibles Gateway ergänzt.
Die Plattform ist nicht auf Container beschränkt. Der Artikel erklärt, dass Trainingsumgebungen Slurm über Slinky von SchedMD verwenden können. Slinky stellt Slurm-Dienste als benutzerdefinierte Ressourcen dar und integriert sie mit GPU Operator und DRA. Außerdem kann KubeVirt virtuelle Maschinen als Kubernetes-Workloads ausführen, sodass virtuelle Maschinen und Container aus demselben Pool mit einheitlichen Berechtigungen und Kontingenten verwaltet werden.
Isolation ist mehr als nur Namespaces
Der Artikel unterteilt das Isolationsproblem in zwei Ebenen. Auf der Control Plane stellt das Muster des Tenant-Clusters jedem Team eine virtuelle Kubernetes-Schnittstelle bereit, einschließlich eines API-Servers, dedizierter Ressourcen sowie unabhängiger Zulassungsregeln und RBAC-Konfigurationen, wobei sie als Workload über einem einzigen Basiskluster betrieben wird. vCluster dient hierfür als Beispiel und ermöglicht die Verwendung vertrauter Werkzeuge wie kubectl, Helm und Argo CD ohne proprietäre Erweiterungen.
Die Datenebene erfordert dagegen die Isolation von Netzwerken und Speicher sowie von Kontingenten und der Laufzeitumgebung. Cilium kann für CNI und Richtlinien eingesetzt werden, Multus und SR-IOV für den schnellen Pfad, ergänzt durch InfiniBand oder RoCEv2 für den Transport des GPU-Datenverkehrs zwischen den Knoten. Außerdem kommen separate VPCs über VXLAN und EVPN oder Partitionierungsschlüssel in InfiniBand zum Einsatz, während DPUs wie NVIDIA BlueField oder AMD Pensando bestimmte Isolations- und Verschlüsselungsfunktionen vom Hostprozessor weg verlagern. Der Artikel betont, dass der Maßstab für eine echte Cloud eine bei Bedarf hardwareseitig erzwungene Isolation ist und nicht allein der Einsatz von Namespaces.
Was macht aus dem Pool einen Cloud-Dienst?
Redaktionelle Einordnung: Der praktische Wert dieses Ansatzes liegt darin, dass er die Diskussion von der Frage „Welches Modell ist schneller?“ auf die Frage nach dem Betrieb der Infrastruktur selbst verlagert. Die Plattform wird nicht allein dadurch zu einem Cloud-Dienst, dass GPUs zusammengefasst werden, sondern erst dann, wenn ein Mandant Cluster über eine API, Terraform oder GitOps erstellen und löschen kann und die Ressourcen in deklarativer Form beschrieben sind und von Flux oder Argo CD verwaltet werden, ergänzt durch OIDC-Identität und RBAC-Berechtigungen.
Der Dienst benötigt außerdem verständliche Mess- und Abrechnungsfunktionen. Der Artikel schlägt vor, DCGM-Daten zur Berechnung von GPU-Sekunden zu verwenden und diese über OpenCost den Mandanten zuzuordnen. Auch Monitoring und Zuverlässigkeit sind Teil des Produkts und keine nachträgliche Betriebsergänzung: DCGM überwacht die Verschlechterung, Node Problem Detector wandelt Fehlersignale in Knotenstatus um, während der Verarbeitungszyklus den verdächtigen Knoten isoliert und leert, bevor neue Workloads geplant werden. Die Sicherheitsschicht umfasst Werkzeuge wie Keycloak über OIDC, OpenBao zusammen mit External Secrets Operator, Kyverno oder OPA für Kontrollen sowie Falco und Trivy für Laufzeitsicherheit und die Lieferkette.
Die schwierigste Prüfung bleibt der Übergang von einer Demonstration zu einem großflächigen Produktionseinsatz. Ein Beispiel, das zwei Teams und zwei Modelle auf einer aufgeteilten GPU ausführt, belegt für sich genommen noch nicht die Eignung des Designs bei Hunderten von Knoten und mehreren Rechenzentren. Der Artikel verweist auf die Rolle von Validierungswerkzeugen wie NVIDIA AI Cluster Runtime und dem Kubernetes AI Conformance-Programm, das zusammen mit Version 1.35 vorgestellt wurde. Er lässt jedoch betriebliche Fragen zur Explosionsreichweite, zu den Grenzen der Mandantenisolation und zur Wahl zwischen dem NVIDIA-DSX-OS-Stack und einer Zusammenstellung quelloffener Schichten offen.
Die Schlussfolgerung lautet, dass der Erfolg einer „KI-Fabrik“ von der Verbindung aus Dichte, Isolation und Abrechnung unter Berücksichtigung der Hardwaretopologie abhängt: von der Position der GPUs im Verhältnis zu NVLink oder NVSwitch, ihrer Anbindung an ein InfiniBand- oder RoCE-Netzwerk sowie der Positionen von GPU, NIC und CPU auf NUMA-Knoten. Wird ein Workload ohne diese Informationen geplant, können sich Kollektivkommunikationen an der langsamsten Verbindung verlangsamen, selbst wenn die Plattform auf Softwareebene funktionsfähig erscheint.