NVIDIA spendet OpenShell an die CNCF und ergänzt Open-Source-Tools für KI-Fabriken

NVIDIA gab am 10. November 2026 auf der KubeCon + CloudNativeCon bekannt, dass das Unternehmen seine OpenShell-Laufzeitumgebung für Agentensicherheit in die Sandbox der Cloud Native Computing Foundation (CNCF) einbringt und drei Open-Source-Komponenten für seine DSX AI Factory Platform veröffentlicht.

Die Ankündigungen verbinden die Governance von Agenten mit der Infrastruktur, die für ihren effizienten Betrieb erforderlich ist. NVIDIA beteiligt sich außerdem am von Google initiierten Projekt Agent Substrate und ergänzt DSX um Kubernetes Engine, Kubernetes Recipes und Snapshot. Damit werden die Ausführung von Sitzungen, die Clusterverwaltung und die Wiederherstellung von Inferenz abgedeckt.

OpenShell bewegt sich in Richtung gemeinschaftlicher Governance

OpenShell setzt deterministische Kontrollen ein, wenn autonome Agenten Werkzeuge nutzen, auf Inferenzdienste zugreifen und Arbeitslasten ausführen. Die Agenten laufen in Sandbox-Umgebungen mit Kernel-Isolierung. Deklarative YAML-Richtlinien regeln den Zugriff auf Dateisysteme, Netzwerke, Prozesse und Anbieterzugangsdaten. Zugangsdaten werden nur in Anfragen eingefügt, die an genehmigte Endpunkte gerichtet sind. Eine formale Verifikation prüft vor der Genehmigung, ob eine vorgeschlagene Richtlinienänderung riskante neue Zugriffsrechte gewähren würde.

Die Laufzeitumgebung steht unter der Apache-2.0-Lizenz. NVIDIA berichtet, dass Hunderte Organisationen sie bereits genutzt haben, in weniger als einem Jahr Zehntausende Beiträge eingegangen sind und an der Sandbox-Governance Organisationen beteiligt sein werden, die OpenShell in ihre Produkte integrieren. Der Übergang ist noch im Gange: Laut einer Projektmitteilung wird die Entwicklung in die Organisation ai-openshell verlagert; während des Übergangs verbleiben Code, Issues und Pull Requests bei NVIDIA/OpenShell.

Agent Substrate soll ungenutzte Rechenkapazitäten besser nutzen

Agent Substrate setzt bei den Kosten an, die dadurch entstehen, dass Agentensitzungen aktiv gehalten werden. Agenten warten häufig auf Eingabeaufforderungen, Werkzeugergebnisse oder Modellantworten. Ein eigens dafür bereitgestellter, betriebsbereiter Kubernetes-Pod hält während dieser Pausen Ressourcen vor. Wird der Pod dagegen neu erstellt, geht der Zustand verloren und ein weiterer Kaltstart wird erforderlich. NVIDIA und Google arbeiten außerdem an einer OpenShell-Integration für Agenten in Cloud- und On-Premises-Systemen.

Das Design von Agent Substrate ordnet viele Sitzungen mit gespeichertem Zustand einem kleineren Pool betriebsbereiter Worker zu. Es erstellt Prüfpunkte für inaktive Sitzungen, einschließlich Speicher- und Dateisystemzustand, gibt die zugehörigen Worker frei und stellt die Sitzungen auf verfügbaren Workern wieder her, ohne den üblichen Weg zur Erstellung eines Kubernetes-Pods erneut durchlaufen zu müssen. Die Worker bleiben gewöhnliche Kubernetes-Pods; daher gelten weiterhin die Richtlinien für Clusterplanung, Kontingente und Platzierung. Zu den vorgesehenen Arbeitslasten zählen Programmierassistenten, Umgebungen für bestärkendes Lernen und kurzlebige GPU-Sandboxes für Forschungszwecke.

NVIDIA entwickelt die Interoperabilität mit Dynamo für Inferenz und KAI Scheduler für gemeinsam genutzte Clusterressourcen. Dynamo kann die prognostizierte Zeit bis zum ersten Token und die Auslastung des GPU-Pools bereitstellen, damit Agent Substrate entscheiden kann, ob ein Agent aktiv bleiben, angehalten oder fortgesetzt werden soll. Die APIs ändern sich noch, die GPU-Unterstützung wird auf Basis der Kubernetes Dynamic Resource Allocation neu aufgebaut, und Teile der Dynamo-Integration sind experimentell.

DSX ergänzt Clusterverwaltung und schnellere Wiederherstellungen

NVIDIA Kubernetes Engine und NVIDIA Kubernetes Recipes (NVKE und NVKR) sind als öffentliche Vorschau unter der Apache-2.0-Lizenz verfügbar. NVIDIA weist darauf hin, dass sich APIs, Konfiguration und Verhalten ändern können, und empfiehlt die Projekte noch nicht für Produktionsarbeitslasten. NVKR erstellt reproduzierbare Knoten- und Container-Images, Binärdateien und Helm-Charts aus Quellen mit festgelegten Versionen und dokumentiert die Eingaben. NVKE verwendet diese Artefakte, um Cluster über eine REST-API und Controller bereitzustellen und zu betreiben. Die Projekte können jedoch unabhängig voneinander eingesetzt werden.

NVKE erstellt Cluster für Kundenarbeitslasten mit getrennten Kubernetes-Steuerungsebenen, etcd-Instanzen und Knotenpools. Die Bare-Metal-Kapazität bezieht das System über NVIDIA Infra Controller und dessen Cluster-API-Provider CAPNICo. Bevor ein Knoten Zugangsdaten für den Clusterbeitritt erhält, muss er eine attestierte SPIFFE-Identität vorweisen. Firmus und SK Telecom integrieren die Projekte in ihre KI-Fabriken. Mirantis, Netris, OpenNebula Systems, Rafay, Spectro Cloud und vCluster planen Integrationen mit ihren Infrastrukturplattformen, verwalteten Kubernetes-Angeboten oder Lösungen zur Netzwerkautomatisierung.

NVIDIA Snapshot soll Kaltstarts bei der Inferenz verkürzen, indem es Prüfpunkte des vollständig initialisierten CPU- und GPU-Speichers einer Arbeitslast erstellt. Für die Wiederherstellung sind dasselbe GPU-Modell und derselbe Treiber erforderlich; wiederholtes Laden von Gewichten, Kompilieren und Erfassen von CUDA-Graphen entfällt.

Für B200-GPUs mit VAST-NFS-Speicher berichtet NVIDIA von Wiederherstellungszeiten zwischen 3,6 und 42,7 Sekunden bei Konfigurationen mit vLLM, SGLang und TensorRT LLM. Gegenüber Kaltstarts entspricht dies einer Beschleunigung um das 8- bis 36-Fache. Die Tests umfassten ein Modell mit 600 Millionen Parametern sowie Konfigurationen mit acht GPUs und Prüfpunkten von nahezu 1 TB. Die Erstellung eines Prüfpunkts dauerte 15 Sekunden bis 5,5 Minuten. In jeder getesteten Konfiguration war die kombinierte Zeit für die Erstellung des Prüfpunkts und die Wiederherstellung kürzer als ein Kaltstart.

Diese Werte erfassen nicht den Start eines gesamten Rechners: Die Bereitstellung der Infrastruktur und das Laden von Container-Images sind nicht Teil der gemessenen Wiederherstellungszeit. Auch der Schlüssel-Wert-Cache wird vor jedem Prüfpunkt freigegeben und nicht im Artefakt gespeichert. Die Ergebnisse beziehen sich daher auf die Wiederherstellung einer initialisierten Arbeitslast auf kompatibler Infrastruktur.

Der eigene GLM-5.3-Test von Crusoe auf NVIDIA HGX B300 verwendete einen Checkpoint mit 594 GB GPU-Zustandsdaten. Crusoe maß für die Wiederherstellung des GPU-Zustands 15,0 Sekunden von einer lokalen NVMe-SSD gegenüber 33,3 Sekunden von NFS. Mit dem Artefakt auf NVMe dauerte es von der Pod-Erstellung bis zur Betriebsbereitschaft 31 Sekunden, verglichen mit etwa acht Minuten bei einem Kaltstart. Das zeigt, dass der Speicher ein wichtiger Faktor für die Wiederherstellungsleistung ist. Crusoe hat außerdem Änderungen zur Leistungssteigerung und Diagnose in vorgelagerte Projekte eingebracht.

Zusammengenommen verlagern die Projekte größere Teile der Steuerungsebene und des Wiederherstellungspfads der KI-Fabrik in offene Repositories, allerdings mit unterschiedlichem Entwicklungsstand: Der Governance-Wechsel bei OpenShell ist noch nicht abgeschlossen, Agent Substrate entwickelt sich weiter, und NVKE sowie NVKR sind weiterhin Vorschauversionen. Die Benchmarks von Snapshot belegen den deutlichsten messbaren betrieblichen Nutzen. Die Kompatibilitätsanforderungen und die Speicherergebnisse von Crusoe zeigen jedoch, dass eine schnellere Wiederherstellung sowohl von wiederverwendbarem Workload-Zustand als auch von der umgebenden Infrastruktur abhängt.