NVIDIA AICR 让 Kubernetes 在 Day 1 就支持 Vera Rubin

Data Center / Cloud

作者：Mark Chmarny 和 Yuan Chen

NVIDIA AI Cluster Runtime（AICR）将调优后的配置固化为可复用的 recipe，生成部署包，并验证运行中的集群，从而简化新 GPU 硬件的 Kubernetes 就绪流程。

Vera Rubin NVL72 recipe 系列固化了经过验证的配置选择：主机管理的 R615.23 开源内核模块驱动、带 ComputeDomains 的 DRA driver v0.5.0、采用 64k 页内核的 Ubuntu 26.04，以及 NFD 拓扑更新器内存限制等平台特定设置。

在 Vera Rubin NVL72 参考集群上，使用 GPU Operator v26.7.0 和 DRA driver v0.5.0 进行的端到端验证通过了部署、一致性测试，以及一项跨节点 NCCL all-reduce 性能门槛测试——在 NVLink 网络上以 16 GiB 达到 744.71 GB/s 总线带宽。

在早期芯片上运行 AICR 验证时，发现 go-nvlib 中存在一个未映射的 Rubin 架构值，导致 DRA driver 的 kubelet 插件崩溃重启；该修复已沿整个软件栈传播，并随官方 DRA driver v0.5.0 版本发布。

后续步骤

使用单条命令生成 NVIDIA/aicr Vera Rubin 训练 recipe，开始评估经过验证的配置。

使用 Dynamo 平台标志生成 NVIDIA/aicr Vera Rubin 推理 recipe，探索推理变体。

查看训练 recipe 的签名验证证据，了解完整的部署、一致性测试和性能结果。由 NVIDIA Nemotron 提供支持。AI 生成的内容可能不完整地概括信息。请核实重要信息。了解更多

为新 GPU 硬件（如 NVIDIA Vera Rubin）配置和优化 Kubernetes 既复杂又容易出错。驱动、内核、运行时、网络、Operator 和调度器必须协同工作，并且设置要针对硬件和工作负载进行调优。细微的不匹配就可能导致工作负载无法运行或性能受限。

NVIDIA AI Cluster Runtime（AICR）是 NVIDIA DSX AI Factory Platform 的一部分，它通过将调优后的配置固化为可复用的 recipe、为现有部署工具生成部署包并验证运行中的集群，简化了这项工作。它将帮助 Kubernetes 环境在 Day 1 就为 NVIDIA Vera Rubin NVL72 计算托盘做好准备。

总体而言，NVIDIA DSX AI Factory Platform 汇集了多种技术，帮助生态系统设计、构建和运营更高效的 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（主机安装的 R615.23 开源 GPU 驱动）完成验证。早期支持目标为 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 的 GA 版本。经验证的 Vera Rubin 系统镜像随附 DOCA-OFED 3.3.0。这是测试平台版本，并非要求或建议。AICR 在此使用主机安装的网卡驱动和 DRANET 进行 Pod 分配。Network Operator 兼容性仍是单独的资格验证步骤（参见 DOCA 3.3.0 发行说明）。

设备拓扑：Vera Rubin NVL72 计算托盘的网卡/GPU/直接内存访问（DMA）拓扑与 GB200 不同，因此对于远程直接内存访问（RDMA）网络和 GPUDirect Storage 等 I/O 密集型工作负载，必须检查 GPU 到网卡的亲和性以及 NUMA 放置。两种参考托盘都包含两个 CPU 和四个 GPU，但 Vera Rubin NVL72 托盘暴露八个 ConnectX-9 PCI 设备组、共 32 个功能，而 NVIDIA DGX GB200 NVL72 计算托盘上为四个 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 driver v0.5.0 版本，并在主机上安装 R615 驱动，在 Vera Rubin 集群上部署了 AICR 运行时捆绑包。

训练和推理两种 recipe 变体现在都能端到端通过部署和一致性验证。对于训练，有一个初始性能门槛：通过 IMEX ComputeDomain 在 NVIDIA NVLink 网络上运行跨节点 NCCL all-reduce，并以总线带宽下限作为门槛。GPU Pod 运行正常，IMEX 通道被注入到跨多个节点的申领 Pod 中，如下方真实集群输出所示。

关于早期芯片现实的说明：让新芯片上线是一个过程。最初的几轮验证曾因某个早期 Vera Rubin 集群中的硬件/网络结构问题而暂时受阻——该问题与 GPU Operator 或 DRA driver 无关——导致一个计算托盘无法加入 NVLink 网络结构。在硬件重新插接后，两个节点上的所有 GPU 都加入了同一个干净的网络结构 clique。

从启动到可复现的 recipe

验证各组件只是故事的一半。搭建一个可用的 Vera Rubin 集群意味着选择驱动模式、容器运行时接线、组件版本以及若干平台特定设置。AICR 将这些选择捕获为带版本的 recipe，因此真实 Vera Rubin 硬件上的配置是明确的、可复现的，并且可以跨集群验证。

新的 Vera Rubin recipe 系列（service：rke2；accelerator：Vera Rubin NVL72（vr200）；操作系统：Ubuntu；包含训练、推理和 NVIDIA Dynamo 推理变体）以 Preview 形式发布。这是一条早期采用者路径，在平台本身仍处于预发布阶段时，尚不具备 Supported recipe 的生产支持和生命周期资格。它编码了本次启动过程中做出的决策：

主机管理的驱动：Vera Rubin 系统镜像预装了 arm64 开放内核模块驱动，因此该 recipe 以 driver.enabled: false 运行 GPU Operator，而容器工具包仍由 operator 管理。当官方构建发布后，该 recipe 将切换到 operator 管理的驱动。

带 ComputeDomains 的 DRA driver：为 NVL72 网络结构启用了由 IMEX 支持的 ComputeDomains，整 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）。Ubuntu 26.04 搭配针对 Vera 优化的 arm64 64k 页内核。还有一些较小的尖锐问题，例如提高 NFD 拓扑更新器默认的 60Mi 内存限制，该限制在多 TB 的 NVL72 工作节点上会因内存不足（OOM）而被杀死。

该捆绑包的首次部署针对的是这些组件从未一起验证过的平台组合——arm64、Ubuntu 26.04、64k 页内核、RKE2 和 Vera Rubin——并在数小时内从集群交接推进到健康的运行时。第二天，第二个 Vera Rubin 集群复现了该结果，而这种可重复性正是该 recipe 的意义和优势所在。

在运行中的 Vera Rubin 集群上的工作流程

为使其具体化，以下是在一个运行中的 Vera Rubin NVL72 参考集群上使用 AICR v1.0.0 工具链执行的实际 AICR 工作流程。

1. 生成 recipe

Recipe 生成是离线的：它根据 recipe 目录解析条件，只需几秒钟。

$ 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

解析后的 recipe 将五个 overlay 层叠为 14 个组件。除了 GPU Operator（主机托管驱动模式）和 DRA driver（启用 ComputeDomains）之外，它还引入了两个最贴合该平台的组件：DraNet，即负责将 ConnectX-9 设备分配给 Pod 的 DRA 网络驱动（基于 ConnectX-9 的 RDMA 数据路径性能不在本次验证范围内）；以及独占 RDMA netns 模式，通过 NodeWright 调优应用。每个 Pod 只能看到自己的主机通道适配器（HCA）。

AICR 还整合了 NVIDIA DSX AI Factory Platform 的各个组件：NodeWright 通过其原生 vr200/rke2 profile 应用节点调优，KAI Scheduler 提供工作负载调度，NVSentinel 监控运行时健康状态。Node Feature Discovery（NFD）和 Prometheus 栈补全了整个 recipe，各组件版本均锁定为在 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 的就绪约束，然后以集群内 Job 的形式运行其验证检查：

$ 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

性能阶段以集群内 Job 的形式运行 NVIDIA 集合通信库（NCCL）all-reduce 门禁：通过 IMEX ComputeDomain 在 NVLink 网络上执行跨节点 all-reduce，并对照 recipe 的总线带宽下限进行检查。rke2/vr200 组合已注册在验证器的适用性矩阵中，其运行时以嵌入式模板的形式提供，因此验证器会自行配置 ComputeDomain 和 IMEX ResourceClaimTemplate——无需 operator 前置条件，也无需 recipe 提供运行时。它从标准的 v1.0.0 版本运行。

完整矩阵现已全部通过。

阶段检查结果处置

deploymentoperator-healthpass所有组件均健康。

deploymentgpu-operator-versionpass版本门禁已满足。

deploymentexpected-resourcespass所有预期的 Kubernetes 资源均已存在且健康。

deploymentcheck-nvidia-smipass所有节点上的 nvidia-smi 均健康

conformanceplatform-healthpass所有平台检查均通过。

conformancegpu-operator-healthpass所有 operator 组件均健康。

conformanceaccelerator-metricspassDCGM 指标路径已端到端验证，所有 GPU 均在上报。

conformanceai-service-metricspass自定义指标 API 正常提供服务。

conformancedra-supportpassDRA/ComputeDomain 支持。

conformancegang-schedulingpassKAI 组调度。

conformancepod-autoscalingpass外部指标 API 加上 HPA 扩容（1->3）和缩容（3->1）。

conformancesecure-accelerator-accesspassDevice-plugin 模式（无 gpu.nvidia.com DeviceClass）

performancenccl-all-reduce-bw-nvlspass首次跨节点 NCCL all-reduce，通过多节点 NVLink（IMEX ComputeDomain）在两个计算托盘上执行：16 GiB 下总线带宽为 744.71 GB/s。

表 1. Vera Rubin NVL72 训练 recipe 的 AICR 验证结果：所有部署、一致性和性能检查均通过，包括在 Vera Rubin 芯片上首次进行的跨节点 NCCL all-reduce 性能门禁

推理变体（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 exporter 路径流动。请注意占位的产品名称，该名称将在接近正式发布时分配 PCI ID 后解析：

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

4. 跨节点 ComputeDomain 测试

最后是 DRA/IMEX 路径的端到端流程：一个双节点 ComputeDomain，其 IMEX 通道由每个计算托盘上的 Pod 申领。对于使用主机托管 IMEX 的镜像，有一个前提条件：必须禁用并屏蔽主机上的静态 nvidia-imex 服务，因为主机托管 IMEX 与 DRA 托管的 ComputeDomain 互斥（DRA driver v0.5.0 新增了主机托管选项）。

GPU Operator v26.7.0+ 注意事项：该 chart 自带一份更严格的 resource.nvidia.com_computedomains.yaml 自定义资源定义（CRD）副本，其中 numNodes 为必填项且无默认值（DRA driver chart 的副本则没有此要求）。这只在全新集群安装时才有影响——Helm 不会覆盖已安装的 CRD，因此升级 gpu-operator 的现有集群不受影响。如果你要搭建新集群，请在 ComputeDomain 清单中显式设置 numNodes，例如 spec: {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 # c02 上的输出相同 crw-rw-rw- 1 root root 505, 0 channel0 # /dev/nvidia-caps-imex-channels

从 apply 到两个 Pod 运行起来——每个计算托盘一个，各自注入 IMEX 通道，且 IMEX 守护进程加入同一个域——大约需要 12 秒。训练 recipe 的 NCCL 性能门禁现在正是在真实工作负载流量下驱动同一条 ComputeDomain 路径：通道注入已在上文得到验证，而 fabric 带宽则在性能阶段得到验证。

整个流程（recipe、bundle、快照，以及部署和一致性验证阶段）针对在线集群大约五分钟即可完成。性能阶段还会加上 NCCL 作业本身的运行时间。

验证证据与反馈闭环

这些结果以 AICR 在 NVL72 参考环境中的部署、一致性和性能验证为基础，并结合了成功的端到端 ComputeDomain 测试。各项检查的详细信息已编入上文的验证矩阵。

同样重要的是当前已验证边界所处的位置。训练 recipe 现在带有一个跨节点 NCCL 性能门禁：这是在 Vera Rubin 芯片上进行的首次性能验证，在真实 all-reduce 流量下走通了上文所示的同一条 IMEX ComputeDomain 路径。

推理服务性能目前仍暂缓。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，该版本完全早于相关代码；其未发布的 main 分支锁定 v0.28.0，而该版本并非基于 13.4 构建。VR200 的推理性能下限需要一个已发布、基于 CUDA >= 13.4 构建、并在真实硬件上验证过的运行时镜像——要越过 JIT 编译崩溃，而不仅仅是越过版本检查。

Vera Rubin recipe 的签名验证证据已公开：训练（三个阶段，包括 NCCL 性能门禁）和推理（部署与一致性）。由于这些 recipe 仍处于预览阶段且仍在变动，请将已发布的证据视为其采集时所对应坐标的历史记录，而非对当前 recipe 内容的证明。对今天的 recipe 做摘要校验会报告不匹配。

图 1. AICR 在 Vera Rubin 上的验证会生成经过签名、可公开验证的证据，并将发现的问题反馈给上游组件。

这次 bring-up 在双向都奏效。在 Vera Rubin 上运行 AICR 验证时，发现 go-nvlib 包中有一个未映射的 Rubin 架构值，导致 DRA driver 的 kubelet 插件崩溃重启循环。由于架构支持首先进入 go-nvml；再流入 go-nvlib；并由此进入 GPU Operator、Kubernetes Device Plugin、MIG Manager 和 DRA 插件，该修复在整个技术栈中一致地传播开来。从第一份崩溃报告到在 Vera Rubin 硬件上获得验证通过的构建，大约用了三天。该修复（go-nvlib 0.11.0 → 0.12.0）已随官方 DRA driver v0.5.0 版本发布，因此 Vera Rubin recipe 锁定的是正式标签——无需暂存构建。

验证还发现，主机托管的 IMEX 守护进程与 DRA 托管的 ComputeDomain 目前无法共享同一节点，这一反馈促成了 DRA driver v0.5.0 中发布的主机托管 IMEX 选项。

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

生成已验证配置只需一条命令：

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 上关注进展、审阅代码或提交 issue：

NVIDIA/go-nvml

NVIDIA/go-nvlib

kubernetes-sigs/dra-driver-nvidia-gpu

关于作者

关于 Mark Chmarny

Mark Chmarny 是 NVIDIA DGX Cloud 组织的一位首席云架构师，专长于大规模分布式系统、容器编排和 GPU 加速计算。他专注于基于 Kubernetes 的 AI/ML 平台、高性能 GPU 集群，以及用于训练和推理的多云基础设施。

查看 Mark Chmarny 的所有文章

关于 Yuan Chen

Yuan Chen 是 NVIDIA 的首席软件工程师，负责为 AI 构建云原生 Kubernetes 基础设施，并维护开源项目 NVIDIA AI Cluster Runtime（AICR）。他专注于将新的 GPU 集群转变为经过验证、可复现、可直接承载 AI 工作负载的 Kubernetes 平台。他此前曾在 Apple 构建超大规模 Kubernetes 基础设施，并且是 Kubernetes 和 CNCF 项目的活跃贡献者。

查看 Yuan Chen 的所有文章

评论