本文是由AI生成的的技术解析与实现示例。所发布的代码和步骤基于一手信息构建,但作者并未在实际设备上进行运行验证。根据环境和版本的不同,运行结果可能会有所差异。
在大规模AI工作负载运行之前,需要安全且实用地上验证GPU集群的运行就绪状态。本文基于NVIDIA提供的开源Kubernetes控制器“NVIDIA Cluster Readiness Engine (NVCRE)”的官方信息,系统梳理了其工作原理、组成部分以及使用时的注意事项。
NVIDIA Cluster Readiness Engine(NVCRE)的目的
尽管所有GPU、网络链路和Pod都报告正常,但GPU集群在运行大规模分布式训练时仍可能导致意料之外的性能下降或失败。原因可能包括性能老化的单个GPU,或者在负载增加时发生劣化的网络链路等。
NVCRE是一个开源的Kubernetes控制器,它在生产工作负载运行之前,在考虑拓扑结构的节点组上运行实际的分布式工作负载,测量结果并识别测试失败的节点。它减少了操作人员手动创建清单或单独排查机架的繁琐工作,并将集群的“就绪状态”证明为客观事实。
flowchart TD
A[Certification] --> B[Workflow: コミュニケーション / トレーニング]
B --> C[Job: ターゲットノードグループのワークロード実行]
C --> D[結果の集約・特定ノードの障害判定]
D --> E[NVSentinel 連携による隔離・検知]
三层API结构
NVCRE的操作层面是通过由自定义资源定义(CRD)构成的三个分层API来完成的。
Certification: 最高级别的资源,用于指定作为测试对象的节点以及要执行的类别。
Workflow: 管理单个类别。负责应用目录、平台、GPU覆盖配置,管理迭代次数,设置编排目标以及创建子作业。
Job: 针对目标节点组运行工作负载,监控节点的健康状况,并记录测量值和故障。
通过这种分层结构,可以清晰地将失败原因追溯到具体节点的具体类别。
目录与Pass条件表达式评估
内置目录涵盖了三个领域:NCCL通信变体(all-reduce、all-gather、all-to-all、loopback、NVSwitch间loopback)、NVIDIA DCGM 4级诊断套件,以及NVIDIA NeMo预训练(Nemotron 5模型的8B和56B参数)。
通过/失败(Pass / Fail)的判定使用Common Expression Language (CEL),并对测量的指标进行评估。默认情况下不包含阈值。例如,显示了以下配置结构。
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: 执行自适应故障隔离。
多节点验证中最大的挑战是带宽下降等并非由单个节点引起的故障,但是testScale: diagnose 配置后,将执行具备拓扑感知能力的分层组测试。引擎会分割失败的组,并重复重新运行直至达到最小组大小(minGroupSize),从而精确定位少数可疑节点,而不是整个影响范围。
通过 WorkloadRun API 实现灵活执行
为了减轻在 Kubernetes 上运行多节点 GPU 工作负载时的配置负担,WorkloadRun 提供了相关 API。
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、mpi、exec 其中的任意一项。此外,为防止繁忙集群中出现死锁,建议使用协同感知调度程序(如 KAI Scheduler)。
在 NVIDIA DSX OS 生态系统中的定位
NVCRE 是构成 NVIDIA DSX OS 运维层的要素之一,并与其他组件协同工作。
NVIDIA AI Cluster Runtime (AICR):通过固定驱动程序、运算符、内核和系统设置等版本的配置方案,维护经过验证的集群配置。
NVIDIA Cluster Readiness Engine (NVCRE):实际生成负载,主动验证遥测数据中无法显示的故障。
NVSentinel: 被动监控 DCGM 指标和 Xid 错误等,并持续跟踪健康状态。
NVCRE 本身的设计不执行节点的隔离(Cordon)或污点(Taint)添加,但可以通过 NVSentinel NVCRE Certification Monitor 将失败的验证结果转化为健康事件,从而触发隔离或排空工作负载。
前提条件与使用注意事项
官方信息中的前提条件和注意事项如下。
环境要求:需要 Kubernetes 1.29 或更高版本、
kubectlHelm 3.x,以及目标集群上的 NVIDIA GPU Operator。特定硬件要求:NVIDIA GB200 NVL72 和 GB300 NVL72 的目录条目需要 NVIDIA DRA Driver for GPUs 才能创建 ComputeDomain 资源。
DCGM 要求:DCGM 4 级类别需要独立的 DCGM 服务。
实机验证注意事项:本文介绍的配置和命令是基于一手信息的说明,属于【实机验证前】的调研信息。实际部署时取决于目标环境的版本和网络配置,请参考官方文档。
总结
本文基于《在 AI 工作负载落地前验证 GPU 集群就绪情况》的一手信息,梳理了 NVCRE 的概述、API 层次结构、基于 CEL 的评估表达式、测试规模、WorkloadRun API 以及生态系统的角色。
执行前需要确认的要点和限制事项如下。
确认集群的 Kubernetes 版本、GPU Operator 以及根据需要引入专用驱动程序的情况。
考虑活跃的负载测试对投产前集群性能和网络结构可能产生的影响。
设计与 NVSentinel 等工具的集成策略,以接收故障节点的识别结果。
参考信息
本文的更新历史
本文通过利用生成式 AI 的自动审查与更新流程进行了内容审查,并反映了必要的修正。
2026年9月26日
- 变更将总结部分开头以顿号开始的不自然表述修改为了“本文根据《Validate GPU Cluster Readiness Before AI Workloads Land》的一手信息”。

