NVIDIA stellt das quelloffene Workload Map vor, eine gemeinsame Beschreibung von Kubernetes-Workloads für Inspektion, Gang-Scheduling und Plattformansichten
Am 2. November 2026 stellte der NVIDIA-Entwicklerblog das quelloffene NVIDIA Workload Map vor, das Struktur und Status von Kubernetes-Workloads wie JobSet, RayCluster oder KServe in Definitionen beschreibt, die man schreiben und prüfen kann. Im Beispiel erscheint ein JobSet in kubectl als drei Jobs und in Run:ai bis zur Registrierung der Katalogdefinition als drei getrennte Workloads, danach als ein Workload mit 12 GPUs. Der Beitrag nennt keine gemessene Zeitersparnis oder Fehlerraten, und die Definitionen selbst brauchen Review und Tests wie jedes Manifest.
Am 2. November 2026 stellte der Entwicklerblog von NVIDIA NVIDIA Workload Map vor, eine quelloffene Beschreibungsschicht für Kubernetes-Workloads. Das Problem kennt jeder, der Scheduler, Controller, Dashboards oder Kostenwerkzeuge für KI-Cluster baut. Ein echter Job besteht selten aus nur einem Pod. Ein verteiltes Training oder ein Inferenzserver über mehrere Knoten ist ein kleiner Baum aus Ressourcen, und jedes Framework, etwa JobSet oder LeaderWorkerSet, legt Rollen, Replikazahlen, Pod-Vorlagen und Status in einer anderen benutzerdefinierten Ressource ab. Werkzeuge brauchen deshalb für jedes Framework einen eigenen Adapter.
Workload Map ersetzt einen großen Teil dieses Codes je Framework durch Daten. Es wird als benutzerdefinierte Kubernetes-Ressourcendefinition samt Go-Bibliothek ausgeliefert, und jede Definition legt fest, wo Pod-Vorlagen, Replikazahlen und Statusfelder eines Workload-Typs zu finden sind. Der Beitrag merkt an, dass die Ressourcenart weiterhin Karta heißt, der frühere Projektname. Mit einer Definition kann ein Verbraucher Pod-Vorlagen, Replikazahlen, Status und Metadaten auslesen, Pod-Spezifikationen, Labels und Annotationen über alle Instanzen hinweg ändern und die Hierarchie verstehen, zum Beispiel die replizierten Jobs eines JobSet und ihre Pods. Eine Statuszuordnung übersetzt native Bedingungen in ein gemeinsames Vokabular. JobSet hat keine einfache Running-Bedingung, daher leitet die Definition sie mit einem Ausdruck über den Status der replizierten Jobs ab, während die nativen Bedingungen Completed und Failed direkt zugeordnet werden.
Das durchgespielte Beispiel ist ein JobSet mit einem Leader-Job und zwei Worker-Jobs, deren Pods jeweils vier GPUs anfordern. Mit kubectl aufgelistet sind das ein JobSet, drei Jobs und drei Pods, ohne Gesamtsumme. In NVIDIA Run:ai erscheinen vor der Registrierung der Definition die drei Jobs als drei getrennte Workloads mit je vier GPUs. Nach der Registrierung derselben Katalogdefinition mit einem einzigen API-Aufruf zeigt Run:ai einen Workload mit 12 GPUs und eine Strukturansicht von Leader und Workern. Das Kommandozeilenwerkzeug von Workload Map löst das laufende Objekt in denselben Baum auf, liest eine kubeconfig, bringt eingebaute Definitionen mit und erfordert laut Beitrag nicht, Workload Map im Cluster zu installieren. Die Ausgabe zeigt die Rollen von Leader und Workern und die Summe von 12 GPUs.
Die zweite Anwendung ist das Scheduling. Eine Definition kann optionale Anweisungen für Gang-Scheduling enthalten. Der Beitrag ist genau bei der Aufgabenteilung: Die Definition liefert Gruppierungsinformationen, während KAI Scheduler die gemeinsame Zulassung durchsetzt und die Platzierung entscheidet. KAI Scheduler nutzt Workload Map als Rückfalloption in seinem Pod-Gruppierer für Workload-Typen ohne natives Plugin, und native Plugins behalten Vorrang. Diese Einzelheit ist wichtig, denn sie zeigt, dass Workload Map Lücken füllt und bestehende Integrationen nicht überschreibt.
Das Projekt liefert einen Katalog vorgefertigter, getesteter Definitionen für JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet und NVIDIA Dynamo mit. Weitere Typen lassen sich durch eine YAML-Definition hinzufügen. NVIDIA gibt an, die Software stehe unter der Apache-2.0-Lizenz und werde in NVIDIA Run:ai produktiv genutzt, und Nova von Elotl verwende sie, um Struktur und Ressourcenbedarf zu deuten, wenn es einen Cluster für verteilte Workloads auswählt. Das Repository beschreibt sich selbst als Übersetzungsschicht, die benutzerdefinierte Ressourcen beliebiger Kubernetes-Frameworks auf eine standardisierte, generische Struktur abbildet.
Nicht gezeigt wird ein gemessener Nutzen. Der Beitrag nennt keine Zahlen zu eingesparter Zeit, Scheduler-Aufwand, Fehlerraten oder zur Genauigkeit der Statusausdrücke, und die Aussagen zur Verbreitung stammen von NVIDIA und einem Partner. Eine Definition ist zudem Code in der Verkleidung von Daten: Ein falscher Statusausdruck oder ein falscher Pfad zur Pod-Vorlage kann dazu führen, dass eine Plattform den Status falsch meldet oder einen Job falsch platziert. Definitionen brauchen daher Review und Tests wie jedes Manifest. Für ein Team ist ein vernünftiger Versuch, ein bereits genutztes Framework auszuwählen, die Katalogdefinition anzuwenden, den Baum und die GPU-Summe des Kommandozeilenwerkzeugs mit der Ausgabe von kubectl zu vergleichen und sie erst danach bei einem Scheduler oder einer Plattform zu registrieren. Auch die Version der installierten CRD und der Bibliothek sollte geprüft werden, da das Projekt Komponenten umbenennt.
Sources
FAQ
Welches Problem löst Workload Map?
Ein echter Kubernetes-Job ist oft ein Baum aus Ressourcen, und jedes Framework legt Rollen, Replikas, Pod-Vorlagen und Status in einer anderen benutzerdefinierten Ressource ab, sodass jedes Werkzeug einen eigenen Adapter braucht. Workload Map beschreibt diese Struktur in Definitionen, die man schreiben und prüfen kann, damit Scheduler und Plattformen dieselbe Deutung teilen.
Wie teilen sich KAI Scheduler und Workload Map die Arbeit?
Die Definition liefert nur Gruppierungsinformationen, während KAI Scheduler die gemeinsame Zulassung durchsetzt und die Platzierung entscheidet. Für Workload-Typen ohne natives Plugin nutzt KAI Scheduler Workload Map als Rückfall, und native Plugins behalten Vorrang, es füllt also Lücken und überschreibt keine bestehenden Integrationen.
Wie kann ein Team die Definitionen sicher ausprobieren?
Ein bereits genutztes Framework wählen, die Katalogdefinition anwenden und den Baum sowie die GPU-Summe des Kommandozeilenwerkzeugs mit der Ausgabe von kubectl vergleichen. Statusausdrücke und Pfade wie jedes Manifest prüfen, bevor man sie registriert, und die Versionen von CRD und Bibliothek kontrollieren, da das Projekt Komponenten umbenennt.