The Pulse
NVIDIA details Workload Map for Kubernetes AI workloads
NVIDIA’s Nov. 2 technical post explains how its open-source Workload Map lets Kubernetes tools interpret different AI workload types through reusable definitions. The project ships 16 workload definitions and examples spanning inspection, s
AI.info Team · Written with AI · fact-checked ·
NVIDIA’s Nov. 2 technical post lays out how Workload Map can help Kubernetes tools interpret AI jobs built with different frameworks, using a shared description rather than a separately coded adapter for each one. The open-source component was included in NVIDIA’s broader Run:ai open-source release on Oct. 13; the new post explains its design and shows how one definition can serve multiple tools.
“NVIDIA Workload Map provides a common description of Kubernetes workload structure that users can reuse across frameworks,” write Alon Lavian, Yuval Grauer and Ron Lev, the post’s authors. The system targets a practical problem for teams running distributed training and inference: a workload often spans several pods and resources, but each Kubernetes framework describes those parts, their roles and their status differently.
One definition instead of another adapter
NVIDIA says developers building schedulers, controllers, dashboards or cost tools often write a custom-resource-definition adapter for each framework they want to support. Each adapter must locate pod templates, determine replica counts, interpret status and make changes without breaking the workload. The work repeats when a customer introduces another framework.
Workload Map moves those instructions into declarative YAML definitions. It ships as a Kubernetes custom resource definition and a Go library that resolves workload objects into a shared structural view. The project was formerly called Karta, and its custom resource kind remains Karta, according to NVIDIA.
The project’s README lists 16 prebuilt definitions that ship with it, covering JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet and NVIDIA Dynamo. Developers can add other workload types by writing a YAML definition that describes their structure and status.
A JobSet becomes one 12-GPU workload
NVIDIA’s example uses a distributed JobSet with one leader job and two worker jobs. Each requests four GPUs, making the example’s total request 12. Without a definition that describes how the JobSet organizes those jobs, platform tools may show the components separately rather than summarize them as one workload.
The JobSet definition maps the framework’s fields into a common representation: it identifies the leader and worker roles, points to pod templates and replica counts, and translates native status conditions into shared workload states. NVIDIA’s command-line tool then displays the components, their readiness and the combined GPU request. The numbers describe the example manifest, not a benchmark or a claim about typical workloads.
Inspection, scheduling and Run:ai use the same map
NVIDIA demonstrates three consumers of the definition. The Workload Map CLI can inspect a workload; NVIDIA’s KAI Scheduler can use definitions for grouping and gang-scheduling instructions; and NVIDIA Run:ai can register the workload type and manage the JobSet as one workload. NVIDIA says the same definitions support its Run:ai platform in production.
The scheduler remains responsible for scheduling decisions: Workload Map supplies the description and grouping information, while KAI Scheduler enforces gang admission and decides placement. NVIDIA says KAI uses Workload Map as a fallback for workload types without a native plugin; native plugins take precedence. The post also names Elotl’s Nova as a user of Workload Map to interpret workload structure and resource requirements when selecting a cluster.
The open-source release came in October
NVIDIA lists Workload Map under the Apache 2.0 license and makes its code available through the NVIDIA DSX AI Factory GitHub organization. The Oct. 13 announcement placed it among four independently adoptable components in the open-source Run:ai release, alongside KAI Scheduler, GPU Fractioning Operator and KAI Resource Management.
The Nov. 2 post is therefore a technical walkthrough, not the date NVIDIA first made the component open source. Its concrete proposition is narrower than a new scheduler or universal workload format: describe a supported Kubernetes workload type once, then let compatible tools reuse that definition instead of maintaining their own framework-specific structural parser.