一个 GPU 集群可以通过所有健康检查，却依然跑不好一个 AI 负载。即使每块 GPU、每条网络链路、每个 Pod 都报告正常，一个 512 GPU 的训练作业仍可能性能不达标甚至失败，原因可能是一块偏慢的 GPU、一条在负载下才退化的链路，或者一个悄悄把流量引到慢路径的配置。运维团队往往在作业跑了几小时后，甚至等到客户提交工单时才发现问题，再用几天时间二分排查，期间算力一直闲置。
NVIDIA 开源了 Cluster Readiness Engine（NVCRE），一个 Kubernetes 控制器，把搜索范围在生产负载落地前收敛到具体节点。它按拓扑感知的节点分组运行真实的分布式负载，测量结果，并报告哪些节点在哪些测试中失败。团队不再需要手写 NCCL 清单、手动二分机架，或从客户工单里得知硬件已经退化。
NVCRE 的 API 就是产品界面，由三层自定义资源组成：Certification 指定要测试的节点与类别；Workflow 管理单个类别，应用目录、平台与 GPU 覆盖项，控制迭代次数并创建子作业；Job 在目标节点组上运行负载、监控节点健康并记录测量值与失败原因。结果逐层向上汇聚，因此一次运行可以明确指出 gpu-01 在 NCCL 阶段发生硬件故障、gpu-02 未达到带宽目标。
内置目录目前覆盖三类：五种 NCCL 通信变体（all-reduce、all-gather、all-to-all、loopback，以及跨 NVSwitch 的 loopback）、DCGM 四级诊断套件，以及基于 Nemotron 5 的 8B 与 56B 参数 NeMo 预训练。NVCRE 会从目标节点识别 GPU 架构与云平台，自动推导每节点 GPU 数、NCCL 环境变量与平台相关网络配置。通过标准用 CEL 表达式描述，默认不下发任何阈值，避免一套固定数字套到所有硬件上。
测试规模是显式参数：intra-node 逐节点独立测试，intra-rack 按拓扑域分组，full-scale 把所有节点放进一组，diagnose 则启用自适应故障隔离。后者针对最难定位的情况——64 节点 all-reduce 带宽偏低，组内每个节点都同等可疑。引擎会把失败组对半拆分重跑，直到达到最小分组规模，仍失败的组被标记为嫌疑节点，并用 maxConcurrent 限制并发作业，避免压垮正在测量的网络。
NVCRE 属于 NVIDIA DSX OS 的一层，与 AICR、NVSentinel 分工：AICR 用版本锁定的配方维护经过验证的集群配置，NVCRE 主动加载以发现没有遥测信号的故障，NVSentinel 则被动消费 DCGM 指标、Xid 错误与云维护事件。NVCRE 只记录失败节点与原因，不做 cordon、taint 或节点状态修补，避免与清理流程冲突；需要隔离节点时，可由 NVSentinel 的认证监控把失败结果转成健康事件再执行。项目以 Apache 2.0 许可开源，要求 Kubernetes 1.29 及以上、GPU Operator，GB200/GB300 NVL72 目录项还需 DRA 驱动。
WeChat
Profile