NVIDIA will verteilte Kubernetes-Workloads einmal beschreiben und überall lesen

NVIDIA will Kubernetes-Workloads einmal beschreiben und überall lesen

NVIDIA stellt mit dem Workload Map eine gemeinsame Beschreibung für die Struktur verteilter Kubernetes-Workloads vor. Das Werkzeug gehört zur NVIDIA DSX AI Factory Platform. Der Konzern beschreibt sie als Bündel offener, modularer Softwarekomponenten für Aufbau und Betrieb von KI-Fabriken mit mehreren Mandanten.

Das Prinzip ist einfach: Nutzer beschreiben einen Workload einmal und verwenden diese Beschreibung über Frameworks hinweg. Integrierte Scheduler, Controller und Plattformen sollen unterstützte Workload-Typen wie JobSet damit interpretieren, ohne eigenen frameworkspezifischen Parsing-Code pflegen zu müssen. Der Anlass liegt in der Struktur solcher Lasten. Ein verteilter Trainingsjob oder ein Inferenzserver über mehrere Knoten besteht auf Kubernetes selten aus einem einzelnen Pod. Er ist ein kleiner Baum aus Ressourcen. Wer Scheduler, Dashboards oder Kostenwerkzeuge baut, musste diesen Baum bisher für jeden Typ getrennt auslesen.

Laut NVIDIA lassen sich Workloads so ohne separate Adapter pro Framework lesen und verwalten. Die Aussage stammt vom Hersteller. Im vorliegenden Material ist sie nicht unabhängig geprüft. Belastbar wäre sie erst nach Blick in Code, Repository und Dokumentation sowie nach Tests mit weiteren Workload-Typen neben JobSet.

Warum JobSet und LeaderWorkerSet bisher eigene Adapter verlangen

Das Problem, das NVIDIA beschreibt, liegt in der Vielfalt der Kodierungen. Jedes Kubernetes-Framework legt Komponenten, Pod-Templates, Replica-Zahlen und Status auf eigene Weise ab. Nach Darstellung von NVIDIA brauchen JobSet, LeaderWorkerSet und andere Custom Resources deshalb oft eigene Adapter, bevor ein Werkzeug sie lesen kann. Jeder neue Typ erhöht den Pflegeaufwand.

JobSet ist eine Kubernetes-native API, die eine Gruppe von Jobs als Einheit verwaltet. Sie soll eine einheitliche Schnittstelle für HPC-Lasten, etwa MPI, und für KI-Training mit PyTorch, JAX oder TensorFlow bieten. Über mehrere Templates lassen sich unterschiedliche Pod-Gruppen definieren, zum Beispiel Leader und Worker. Ein einzelner Job kann das nicht. Genau diese Struktur aus Rollen, Replikas und Templates soll der Workload Map vereinheitlicht abbilden.

Ein JobSet-Beispiel für Inspektion, Gang Scheduling und Sichtbarkeit

NVIDIAs Beitrag zeigt das Vorgehen an einem verteilten JobSet-Workload. Die Definition wird einmal beschrieben und danach dreifach genutzt: zur Inspektion des Workloads, für Gang Scheduling und für die Sichtbarkeit auf der Plattform.

Vom Blogpost liegt bislang nur der Anfang vor. Offen bleiben deshalb zentrale Angaben. Schema und API des Workload Map sind unbekannt, ebenso Repository, Version, Lizenz und Reifegrad. Auch der Umfang der unterstützten Workload-Typen geht aus dem Material nicht hervor. Ob bestehende Setups migriert werden müssen oder der Workload Map parallel dazu laufen kann, lässt sich so nicht beurteilen.