Vera Rubin接入Kubernetes：4处旧配置别照抄

三分钟热度 技术创作者 2026-11-04 78 阅读

2026年11月2日，NVIDIA技术博客发布Vera Rubin NVL72的Kubernetes验证结果：GPU Operator v26.7.0与动态资源分配（DRA）驱动v0.5.0已通过部署、一致性和跨节点通信测试。现在值得看，不只是因为新GPU即将进入集群，而是平台团队可以借这套公开配置，提前找出驱动、内核、网络和调度之间的不匹配，避免硬件到货后现场排障。

下文凡标注“按官方口径推算”的内容，都是基于官方给出的版本和测试结果得出的判断，并非官方结论；其余硬件与软件信息均来自对应的一手材料。

“首日就绪”不是装好驱动就行

AI Cluster Runtime（AICR，AI集群运行时）可以理解为一套配置配方生成与验证工具：它把经过调校的驱动、内核、网络和调度设置封装成可复用配方，生成部署包，再检查运行中的集群是否符合预期。它是NVIDIA DSX AI Factory Platform的一部分，目标不是替代Kubernetes，而是把新GPU进入Kubernetes时最容易断裂的各层连接起来。

传统做法通常是平台团队自行整理安装步骤，再逐项测试；AICR的做法则是先生成配方、部署组件、执行验证，并保存可复核的证据。官方博客提供了训练与推理两类配方入口，其中训练配方明确采用GPU Operator的主机托管驱动模式，以及启用了ComputeDomains的DRA驱动。

不过，“首日就绪”有明确边界：这是面向Vera Rubin NVL72计算托盘的参考验证，不等于所有Vera Rubin服务器、所有Kubernetes发行版或所有推理模型都已获得同等支持。NVIDIA也明确称Vera Rubin仍处于早期阶段。

从GB200迁移：4处不能照抄旧配置

第一处是驱动基线。Vera Rubin NVL72需要新的驱动分支，当前验证版本是R615.23；早期支持目标是R610，正式平台支持计划落在R620。AICR的GB200基线则是R580.173.02。R615.23只是本次测试所用版本，不是官方确认的最低支持版本，因此不能据此自行降低生产环境的版本要求。

第二处是网卡与数据处理单元。Vera Rubin NVL72从GB200参考设计中的ConnectX-7网卡和BlueField-3 DPU，切换到ConnectX-9 SuperNIC与BlueField-4 DPU。ConnectX-9首个正式支持的DOCA版本为3.3.0，但官方强调，验证镜像里的3.3.0只是测试床版本，不应直接当成通用要求。

第三处是设备拓扑。两个参考计算托盘都包含两颗CPU和四块GPU，但Vera Rubin托盘暴露八组ConnectX-9 PCI设备、共32个功能，而GB200托盘是四个ConnectX-7适配器。PCI功能数不等于物理端口数。对于RDMA网络和GPUDirect Storage这类I/O密集型任务，必须重新检查GPU到网卡的亲和性及NUMA放置，不能沿用GB200的假设。

第四处是资源管理模式。DRA是一种Kubernetes资源分配机制，让调度器按设备能力与拓扑分配GPU及网络设备。Rubin上的DRA管理IMEX时，需要停止、禁用并屏蔽主机原有的静态nvidia-imex服务，以免产生所有权冲突；本次验证使用driverManaged模式。

配置层 GB200基线 Vera Rubin已验证状态 平台团队动作
GPU驱动 R580.173.02 R615.23测试版本 不把测试版本误当最低版本
网卡与DPU ConnectX-7、BlueField-3 ConnectX-9、BlueField-4 重查亲和性、NUMA和驱动兼容性
GPU分配 既有DRA路径 ComputeDomains已启用 检查插件与调度器版本
IMEX 静态主机服务 DRA管理的driverManaged模式 禁用静态服务，避免所有权冲突

配方生成只是起点，验证结果才决定能否上线

官方给出的训练配方生成命令如下。它展示的是配置入口，不应被理解为对任意集群执行后都能得到相同性能：

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

这条命令会按服务类型、加速器、操作系统和训练意图解析配方，并把结果输出为recipe.yaml。官方工作流最终在Vera Rubin NVL72参考集群上使用AICR v1.0.0，生成包含14个组件并叠加5层覆盖配置的部署方案。

验证不止检查Pod能否启动。官方报告还覆盖Kubernetes一致性检查，以及跨节点NCCL all-reduce性能门槛。all-reduce是分布式训练中汇总并同步梯度的常见通信操作；NCCL则是NVIDIA面向多GPU通信的库。官方给出的结果是，在16 GiB消息大小下，NVLink互连达到744.71 GB/s总线带宽。

这个数字能证明参考配置通过了通信性能门槛，但不能直接外推到用户集群。不同消息尺寸、拓扑、网络隔离方式、容器运行时和业务进程都会影响结果。按官方口径推算，若只复刻配方而缺少对应硬件与软件组合，得到相同数字并不现实。

一个真实故障揭示：兼容不是“版本号够新”

早期硬件验证中，go-nvlib里有一个尚未映射的Rubin架构值，导致DRA驱动的kubelet插件进入崩溃重启循环。修复随后贯穿相关软件栈，并进入正式发布的DRA驱动v0.5.0。

这个案例说明，新GPU支持不是简单更新一个驱动版本。底层设备信息变更可能先破坏编排层插件，而Kubernetes调度器仍可能接收资源请求，实际设备却无法稳定初始化。go-nvlib仓库后续提交可帮助用户判断相关问题是否已经进入上游代码。

此外，Rubin GPU还引入了新的MIG配置。MIG是NVIDIA把一块物理GPU划分为多个独立实例的机制，可为不同工作负载提供隔离。不过，本次AICR配方采用整块GPU分配，没有配置MIG，官方也明确表示Rubin上的MIG不在此次验证范围内。因此，验证通过不代表共享实例场景已获覆盖。

性能门槛已过，推理链仍需单独确认

训练侧的部署、一致性和跨节点通信结果已经公开，但推理侧不能据此直接宣布完成。官方后续步骤是在Dynamo平台标志下生成推理配方；中文社区对官方文章的整理称，推理性能验证仍需等待CUDA 13.4镜像发布后推进。这属于二手报道，应回到实际集群中重新验证，不能把训练通信成绩当作推理性能结论。

对普通AI技术用户而言，真正有用的不是记住一串版本号，而是看懂升级顺序：先核对驱动与内核，再检查ConnectX-9、DOCA及PCI拓扑，然后确认DRA、GPU Operator、IMEX和调度器能够协同运行，最后分别执行训练与推理测试。任一环节沿用GB200经验，都可能把兼容问题推迟到业务上线之后。

参考来源与核验入口

# AI# 知识

评论区

0 条评论

登录后可评论。

三分钟热度 78 阅读