NVIDIA介绍开源的Workload Map：用共享定义描述Kubernetes工作负载，支持检查、成组调度和平台视图

2026年11月2日，NVIDIA开发者博客介绍了NVIDIA Workload Map，一个面向Kubernetes工作负载的开源描述层。它要解决的问题，凡是为人工智能集群开发调度器、控制器、仪表盘或成本工具的人都很熟悉：真实的作业很少只是一个Pod。一次分布式训练或一个多节点推理服务，是一小棵资源树，而且JobSet、LeaderWorkerSet等每个框架都用不同的自定义资源保存角色、副本数、Pod模板和状态。因此工具必须为每一种框架各写一个适配器。

Workload Map用数据取代了大量按框架编写的代码。它以Kubernetes自定义资源定义加一个Go库的形式发布，每份定义说明某一种工作负载的Pod模板、副本数和状态字段在哪里。文章提到，资源的kind仍然叫Karta，那是项目原来的名字。有了定义，使用方可以提取Pod模板、副本数、状态和元数据，在所有实例上更新Pod规格、标签和注解，并理解层级关系，比如JobSet下的多个复制Job及其Pod。状态映射负责把原生状态条件翻译成一套共同词汇：JobSet没有直接的“运行中”条件，定义就用一条针对复制Job状态的表达式推导出来，而原生的完成和失败条件则直接对应。

文中的示例是一个JobSet，包含一个领导者Job和两个工作者Job，每个Pod申请四块GPU。用kubectl列出来，只是一个JobSet、三个Job和三个Pod，没有总量。在注册定义之前，NVIDIA Run:ai把这三个Job显示为三个独立的工作负载，各占四块GPU。用一次API调用注册同一份目录里的定义之后，Run:ai把它显示为一个占用12块GPU的工作负载，并给出领导者与工作者的结构视图。Workload Map命令行工具会把运行中的对象解析成同样的树，需要读取kubeconfig，内置了定义，据文章所说并不需要把Workload Map安装进集群，输出里能看到领导者和工作者角色以及12块GPU的总数。

第二个用途是调度。定义可以带上可选的成组调度（gang scheduling）说明。文章对分工说得很清楚：定义只提供分组信息，成组准入和放置决策由KAI Scheduler完成。对于没有原生插件的工作负载类型，KAI Scheduler的Pod分组器把Workload Map当作后备方案，原生插件仍然优先。这个细节很重要，因为它说明Workload Map是在补空缺，而不是覆盖已有的集成。

项目附带一个目录，收录经过测试的现成定义，覆盖JobSet、PyTorchJob、RayCluster、RayJob、RayService、KServe、Knative、MPIJob、NVIDIA NIM、LeaderWorkerSet、Milvus、Grove PodCliqueSet和NVIDIA Dynamo。其他类型可以通过编写YAML定义添加。NVIDIA称该软件采用Apache 2.0许可，已在NVIDIA Run:ai内部用于生产，Elotl的Nova也用它理解分布式工作负载的结构和资源需求，以便选择集群。仓库自述它是一个转换层，把任何Kubernetes框架的自定义资源映射成标准化的通用结构。

换句话说，这篇文章的核心主张是“把工作负载的知识从编译进程序的适配器移到可以编写、评审并像其他清单一样应用到集群的数据里”。这个主张是否成立，取决于定义的覆盖面和维护质量，而不是取决于文章里的演示。读者可以先查看目录里是否已经有自己在用的框架，再看定义里的状态映射是否符合自己对“运行中”“已完成”“失败”的理解，最后再决定要不要把它接到生产调度链路里。

文章没有展示的是可度量的收益。它没有给出节省的时间、调度开销、错误率或状态表达式的准确度，采用情况的说法来自NVIDIA和一家合作伙伴。另外，定义本质上是披着数据外衣的代码：状态表达式写错，或者指向Pod模板的路径写错，都可能让平台误报状态或错误调度作业，所以定义需要像其他清单一样经过审查和测试。对团队来说，比较稳妥的试用方式是：选一个已经在用的框架，应用目录里的定义，把命令行工具给出的树和GPU总数与kubectl的结果对比，确认无误后再注册到调度器或平台上。还要留意所安装的自定义资源定义和库的版本，因为项目正在重命名其中的组件。

对平台团队而言，这类描述层的真正价值在于把“支持一个新框架”的成本从发版周期里移出来。以前遇到新的自定义资源，往往要等调度器或平台的下一个版本才能识别它；如果定义可以像清单一样被编写、评审并应用，团队就能自行补上支持。代价是需要维护这些定义，并在上游框架改变状态字段时及时更新，否则映射会悄悄失效。