NVIDIA Workload Map: Kubernetes-Tools verstehen KI-Workloads ohne eigene Adapter

Das Adapter-Problem unter Kubernetes

Ein reale KI-Workload besteht unter Kubernetes selten aus einem einzelnen Pod. Laut NVIDIA ist ein verteilter Trainingsjob oder ein Multi-Node-Inferenzserver ein kleiner Baum aus Ressourcen: Gruppen von Pods, jeweils mit einer Rolle, einer Replikazahl, einem Pod-Template und einem Status, der vom Workload-Typ abhängt.

Teams, die Scheduler, Controller, Dashboards oder Kostentools entwickeln, müssen für jede Custom Resource Definition (CRD) dieselben Fragen beantworten. Wie ist der Workload-Typ aufgebaut? Wie wird sein Status als Phase gedeutet? Wie lässt sich die Pod-Spezifikation ändern, ohne die Workload zu beschädigen? Die Antworten landen in einem Adapter pro CRD.

NVIDIA zufolge wird die Entwicklung solcher Adapter dadurch für jedes Framework zu einem eigenen Roadmap-Punkt. Deshalb muss die Unterstützung für einen neuen Workload-Typ so oft auf ein Release warten. Vor derselben Herausforderung stand nach Angaben des Unternehmens auch das Team von NVIDIA Run:ai beim Bau seiner Plattform.

Der Beitrag verdeutlicht das Problem an einem JobSet mit einem Leader-Job und zwei Worker-Jobs, in dem jeder Pod vier GPUs anfordert, insgesamt also 12 GPUs. Da kubectl das JobSet, seine Jobs und die Pods als getrennte Ressourcen auflistet, braucht eine Plattform eine Definition, um deren Rollen zu deuten und die Anforderungen zu aggregieren. Solange die JobSet-Definition nicht registriert ist, zeigt NVIDIA Run:ai die einzelnen Jobs als drei separate Workloads mit jeweils vier angeforderten GPUs an.

So funktioniert Workload Map

Workload Map, früher unter dem Namen Karta bekannt, besteht aus einer Kubernetes-CRD und einer Go-Bibliothek, die Workload-Definitionen auswertet. Der Ressourcentyp (Kind) der CRD heißt weiterhin Karta. Jede Definition legt fest, wo für den jeweiligen Workload-Typ Pod-Templates, Replikazahlen und Statusfelder zu finden sind.

Mit einer Definition kann ein Konsument:

• Pod-Templates, Replikazahlen, Status und Metadaten auslesen.
• Pod-Spezifikationen, Labels und Annotationen über alle Instanzen hinweg aktualisieren.
• die Hierarchie der Workload verstehen, etwa die replizierten Jobs eines JobSets und deren Pods.

Der KAI Scheduler nutzt die Definitionen, um Pod-Gruppierungen und Gang-Scheduling-Vorgaben zu interpretieren, während NVIDIA Run:ai sie für Workload-Verwaltung und Transparenz einsetzt. Laut NVIDIA arbeitet jeder Konsument mit derselben Beschreibung, was den Bedarf an separaten, frameworkspezifischen Parsern verringert.

Wie es in dem Beitrag heißt, wandert das Wissen über Workloads damit aus kompilierten Adaptern in Daten, die Entwickler schreiben, prüfen und wie jedes andere Manifest auf einen Cluster anwenden können.

Die JobSet-Definition und der fertige Katalog

NVIDIA erläutert eine JobSet-Definition im Detail. Die Wurzelkomponente deklariert den Typ (Kind) der Workload und legt fest, wie ihr Status gelesen wird. Ein Abschnitt statusMappings dient als Übersetzungsschicht: JobSet meldet keine schlichte Condition „Running“, daher leitet die Definition sie über einen jq-Ausdruck auf replicatedJobsStatus ab und bildet die nativen Conditions Completed und Failed auf ein gemeinsames Vokabular ab. Ein RayJob oder ein LeaderWorkerSet, deren Status ganz anders aussieht, wird denselben Kategorien zugeordnet.

Untergeordnete Komponenten beschreiben die Struktur innerhalb der Workload. Beim JobSet verweist podTemplateSpecPath auf das Pod-Template jedes Jobs, und scaleDefinition berechnet die Zahl der Pods pro repliziertem Job als Replicas mal Parallelism. Ein instanceIdPath übernimmt den Namen jeder Instanz aus dem Namen des replizierten Jobs, wodurch die Rollen Leader und Worker sichtbar werden.

Workload Map enthält einen Katalog fertiger, getesteter Definitionen für JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet und NVIDIA Dynamo. Weitere Workload-Typen lassen sich ergänzen, indem man eine YAML-Definition schreibt, die ihre Struktur und ihren Status beschreibt.

Was das für Plattformteams bedeutet

Nach Angaben von NVIDIA unterstützt eine einzige JobSet-Definition die Inspektion von Workloads über die Workload-Map-CLI, Gang Scheduling über den KAI Scheduler und die einheitliche Verwaltung in NVIDIA Run:ai. Auch Nova von Elotl nutzt Workload Map, um Struktur und Ressourcenbedarf von Workloads für Scheduling-Entscheidungen über mehrere Cluster hinweg zu ermitteln.

Für Teams, die mehrere Frameworks betreiben, bedeutet der Ansatz: Die Unterstützung eines neuen Workload-Typs kann darin bestehen, eine Definition zu schreiben, statt neuen Adapter-Code auszuliefern. NVIDIA empfiehlt, zunächst im Workload-Katalog nach einem bereits genutzten Framework zu stöbern, und lädt dazu ein, dem Slack-Workspace NVIDIA DSX AI Factory beizutreten, um Definitionen und Integrationen zu diskutieren.