为NVIDIA Vera Rubin等新型GPU硬件配置和优化Kubernetes是一项复杂且容易出错的工作。驱动、内核、运行时、网络、operator和调度器必须协同工作，并根据硬件和工作负载调整设置。微小的不匹配就可能导致工作负载无法运行或性能受限。
NVIDIA AI Cluster Runtime（AICR）是NVIDIA DSX AI Factory平台的组成部分，它通过将调优后的配置封装为可复用的配方（recipe），为现有部署工具生成软件包，并对运行中的集群进行验证，从而简化了这项工作。它将帮助Kubernetes环境在首日就为NVIDIA Vera Rubin NVL72计算托盘做好准备。
总体而言，NVIDIA DSX AI Factory平台汇聚了多项技术，帮助生态系统设计、构建和运营更高效的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用NVIDIA ConnectX-9超级网卡和NVIDIA BlueField-4数据处理器（DPU）取代了GB200 NVL72参考设计中的NVIDIA ConnectX-7网卡和NVIDIA BlueField-3 DPU。DOCA 3.3.0是首个支持ConnectX-9的正式发布版本。经过验证的Vera Rubin系统镜像搭载的是DOCA-OFED 3.3.0，这是测试平台所使用的版本，并非强制要求或推荐配置。AICR在这里使用主机安装的网卡驱动和DRANET进行pod分配。Network Operator的兼容性仍是一个独立的验证环节（详见DOCA 3.3.0发布说明）。
设备拓扑：Vera Rubin NVL72计算托盘的网卡/GPU/直接内存访问（DMA）拓扑与GB200不同，因此对于RDMA网络和GPUDirect存储等I/O密集型工作负载，必须检查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配方采用整卡分配方式，不配置MIG。本次验证不涉及Vera Rubin上的MIG功能。
AICR配方：以上所有变化都已编码在全新的Vera Rubin配方系列中，因此aicr recipe和aicr validate反映的是经过验证的组合方案，无需用户逐一重新摸索每项变化（详细内容见下文）。
Vera Rubin NVL72上的验证工作
为了端到端验证对Vera Rubin NVL72的支持，我们在Vera Rubin集群上部署了AICR运行时软件包，使用的是官方GPU Operator v26.7.0版本和官方DRA驱动v0.5.0版本，配合主机安装的R615驱动。
训练和推理两种配方变体目前均已通过端到端的部署与一致性验证。对于训练场景，设置了一个初始性能门槛：通过IMEX ComputeDomain、跨节点经由NVIDIA NVLink结构运行的NCCL全归约（all-reduce）操作，并以总线带宽下限作为通过标准。GPU pod运行顺畅，IMEX通道被成功注入跨多个节点的声明pod中，下文将展示实际集群输出结果。
关于早期芯片现实情况的说明：新芯片的上线调试是一个持续过程。在最初几轮验证中，其中一个早期Vera Rubin集群曾因硬件/网络结构问题而暂时受阻——该问题与GPU Operator或DRA驱动无关——导致一个计算托盘无法接入NVLink网络。重新插接硬件后，两个节点上的所有GPU都成功加入了同一个完整的网络结构集群（clique）。
从上线调试到可复现配方
验证各个组件只是工作的一半。要搭建一个可正常运行的Vera Rubin集群，还需要选择驱动模式、容器运行时的连接方式、各组件版本以及一些平台专属设置。AICR将这些选择固化为版本化的配方，使得真实Vera Rubin硬件上的配置变得明确、可复现，并可在各集群间进行验证。
全新的Vera Rubin配方系列（服务：rke2；加速器：Vera Rubin NVL72（vr200）；操作系统：Ubuntu；包含训练、推理和NVIDIA Dynamo推理变体）以预览版形式发布。这是面向早期采用者的方案，由于平台本身尚处于预发布阶段，目前还不具备"受支持"配方所拥有的生产级支持和生命周期管理资质。该配方编码了本次上线调试过程中所做出的各项决策：
主机管理驱动：Vera Rubin系统镜像预装了arm64开源内核模块驱动，因此该配方运行GPU Operator时设置driver.enabled: false，而容器工具包仍由operator进行管理。待官方正式版本发布后，该配方将切换为由operator管理驱动。
搭配ComputeDomain的DRA驱动：针对NVL72网络结构启用了基于IMEX的ComputeDomain，而整卡分配功能仍保留在设备插件（device plugin）中。
平台底线与特殊问题：这些内容只需编码一次，用户便无需重新摸索。Kubernetes版本需 >= 1.34.1——1.34版本是因为ComputeDomain/IMEX所使用的resource.k8s.io/v1 DRA API已进入GA阶段，而.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集群复现了同样的结果，这种可复现性正是该配方的意义与价值所在。
实时Vera Rubin集群上的工作流程
为了具体说明这一点，以下是在搭载AICR v1.0.0工具链的实时Vera Rubin NVL72参考集群上执行的实际AICR工作流程。
1. 生成配方
配方生成是离线进行的：它根据配方目录解析各项标准，整个过程仅需数秒。
（命令行输出显示：根据criteria=criteria(service=rke2, accelerator=vr200, intent=training, os=ubuntu)构建配方，生成文件recipe.yaml，包含14个组件，组件名称包括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，叠加5个overlay。）
解析出的配方将5个overlay整合为14个组件。除了GPU Operator（主机管理驱动模式）和DRA驱动（启用ComputeDomain）之外，还启动了两个与该平台最为相关的组件：DraNet（负责为pod分配ConnectX-9设备的DRA网络驱动，本次验证不涉及ConnectX-9上的RDMA数据通路性能）；以及通过NodeWright调优应用的独占RDMA网络命名空间（netns）模式，确保每个pod只能看到自己的主机通道适配器（HCA）。
AICR还整合了NVIDIA DSX AI Factory平台的多个组件：NodeWright通过其原生的vr200/rke2配置文件应用节点调优，KAI Scheduler提供工作负载调度，NVSentinel负责监控运行时健康状态。节点特征发现（NFD）和Prometheus技术栈则完善了整个配方，各组件版本均锁定为经过Vera Rubin硬件验证的配置。
2. 渲染部署包
部署包是一组按顺序排列、各组件独立的Helm chart，配合一个统一的部署脚本。
3. 快照与验证
AICR会捕获集群的实际状态，依据配方的就绪性约束条件进行检查，然后以集群内任务的形式运行各项验证检查。
部署阶段的验证结果显示：操作系统版本约束通过（期望值26.04，实际值26.04）；内核版本约束通过（期望值>= 7.0，实际值7.0.0-2008-nvidia-bos-64k）；部署阶段共4项验证全部通过。一致性阶段共8项验证全部通过。性能阶段共1项验证通过。
性能阶段以集群内任务的形式运行NVIDIA集合通信库（NCCL）全归约门槛测试：通过IMEX ComputeDomain、跨节点经由NVLink网络结构进行全归约，并依据配方设定的总线带宽下限进行检查。rke2/vr200这一组合已在验证器的适用性矩阵中注册，其运行时以内嵌模板形式提供，因此验证器会自行配置ComputeDomain和IMEX ResourceClaimTemplate——无需operator前置条件，也无需配方提供运行时。该测试基于标准的v1.0.0版本运行。
整个验证矩阵现已全部通过。
推理变体（Dynamo平台、推理网关、团伙调度、DCGM指标）在同一集群上也通过了相同的部署和一致性验证矩阵。
这次运行中有两项结果值得展示。首先，预发布驱动上的nvidia-smi显示信息，正是首次接触时让验证器出错的确切原因，这很好地说明了早期芯片会带来的各种小意外。该修复（NVIDIA/aicr#1748）已合并，并在NVIDIA Vera Rubin硬件上验证通过。
（nvidia-smi输出显示：NVIDIA-SMI 615.23，KMD版本615.23，CUDA UMD版本13.4）
其次，实时GPU遥测数据通过标准DCGM导出器路径正常流转。需要注意其中的产品名称占位符，这将在PCI ID分配完成、正式发布临近时得到解决（DCGM指标显示：GPU型号为"NVIDIA Graphics Device"，驱动版本为615.23，SM时钟频率为120）。
4. 跨节点ComputeDomain测试
最后是端到端的DRA/IMEX路径测试：一个双节点ComputeDomain，其IMEX通道被每个计算托盘上的pod分别声明占用。对于采用主机管理IMEX的镜像，有一个前置条件：必须禁用并屏蔽主机上静态的nvidia-imex服务，因为主机管理的IMEX与DRA管理的ComputeDomain是互斥的（DRA驱动v0.5.0新增了主机管理选项）。
针对GPU Operator v26.7.0+的提示：该chart自带一份更为严格的resource.nvidia.com_computedomains.yaml自定义资源定义（CRD）副本，要求必须设置numNodes且无默认值（而DRA驱动chart自带的副本则没有此要求）。这一点仅在全新集群安装时才会产生影响——Helm不会覆盖已安装的CRD，因此现有集群升级gpu-operator时不受影响。如果你正在搭建新集群，需要在ComputeDomain清单中明确设置numNodes，例如spec: {numNodes: 2, …}。
（命令行输出显示：ComputeDomain cd-2node-test创建成功，pod cd-test-c01和cd-test-c02创建成功；查询结果显示ComputeDomain状态为Ready，涉及两个节点；两个ResourceClaim均为allocated,reserved状态；两个pod均为1/1 Running状态，分别运行在两个节点上；日志显示两个节点上均正确识别到IMEX通道设备文件/dev/nvidia-caps-imex-channels。）
从执行apply命令到两个pod成功运行——每个计算托盘各一个，各自注入了IMEX通道，且IMEX守护进程加入了同一个域——整个过程大约耗时12秒。训练配方的NCCL性能门槛测试正是在真实工作负载流量下驱动着同样的ComputeDomain路径：上文已证明了通道注入的有效性，而网络结构带宽则在性能阶段得到了验证。
整个流程（配方生成、打包、快照、部署与一致性验证阶段）在真实集群上大约5分钟内即可完成。性能阶段则需额外加上NCCL任务本身的运行时间。
验证证据与反馈闭环
这些结果以AICR在NVL72参考环境中进行的部署、一致性和性能验证为支撑，并配合成功的端到端ComputeDomain测试。各项具体检查的详情已记录在上文的验证矩阵中。
同样重要的是，目前已验证的边界所在。训练配方现已包含跨节点NCCL性能门槛测试：这是在Vera Rubin芯片上进行的首次性能验证，在真实全归约流量下验证了上文展示的同一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，该版本本身就早于相关代码的加入；其尚未发布的主分支锁定的是v0.28.0，但该版本同样未基于CUDA 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配方已在开源的NVIDIA/aicr代码库v1.0.0版本中发布，该版本已在公共目录中注册了rke2服务和vr200加速器。
开始使用
通过AICR公共目录中的预览版配方，即可开始在Vera Rubin上使用AICR。
生成经过验证的配置只需一条命令：
aicr recipe --service rke2 --accelerator vr200 --os ubuntu --intent training
对于上文介绍的Dynamo推理变体，可使用以下命令生成配方：
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
