NVIDIA开源NVCRE：上生产前先在Kubernetes上跑真实分布式负载验证GPU集群
NVIDIA发布开源Kubernetes控制器Cluster Readiness Engine，通过拓扑感知节点组跑真实NCCL、DCGM和NeMo工作负载，报告是哪块节点失败，而不是等 512 卡训练跑几小时后才发现问题。
AI解读：NVIDIA开源了Cluster Readiness Engine（NVCRE），一个跑在Kubernetes上的控制器，用来在生产负载落地前验证GPU集群是否真的能跑分布式AI任务。它针对的是传统健康检查查不出的问题：所有GPU、链路和Pod都报健康，512 卡训练仍可能因为一块慢GPU、一条负载下退化的链路或一条悄悄走慢路的配置而变慢或失败。
它的做法是直接跑真实工作负载，而不是只读遥测。内置目录目前覆盖三个域：五种NCCL通信变体（all-reduce、all-gather、all-to-all、loopback以及跨NVSwitch的loopback）、DCGM四级诊断套件，以及 8B和 56B参数Nemotron 5模型的NeMo预训练。哪块节点失败、为什么失败，会逐节点记录下来。
对平台团队来说，价值在于把“就绪”从假设变成可验证属性。NVCRE用Certification、Workflow、Job三层API组织测试，失败结果会归因到具体节点和类别；诊断模式还能把失败组不断二分，最终只点名少数嫌疑节点，而不是让 64 个节点一起背锅。
它不负责配置管理，也不主动隔离节点。配置层由AICR负责，被动监控由NVSentinel负责，NVCRE只记录失败节点和原因，不cordon、不taint、不改节点条件，避免和清理流程冲突；NVSentinel的认证监控可把失败结果转成健康事件再触发隔离。
NVCRE采用Apache 2.0许可，要求Kubernetes 1.29以上、kubectl、Helm 3.x和目标集群上的NVIDIA GPU Operator。GB200 NVL72和GB300 NVL72目录项还需要NVIDIA DRA Driver for GPUs，DCGM四级类别需要独立DCGM服务。KAI Scheduler之类gang调度器可选，但在繁忙共享集群上建议启用。
NVIDIA发布了开源Kubernetes控制器Cluster Readiness Engine（NVCRE），用来在生产AI负载落地前验证GPU集群是否真正就绪。NVIDIA技术博客称，集群可能通过所有健康检查仍无法跑好AI负载：即使每块GPU、每条网络链路和每个Pod都报告健康，一个 512 卡训练任务仍可能表现不佳或失败。原因可能是一块慢GPU、一条在负载下退化的链路，或者一个悄悄把流量引向更慢路径的配置。
NVCRE的做法是直接在拓扑感知节点组上运行真实分布式工作负载，测量结果，并报告哪些节点在每项测试中失败。NVIDIA称，运营人员不再需要手写NCCL manifest、手动二分排查机架，或者从客户工单里才发现硬件降级；就绪状态从假设变成集群的可验证属性。该项目采用Apache 2.0许可，在GitHub上开放开发。
集群在标准诊断下通过、在真实分布式任务里失败
NVIDIA描述，GPU集群就绪是分阶段的：bring-up、burn-in、预生产和生产，每个阶段的标准不同。通过冒烟测试的节点不一定能加入 512 卡训练任务。平台团队常把这种递进关系编码在runbook、电子表格或包裹NCCL测试的shell脚本里，于是又多了一套需要与节点配置、GPU共享和工作负载编排一起维护的系统。
在Slurm上跑一次就绪测试只需一条srun命令；Kubernetes没有内置对应能力，同样测试需要GPU和远程直接内存访问（RDMA）资源请求、匹配网络结构的NCCL设置、足够大的共享内存卷，以及确保所有Pod一起启动的机制。NVCRE填补了这些空缺。它运行能暴露真实硬件问题的工作负载，并准确指出每个失败由哪个节点造成。
博客给出的失败输出示例：communication/nccl-all-reduce状态为Failed，运行时长 42 分 18 秒，规模full-scale，每个Job 8个节点，失败节点为gpu-node-07（ThresholdViolation）和gpu-node-12（HardwareFailureDetected），2 个类别中 1 个通过，结果FAILED。
Certification、Workflow、Job三层API与内置测试目录
NVCRE的产品界面就是API。自定义资源定义（CRD）定义每种资源，因此可以用kubectl查看，也能通过GitOps工作流管理。API按层级分为三种资源：Certification是用户创建的资源，指定要测试的节点和要运行的类别；Workflow管理一个类别，应用目录、平台和GPU覆盖，管理迭代次数，设置编排目标，并创建子Job；Job在目标节点组上运行负载、监控节点健康，并记录测量值和失败。
一个Certification为每个类别创建一个Workflow，每个Workflow再创建子Job，结果向上传播：Job记录哪些节点失败及原因，Workflow报告测试结果，Certification按类别归组结果。这种层级把每次失败归因到具体节点和类别。例如一次运行报告gpu-01在NCCL中遇到硬件故障，gpu-02未达到带宽目标。
博客给出了创建认证的示例配置：apiVersion为nvcre.nvidia.com/v1alpha1，kind为Certification，target使用nodeSelector匹配nvidia.com/gpu.present: "true"，categories指定domain: communication、variant: nccl-all-reduce，以及domain: training、variant: nemotron5-8b。用kubectl apply应用后，可用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表达式判定通过，默认不提供阈值
通过和失败标准使用Common Expression Language（CEL），针对测量指标求值。NVCRE默认不附带任何阈值。博客给出的数值是对NVIDIA GB200 NVL72级系统的示例：communication/nccl-all-reduce的busBandwidthGBps要求value >= 900；training/nemotron5-8b的goodputRatio要求value >= 0.9，avgTFLOPsPerGPU要求value >= 800。
当测量指标未达目标时，NVCRE会设置ValidationFailed条件，这个记录与运行本身是否成功分开。一次跑完但未达目标的工作负载仍会被报告为失败。
按失败出现的规模测试，并自动做故障隔离
NVIDIA指出，有些失败只在特定规模下可见，因此分组策略是显式的。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与gang调度
在Kubernetes上运行多节点GPU工作负载需要平台检测、框架特定运行时配置、GPU和网络资源请求，以及失败运行后的清理。这套设置重复且容易出错。WorkloadRun负责处理这些设置：提供容器镜像、选择框架、指定节点数即可。
framework字段只支持三种之一：torch（通过torchrun做分布式训练）、mpi（NCCL测试及其他MPI工作负载）或exec（任意命令）。NVCRE会生成匹配的Kubeflow TrainingRuntime、注入共享内存卷、设置NCCL和平台环境变量，并在硬件支持时启用NVIDIA NVLink纵向扩展网络。
如果没有gang调度器，默认Kubernetes调度器会独立放置Pod，各个rank在框架rendezvous处等待同伴。在繁忙集群上这可能导致死锁：部分已放置的Pod占着GPU等待永远不会到达的同伴。设置spec.gangScheduler可让每个工作负载Pod加入gang感知调度器，例如KAI Scheduler，它会等到整个gang能一次放置时才放行所有Pod。WorkloadRun是普通CRD，外部工具可以用它运行工作负载，而不必采用NVCRE的其余部分：NVCRE提供执行路径，调用工具提供测试。
与AICR、NVSentinel的分工和安装要求
NVIDIA把集群走向生产需要回答的三个问题分给不同层：配置是否正确由NVIDIA AI Cluster Runtime（AICR）负责，它把驱动、算子、内核和系统设置的已验证组合固化为带版本锁定的配方，可跨集群复现同一优化配置、验证实时状态并检测漂移；是否准备好运行真实AI负载由NVCRE负责，它主动生成负载，能发现不产生遥测的故障；当前是否健康由NVIDIA NVSentinel负责，它作为被动、遥测驱动的层，观察集群已产生的信号，包括DCGM指标、Xid错误、系统日志和云厂商维护事件，并驱动隔离、排水和修复工作流。NVSentinel不消耗GPU时间，因此可以在生产环境持续运行。
NVCRE记录失败节点和原因，但不cordon、不taint、不修改节点条件，以避免冲突操作和不同步的清理。NVSentinel的NVCRE Certification Monitor可以把失败的认证结果转成健康事件，配置好的NVSentinel策略随后可以隔离和排水节点或触发外部修复；后续认证成功可以清除失败信号并解除taint。
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感知调度器可选，但在繁忙共享集群上建议使用。安装通过nvcrectl setup init完成，它会安装CRD、控制器、Kubeflow Trainer和默认日志配置；随后可用nvcrectl certification run --cert-file certification.yaml --wait和nvcrectl certification report gpu-cluster-cert -n运行并查看报告。