NVIDIA 于 2026 年 9 月 23 日公开 NVCRE：在 Kubernetes 上用真实负载给 GPU 集群做就绪认证，失败时能定位到具体机器。 前置部署 Forward Deployed Engineer（FDE）在客户机房接手一批刚上架的 GPU 服务器时，缺的往往不是监控面板，而是「这批卡到底能不能一起跑一个大作业」的可复现结论。前置部署 Forward Deployed Engineer（FDE）的交付清单里因此多了一项：在真实负载下证明集群就绪，并把失败定位到具体的机器，而不是笼统地说这一组有问题。 ## 一、要解决的是「所有健康检查都通过却跑不动」 NVIDIA Cluster Readiness Engine（NVCRE）是一个开源的 Kubernetes 控制器，它在拓扑感知的节点组上运行真实的分布式工作负载，用实测结果证明 GPU 集群能在生产作业落地之前跑起来。配套仓库为 github.com/NVIDIA/cluster-readiness-engine，最新版本 v0.4.0 发布于 2026 年 9 月 21 日，采用 Apache 2.0 许可。 原文给出的问题描述很具体：一个 GPU 集群可以每一项健康检查都通过，却依然跑不动 AI 作业；即使每一块 GPU、每一条网络链路、每个 Pod 都报告健康，一个 512 块 GPU 的训练作业仍可能跑不满或者直接失败。原因可能是某一块 GPU 偏慢、某一条链路在负载下降级，或者配置把流量悄悄引到了更慢的路径上。 这类故障在被动监控里不可见，运维团队往往要到作业运行数小时后、或者客户提了工单才发现，然后再花几天做二分排查，期间昂贵算力一直空转。 前置部署 Forward Deployed Engineer（FDE）在客户现场遇到的正是这一段时间差：集群从到货到真正可用之间的空窗，交付方与客户都很难证明自己该负责哪一段。NVCRE 把这段空窗变成一次可复现、可留存报告的实测。 ## 二、三层自定义资源加上一份最小 Certification NVCRE 的产品界面就是它的 API，三层自定义资源按层级排列：Certification 是要创建的资源，指定测哪些节点、跑哪些类别；Workflow 管理单个类别，负责套用目录项与平台、GPU 层面的覆盖参数，管理迭代次数、设置编排目标并创建子作业；Job 在目标节点组上运行负载、监控节点健康、记录测量值与失败。 一个 Certification 为每个类别创建一个 Workflow，每个 Workflow 创建自己的子 Job，结果自下而上回传。因为全部是 CRD，可以直接用 kubectl 查看，也可以纳入 GitOps 流程管理。 最小可跑的 certification.yaml 如下：apiVersion 填 nvcre.nvidia.com/v1alpha1，kind 填 Certification，metadata.name 填 gpu-cluster-cert，spec.target.nodeSelector 用 nvidia.com/gpu.present 且值为 true 选中全部带 GPU 的节点，spec.categories 下并列两项——domain 为 communication 配 variant 为 nccl-all-reduce，以及 domain 为 training 配 variant 为 nemotron5-8b。 提交与观察用两条命令：kubectl apply -f certification.yaml，以及 kubectl get certifications.nvcre.nvidia.com -w。加 -w 是必需的，因为 NCCL 与训练类测试的运行时长远超一次 kubectl apply 的等待窗口，原文那个失败样例就跑了 42 分 18 秒。 内置目录当前覆盖三个领域：五个 NCCL 通信变体（all-reduce、all-gather、all-to-all、loopback，以及跨 NVIDIA NVSwitch 的 loopback）、NVIDIA Data Center GPU Manager（DCGM）的 level-4 诊断套件、以及用 NVIDIA Nemotron 5 的 8B 与 56B 两个参数规模做 NeMo 预训练。每个目录项都带平台感知的默认值，NVCRE 会从目标节点探测 GPU 架构与云平台，自己推导每节点 GPU 数、NCCL 环境变量与平台相关网络设置。 ## 三、前置条件与两条安装运行命令 NVCRE 要求 Kubernetes 1.29 或更高版本、kubectl、Helm 3.x，以及目标集群上已装 NVIDIA GPU Operator。 两个最容易漏掉的额外依赖：NVIDIA GB200 NVL72 与 GB300 NVL72 的目录条目会创建 ComputeDomain 资源，因此另需 NVIDIA DRA Driver for GPUs；DCGM level-4 这个类别需要独立的 DCGM 服务，装了 GPU Operator 不等于装了这个服务。一个可选但强烈建议的依赖是 gang 感知调度器，例如 KAI Scheduler，原因见第九节。 安装 CLI 并初始化集群：先执行 curl -fsSL https://github.com/NVIDIA/cluster-readiness-engine/releases/latest/download/installer | bash，再执行 nvcrectl setup init。setup init 会安装 CRD、控制器、Kubeflow Trainer 与默认日志配置。 端到端验证用两条命令：nvcrectl certification run --cert-file certification.yaml --wait，以及 nvcrectl certification report gpu-cluster-cert -n 命名空间名。--wait 会阻塞到测试结束，长测建议放进 tmux 或 CI 任务。 报告会逐类别列出状态、运行时长、实测带宽、失败节点与失败原因。原文给出的成功样例是：平台 aws、GPU 为 gb300、16 个节点、full-scale 分组、每作业 16 个节点、MNNVL 已启用，communication/nccl-all-reduce 类别 3 分 56 秒完成，16 GB 消息尺寸下算法带宽 473.44 GB/s、总线带宽 932.09 GB/s，采样 9 次，类别 1/1 通过，结果 PASSED。 失败样例同样明确：communication/nccl-all-reduce 结果为 Failed，运行时长 42 分 18 秒，full-scale 分组、每作业 8 个节点，失败节点是 gpu-node-07（ThresholdViolation）与 gpu-node-12（HardwareFailureDetected），类别 1/2 通过，结果 FAILED。前置部署 Forward Deployed Engineer（FDE）拿这份报告可以直接向客户指出是哪两台机器、哪一类指标不达标。 ## 四、判定标准是 CEL 表达式，而且默认一个阈值都不带 这是本条最容易踩的坑：NVCRE 默认不附带任何阈值。没有阈值时，测试会记录测量值，但不会因为你认为太慢而判失败——第一次跑完看到 PASSED，并不代表集群达标。 通过与否用 Common Expression Language（CEL）写在 options.thresholds 里，针对实测指标求值。原文给出的是 NVIDIA GB200 NVL72 级别系统的示例值，不是通用基线：通信类别写 busBandwidthGBps: value >= 900；训练类别写 goodputRatio: value >= 0.9 与 avgTFLOPsPerGPU: value >= 800。 判定与运行结果是两个独立信号：指标没达到目标时 NVCRE 会设置 ValidationFailed 条件，一个跑完却没达标的作业仍然报为失败。写验收脚本时必须显式读这个条件，只看作业是否结束会漏掉一批不合格的机器。 落地顺序建议先观察再收紧：第一轮不加阈值跑一遍，记录这台集群的真实总线带宽与单卡算力，再按实测值的九成左右设阈值。照抄 900 与 800 会在不同机型上大面积误报，因为这两个值是针对 GB200 NVL72 这一档系统给出的。 还有一个配套动作：阈值写进版本库随 certification.yaml 一起管理。前置部署 Forward Deployed Engineer（FDE）换客户、换机型时改的是这一份文件，而不是改控制器的全局配置。 ## 五、testScale 决定你到底在测什么 testScale 字段显式选择分组策略，四个取值分别是：intra-node 每个节点独立测；intra-rack 按拓扑域切分、使用 nvidia.com/gpu.clique 标签；full-scale 把所有节点放进一个组；diagnose 启用自适应故障隔离。 为什么必须显式选：同一个 NCCL 测试，在单个 NVIDIA NVLink 域里跑测的是 NVLink 带宽，跨三个机架跑测的是横向扩展网络的带宽，两者测的根本不是同一个东西。 这条直接改变排期。intra-node 几分钟能跑完，适合每次上架新节点后做；full-scale 需要把所有目标机器同时空出来，属于必须提前和客户约维护窗口的动作。 可复用的分工是：把 intra-node 当作每次变更后的常驻检查塞进交付流程，把 full-scale 留到验收节点，把 diagnose 留给已经出现异常的集群。 ## 六、诊断模式把「一整组都慢」收敛到少数几台机器 多节点验证里最难处理的是无法归因到单台机器的失败：64 节点 all-reduce 报带宽偏低，组里每一台机器都同样可疑，人工隔离往往要花几天工程时间。 把 testScale 设为 diagnose 后，NVCRE 做拓扑感知的分层分组测试：把失败的组一分为二分别重跑，持续切分直到组大小降到 minGroupSize；到该规模仍然失败的组被标为嫌疑节点。maxConcurrent 限制同时运行的作业数量，避免测试自己把待测网络打满、污染测量结果。 输出是小批嫌疑节点加每台机器的失败原因，而不是把整组都列为可疑。这两个参数的配合是本条最实用的一处：minGroupSize 定收敛点，maxConcurrent 定测量保真度，后者设得太大，测出来的带宽会是自己造成的。 缺点也要说清：分层重跑意味着总耗时随组数增加而放大，一轮 diagnose 可能比一次 full-scale 慢数倍。所以它是排查手段，不是日常巡检手段。前置部署 Forward Deployed Engineer（FDE）应把它留给已经出现异常的集群，而不是每次交付都跑一遍。 ## 七、WorkloadRun 让任意多节点负载不必手写 manifest 在 Kubernetes 上跑一个多节点 GPU 作业，需要平台探测、框架相关的运行时配置、GPU 与网络资源申请，以及失败后的清理。WorkloadRun 这个 API 把这些接管：给出容器镜像、选择框架、指定节点数即可。 framework 字段三选一且必须且只能填一个：torch 走 torchrun 做分布式训练；mpi 用于 NCCL 测试与其他 MPI 工作负载；exec 执行任意命令。NVCRE 会生成对应的 Kubeflow TrainingRuntime、注入共享内存卷、设置 NCCL 与平台环境变量，并在硬件支持时启用 NVIDIA NVLink scale-up 网络。 原文给出的 MPI 例子：image 为 nvcr.io/nvidia/pytorch:26.01-py3，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，bandwidthMeasurement.testType 为 all_reduce。这组参数把消息尺寸从 8 字节扫到 32G、每个尺寸重复 2 次、每个尺寸迭代 100 次，是判断带宽曲线的常用扫法。 因为 WorkloadRun 只是一个普通 CRD，外部工具可以只借它跑作业而不引入 NVCRE 的其余部分：NVCRE 提供执行路径，调用方提供测试内容。这一点对已有自研验证脚本的团队很实用，可以先用它替换掉手写的 NCCL manifest 与共享内存配置。 ## 八、没有 gang 调度会在繁忙集群上死锁 默认 Kubernetes 调度器逐个放置 Pod，而各 rank 要在框架的 rendezvous 点等待同伴。在繁忙集群上这会死锁：已放置的 Pod 占着 GPU，等一批永远不会到达的同伴。 对策只有一个字段：spec.gangScheduler 让作业的所有 Pod 交给 gang 感知的调度器，例如 KAI Scheduler，整个 gang 能一次性放置时才放。 这条在共享集群上不是优化项而是必需项：客户的生产集群不可能为了你的验收测试腾空。反过来，在独占的验收集群上它也可以先不开，少一层依赖。 对应的常见报错症状是作业一直处于 Pending 或运行但无输出，日志里停在等待 rank 的顺序上，而 kubectl describe 显示 Pod 已在 Running——遇到这个组合先检查 gang 调度器是否被排除了该命名空间。 ## 九、职责边界决定了卸载时会发生什么 NVCRE 只记录失败节点与原因，它不 cordon、不 taint、也不修改节点 condition，原文的理由是避免动作冲突与清理不同步。 要把失败转成实际动作，需要 NVSentinel 的 NVCRE Certification Monitor：它把失败的认证结果翻译成健康事件，再由 NVSentinel 既有策略去隔离、驱逐节点或触发外部修复；后续一次成功的认证可以清除失败信号并解除污点。 这条边界对回滚很关键：把 NVCRE 装进客户集群再卸掉，不会留下被污点标记的节点，因为它从来不写节点状态。真正要清理的是它创建的 CRD、控制器与 Kubeflow Trainer，以及测试期间占用 GPU 的遗留作业。 三个组件别混用：NVIDIA AI Cluster Runtime（AICR）负责建立并维持经过验证的集群配置，把驱动、Operator、内核与系统设置的组合固化成版本锁定的配方，用于检测配置漂移；NVCRE 主动生成负载，用来发现不产生遥测的故障；NVSentinel 是被动层，读取集群已经产生的信号，包括 DCGM 指标、Xid 错误、系统日志与云厂商维护事件。NVSentinel 不消耗 GPU 时间，可以在生产环境常开；NVCRE 会占用 GPU，只能按窗口跑。 ## 十、谁该行动、怎么做、什么时候不该用 第一类该行动的是在客户现场交付 GPU 集群的前置部署 Forward Deployed Engineer（FDE），以及自建 AI 训练集群的平台团队。落地动作分五步，每步都能直接搬。 第一步，先只装不改：执行 nvcrectl setup init 后立刻跑一次只含 communication 类别的 Certification，目标节点选全量，不加任何阈值，拿到这台集群的真实带宽基线。 第二步，按自己记录到的数字定阈值：用实测的总线带宽与单卡算力取九成左右写进 busBandwidthGBps 与 avgTFLOPsPerGPU，不要照抄原文示例里的 900 与 800。 第三步，把 intra-node 设成每次节点变更后的常驻检查，把 full-scale 与 diagnose 设成验收与排查时的按需动作。 第四步，验收报告必须同时给三样东西：类别级通过情况、实测带宽与采样次数、失败节点与失败类别。只给一个 PASSED 或 FAILED 的结论，对客户没有说服力，也无法支撑后续的换件与返修索赔。 第五步，把失败处置接到 NVSentinel 而不是自己写脚本 taint 节点，避免与集群既有的修复流程打架。 适用条件有三条：集群必须是 Kubernetes 1.29 或更高版本且已装 GPU Operator；GB200 NVL72 与 GB300 NVL72 机型还要额外装 DRA Driver for GPUs；选 DCGM level-4 类别要先有独立的 DCGM 服务。Slurm 集群不适用——原文明确说同一件事在 Slurm 上一条 srun 命令就够，NVCRE 补的是 Kubernetes 上缺失的等价能力。 退出与回滚方式：先把 NVCRE 装进独立命名空间并只跑 intra-node，确认对生产调度无影响后再扩大范围；需要退出时卸载 CRD、控制器与 Kubeflow Trainer，并确认没有遗留的 Certification 作业仍在占用 GPU。因为 NVCRE 不修改节点状态，卸载不会留下被隔离的节点；但如果已经接了 NVSentinel 的认证监视器，要先停掉该策略，否则它会持续产生健康事件。 ## 十一、原文自述的局限与本条未覆盖的场景 局限一，内置目录只有三个领域，覆盖 NCCL 通信、DCGM level-4 诊断与 NeMo 预训练，够不到推理服务、显存带宽压测与多租户隔离场景。原文把推理与自动化生命周期验证列为路线图，也就是说当前版本没有。 局限二，默认不带阈值，判定标准要自己写 CEL。原文给的 900、0.9、800 三个值明确标注为 GB200 NVL72 级别系统的示例，不能当通用基线。 局限三，整套验证依赖目标集群已经具备 GPU Operator 等前提组件，它不是能在裸机上直接跑的独立工具。 局限四，只有 Kubernetes 侧实现。Slurm 场景下同一件事用一条 srun 命令就能完成，本条不提供 Slurm 侧的等价做法。 局限五，全部数字与结论来自 NVIDIA 自己的技术博客与官方仓库，没有第三方独立复现，也没有客户侧交叉验证。文中的 932.09 GB/s 与 473.44 GB/s 取自原文给出的单个 16 节点 GB300 样例，不是多集群统计值，换机型与换拓扑后不可比。 局限六，原文未公布测试对生产流量的影响面，也未说明在已有生产作业运行的集群上跑 full-scale 的隔离要求。 本条未覆盖的场景包括：如何自建目录项与 workload adapter、如何把 NVCRE 的结果接入客户既有的变更管理系统、以及多集群场景下如何汇总认证结果。前置部署 Forward Deployed Engineer（FDE）需要提前接受的限制是，本条给的是配置面与判定面，不含任何性能调优建议，也不替代对具体硬件的返修流程。 ## 十二、与本站既有条目的差异说明 检索本站已发布列表标题，含 NVCRE 的条目为 0 条，含 Cluster Readiness、NVSentinel、DCGM、NCCL、NVLink 的条目均为 0 条。 含 NVIDIA 的条目有 2 条，分别是 SWE-Serve 推理服务补丁评测与 Container Toolkit v1.20.1 版本发布；含 Kubernetes 的条目有 4 条，落点分别是 LangGraph CLI 自托管部署、VPA 1.8.0 的匹配索引优化、自管 Kubernetes 迁 Amazon EKS 的共享服务架构、以及 k3s v1.37.0 的隔离交付修复。 本条与它们的技术面都不同：本条落点是 GPU 集群在 Kubernetes 上的就绪认证方法，讲的是用什么负载证明集群可用、阈值怎么定、失败怎么收敛到具体节点，不是版本里改了什么，也不是迁移或权限方案。前置部署 Forward Deployed Engineer（FDE）在本条里换到的是集群交付前的验收环节。 ## 原始来源 原始来源： https://developer.nvidia.com/blog/validate-gpu-cluster-readiness-before-ai-workloads-land/ https://github.com/NVIDIA/cluster-readiness-engine https://github.com/NVIDIA/cluster-readiness-engine/releases/tag/v0.4.0 https://docs.nvidia.com/cluster-readiness-engine