让 Kubernetes 在首发日即支持 NVIDIA Vera Rubin 的 AI

为 NVIDIA Vera Rubin 等新 GPU 硬件配置和优化 Kubernetes 非常复杂且容易出错。驱动程序、内核、运行时、网络、运算符和调度程序必须协同工作，并根据硬件和工作负载调整设置。小的不匹配可能会阻止工作负载运行或限制性能。

NVIDIA AI Cluster Runtime (AICR) 是 NVIDIA DSX AI Factory Platform 的一部分，通过在可重复使用的 recipe 中捕获经过调优的配置、为现有部署工具生成捆绑包以及验证正在运行的集群，简化了这项工作。它将帮助 Kubernetes 环境在第一天就为 NVIDIA Vera Rubin NVL72 计算托盘 做好准备。

总体而言，NVIDIA DSX AI 工厂平台整合了多种技术，可帮助生态系统设计、构建和运营更高效的 AI 工厂，其中包括专为支持多租户运营和扩展而构建的开源模块化软件组件。 

在云原生堆栈中配置新的硬件架构需要从底层绑定一直到编排层的持续更新。对于 Vera Rubin 来说，这还为时尚早。

本文介绍了如果您现在运行 NVIDIA GB200 NVL72 会发生什么变化，以及在使用 NVIDIA GPU Operator 和支持 Vera Rubin 的动态资源分配 (DRA) 驱动程序进行早期硬件访问时发生的变化。它还展示了 AICR 如何将这些组件整合到一个可供平台团队复制和验证的配置中。

GB200 NVL72 有哪些变化：规划升级

如果您现在运行 GB200 NVL72，NVIDIA Vera Rubin NVL72 是同一 NVIDIA MGX 机架级架构的升级版本，现已推出第三代。但一些用户可见的部分会发生变化。了解这些更改后，您可以计划集群软件和配置更改以及即将发布的版本：

• GPU 驱动程序：Vera Rubin NVL72 需要新的驱动程序分支。它已通过主机安装的 R615.23 开放 GPU 驱动程序 R615.23 进行验证。早期支持针对的是 R610，而 R620 则提供官方平台支持。AICR 的 GB200 基准是 R580.173.02。R615.23 是当前测试版本，不是官方 Vera Rubin 支持的确认最低版本。
• DOCA 和网卡驱动：Vera Rubin NVL72 将 GB200 NVL72 参考设计的 NVIDIA ConnectX-7 网卡和 NVIDIA BlueField-3 DPU 替换为 NVIDIA ConnectX-9 SuperNIC 和 NVIDIA BlueField-4 DPU。DOCA 3.3.0 是首个支持 ConnectX-9 的正式版本。Vera Rubin 系统镜像在 DOCA-OFED 3.3.0 上进行了验证。这是测试平台版本，不是要求或推荐。AICR 使用主机安装的网卡驱动和 DRANET 进行此处的 Pod 分配。网络运算符兼容性仍然是一个单独的认证步骤 (请参阅 DOCA 3.3.0 版本说明)。
• 设备拓扑：Vera Rubin NVL72 计算托盘的 NIC/GPU/直接内存访问 (DMA) 拓扑与 GB200 不同，因此对于 I/O 密集型工作负载，如远程直接内存访问 (RDMA) 网络和 GPUDirect Storage，必须检查 GPU 到网卡的亲和性和 NUMA 放置。两个参考托盘均包含 2 个 CPU 和 4 个 GPU，但 Vera Rubin NVL72 托盘显示的 8 个 ConnectX-9 PCI 设备组具有 32 个功能，而 NVIDIA DGX GB200 NVL72 计算托盘上只有 4 个 ConnectX-7 适配器。在 GB200 NVL72 和 Vera Rubin NVL72 托盘中，GPU 0 到 1 的 CPU NUMA 亲和力为 0；GPU 2 到 3 的亲和力为 1。GPU 到网卡的连接方式是在插槽内连接 NODE，在插槽间连接 SYS。PCI 功能数量并不代表物理端口数量 (请参阅 GB200 参考架构)。
• IMEX：与 GB200 NVL72 一样，多节点 NVIDIA NVLink 工作负载使用 IMEX。借助 DRA 管理的 IMEX，停止、禁用和屏蔽主机的静态 nvidia-imex 服务，以防止所有权冲突。DRA v0.5.0 添加了仅具有域隔离的 Alpha 主机管理选项；我们的集群使用 driverManaged 模式。(请参阅版本说明)
• NVIDIA 多实例 GPU (MIG) 配置文件：Rubin GPU 引入了新的 MIG 配置文件。R615.23 会在节点上公布这些配置文件。AICR Vera Rubin recipe 使用整个 GPU 分配，不配置 MIG。此验证不涵盖 Vera Rubin 上的 MIG。
• AICR recipe：所有这些增量都在新的 Vera Rubin recipe 系列中编码，因此 aicr recipe 和 aicr validate 反映了经过验证的组合，而不是让您重新发现每个更改 (详情请参阅以下部分) 。

在 Vera Rubin NVL72 上进行验证 

为了验证对 Vera Rubin NVL72 的端到端支持，我们使用官方 GPU Operator v26.7.0 版本和官方 DRA 驱动程序 v0.5.0 版本在 Vera Rubin 集群上部署了 AICR 运行时软件包，并安装了主机安装的 R615 驱动程序。 

训练和推理 recipe 变体现在都可以验证端到端部署和一致性。对于训练，初始性能门：跨节点 NCCL 通过 NVIDIA NVLink 结构进行全归约，通过 IMEX ComputeDomain 运行，并在总线带宽层上进行门控。GPU pod 运行良好，IMEX 通道被注入到跨多个节点的 pod 声明中，如下所示。

有关早期硅现实的说明：研发新的硅是一个过程。由于早期 Vera Rubin 集群之一的硬件/网络问题（与 GPU Operator 或 DRA 驱动程序无关），使一个计算托盘无法进入 NVLink 网络，因此首批验证轮暂时受阻。重新安装硬件后，两个节点上的所有 GPU 加入了一个干净的网络集群。

从启动到可复制的配方

验证组件只完成了一半的工作。启动正常运行的 Vera Rubin 集群意味着选择驱动模式、容器运行时接线、组件版本和一些特定于平台的设置。AICR 将这些选择捕捉为版本化的 recipe，因此真实 Vera Rubin 硬件上的配置在集群上是显式的、可复制的和可验证的。

新的 Vera Rubin recipe 系列 (服务：rke2；加速器：Vera Rubin NVL72 (vr200) ；操作系统：Ubuntu；具有训练、推理和 NVIDIA Dynamo 推理变体) 作为预览版发布。这是一种早期采用者路径，在平台本身处于预发布阶段时，尚未提供受支持配方的生产支持和生命周期资格。它对在此启动期间做出的决策进行编码：

• 主机管理的驱动：Vera Rubin 系统镜像预安装 arm64 开放内核模块驱动，因此 recipe 使用 driver.enabled: false 运行 GPU Operator，而容器工具包则由 Operator 管理。当官方建造船舶时，配方将转移到由操作员管理的驾驶员身上。
• 具有计算域的 DRA 驱动程序：NVL72 结构启用了 IMEX 支持的计算域，整个 GPU 分配保留在设备插件上。
• 平台层和怪念头：它们只经过一次编码，因此用户不会重新发现它们。Kubernetes >= 1.34.1 — 1.34，用于 ComputeDomains/IMEX 使用的 GA resource.k8s.io/v1 DRA API，以及 .1 补丁，因为 RKE2 CDI/NRI 工具套件路径需要 containerd 2.1 (v1.34.1+rke2r1)。采用经过 Vera 优化的 arm64 64k 页面内核的 Ubuntu 26.04。以及更小的锐利边缘，例如提高 NFD 拓扑更新程序的默认 60Mi 内存限制，该限制会在多 TB 的 NVL72 工作节点上导致显存不足 (OOM) 死亡。

此捆绑包的首次部署针对的是平台组合，这些组件 ( arm64、Ubuntu 26.04、64k 页内核、RKE2 和 Vera Rubin) 从未一起进行过验证，只需几个小时即可从集群交接转变为正常的运行时。第二天，第二个 Vera Rubin 集群再现了结果，这种可重复性是该方法的重点和优势。

实时 Vera Rubin 集群上的工作流

为了实现这一点，请查看实际的 AICR 工作流，该工作流使用 AICR v1.0.0 工具链在实时 Vera Rubin NVL72 参考集群上执行。

1. 生成食谱

离线生成食谱：根据食谱目录解析标准，只需几秒钟即可完成。

$ aicr recipe \
    --service rke2 \
    --accelerator vr200 \
    --os ubuntu \
    --intent training \
    -o recipe.yaml

[cli] building recipe from criteria: criteria=criteria(service=rke2,
accelerator=vr200, intent=training, os=ubuntu)
[cli] recipe generation completed: output=recipe.yaml components=14
componentNames=cert-manager, dra-node-labeler, dranet, gpu-operator,
k8s-ephemeral-storage-metrics, kai-scheduler, kube-prometheus-stack, nfd,
nodewright-customizations, nodewright-operator, nvidia-dra-driver-gpu,
nvsentinel, prometheus-adapter, prometheus-operator-crds
overlays=5

所解决的配方将五个叠加层叠加为 14 个组件。除了 GPU Operator (主机管理驱动模式) 和 DRA 驱动 (已启用计算域) 之外，它还提供了与此平台最相关的两个部分：DraNet、将 ConnectX-9 设备分配给 Pod 的 DRA 网络驱动 ( ConnectX-9 上的 RDMA 数据路径性能不在此验证范围内) ，以及通过 NodeWright 调优应用的专用 RDMA 网络模式。每个 Pod 只能看到自己的主机网卡 (HCA) 。

AICR 还整合了 NVIDIA DSX AI 工厂平台的组件：NodeWright 通过其原生 vr200/rke2 配置文件应用节点调优，KAI Scheduler 提供工作负载调度，NVSentinel 监控运行时运行状况。节点特征发现 (NFD) 和 Prometheus 堆栈完善了该方案，并在 Vera Rubin 硬件上验证了固定到配置的组件版本。

2. 渲染部署包

捆绑包是一组按组件排序的 Helm Chart，具有单个部署脚本：

$ aicr bundle -r recipe.yaml -o ./bundle
Files generated: 61

$ ls bundle
001-cert-manager               008-gpu-operator                 checksums.txt
002-dranet                     009-k8s-ephemeral-storage-...    deploy.sh
003-nfd                        010-kai-scheduler                README.md
004-nodewright-operator        011-nvidia-dra-driver-gpu        recipe.yaml
005-nodewright-customizations  012-nvsentinel
006-prometheus-operator-crds   013-prometheus-adapter
007-kube-prometheus-stack      

3. 快照和验证

AICR 会捕获集群的实际状态，根据该状态检查 recipe 的就绪性限制，然后将其验证检查作为集群内作业运行：

$ aicr snapshot --output snapshot.yaml
$ aicr validate -r recipe.yaml -s snapshot.yaml --phase deployment
[cli] readiness constraint passed: name=OS.release.VERSION_ID
expected=26.04 actual=26.04
[cli] readiness constraint passed: name=OS.sysctl./proc/sys/kernel/osrelease
expected=>= 7.0 actual=7.0.0-2008-nvidia-bos-64k
[cli] phase completed: phase=deployment status=passed validators=4 passed=4
$ aicr validate -r recipe.yaml -s snapshot.yaml --phase conformance
[cli] phase completed: phase=conformance status=passed validators=8 passed=8



$ aicr validate -r recipe.yaml -s snapshot.yaml --phase performance
[cli] phase completed: phase=performance status=passed validators=1 passed=1

性能阶段将 NVIDIA 集合通信库 (NCCL) all-reduce gate 作为集群内作业运行：通过 IMEX ComputeDomain 在 NVLink 结构上进行跨节点 all-reduce，并根据 recipe 的总线带宽层进行检查。rke2/vr200 组合已在验证器的适用性矩阵中注册，并且其运行时作为嵌入式模板提供，因此验证器将配置 ComputeDomain 和 IMEX ResourceClaimTemplate 本身，无需任何 Operator 前提条件，也无需使用 recipe 提供的运行时。它从 v1.0.0 正式版本运行。

完整的矩阵现在通过。

推理变体 (Dynamo 平台、推理网关、分组调度、DCGM 指标) 在相同集群上通过相同的部署和一致性矩阵。

该运行的两个构件值得展示。首先，预发布驱动上的 nvidia-smi 横幅正是验证者首次接触时出现问题的确切更改。这是早期芯片带来的小惊喜的一个很好的例子。修复程序 (NVIDIA/aicr#1748) 与 NVIDIA Vera Rubin 硬件进行合并和验证。

$ nvidia-smi | head -3
+--------------------------------------------------------------------+
| NVIDIA-SMI 615.23    KMD Version: 615.23   CUDA UMD Version: 13.4  |
+--------------------------------------------------------------------+

其次，实时 GPU 遥测数据流通过标准 DCGM 导出路径。请注意占位符产品名称，一旦 PCI ID 在接近全面推出时得到分配，此产品名称便会解析：

DCGM_FI_DEV_SM_CLOCK{gpu="0",modelName="NVIDIA Graphics Device",
    DCGM_FI_DRIVER_VERSION="615.23"} 120

4. 跨节点计算域测试

最后，DRA/ IMEX 路径端到端：双节点 ComputeDomain，其 IMEX 通道由每个计算托盘上的 pod 声明。使用主机管理 IMEX 时，镜像有一个先决条件：必须禁用和屏蔽主机的静态 nvidia-imex 服务，因为主机管理 IMEX 和 DRA 管理的计算域是互斥的 ( DRA 驱动程序 v0.5.0 增加了主机管理选项) 。

GPU Operator v26.7.0+ 的注意事项：该图表提供了自己更严格的 resource.nvidia.com_computedomains.yaml 自定义资源定义 (CRD) 副本，该副本需要无默认的 numNodes ( DRA 驱动程序图表的副本不需要) 。只有在重新安装集群时，这一点才重要 – Helm 不会覆盖已安装的 CRD，因此升级 GPU – operator 的现有集群不受影响。如果要启动新集群，请在 ComputeDomain 清单中显式设置 numNodes，例如。规格：{numNodes：2，…}。

$ kubectl apply -f cd-2node-test.yaml
computedomain.resource.nvidia.com/cd-2node-test created
pod/cd-test-c01 created
pod/cd-test-c02 created

$ kubectl get computedomain,resourceclaims,pods -n cd-test
NAME            STATUS   NODES
cd-2node-test   Ready    vr-...-c01,vr-...-c02

NAME                             STATE                AGE
cd-test-c01-imex-channel-k9j2d   allocated,reserved   32s
cd-test-c02-imex-channel-l6tl2   allocated,reserved   30s

NAME          READY   STATUS    NODE
cd-test-c01   1/1     Running   vr-...-c01
cd-test-c02   1/1     Running   vr-...-c02

$ kubectl logs cd-test-c01 -n cd-test   # identical output on c02
crw-rw-rw- 1 root root 505, 0 channel0  # /dev/nvidia-caps-imex-channels

从应用到两个正在运行的 POD (每个计算托盘一个，每个都注入 IMEX 通道并将 IMEX 守护程序加入到单个域中) 大约需要 12 秒。现在，训练 recipe 的 NCCL 性能门会在实际工作负载流量下驱动相同的 ComputeDomain 路径：通道注入已在上文得到验证，而网络带宽已在性能阶段得到验证。

针对实时集群，整个序列 ( recipe、捆绑包、快照以及部署和一致性验证阶段) 大约在五分钟内完成。性能阶段会增加 NCCL 作业本身的运行时。

验证证据和反馈回路

这些结果基于 AICR 在 NVL72 参考环境中的部署、一致性和性能验证，以及成功的端到端 ComputeDomain 测试。单个检查详细信息已编入上述验证矩阵。

同样重要的是验证边界目前所处的位置。该训练方法现在带有跨节点 NCCL 性能门：这是 Vera Rubin 芯片上的第一个性能验证，在真正的 all-reduce 流量下执行与上述相同的 IMEX 计算域路径。

推理服务性能目前仍处于延迟状态。vLLM 合并了 v0.27.0 中的 Rubin (sm_107a) 支持，但 SM107 内核路径在构建时在 NVIDIA CUDA >= 13.4 上进行门控，并且 vLLM 自己发布的镜像通过 v0.28.0 仍然基于 CUDA 13.0.3 构建。因此，即使是最新的 vLLM 版本镜像也会在没有编译内核的情况下携带调度代码。ai-dynamo 的最新版本 (v1.4.2) 引脚 vllm-openai v0.26.0，该版本完全早于代码发布；其未发布的主分支引脚 v0.28.0，该版本并非基于 13.4 构建。VR200 推理性能地板需要一个已发布、CUDA >= 13.4 构建的运行时镜像在真实硬件上进行验证，通过 JIT 编译崩溃，而不仅仅是通过版本检查。

Vera Rubin 方案的签名验证证据是公开的：训练 (包括 NCCL 性能门在内的三个阶段) 和 推理 (部署和一致性) 。由于菜谱处于预览状态且仍在移动，因此请将已发布的证据视为所捕获坐标的历史记录，而非当前菜谱内容的证明。对当前食谱进行摘要检查，即可报告不匹配情况。

启动也是双向的。在 Vera Rubin 上运行 AICR 验证会在 go-nvlib 包中显示一个未映射的 Rubin 架构值，该值对 DRA 驱动程序的 kubelet 插件进行了崩溃循环。由于架构支持首先出现在 go-nvml 中；流入 go-nvlib；然后从那里进入 GPU Operator、Kubernetes 设备插件、MIG 管理器和 DRA 插件，因此修复程序会在整个堆栈中持续传播。在大约三天的时间内，它完成了从第一次崩溃报告到基于 Vera Rubin 硬件的验证构建。该修复程序 (go-nvlib 0.11.0 → 0.12.0) 已在官方 DRA 驱动 v0.5.0 版本中发布，因此 Vera Rubin 方法固定了原厂标签，无需进行临时构建。

验证还表明，主机管理的 IMEX 守护程序和 DRA 管理的 ComputeDomain 目前无法共享节点，这一反馈塑造了 DRA 驱动程序 v0.5.0 中提供的主机管理 IMEX 选项。

Vera Rubin recipe 在 v1.0.0 的开源 NVIDIA/aicr 仓库中发布，在公共目录中注册了 rke2 服务和 vr200 加速器。

开始使用

使用 AICR 公共目录中的预览方法，开始在 Vera Rubin 上使用 AICR。

生成经过验证的配置只需一条命令：

aicr recipe --service rke2 --accelerator vr200 --os ubuntu --intent training

对于上述 Dynamo 推理变体，以下命令将生成 recipe：

aicr recipe --service rke2 --accelerator vr200 --os ubuntu --intent inference --platform dynamo

您可以在 GitHub 上跟踪进度、查看代码或解决相关问题：

• NVIDIA/go-nvml
• NVIDIA/go-nvlib
• kubernetes-sigs/dra-driver-nvidia-gpu
• NVIDIA/aicr