在 Kubernetes 上启用 NVIDIA GB200 NVL72 及以上型号的多节点 NVLink

NVIDIA GB200 NVL72 将 AI 基础设施提升至全新高度，在大语言模型训练以及可扩展、低延迟推理工作负载的运行方面实现显著突破。无论是在本地环境还是云端，Kubernetes 在高效部署和扩展这些工作负载中正发挥着日益关键的作用。然而，快速演进的 AI 工作负载、不断变化的基础设施需求以及新兴硬件架构，也为 Kubernetes 的编排能力与资源管理带来了新的挑战。

在本文中，我们将介绍一种名为 ComputeDomains 的新型 Kubernetes 抽象，旨在简化多节点 NVLink 架构下跨节点边界执行 安全 的 GPU 间内存操作的复杂性，确保多节点工作负载中的每个工作进程都能高效运行。

作为适用于 GPU 的 NVIDIA DRA 驱动的一部分， ComputeDomains 实现了低级 GPU 架构（如 NVIDIA NVLink 和 NVIDIA IMEX）与现代 Kubernetes™ 原生调度机制（即 动态资源分配，DRA）之间的桥梁，为在先进 GPU 硬件上运行分布式多节点工作负载提供了必要的基础支持。若缺少 ComputeDomains ，用户将不得不手动配置并固定多节点 NVLink 设置，这不仅削弱了 Kubernetes 所追求的灵活性，还会在安全隔离、故障隔离以及成本效益方面带来不利影响。

尽管该工作已在NVIDIA DGX GB200（基于NVIDIA GB200 NVL72系统的蓝图）上完成验证，但 ComputeDomains 的设计目标是能够适用于当前或未来任何支持多节点NVLink的架构，包括未来的 NVL576 系统。

在本文中，我们将重点介绍基础知识： ComputeDomains 是什么，它们为何重要，以及如何利用它们在 Kubernetes 上运行您自己的分布式多节点工作负载。

从单节点到多节点 GPU 计算

为了理解 ComputeDomains 的重要性，我们可以简要回顾 GPU 系统设计随时间的发展历程。

前几代 NVIDIA DGX 系统 通过在单个服务器内集成尽可能多的 GPU，并利用高带宽 NVLink 实现互联，从而提升性能。这种架构在单节点内实现了出色的扩展能力，但适用的工作负载受限于单台系统的容量。随着 NVIDIA 多节点 NVLink（MNNVL） 的推出，这一限制得以突破。现在，不同服务器中的 GPU 可通过 NVIDIA NVLink 交换机 以完整的 NVLink 带宽进行通信，将整个机架整合为一个统一的 GPU 网络。这不仅实现了跨节点的无缝性能扩展，也为高速分布式训练与推理提供了坚实基础。

NVIDIA NCCL 和 NVIDIA NVSHMEM 等 GPU 通信库已扩展以充分利用该网络，而 PyTorch 等深度学习框架则基于这些库构建，实现跨节点、跨 GPU 的高效通信。这些库能够自动识别并选用可用的高速网络（例如 NVLink、RDMA、InfiniBand 或 以太网），从而确保分布式应用程序在不同网络拓扑下无需修改代码即可获得优异的性能表现。

借助 ComputeDomains ，我们提供了在 Kubernetes 上支持多节点 NVLink 的推荐方案。这些方案已作为公共基础层，支撑了 NVIDIA Kubernetes 堆栈中的多个高级组件，包括 KAI 调度程序、NVIDIA Dynamo，以及 NVIDIA DGX 云 Lepton。

下图展示了 DGX GB200 系统所采用的 NVIDIA GB200 NVL72 机架拓扑结构，这只是 ComputeDomains 在 Kubernetes 上支持的系统类型之一。

支持 Kubernetes 上的多节点 NVLink

那么，如何在 Kubernetes 上实现对多节点 NVLink 的支持？计算域在此过程中能发挥怎样的作用？关键在于 NVIDIA 的节点间内存交换服务 (IMEX)，这是一款运行在 GPU 驱动层面的软件，能够实现 GPU 跨节点通信。通过 IMEX，每个 GPU 的显存导出与导入操作均可实现细粒度的访问控制。IMEX 运行在一组被称为 IMEX 域的节点集合之上。

请参考下图，以更清晰地理解 NVLink 域、IMEX 域以及多节点 NVLink 环境中可能实现的其他 GPU 分区级别之间的关系。

ComputeDomains可视为 IMEX 域的泛化。虽然 IMEX 域存在于驱动层中，并定义了哪些节点可以通过 NVLink 进行通信，但 ComputeDomain 泛化了这一概念并将其扩展到 Kubernetes 中。它们代表了多节点工作负载的分布式工作者之间的更高级别的连接 (或可达性) 概念。下方使用 IMEX 来启用该连接这一事实是实现细节。

随着多节点工作负载被调度到各个节点并运行直至完成， ComputeDomains 会动态地创建、管理并拆解 IMEX 域。

ComputeDomains 无需预先配置静态的 IMEX 设置，而是能够实时响应调度事件，自动根据分布式作业所在的节点集合动态构建 IMEX 域。

IMEX 本质上提供可重新配置的隔离边界，而 ComputeDomains 能够以流畅且透明的方式管理这些边界。通过 ComputeDomains ，每个工作负载都拥有独立的隔离 IMEX 域以及共享的 IMEX 通道，既保障了任务中各工作单元之间高效的 GPU 到 GPU 通信，又实现了与其他作业的安全隔离。 ComputeDomain 可持续追踪工作负载状态，并根据其规模的扩展或缩减动态调整拓扑结构。当工作负载完成后，系统将自动清理对应的 IMEX 域和通道，释放资源以供后续任务使用。

在不影响利用率的情况下实现隔离

如上所述，IMEX 基元是隐藏在 ComputeDomain 抽象之下的实现细节。然而，我们认为，围绕工作负载动态构建 IMEX 域仍需一个可靠且经过实践验证的解决方案，主要原因有三：

1. 安全隔离: 在零信任环境中，即便通过物理 NVLink 相连，相邻的 GPU 作业之间也必须实现明确的安全隔离。
2. 故障隔离: 即使相邻作业相互可信，也应避免彼此产生影响，确保系统稳定性。
3. 成本效益: 在满足上述两项要求的前提下，仍需保持较高的资源利用率，这一点在多租户环境中尤为重要。

可以通过静态 NVLink 分区实现安全隔离，但这会显著限制资源利用率。

在可信环境中，安全隔离未必始终是首要关注点，但作业的可靠性却至关重要，因此故障隔离同样不容忽视。IMEX 域是一个有状态的分布式系统，天然容易受到各类故障场景和瞬态条件的影响，这些因素可能导致系统状态退化或不一致。尤其在大规模运行时，此类问题将更频繁地显现。在此类情况下，应将故障的影响范围严格限制在单个作业之内。

从概念上讲，提升故障隔离安全性的理想方式是在时间和空间上将单个 IMEX 域与特定工作负载绑定，这正是 ComputeDomain 实现所保障的。

若缺乏 ComputeDomains ，则必须静态配置生命周期较长的 IMEX 域，这将导致在 (1) 和 (2) 之间做出权衡。任何旨在动态编排 IMEX 域的自主解决方案，最终都会演变为与 ComputeDomains 类似的架构，且构建难度较高。通过提供通用解决方案，可使用户免于自行实现这一复杂过程，同时有助于集中积累和沉淀实践经验。

在 Kubernetes 中使用计算域

计算域由适用于 NVIDIA DRA 驱动的 GPU 提供支持。在近期，DRA 驱动将随 NVIDIA GPU Operator 一并提供，目前需通过 Helm Chart 手动安装。

您可在此处查阅详细的安装说明和先决条件 here。通常，Kubernetes 1.32 或更高版本需要启用 DRA APIs enabled 和 CDI。请确保在安装 DRA 驱动程序时启用 ComputeDomain 支持（此为默认配置），并在配置了跨多个节点 NVLink 分区的环境中运行，例如 GB200 NVL72 机架内或跨机架环境。

该驱动程序正处于积极开发阶段。建议您关注我们的 GitHub 项目；您可以在此阅读关于最新版本（v25.8.0）的更新信息，这里。

部署工作负载

我们来看一个创建和使用 ComputeDomain 的示例。以下 Kubernetes 规范定义了一个名为 compute-domain-0 的 ComputeDomain ：

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: compute-domain-0
spec:
  numNodes: 0	 # <-- this field is deprecated and should always be set to 0
  channel:
    resourceClaimTemplate:
      name: compute-domain-0-rct

目前尚未有任何工作负载引用此 ComputeDomain 因此，它仅是一个 API 对象。 ComputeDomain 遵循 工作负载的调度过程：当工作负载的 Pod 被实际调度到节点时， ComputeDomain 将围绕该 Pod 及时生成。

接下来，我们将定义工作负载，并通过在其中引用 compute-domain-0 来使用它。

假设我们要运行一个分布在18个节点上的任务，目标是在每个节点使用4块GPU，并实现全部72块GPU之间通过NVLink的全互联通信。

为此，在本例中，我们将为每个节点启动一个 Kubernetes Pod。每个 Pod 的资源请求如下：

• 四个 GPU。
• 与该工作负载的其他所有 Pod 一样，将其部署在同一个 NVLink 分区内，以确保物理可访问性，
• 并加入先前指定的 ComputeDomain ，以实现逻辑可达性。

以下 Kubernetes 部署示例实现了上述所有目标，并通过内联注释解释了关键概念。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-mnnvl-workload
spec:
  # Ask for this deployment to be comprised of 18 pods.
  replicas: 18
  selector:
    matchLabels:
      job: ex1
  template:
    metadata:
      labels:
        job: ex1
    spec:
      # Associate all pods in this deployment with the specific ComputeDomain
      # that was previously created. To that end, refer to the so-called
      # resource claim template associated with that domain. The name of that
      # template in this case is defined as `compute-domain-0-rct` in the
      # ComputeDomain API object. Here we also define a new name `cd-0` that
      # is consumed by the container spec below.    
      resourceClaims:
      - name: cd-0
        resourceClaimTemplateName: compute-domain-0-rct  
      # Define a `podAffinity` rule to ensure that all pods will land on nodes
      # in the same NVLink partition. Specifically, require all pods to land on
      # nodes that have the _same_ value set for the `nvidia.com/gpu.clique`
      # node label. This label is set by the NVIDIA GPU Operator (based on
      # static NVLink configuration state).
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: job
                operator: In
                values:
                - ex1
            topologyKey: nvidia.com/gpu.clique    
      containers:
      - name: ctr
        image: ubuntu:22.04
        command: ["mnnvl-workload"]
        resources:
          claims:
          - name: cd-0  # See `resourceClaims` above.
          limits:
            nvidia.com/gpu: 4  # Request four GPUs.

为便于理解，上述示例通过声明 resourceClaimTemplateName: compute-domain-0-rct 来连接到先前指定的 计算域。此时，资源声明 模板 的概念应更清晰：在此部署中，每个 Pod 在后台都会生成一个唯一的资源声明。

上述示例还展示了一种典型方法，即通过统一 nvidia.com/gpu.clique 节点标签的值，确保将一组 Pod 调度到属于同一 NVLink 分区的节点上。当计算范围超出单个 NVLink 分区时，需移除或调整此限制。

您可以在 DRA 驱动文档中找到完整的示例，其中包括一组可运行的验收测试，用于验证 计算域 是否已正确配置并正常运行。

已知限制和未来工作

NVIDIA DRA 驱动程序版本 25.8.0 针对 GPU 进行了显著的计算域优化。此外，我们还引入了多项增强功能，以提升调度的灵活性和使用便捷性。

以下是目前已知的两项限制，以及为缓解这些问题而计划开展的相关工作：

• 目前，每个节点仅能运行属于同一计算域的一个 Pod。用户需要了解节点中可用的 GPU 数量，并通常通过单个工作负载的 Pod 占用全部 GPU，再由该 Pod 内的应用程序在这些 GPU 之间划分计算任务。我们计划消除这一限制，弱化单个节点在架构中的重要性。未来，应用程序可由多个使用单个 GPU 的 Pod 构成，这些 Pod 既可部署在同一节点上，也可分布在不同节点。在此模式下，关注的焦点将从节点转向单个 GPU，节点边界将近乎透明。我们正在计划移除此约束，以使单个节点的概念变得不那么重要。届时，应用程序可以由许多单个 GPU 的 Pod 组成，这些 Pod 可能或可能不在同一节点上相邻放置。在此模式下，关注的焦点是单个 GPU，而不是单个节点——节点边界变得几乎透明。

• 目前，每个节点最多仅支持一个 ComputeDomain。这一限制源于为每个工作负载分配独立 IMEX 域的设计决策，以及每个节点上最多运行一个 IMEX 守护程序的事实。当某个 ComputeDomain 仅使用节点中一小部分 GPU 时，该节点剩余的 GPU 资源将无法被其他 ComputeDomain 利用。例如，在 GB200 机架中，若将六个 GPU 划分为一个计算域，则会不可避免地导致多个 GPU 闲置——理想情况下为两个，极端情况下可达十八个。解除这一限制虽有助于提升资源利用率，但可能降低工作负载之间的故障隔离能力。目前尚无通用的解决方案，因此我们计划允许用户根据实际需求，在成本效益与隔离强度之间进行权衡，并选择最适合的配置。此项工作已在规划中并持续跟进。

其他计划正在持续推进，例如进一步提升大规模系统的鲁棒性以及增强整体调试能力。欢迎关注 问题追踪器 并查看 里程碑视图，以获取路线图的最新进展。我们也鼓励您在问题追踪器中提交问题、错误报告或改进建议。

总结

随着 NVIDIA GB200 NVL72 等先进的多节点 GPU 架构不断推动高性能 AI 基础设施的发展，Kubernetes 需要具备理解并管理这些现代 GPU 系统拓扑的能力。 计算域通过将 NVLink 和 IMEX 域等底层结构与 Kubernetes™ 原生调度及 DRA 机制相集成，有效应对了这一挑战。

计算域随着工作负载在集群中迁移，能够动态地创建、管理和拆除 IMEX 域，无需人工配置即可实现安全且高带宽的 GPU 到 GPU 连接。适用于 GPU 的 NVIDIA DRA 驱动程序 v25.8.0 版本进一步增强了该架构的弹性与容错能力，支持计算域根据工作负载需求灵活扩展或收缩，自动从节点故障中恢复，并显著缩短分布式作业的启动时间。

对基础架构团队而言，这些改进意味着在 GB200 NVL72 或 DGX GB200 系统上开展多节点训练与推理时，能够实现极简配置。对开发者而言，原本在复杂的 NVLink® GPU 互联架构中运行分布式训练或推理的任务，如今如同部署标准的 Kubernetes 工作负载一般简便。这些创新构成了计算域的核心，为在 NVIDIA GB200 NVL72 及未来平台上实现可扩展、拓扑感知的 AI 编排奠定了坚实基础。

请参阅适用于 GPU 的 NVIDIA DRA 驱动程序及其最新发布的 v25.8.0 版本，以开始使用。同时，可参考以下其他资源：

• Kubernetes 设备管理工作组
• 7 月 WeAreDevelopers 大会计算领域演讲的幻灯片on ComputeDomains 在 7 月 WeAreDevelopers 大会
• 7 月 WeAreDevelopers 大会计算领域演讲的视频
• 计算域设计文档
• NVIDIA 针对 GPU 的 DRA 驱动程序公开文档
• 展示 NVIDIA GPU DRA 驱动程序未来发布计划的项目路线图