在机架级超级计算机上运行 AI 工作负载：从硬件到拓扑感知调度

采用 NVIDIA Blackwell 架构的 NVIDIA GB200 NVL72 和 NVIDIA GB300 NVL72 系统是机架级超级计算机。它们由 18 个紧密耦合的计算托盘、大规模 GPU 互连结构以及作为一个整体封装的高带宽网络组成。

对于 AI 架构师和 HPC 平台运营人员而言，挑战并不只是将硬件上架和堆叠，而是把基础设施转化为对最终用户安全、高性能且易于使用的资源。机架级硬件拓扑与调度器抽象之间的不匹配，正是大部分运维复杂性的来源。如果不加以解决，调度器就会把 GPU 和节点作为一个扁平的资源池来操作，而忽视系统的层级化和拓扑敏感型设计。

这正是经过验证的软件栈（如 NVIDIA Mission Control）旨在弥合的差距。Mission Control 为 NVIDIA Grace Blackwell NVL72 系统提供机架级控制平面。凭借对 NVIDIA NVLink 和 NVIDIA IMEX 域的原生理解，它可与 Slurm 和 NVIDIA Run:ai 等工作负载管理平台集成。这些能力也将支持 NVIDIA Vera Rubin 平台，包括 NVIDIA Rubin NVL8。

本文演示了 Mission Control、Slurm 和 NVIDIA Run:ai 如何将 NVLink 和 IMEX 域等先进 GPU 架构概念转化为可扩展、可调度且易于管理的运营型 AI 工厂。

核心挑战：机架级拓扑遇上 AI 工作负载调度

在物理层面，GB300 NVL72 和 GB200 NVL72 系统都是功能强大且复杂精密的系统。每套系统都提供由 NVLink 交换机连接的高密度 GPU Fabric，支持机架内的 NVIDIA Multi-Node NVLink (MNNVL)，并包含支持 IMEX 的计算托盘，可实现跨节点共享 GPU 内存。

然而，调度器并不在交换机和 Fabric 的层级上运行。它们需要：

• 离散 GPU 资源池可以实现可预测的分配。
• 清晰的隔离边界，可保护工作负载彼此不受影响。
• 一致的性能特征，符合用户预期。

在底层，Grace Blackwell NVL72 机架的 NVLink 拓扑通过一对系统级标识符向上反映到软件栈中：cluster UUID 和 clique ID。

这些标识符以系统软件、调度器和更高层工具能够理解的方式，对 GPU 在 NVLink Fabric 中的位置进行编码——无论是跨域还是跨机架。

其映射关系很直接：

• Cluster UUID 对应于 NVLink 域。
• Clique ID 对应于 NVLink 分区。

共享的集群 UUID 意味着系统及其 GPU 属于同一个 NVLink 域，并通过共同的 NVLink fabric 连接。在 Grace Blackwell NVL72 上，该 UUID 在整个机架内保持一致：同一 NVL72 机架中的所有 GPU 都报告相同的集群 UUID。

clique ID 提供了更细粒度的区分。共享同一 clique ID 的 GPU 属于该域内的同一个 NVLink 分区。当一个机架被划分为多个 NVLink 分区时，集群 UUID 保持不变——因为这些 GPU 位于同一个物理 NVLink 域中——但 clique ID 会不同，以反映该 fabric 的逻辑分区。

从运维角度来看，这一区分很重要：

• 集群 UUID 回答的是：哪些 GPU 在物理上共享同一个机架，并且能够进行 NVLink 通信？
• Clique ID 回答的是：哪些 GPU 共享一个 NVLink Partition，并且旨在为给定工作负载或服务层级一起通信？

这些标识符构成了硬件拓扑与调度逻辑之间的连接纽带。它们使 Slurm、Kubernetes 和 NVIDIA Run:ai 等平台能够根据 NVLink Fabric 的实际结构来协调作业放置、隔离和性能保障，而无需将这种复杂性直接暴露给最终用户。

使用 Slurm 调度多节点 NVLink 工作负载

一旦开始在基于 Blackwell 的 NVL72 系统上运行多节点工作负载，位置分配就会变得与 GPU 数量同样重要。一个 16-GPU 作业如果分散在不合适的节点上，其表现可能会与被限制在单个 NVLink fabric 内的同一作业截然不同。

这正是 Slurm 的 topology/block 插件变得至关重要的地方，它使 Slurm 能够识别并非所有节点都是相同的。

在 Grace Blackwell NVL72 上，具有更低延迟连接的节点块会直接映射到 NVLink 分区——即共享高带宽 NVLink 结构的一组 GPU。

考虑一个包含两个 NVL72 机架的简单示例。这两个机架可能属于同一个 Slurm 分区（队列），但这并不意味着作业应该自由跨越它们。从性能角度来看，每个机架——或从中划分出的每个 NVLink 分区——都是一个独立的高带宽块。

通过启用 topology/block 插件并将 NVLink 分区公开为块，Slurm 获得了做出更好决策所需的上下文。默认情况下，作业会被放置在单个 NVLink 分区（或块）内，从而保持 MNNVL 性能。较大的作业可在必要时跨越多个块，但这种权衡会变得明确，而不是偶然发生。

在实践中，这意味着：

• 每个机架一个块/节点组，并在用户或组级别应用 Slurm QoS，以管理对共享分区的访问。
• 在提供较小的、隔离的高带宽 GPU 池时，每个机架可包含多个块/节点组。在这种模型中，每个块/节点组映射到一个 Slurm 分区，为每个分区提供一个服务层级。用户通过 Slurm 分区自动进入预期的 NVLink 分区，而无需了解底层结构。

使用 Slurm 管理 IMEX：从机架级服务到按作业隔离

对于依赖 MNNVL 的多节点 NVIDIA CUDA 工作负载，IMEX 使不同计算托盘上的 GPU 能够参与共享内存编程模型。

从应用程序的角度来看，使用 MNNVL 似乎简单得令人误以为毫无难度。然而，在底层，Mission Control 会确保在使用 Slurm 运行 MNNVL 作业时有几项条件保持一致：

• IMEX 仅在参与该作业的那组计算托盘上运行。
• 这些托盘属于同一个 NVLink 分区。
• IMEX 生命周期可靠、安全，并且作用范围足够严格，以避免作业之间相互干扰。

IMEX 是一种系统级守护进程，运行在每个计算托盘的主机操作系统中。它提供 CUDA 库所依赖的内存共享和同步机制。如果 IMEX 的作用范围配置不当、运行范围过宽，或出现明显故障，多节点工作负载会很快变得脆弱。

将多节点 NVLink 支持扩展到 Kubernetes 和 NVIDIA Run:ai

正如 Slurm 需要借助对 NVLink 网络结构的理解来优化调度 Grace Blackwell NVL72 作业一样，Kubernetes 也缺乏对 NVLink 这类机架级高带宽互连的原生感知能力。

为了解决这一问题，NVIDIA 生态系统结合了 ComputeDomains（通过 NVIDIA Dynamic Resource Allocation (DRA) GPU driver）和 NVIDIA Run:ai 集成，将 NVLink 和 IMEX 概念提升为具备域感知、可供调度器使用的原语。

在 Kubernetes 中，动态资源分配（DRA）提供了一个 API，用于对专用硬件进行灵活、细粒度的管理。

NVIDIA k8s-dra-driver-gpu 为 GPU 和 ComputeDomains 实现了这一 API。该驱动包含分别用于 GPU 分配和 ComputeDomains 的 kubelet 插件；启用后，它会管理 GPU 多节点 NVLink 域——将跨节点的 GPU 分组到安全、高带宽、内存一致的域中，以支持 HPC 和 AI 工作负载。

Kubernetes：从扁平化调度器到支持 NVLink 感知的放置

在 Kubernetes 中，核心挑战与 Slurm 类似。Kubernetes Pod 需要被放置在共享高带宽连接的节点上。Kubernetes 本身并不了解 NVLink 域，因此工作负载可能会分散到缺乏高效多节点执行所需结构连接的节点上。

解决方案是 NVIDIA DRA GPU 驱动提供的 ComputeDomains 概念。ComputeDomain：

• 表示一组共享 NVLink/MNNVL 域的节点。
• 在提交分布式工作负载（训练或推理）时，工作负载提交必须创建 ComputeDomain 对象，并通过 ResourceClaim 链接到该对象。
• 与参与工作负载的确切 pod 集合绑定。
• 在工作负载结束时被拆除。

通过这样做，ComputeDomains 使高性能互连结构在调度中成为一等对象。ComputeDomains 还确保 IMEX 通道等底层资源被正确实例化，并限定在该工作负载的范围内。

---
apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: compute-domain
spec:
  numNodes: 18
  channel:
    resourceClaimTemplate:
      name: compute-domain-resource-claim

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-workload
  labels:
    app: test-workload
spec:
  replicas: 18
  selector:
    matchLabels:
      app: test-workload
  template:
    metadata:
      labels:
        app: test-workload
    spec:
      containers:
      - name: ctr
        image: ubuntu:22.04
        command: ["test-workload"]
        resources:
          limits:
            nvidia.com/gpu: 4
          claims:
          - name: compute-domain
      resourceClaims:
      - name: compute-domain
        resourceClaimTemplateName: compute-domain-resource-claim

NVIDIA Run:ai 如何简化 NVLink 域上的分布式工作负载

NVIDIA Run:ai 基于 Kubernetes 和 ComputeDomains 构建，使 Grace Blackwell NVL72 系统无需向用户暴露 NVLink 拓扑、IMEX 域或底层调度机制即可使用。用户请求分布式 GPU。其余部分由 NVIDIA Run:ai 处理。



在底层，NVIDIA Run:ai 自动化了几个关键部分：

• 自动检测和标记：GB200 NVL72 节点会根据其 NVLink/MNNVL 域成员关系进行识别和标记。这些标签构成了 NVLink 感知放置的基础。
• 由 ComputeDomain 支持的工作负载放置：提交作业时，会自动创建并附加一个 ComputeDomain。Pod 会被放置在共享 NVLink 连接且具有正确作用域 IMEX 域的节点上。
• 拓扑感知调度：为节点池定义网络拓扑后，NVIDIA Run:ai 会应用拓扑感知调度偏好，使分布式工作负载中的所有 Pod 尽可能保持彼此接近，仅在必要时向外扩展。这可降低延迟，并避免意外的跨域放置。

使用 Topograph 进行自动拓扑检测

所有这些方法都依赖于对底层硬件和网络拓扑的准确了解。对于平台工程师而言，在大型或频繁变化的环境中手动定义 NVLink 域、机架边界或网络层级并不具备可扩展性。这正是 Topograph 这一开源 NVIDIA 工具发挥作用的地方。

Topograph 通过收集节点级和基础设施元数据，并将其转换为调度器可使用的表示形式，自动发现集群拓扑。它可以检测节点之间的连接方式——跨机架、交换机或网络结构层级——并通过 API 向上层系统揭示这一结构。调度器不再假设集群是扁平的，而是获得了关于邻近性和带宽关系的具体视图。

当与 Slurm 和 Kubernetes，以及 ComputeDomains 和 NVIDIA Run:ai 结合使用时，Topograph 可实现完全自动化的流程。拓扑是被发现的，而不是手工建模的；节点会被一致地标记；并且可以在操作员最少干预的情况下做出拓扑感知的放置决策。这弥合了物理基础设施与逻辑调度抽象之间的差距。

了解有关高级 AI 运维的更多信息

请查看 Mission Control Administrator Guide 或 User Guide，以了解有关实施的更多信息。

观看 NVIDIA GTC 2026 的 Eli Lilly & Company 点播会议，了解他们如何借助强大而智能的软件，从机架级硬件迈向可调度的 AI 基础设施。