GPU集群通过所有健康检查后，仍可能无法运行AI工作负载。即使每块GPU、每条网络链路和每个Pod都报告健康状态，一个512-GPU训练任务仍可能表现不佳或直接失败。原因可能是某块GPU运行缓慢、某条链路在负载下性能下降，或某项配置悄悄将流量导向了较慢的路径。运维人员可能要等到运行数小时后才发现问题，或者直到客户提交工单才察觉。此后团队可能要花费数天时间在集群中逐一排查，才能找到根本原因，而这段时间宝贵的算力资源却处于闲置状态。
NVIDIA集群就绪引擎（NVCRE）是一款开源的Kubernetes控制器，它能在生产工作负载正式上线前，将排查范围缩小到具体涉及的节点。该引擎会在具备拓扑感知能力的节点组上运行真实的分布式工作负载，测量结果并报告每项测试中失败的节点。运维人员不再需要手动编写NVIDIA集合通信库（NCCL）配置清单、手动排查机架问题，也不必等到客户工单才得知硬件存在性能下降。集群的就绪状态由此从一种假设变成了一项可验证的属性。
证明就绪状态需要什么
GPU集群的就绪过程分为多个阶段，依次经历初始部署、老化测试、预生产和生产阶段，每个阶段设定的标准都不同。一个通过冒烟测试的节点，未必就已经具备加入512-GPU训练任务的条件。
平台团队通常会将这一流程固化为运行手册、电子表格，或围绕NCCL测试编写的shell脚本。这就成了他们需要与节点配置、GPU共享和工作负载编排一起构建和维护的另一套系统。
集群可能通过标准诊断测试却仍在真实分布式任务中失败，因此验证就绪状态的最佳方式是直接运行一个工作负载。在Slurm上，这只需一条srun命令即可完成。而Kubernetes没有内置的等效方案，同样的测试需要GPU和远程直接内存访问（RDMA）资源请求、与网络架构匹配的NCCL设置、足够大的共享内存卷，以及确保所有Pod同时启动的机制。
NVCRE填补了Kubernetes上的这些空白。它运行的工作负载能够暴露真实的硬件问题，并精确指出是哪个节点导致了每次失败。
NVCRE的工作原理
API是这款产品的核心界面。自定义资源定义（CRD）定义了每种资源，因此可以用kubectl进行检查，并通过GitOps工作流进行管理。
分层API架构
该API包含三种按层级排列的资源。
认证（Certification）：用户创建的资源，指定要测试的节点和要运行的类别。
工作流（Workflow）：管理一个类别，应用目录、平台和GPU层面的覆盖设置，管理迭代次数，设定编排目标，并创建子任务。
任务（Job）：为目标节点组运行工作负载，监控节点健康状况，记录测量结果和故障信息。
一次认证会为每个类别创建一个工作流，每个工作流再创建其对应的子任务。
结果随后向上传递：任务记录哪些节点失败及原因，工作流报告测试结果，认证按类别汇总结果。
这种层级结构能将每次故障精确归因到具体的节点和类别。例如，一次运行可能报告gpu-01在NCCL测试中出现硬件故障，而gpu-02未达到带宽目标。
集群验证示例
下面的示例展示了一次认证如何指定目标节点和要运行的测试类别。配置文件中定义了目标节点选择器（选取所有具备GPU的节点）以及要运行的测试类别，包括NCCL全归约通信测试和Nemotron5-8b训练测试。
内置目录目前涵盖三个领域：五种NCCL通信变体（全归约、全收集、全对全、环回，以及跨NVIDIA NVSwitch环回）、NVIDIA数据中心GPU管理器（DCGM）四级诊断套件，以及使用80亿和560亿参数的NVIDIA Nemotron 5模型进行NVIDIA NeMo预训练。每个条目都包含平台感知的默认设置。
NVCRE会自动从目标节点检测GPU架构和云平台，并据此推导出其余配置，包括每节点GPU数量、NCCL环境和特定平台的网络设置。
以表达式定义通过标准
通过与失败的判定标准采用通用表达式语言（CEL），并根据实测指标进行评估。系统默认不附带任何阈值，以下数值仅为针对NVIDIA GB200 NVL72级别系统的示例。
当某项实测指标未达到目标时，NVCRE会设置一个"验证失败"状态，该状态与运行本身是否成功是分开记录的。也就是说，一个成功完成但未达标的工作负载仍会被报告为失败。
在故障出现的规模上进行测试
某些故障只有在特定规模下才会显现，因此分组策略是明确指定的。testScale字段用于选择分组策略。
节点内测试：独立测试每个节点。
机架内测试：使用nvidia.com/gpu.clique标签按拓扑域对节点分组。
全规模测试：将所有节点纳入单一组。
诊断模式：运行自适应故障隔离（详见下文）。
所选策略决定了测量的内容。在一个NVIDIA NVLink域内进行的NCCL测试测量的是NVLink带宽，而跨三个机架进行的同一测试测量的则是横向扩展网络架构。二者测量的是不同的对象。
自适应故障隔离
多节点验证中最棘手的情形是无法将故障归因到任何单一节点的情况。例如，一次64节点的全归约测试返回了低带宽结果，而组内每个节点都同样可疑。若靠人工排查原因，可能需要花费数天的工程时间。
NVCRE可以自动完成这项隔离工作。设置testScale: diagnose会启动具备拓扑感知能力的分层分组测试。该引擎会拆分每个出现故障的组，对拆分后的两半重新测试，并持续这一过程，直到达到minGroupSize设定的最小分组规模。在该规模下仍然失败的分组会被标记为可疑对象。maxConcurrent参数则限制同时运行的任务数量，避免测试本身占满被测网络架构的带宽。
最终输出会精确列出少数几个可疑节点，而非笼统地指向整个测试组，并给出每个节点失败的具体原因。
运行任意工作负载：WorkloadRun API
在Kubernetes上运行多节点GPU工作负载，需要平台检测、特定框架的运行时配置、GPU和网络资源请求，以及运行失败后的清理工作。这套配置流程繁琐且容易出错。
WorkloadRun资源负责处理这些配置工作：用户只需提供容器镜像、选择框架并指定节点数量即可。
framework字段支持三种选项之一：torch（通过torchrun进行分布式训练）、mpi（NCCL测试及其他MPI工作负载）或exec（任意命令）。NVCRE会自动生成匹配的Kubeflow TrainingRuntime，注入共享内存卷，设置NCCL和平台相关的环境变量，并在硬件支持的情况下启用NVIDIA NVLink横向扩展网络。
如果没有组调度器，默认的Kubernetes调度器会独立放置各个Pod，而各个计算单元（rank）会在框架的集合点等待其他节点就绪。在繁忙的集群上，这可能导致死锁：部分已放置的Pod占用着GPU，却在等待永远不会到来的其他节点。设置spec.gangScheduler可以让每个工作负载Pod都采用组感知调度器（例如KAI Scheduler），该调度器会保持所有Pod处于等待状态，直到整个组能够被一次性完整放置。
由于WorkloadRun是一个普通的CRD，外部工具可以直接使用它来运行工作负载，而无需采用NVCRE的其余部分。NVCRE提供执行路径，调用工具则提供具体的测试内容。
大规模配置、验证与监控AI集群
一个集群在迈向生产环境的过程中必须回答三个问题：配置是否正确？是否已准备好运行真实的AI工作负载？当前是否健康？NVIDIA DSX OS的不同层级分别解决这三个问题。
NVIDIA AI集群运行时（AICR）负责建立并维护经过验证的集群配置。AICR将驱动程序、算子、内核和系统设置的已验证组合捕获为版本锁定的配置方案。团队可以跨集群复现同样经过优化的配置，验证实际运行状态，并检测配置漂移。这能减少性能波动，避免让昂贵的GPU在数天的调优过程中闲置。
NVCRE负责验证集群是否已准备好运行真实的AI工作负载。作为主动的、由工作负载驱动的层级，它会产生实际负载，因此能够发现那些不会产生任何遥测数据的故障。单块性能下降的GPU会将同步训练任务拖慢到其最差计算单元的速度，而NCCL带宽测试能在数分钟内识别出这一问题。
NVIDIA NVSentinel则持续监控集群健康状况。作为被动的、由遥测数据驱动的层级，它监视集群本身已经产生的各类信号，包括DCGM指标、Xid错误、系统日志和云服务商的维护事件。它能检测运行时故障，并可驱动隔离、排空和修复工作流。由于它不消耗任何GPU时间，因此可以在生产环境中持续运行，而主动测试在生产环境中运行则会占用本应用于工作负载的GPU资源。
这三个项目各自独立提供价值，同时也能相互集成，供运行完整技术栈的团队使用。
NVCRE只负责记录故障节点及其原因，并不会对节点执行隔离、打标记或修改节点状态等操作，从而避免了操作冲突和清理不同步的问题。NVSentinel的NVCRE认证监控器可以将失败的认证结果转化为健康事件，随后配置好的NVSentinel策略便可以隔离并排空相关节点，或触发外部修复流程。后续一次成功的认证则可以清除故障信号并解除相应的隔离标记。
开始使用
NVCRE需要Kubernetes 1.29或更高版本、kubectl、Helm 3.x，以及目标集群上已安装的NVIDIA GPU Operator。NVIDIA GB200 NVL72和NVIDIA GB300 NVL72的目录条目还需要NVIDIA GPU动态资源分配（DRA）驱动，因为这些条目会创建ComputeDomain资源。DCGM四级测试类别则需要独立部署的DCGM服务。组感知调度器（如KAI Scheduler）虽为可选项，但在繁忙的共享集群上建议启用。
安装命令行工具并设置集群后，即可执行端到端验证，生成的报告会列出每个测试类别的状态、运行时长、实测带宽以及任何故障节点，并说明每次故障的原因。
参与项目
NVCRE基于Apache 2.0协议开源，并采用公开开发模式。用户可以在GitHub上报告漏洞、提交功能请求或在发起拉取请求前提出修改建议，也可以贡献目录条目、工作负载适配器、测试用例和文档。
该引擎可用于在生产环境上线前验证GPU集群，其共享的工作流和测试目录能够在各类Kubernetes集群上保持一致运行，未来路线图还将支持更多NVIDIA新架构、推理场景以及自动化的生命周期验证。
该项目是NVIDIA DSX OS的一部分，而NVIDIA DSX OS正是NVIDIA DSX AI Factory Platform的运行层。
Q&A
Q1：NVIDIA集群就绪引擎（NVCRE）是什么？
A：NVCRE是一款开源的Kubernetes控制器，能在AI工作负载正式上线前验证GPU集群的就绪状态。它通过在拓扑感知的节点组上运行真实的分布式工作负载，测量结果并精确报告哪些节点存在问题，帮助运维人员避免手动排查故障。
Q2：NVCRE如何找出集群中的故障节点？
A：NVCRE采用自适应故障隔离机制，通过分层分组测试，不断拆分出现故障的节点组并重新测试，直到定位到具体的可疑节点，并给出每个节点失败的具体原因，而不是笼统地指向整个测试组。
Q3：使用NVCRE需要满足哪些条件？
A：需要Kubernetes 1.29或更高版本、kubectl、Helm 3.x，以及目标集群上的NVIDIA GPU Operator。如果使用GB200或GB300 NVL72平台，还需要NVIDIA DRA驱动；DCGM四级测试类别需要独立的DCGM服务。
