一个 GPU 集群可能通过所有健康检查，却仍然无法运行 AI 工作负载。即使每个 GPU、网络链路和 Pod 都报告健康，一个 512-GPU 的训练作业仍可能性能不达标或失败。原因可能是一个缓慢的 GPU、一条在负载下性能下降的链路，或者一个悄悄将流量路由到较慢路径的配置。运维人员可能直到运行数小时后，或直到客户提交工单时才发现问题。随后，团队可能花费数天对集群进行二分排查以找到根本原因，而容量却一直闲置。
NVIDIA Cluster Readiness Engine (NVCRE) 是一个开源 Kubernetes 控制器，可在生产工作负载落地之前将搜索范围缩小到涉及的特定节点。它在拓扑感知的节点组上运行真实的分布式工作负载，测量结果，并报告哪些节点未通过每项测试。运维人员不再需要手写 NVIDIA Collective Communications Library (NCCL) 清单、手动对机架进行二分排查，或从客户工单中得知硬件性能下降。就绪性成为集群经过验证的属性，而非假设。
证明就绪性需要什么
GPU 集群分阶段达到就绪状态。它经历启动、烧机、预生产和生产阶段，每个阶段设定不同的标准。通过冒烟测试的节点不一定准备好加入 512-GPU 训练运行。
平台团队通常将这一进程编码在运行手册、电子表格或围绕 NCCL 测试的 shell 脚本中。这成为他们必须在节点配置、GPU 共享和工作负载编排之外构建和维护的另一个系统。
集群可以通过标准诊断，却仍然在真实的分布式作业下失败，因此测试就绪性的最佳方式是运行工作负载。在 Slurm 上，这需要一条 srun
命令。Kubernetes 没有内置的等效功能，因此同样的测试需要 GPU 和远程直接内存访问 (RDMA) 资源请求、与网络结构匹配的 NCCL 设置、足够大的共享内存卷，以及确保所有 Pod 一起启动的方法。
NVCRE 在 Kubernetes 上填补了这些空白。它运行能够暴露真实硬件问题的工作负载，并准确指出每个故障是由哪个节点引起的。
communication/nccl-all-reduce
状态：失败
运行时长：42分18秒
规模：全规模
节点/作业：8
失败节点：
gpu-node-07 阈值违规
gpu-node-12 检测到硬件故障
摘要
类别：1/2 通过
失败节点：2
结果：失败
NVCRE 的工作原理
API 就是产品界面。自定义资源定义（CRD）定义了每种资源，因此你可以用 kubectl 检查它
并通过 GitOps 工作流管理它。
分层 API
该 API 有三种按层级排列的资源。
Certification：你创建的资源。它指定要测试的节点以及要运行的类别。Workflow：管理一个类别。它应用目录、平台和 GPU 覆盖；管理迭代次数；设置编排目标；并创建子作业。Job：为目标节点组运行工作负载，监控节点健康状况，并记录测量结果和故障。
一个 certification 会为每个类别创建一个 workflow，而每个 workflow 会创建其子 job。
结果随后向上传播。job 记录哪些节点失败以及原因，workflow 报告测试结果，certification 按类别对结果进行分组。
这种层级结构将每个故障归因到特定节点和类别。例如，一次运行报告 gpu
-01
在 NCCL 期间遇到硬件故障，而 gpu
-02
未达到其带宽目标。
验证集群
以下示例展示了 certification 如何指定其目标和要运行的类别。
apiVersion: nvcre.nvidia.com/v1alpha1
kind: Certification
metadata:
name: gpu-cluster-cert
spec:
target:
nodeSelector:
nvidia.com/gpu.present: "true"
categories:
- domain: communication
variant: nccl-all-reduce
- domain: training
variant: nemotron5-8b
$ kubectl apply -f certification.yaml
$ kubectl get certifications.nvcre.nvidia.com -w
内置目录目前涵盖三个领域：五种 NCCL 通信变体（all-reduce、all-gather、all-to-all、loopback，以及跨 NVIDIA NVSwitch 的 loopback）、NVIDIA 数据中心 GPU 管理器（DCGM）四级诊断套件，以及使用 NVIDIA Nemotron 5 模型（8B 和 56B 参数）进行的 NVIDIA NeMo 预训练。每个条目都包含平台感知的默认值。
NVCRE 会从目标节点检测 GPU 架构和云平台，并推导出其余配置，包括每节点 GPU 数量、NCCL 环境以及平台特定的网络配置。
以表达式表示的通过标准
通过和失败标准使用通用表达式语言（CEL），并针对测量指标进行评估。默认不附带任何阈值。以下数值是面向 NVIDIA GB200 NVL72 级系统的示例说明。
categories:
- domain: communication
variant: nccl-all-reduce
options:
thresholds:
busBandwidthGBps: "value >= 900"
- domain: training
variant: nemotron5-8b
options:
thresholds:
goodputRatio: "value >= 0.9"
avgTFLOPsPerGPU: "value >= 800"
当某项测量指标未达到其目标值时，NVCRE 会设置一个条件，该条件与运行本身是否成功分开记录。一个完成运行但未达到目标值的工作负载仍会被报告为失败。ValidationFailed
在故障显现的规模上进行测试
有些故障只有在特定规模下才会显现，因此分组策略是显式指定的。testScale
字段用于选择策略。
- Intra-node 独立测试每个节点。
- Intra-rack 使用
nvidia.com/gpu.clique
标签按拓扑域对节点进行分区。 - Full-scale 将所有节点放入单个组中。
- Diagnose 运行自适应故障隔离（下一节介绍）。
你选择的策略决定了要测量什么。在一个 NVIDIA NVLink 域内运行的 NCCL 测试测量的是 NVLink 带宽，而同样的测试跨三个机架运行时测量的则是横向扩展网络。两者测量的是不同的东西。
自适应故障隔离
多节点验证中最困难的情况是无法归因于任何单个节点的故障。一个 64 节点的 all-reduce 返回低带宽，组内每个节点都同样有嫌疑。手动隔离原因可能需要耗费数天的工程时间。
NVCRE 将这种隔离自动化。设置 testScale: diagnose
会运行拓扑感知的分层分组测试。引擎会拆分每个失败的组，重新运行拆分后的两半，并持续进行直到达到 minGroupSize
。在该规模下仍然失败的组会被标记为可疑对象。maxConcurrent
限制并发运行的作业数量，以免它们占满正在被测量的网络。
输出会指出少量可疑节点，而不是将整个组都列为嫌疑对象，并给出每个节点失败的原因。
运行任意工作负载：WorkloadRun
API
在 Kubernetes 上运行多节点 GPU 工作负载需要平台检测、特定框架的运行时配置、GPU 和网络资源请求，以及失败运行后的清理。这些设置重复且容易出错。
负责处理这些设置：提供容器镜像、选择框架，并指定节点数量。WorkloadRun
apiVersion: nvcre.nvidia.com/v1alpha1
kind: WorkloadRun
metadata:
name: nccl-all-reduce
spec:
image: nvcr.io/nvidia/pytorch:26.01-py3
framework:
mpi:
binary: /usr/local/bin/all_reduce_perf_mpi
args: ["-b", "8", "-e", "32G", "-f", "2", "-n", "100"]
mpirunPath: /usr/local/mpi/bin/mpirun
numNodes: 4
bandwidthMeasurement:
logProfileRef: nccl-bandwidth
testType: all_reduce
framework
字段仅支持以下三者之一：torch
（通过 torchrun
进行分布式训练）、mpi
（NCCL 测试及其他 MPI 工作负载）或 exec
（任意命令）。NVCRE 会生成匹配的 Kubeflow TrainingRuntime
，注入共享内存卷，设置 NCCL 和平台环境变量，并在硬件支持时启用 NVIDIA NVLink 纵向扩展网络。
如果没有 gang 调度器，默认的 Kubernetes 调度器会独立放置各个 pod，各 rank 会在框架会合点等待其对等节点。在繁忙的集群上，这可能导致死锁：部分已放置的 pod 占用着 GPU，等待永远不会到达的对等节点。设置 spec.gangScheduler
可将每个工作负载 pod 纳入支持 gang 调度的调度器（例如 KAI Scheduler），该调度器会保持所有 pod 等待，直到整个 gang 能够一次性完成放置。
由于
是一个普通的 CRD，外部工具可以使用它来运行工作负载，而无需采用 NVCRE 的其余部分。NVCRE 提供执行路径，调用工具提供测试。WorkloadRun
大规模配置、验证和监控 AI 集群
集群在走向生产的过程中必须回答三个问题：它配置正确吗？它准备好运行真实的 AI 工作负载了吗？它现在健康吗？NVIDIA DSX OS 的不同层分别解决每个问题。
NVIDIA AI Cluster Runtime (AICR) 建立并维护经过验证的集群配置。AICR 将驱动程序、算子、内核和系统设置的经过验证的组合捕获为版本锁定的配方。团队可以在不同集群间复现相同的优化配置，验证实时状态，并检测漂移。这减少了性能差异，避免了在昂贵的 GPU 闲置时耗费数天的调优。
NVCRE 验证集群是否准备好运行真实的 AI 工作负载。这个主动的、由工作负载驱动的层会生成负载，因此能够发现不产生遥测数据的故障。单个性能下降的 GPU 会将同步训练作业拖慢到其最差 rank 的速度，而 NCCL 带宽测试可以在几分钟内识别出问题。
NVIDIA NVSentinel 持续监控集群健康。作为被动的、由遥测数据驱动的层，它监视集群已经产生的信号，包括 DCGM 指标、Xid 错误、系统日志和云提供商维护事件。它检测运行时故障，并可驱动隔离、排空和修复工作流。由于它不消耗 GPU 时间，因此可以在生产环境中持续运行，而主动测试则会占用本应属于工作负载的 GPU。
每个项目都能独立交付价值，并可与其它项目集成，供运行完整技术栈的团队使用。
图 1. NVSentinel 被动接收集群遥测数据，而 NVCRE 主动生成负载以发现不产生遥测数据的故障
NVCRE 记录失败节点及原因。它不会对节点执行 cordon、taint 或修补节点状况，从而避免冲突操作和不同步的清理。NVSentinel NVCRE 认证监控器可以将认证失败结果转换为健康事件。随后，已配置的 NVSentinel 策略可以隔离并驱逐节点，或触发外部修复。之后一次成功的认证可以清除失败信号并解除 taint。
开始使用
NVCRE 需要 Kubernetes 1.29 或更高版本、kubectl
、Helm 3.x，以及目标集群上的 NVIDIA GPU Operator。NVIDIA GB200 NVL72 和 NVIDIA GB300 NVL72 目录条目还需要用于 GPU 的 NVIDIA DRA Driver，因为这些条目会创建 ComputeDomain 资源。DCGM level-4 类别需要独立的 DCGM 服务。诸如 KAI Scheduler 之类的 gang-aware 调度器是可选的，但在繁忙的共享集群上推荐使用。
安装 CLI 并设置集群。nvcrectl setup init
命令会安装 CRD、控制器、Kubeflow Trainer 和默认日志配置文件。
$ curl -fsSL https://github.com/NVIDIA/cluster-readiness-engine/releases/latest/download/installer | bash
$ nvcrectl setup init
然后运行端到端验证。
$ nvcrectl certification run --cert-file certification.yaml --wait
$ nvcrectl certification report gpu-cluster-cert -n <namespace>
以下报告列出了每个类别的状态、运行时间、实测带宽以及任何失败的节点，并附有每次失败的原因。
认证报告
名称：gpu-cluster-cert
平台：aws
GPU：gb300
节点数：16
communication/nccl-all-reduce
状态：成功
运行时长：3分56秒
规模：全规模
节点数/作业：16
MNNVL：已启用
带宽：
大小 算法带宽 总线带宽 样本数
16 GB 473.44 GB/s 932.09 GB/s 9
摘要
类别：1/1 通过
失败节点：无
结果：通过
参与贡献
NVCRE 采用 Apache 2.0 许可证，并以开放方式开发。在 GitHub 上发送拉取请求之前，请先报告缺陷、请求功能或提出变更建议。你也可以贡献目录条目、工作负载适配器、测试和文档。
使用该引擎在生产环境之前验证 GPU 集群。其共享工作流和测试目录可在 Kubernetes 集群中一致运行，并规划支持新的 NVIDIA 架构、推理和自动化生命周期验证。
在下一个生产工作负载上线之前，验证你的 GPU 集群。
该项目是 NVIDIA DSX OS 的一部分，后者是 NVIDIA DSX AI Factory Platform 的操作层。