NVIDIA’s Workload Map (the CRD kind is still Karta) is a Kubernetes custom resource and Go library that turns distributed workload structure into declarative data. According to NVIDIA’s Developer Blog, the goal is simple: schedulers, controllers, dashboards, and cost tools should be able to interpret AI jobs without shipping a separate adapter for each framework.
The adapter tax on Kubernetes AI workloads
On Kubernetes, a distributed training job or multi-node inference server is rarely one pod. It’s a small tree of resources: groups of pods with roles, replica counts, pod templates, and status phases. The trouble is that JobSet, LeaderWorkerSet, RayJob, and other CRDs encode that tree differently. NVIDIA’s Run:ai team, for example, had to answer the same structural questions in code for every new custom resource—where the pod spec lives, how status maps to a phase, how to update pods without breaking the workload. Each answer became another per-CRD adapter, and every new customer framework became a roadmap item.
One YAML definition to rule the distributed tree
Workload Map moves that knowledge out of compiled adapters and into YAML definitions that developers can write, review, and apply like any manifest. Each definition points to where a workload stores its pod templates, replica counts, instance IDs, and status. A jq-based statusMappings layer translates framework-specific conditions—for example, deriving a plain “Running” phase for JobSet from its replicatedJobsStatus—into a shared vocabulary. The Go library then resolves a live object into a uniform structural view, extracting pod templates, replica counts, status, and metadata, and updating pod specs, labels, and annotations across every instance.
The project ships prebuilt definitions for:
- JobSet
- PyTorchJob
- RayCluster, RayJob, and RayService
- KServe and Knative
- MPIJob
- NVIDIA NIM
- LeaderWorkerSet
- Milvus
- Grove PodCliqueSet
- NVIDIA Dynamo
The post walks through a JobSet example with one leader Job and two worker Jobs, each pod requesting four GPUs—a total of 12 GPUs that kubectl would otherwise list as disconnected resources. With a Workload Map definition, the same object resolves into leader and worker roles with aggregated GPU requests.
From inspection to scheduling and management
The same JobSet definition powers three different workflows. The Workload Map CLI reads a live workload from a kubeconfig and prints its tree without needing Workload Map installed in the cluster. KAI Scheduler uses the definitions for pod grouping and gang scheduling. NVIDIA Run:ai uses them for unified workload management and visibility. Elotl’s Nova interprets workload structure and resource requirements for multi-cluster scheduling decisions. Because all these consumers act on the same description, the need to maintain separate framework-specific parsers shrinks.
NVIDIA positions Workload Map as part of the DSX AI Factory Platform, its umbrella for modular, multi-tenant AI factory software. For platform teams, the immediate payoff is faster support for new AI frameworks: write a YAML definition instead of waiting for a vendor release, then reuse it across inspection, scheduling, and management.