NVIDIA Workload Map

How NVIDIA Workload Map Works

Kubernetes workload types share common building blocks but organize them differently. Workload Map uses declarative definitions and JQ expressions to map those fields into a consistent structure that tools can interpret across frameworks.

• Workload Structure: Describe root resources, child components, and pod templates so tools can understand how a workload’s roles and resources fit together.

• Scaling Information: Map replica counts and scaling fields so tools can read each component’s intended scale through the same API, regardless of workload type.

• Workload Status: Map workload-specific conditions to common states such as running, completed, and failed so tools can interpret progress consistently across workload types.

• Gang Scheduling: Tell schedulers which pods belong together, so a job is admitted as one unit instead of landing halfway and waiting. This works for frameworks the scheduler has never seen, once they have a definition.

Example: A DynamoGraphDeployment

A DynamoGraphDeployment describes a multi-service inference graph as one workload. This example has a frontend, a prefill worker service, and a decode worker service, each with its own pod spec and autoscaling range. The green header represents the complete deployment, the light gray section groups its services, and the dark gray blocks represent individual services. Workload Map exposes this structure through the matching definition: per-service pod specs; replicas with min and max; a status of initializing, running, or failed; and a gang-scheduling group per service.