NVIDIA Workload Map unifies Kubernetes AI workload parsing
NVIDIA releases an open-source tool that provides a common structural description for distributed AI workloads on Kubernetes, eliminating the need for framework-specific adapters.
NVIDIA has released Workload Map, an open-source component designed to standardize how Kubernetes tools interpret distributed AI workloads. Published in November 2026 as part of the NVIDIA DSX AI Factory Platform, this project aims to eliminate the fragmentation caused by diverse custom resource definitions across different AI frameworks.
What happened
Operating AI infrastructure on Kubernetes often involves managing complex distributed tasks, such as multi-node training jobs or inference servers. These workloads are rarely single pods; they are trees of resources with specific roles, replica counts, and status indicators. However, each AI framework encodes this information differently. For example, JobSet, LeaderWorkerSet, and RayCluster all use distinct custom resource definitions (CRDs) to describe their structure.
This diversity creates a significant burden for teams building schedulers, controllers, dashboards, or cost management tools. Developers must write separate adapter code for every new framework they wish to support. This adapter development becomes a recurring roadmap item rather than a one-time engineering cost, often delaying support for new workload types until a specific software release is ready.
To address this, NVIDIA introduced Workload Map, which provides a common description of Kubernetes workload structure. The project ships with a catalog of prebuilt definitions for popular frameworks including JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet, and NVIDIA Dynamo. By moving workload knowledge out of compiled adapters and into declarative data, the tool allows platforms to interpret supported workload types without maintaining separate parsing logic for each one.
How it works
Workload Map functions as a Kubernetes CRD, formerly known as Karta, accompanied by a Go library that interprets these workload definitions. Each definition specifies exactly where to find pod templates, replica counts, and status fields for a given workload type. The Go library resolves a live object into a uniform structural view, allowing consumers to extract metadata, update pod specs, and understand the workload hierarchy consistently.
A key feature is the translation layer for status mappings. Since different frameworks report status differently, Workload Map definitions map native conditions to a shared vocabulary. For instance, JobSet does not report a simple "Running" condition. Instead, the definition uses a jq expression to derive this state by checking if any job is ready and active while none have failed. This ensures that a RayJob or a LeaderWorkerSet can map its unique status indicators to the same standard categories used by monitoring tools.
The system supports multiple consumption patterns. The Workload Map CLI can inspect workloads directly from a cluster without installing the CRD, rendering a tree view of roles and resource requests. For scheduling, the KAI Scheduler uses these definitions to enforce gang scheduling, ensuring that all pods in a group are scheduled together. Platforms like NVIDIA Run:ai use the same definitions to manage visibility, presenting a distributed job as a single unified entity rather than a collection of disparate pods.
Key details
- Workload Map provides prebuilt definitions for over ten major AI frameworks, including JobSet, RayCluster, and PyTorchJob.
- The project is available under the Apache 2.0 license and is part of the NVIDIA DSX AI Factory Platform.
- A Go library and CLI allow tools to resolve live objects into a uniform structural view without custom parsers.
- Status mappings use jq expressions to translate framework-specific conditions into standard states like Running, Completed, or Failed.
- Elotl’s Nova scheduler uses Workload Map to interpret workload structure for multi-cluster scheduling decisions.
- The CLI can inspect workloads using only a kubeconfig, requiring no installation of the Workload Map CRD in the cluster.
Why it matters
For software engineers building AI infrastructure, Workload Map reduces the maintenance overhead of supporting new frameworks. Instead of writing and testing new adapter code for every CRD, developers can rely on a standardized interface. This accelerates the integration of new AI tools into existing platforms and ensures that schedulers and monitors can interpret workload requirements accurately from day one.
The standardization also improves operational visibility. Without a shared description, operators must manually reconstruct workload structures to understand total resource usage, such as aggregating GPU requests across multiple pods. Workload Map automates this aggregation, providing clear insights into the hierarchy and resource consumption of distributed jobs. This clarity is essential for effective cost management and capacity planning in large-scale AI factories.
Furthermore, the decoupling of workload interpretation from specific platform code fosters a more modular ecosystem. Tools like KAI Scheduler and NVIDIA Run:ai can share the same definitions, reducing duplication of effort. As the catalog of supported frameworks grows, the barrier to entry for new AI workloads on Kubernetes decreases, enabling faster adoption of emerging technologies without compromising on manageability.
What you can do
- Explore the workload catalog in the NVIDIA DSX AI Factory GitHub repository to find definitions for frameworks you currently use.
- Install the Workload Map CLI using Homebrew to inspect your existing Kubernetes workloads and visualize their structure.
- Review the JobSet definition example to understand how status mappings and pod templates are declared in YAML.
- If you use KAI Scheduler, configure it to use Workload Map as a fallback for pod grouping on unsupported workload types.
- Join the NVIDIA DSX AI Factory Slack workspace to discuss integrations and share feedback on workload definitions.
- Consider writing a custom YAML definition if you operate a niche framework not yet included in the prebuilt catalog.



