NVIDIA Describes Open Source Workload Map, a Shared Description of Kubernetes Workloads for Inspection, Gang Scheduling and Platform Views
On November 2, 2026, NVIDIA's developer blog introduced the open source NVIDIA Workload Map, which describes the structure and status of Kubernetes workloads such as JobSet, RayCluster and KServe in definitions that can be written and reviewed. In the example, a JobSet is three Jobs in kubectl and three separate workloads in Run:ai until the catalog definition is registered, after which it appears as one workload using 12 GPUs. The post gives no measured time savings or error rates, and the definitions themselves need review and tests like any manifest.
On November 2, 2026, NVIDIA's developer blog described NVIDIA Workload Map, an open source description layer for Kubernetes workloads. The problem it targets is familiar to anyone who builds schedulers, controllers, dashboards or cost tools for AI clusters. A real job is rarely one pod. A distributed training run or a multi-node inference server is a small tree of resources, and each framework, such as JobSet or LeaderWorkerSet, stores roles, replica counts, pod templates and status in a different custom resource. Tools therefore need a separate adapter for each one.
Workload Map replaces much of that per-framework code with data. It ships as a Kubernetes custom resource definition plus a Go library, and each definition says where to find the pod templates, replica counts and status fields for one workload type. The post notes that the resource kind is still called Karta, the project's former name. With a definition in hand, a consumer can extract pod templates, replica counts, status and metadata, update pod specs, labels and annotations across every instance, and understand the hierarchy, for example a JobSet's replicated Jobs and their pods. A status mapping translates native conditions into one shared vocabulary. For JobSet, which has no plain Running condition, the definition derives it with an expression over the replicated Jobs status, while the native Completed and Failed conditions map directly.
The worked example is a JobSet with one leader Job and two worker Jobs, each pod asking for four GPUs. Listed with kubectl, that is a JobSet, three Jobs and three pods, with no total. In NVIDIA Run:ai before the definition is registered, the three Jobs appear as three separate workloads of four GPUs each. After registering the same catalog definition with one API call, Run:ai shows one workload using 12 GPUs, with a structure view of the leader and workers. The Workload Map command-line tool resolves the live object into the same tree, reads a kubeconfig, includes built-in definitions, and, according to the post, does not require installing Workload Map into the cluster. Its output shows the leader and worker roles and the 12-GPU total.
Scheduling is the second use. A definition can carry optional gang-scheduling instructions. The post is careful about who does what: the definition supplies grouping information, while KAI Scheduler enforces gang admission and makes placement decisions. KAI Scheduler uses Workload Map as a fallback in its pod grouper for workload types without a native plugin, and native plugins keep precedence. That detail matters because it means Workload Map fills gaps and does not override existing integrations.
The project ships a catalog of prebuilt, tested definitions for JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet and NVIDIA Dynamo. Other workload types can be added by writing a YAML definition. NVIDIA says the software is under the Apache 2.0 license and is used in production within NVIDIA Run:ai, and that Elotl's Nova uses it to interpret structure and resource requirements when choosing a cluster for distributed workloads. The repository describes itself as a translation layer that maps any Kubernetes framework's custom resources into a standardized, generic structure.
What the post does not show is measured benefit. It gives no figures for time saved, scheduler overhead, error rates or the accuracy of the status expressions, and the adoption statements come from NVIDIA and a partner. A definition is also code in disguise: a wrong status expression or a wrong path to a pod template can make a platform misreport or mis-schedule a job, so definitions need review and tests like any manifest. For a team, a sensible trial is to take one framework already in use, apply its catalog definition, compare the CLI's tree and GPU total with what kubectl shows, and only then register it with a scheduler or platform. Check the version of the CRD and the library you install, since the project is renaming components.
Sources
FAQ
What problem does Workload Map address?
A real Kubernetes job is often a tree of resources, and each framework keeps roles, replicas, pod templates and status in a different custom resource, so every tool needs its own adapter. Workload Map describes that structure in definitions that can be written and reviewed, so schedulers and platforms share one interpretation.
How do KAI Scheduler and Workload Map divide the work?
The definition only supplies grouping information, while KAI Scheduler enforces gang admission and makes the placement decisions. For workload types without a native plugin, KAI Scheduler uses Workload Map as a fallback, and native plugins keep precedence, so it fills gaps and does not override existing integrations.
How can a team try the definitions safely?
Pick a framework you already run, apply its catalog definition, and compare the command-line tool's tree and GPU total with what kubectl shows. Review the status expressions and paths like any manifest before registering them with a scheduler or platform, and check the CRD and library versions because the project is renaming components.