NVIDIA 开源 NVCRE：在生产负载落地前验证 GPU 集群就绪性

一个 GPU 集群可以通过所有健康检查，却依然跑不动 AI 工作负载。即便每块 GPU、每条网络链路和每个 pod 都报告健康，一个 512 卡的训练任务仍可能性能不佳甚至失败。原因可能是某一块慢 GPU、某条在负载下性能退化的链路，或是悄悄把流量路由到较慢路径上的某项配置。运维人员可能要到任务跑了几个小时之后，或客户提交工单时，才会发现问题。团队随后可能要花上几天时间对集群做二分排查来定位根因，而这段时间里算力就这样闲置着。

NVIDIA Cluster Readiness Engine（NVCRE）是一个开源的 Kubernetes 控制器，能在生产负载落地之前，把排查范围缩小到涉事的具体节点。它在按拓扑划分的节点组上运行真实的分布式工作负载，度量结果，并报告每项测试中哪些节点失败。运维人员不用再手写 NVIDIA Collective Communications Library（NCCL）清单，不用手动对机架做二分排查，也不用再从客户工单里才得知硬件出现退化。就绪性成为集群一项经过验证的属性，而不再只是一种假设。

证明就绪性需要什么？

GPU 集群是分阶段达到就绪的。它要依次经历上线调试、老化测试、预生产和生产，每个阶段设定的门槛各不相同。一个节点通过了冒烟测试，并不一定就能加入 512 卡的训练任务。

平台团队常常把这套递进过程写进运维手册、电子表格，或是围绕 NCCL 测试写的 shell 脚本里。这就成了他们除节点配置、GPU 共享和工作负载编排之外，还得另行构建和维护的又一套系统。

集群可能通过标准诊断，却在真实的分布式任务下失败，所以测试就绪性的最佳方式就是运行一个工作负载。在 Slurm 上，这只需要一条 srun 命令。Kubernetes 没有内置的等价功能，因此同样的测试需要声明 GPU 和远程直接内存访问（RDMA）资源请求，配置与网络架构相匹配的 NCCL 设置，提供足够大的共享内存卷，还要有办法确保所有 pod 同时启动。

NVCRE 在 Kubernetes 上补上了这些缺口。它运行能暴露真实硬件问题的工作负载，并准确指出是哪个节点导致了每一次失败。

communication/nccl-all-reduce
Status:       Failed
Runtime:      42m 18s
Scale:        full-scale
Nodes/Job:    8

Failed Nodes:
  gpu-node-07  ThresholdViolation
  gpu-node-12  HardwareFailureDetected

Summary
Categories:   1/2 passed
Failed Nodes: 2
Result:       FAILED

NVCRE 的工作原理

API 就是产品的对外界面。每种资源都由自定义资源定义（CRD）来定义，因此你可以用 kubectl 查看它，并通过 GitOps 工作流来管理它。

分层的 API

该 API 有三种资源，按层级结构排列。

• Certification：由你创建的资源。它指定要测试的节点和要运行的类别。
• Workflow：管理一个类别。它应用目录、平台和 GPU 的覆盖配置，管理迭代次数，设定编排目标，并创建子 Job。
• 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 Data Center GPU Manager（DCGM）四级诊断套件，以及使用 8B 和 56B 参数 NVIDIA Nemotron 5 模型的 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 限制同时运行的 Job 数量，以免它们占满正在被测量的网络架构。

输出会指出少数几个嫌疑节点，而不是把整个组都牵连进来，并给出每个节点失败的原因。

运行任意工作负载：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 能够一次性全部放置。

由于 WorkloadRun 只是一个普通的 CRD，外部工具可以用它来运行工作负载，而无需采用 NVCRE 的其余部分。NVCRE 提供执行路径，调用方工具则提供测试内容。

大规模配置、验证和监控 AI 集群

集群在迈向生产的途中必须回答三个问题：配置是否正确？是否已准备好运行真实的 AI 工作负载？此刻是否健康？NVIDIA DSX OS 的不同层分别解决其中一个问题。

NVIDIA AI Cluster Runtime（AICR）负责建立并维护经过验证的集群配置。AICR 把经过验证的驱动、Operator、内核和系统设置的组合，记录为版本锁定的配方（recipe）。团队可以在多个集群上复现同一套优化配置，验证实时状态，并检测配置漂移。这样既能减少性能波动，又能避免昂贵的 GPU 闲置、人工调优耗费数天。

NVCRE 验证集群是否已准备好运行真实的 AI 工作负载。这一层是主动的、由工作负载驱动的，会产生负载，因此能发现不产生任何遥测数据的故障。单块性能退化的 GPU 就会把同步训练任务拖慢到最差 rank 的速度，而一次 NCCL 带宽测试几分钟内就能找出问题。

NVIDIA NVSentinel 持续监控集群健康状况。作为被动的、由遥测驱动的一层，它观察集群本来就会产生的信号，包括 DCGM 指标、Xid 错误、系统日志和云服务商的维护事件。它能检测运行时故障，并可驱动隔离、排空和修复工作流。由于不占用 GPU 时间，它可以在生产环境中持续运行，而主动测试在那里会把 GPU 从工作负载手中抢走。

各个项目各自独立地创造价值，对于运行完整技术栈的团队，它们之间也能相互集成。

NVCRE 会记录故障节点及原因。它不会对节点执行 cordon、添加污点（taint）或修改节点状态条件，从而避免相互冲突的操作和清理不同步。NVSentinel NVCRE Certification Monitor 可以把失败的 Certification 结果转换为健康事件。已配置的 NVSentinel 策略随后可以隔离并排空节点，或触发外部修复。之后一次成功的 Certification 可以清除故障信号并解除污点。

快速上手

NVCRE 要求目标集群具备 Kubernetes 1.29 或更高版本、kubectl、Helm 3.x 和 NVIDIA GPU Operator。NVIDIA GB200 NVL72 和 NVIDIA GB300 NVL72 的目录条目还需要 NVIDIA DRA Driver for GPUs，因为这些条目会创建 ComputeDomain 资源。DCGM 四级类别需要独立的 DCGM 服务。KAI Scheduler 这类支持 gang 的调度器是可选的，但在繁忙的共享集群上建议使用。

安装 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>

下面的报告列出了每个类别的状态、运行时间、测得的带宽以及所有失败的节点，并附上每次失败的原因。

Certification Report

Name:     gpu-cluster-cert
Platform: aws
GPU:      gb300
Nodes:    16

communication/nccl-all-reduce
Status:       Succeeded
Runtime:      3m 56s
Scale:        full-scale
Nodes/Job:    16
MNNVL:        Enabled

Bandwidth:
  Size       AlgBW        BusBW        Samples
  16 GB      473.44 GB/s  932.09 GB/s  9

Summary
Categories:   1/1 passed
Failed Nodes: none
Result:       PASSED

参与进来

NVCRE 采用 Apache 2.0 许可，并公开开发。在提交 pull request 之前，你可以在 GitHub 上报告 bug、提出功能请求或提议修改。你也可以贡献目录条目、工作负载适配器、测试和文档。

在投入生产之前，用该引擎来验证 GPU 集群。它共享的工作流和测试目录可在各个 Kubernetes 集群上一致地运行，路线图中还计划支持新的 NVIDIA 架构、推理以及自动化的生命周期验证。

• GitHub 仓库
• 文档

在下一个生产工作负载落地之前，先验证你的 GPU 集群。

该项目属于 NVIDIA DSX OS，即 NVIDIA DSX AI Factory Platform 的运行层。