NVIDIA Workload Map：将 AI 工作负载结构知识从适配器代码迁移为声明式定义
NVIDIA 技术博客文章解释了 Workload Map 如何将 Kubernetes 上 AI 工作负载的结构知识从编译型适配器代码迁移为可审查的 YAML 数据定义，使调度器、控制器和平台通过同一份描述完成工作负载检查、gang 调度与统一管理。
在 Kubernetes 上运行分布式 AI 训练或推理任务时，一个真实的工作负载很少是单个 Pod。它是一棵小型资源树：若干 Pod 组，每组有角色、副本数、Pod 模板和依赖工作负载类型的状态。JobSet、LeaderWorkerSet、PyTorchJob、RayCluster 等框架各自用不同方式编码这些信息。构建调度器、控制器、仪表盘或成本工具的团队因此面临一个组合爆炸问题：每接入一个新框架的 CRD，就需要编写一套适配器来回答同样的三个问题——工作负载的结构是什么？状态如何解读为运行阶段？如何在不破坏工作负载的前提下修改 Pod 规格？
NVIDIA Run:ai 团队在构建平台时遇到了这个瓶颈。Alon Lavian（NVIDIA Run:ai 产品经理，负责 Workload Map 的定位与推广）、Yuval Grauer（NVIDIA 工程负责人兼 Workload Map 维护者）和 Ron Lev（NVIDIA 高级软件工程师兼 Workload Map 技术负责人）在 2026 年 11 月的 NVIDIA 技术博客中描述了现状：每新增一个客户带来的框架，就需要另一个适配器；适配器开发因此成为按框架排期的路线图项目，而非一次性成本。这就是为什么新工作负载类型的支持常常要等待一个版本发布。
Workload Map（原名 Karta，CRD 的 kind 仍保留 Karta）提出的方案是将工作负载结构知识从编译型代码迁移为声明式数据。它由一个 Kubernetes CRD 和一个 Go 解释库组成。每份定义用 YAML 描述该工作负载类型的 Pod 模板路径、副本数计算方式和状态字段位置。文章以 JobSet 为例展示了关键部分：根组件通过 jq 表达式将 JobSet 特有的 replicatedJobsStatus 字段翻译为统一的 Running、Completed、Failed 阶段；子组件定义用路径表达式定位每个 replicated Job 的 Pod 模板，并用 replicas 乘以 parallelism 计算实际 Pod 数。
这套定义提供的不只是状态翻译。statusMappings 将各框架截然不同的原生状态映射到统一的 Running、Completed、Failed 词汇——JobSet 不直接报告 Running 条件，定义便用 jq 表达式检查是否有任何 Job 处于 ready 且 active 且无 failed；当 RayJob 或 LeaderWorkerSet 被描述时，它们各自不同的状态字段被映射到相同的共享类别。同时，定义中的路径表达式让消费者提取 Pod 模板、副本数、元数据并理解工作负载层级，还能跨所有实例更新 Pod 规格、标签和注释。消费者工具因此不需要为每种框架编写专用解析逻辑，而是通过同一份结构描述完成检查、调度和管理。
文章展示了同一份 JobSet 定义被三个消费者使用的场景。Workload Map CLI 加载定义后解析集群中的实时对象，输出包含 leader 和 worker 角色、12 个 GPU 总请求的工作负载树。KAI Scheduler 用定义中的 gangScheduling 指令进行 Pod 分组和 gang 准入；对于没有原生插件的工作负载类型，Workload Map 作为 pod grouper 的回退方案提供结构信息，已有原生插件仍保持优先。NVIDIA Run:ai 通过一次 API 调用注册目录定义，将 JobSet 作为单一工作负载管理。此外，多集群调度工具 Elotl Nova 也使用 Workload Map 在集群选择时解读工作负载结构和资源需求。
项目附带一份预构建目录，覆盖 JobSet、PyTorchJob、RayCluster、RayJob、RayService、KServe、Knative、MPIJob、NVIDIA NIM、LeaderWorkerSet、Milvus、Grove PodCliqueSet 和 NVIDIA Dynamo。新工作负载类型通过编写 YAML 定义添加，无需修改消费者代码。Workload Map 以 Apache 2.0 许可开源，已在 NVIDIA Run:ai 生产环境中使用。
需要指出的是，这个方案将成本从编写适配器代码转移到了编写和审查定义数据。jq 表达式对框架 API 版本敏感——如果 JobSet 的 replicatedJobsStatus 结构在后续版本中改变，定义需要同步更新。文章没有报告跨框架的适配器开发时间节省数据，也没有独立第三方对目录定义准确性的验证。对于已经为特定框架编写了原生插件的调度器，Workload Map 仅作为回退方案，不替代已有逻辑。