NVIDIA 开源 NVCRE：在 Kubernetes 上跑真实分布式负载，把 512-GPU 训练前的集群就绪变成可验证属性

NVCRE 把集群就绪从假设变成可验证属性：它运行真实分布式工作负载并报告每个测试中失败的节点，示例报告显示 communication/nccl-all-reduce 在 8 节点全规模运行 42 分 18 秒后失败，gpu-node-07 为 ThresholdViolation、gpu-node-12 为 HardwareFailureDetected。 此前平台团队需用 runbook、电子表格或包裹 NCCL 测试的 shell 脚本自行搭建这套流程，且往往要等到客户提交工单才发现降级硬件；NVCRE 将这一能力做成 Kubernetes 控制器，无需手写 NCCL 清单或人工二分机架。 文中给出失败与通过两类完整报告样例（含节点名、失败原因、运行时长、带宽数值），并说明内置目录覆盖三个域；但未提供与人工排查的对照实验或统计样本量。

NVCRE 用 Certification、Workflow、Job 三层 CRD 层级把每个失败归因到具体节点和类别：Certification 命名待测节点与类别，每个类别生成一个 Workflow，Workflow 再创建子 Job，结果逐层向上传播。 相比把测试逻辑散落在脚本中，该层级让结果可按类别分组、可用 kubectl 检查并纳入 GitOps 工作流，文中举例说明一次运行可报告 gpu-01 在 NCCL 中发生硬件故障、gpu-02 未达带宽目标。 文中给出 Certification 的 YAML 示例与 kubectl 命令，并说明 API 即产品界面；属于设计说明与示例，而非对照评测。

针对无法归因到单一节点的多节点故障，testScale: diagnose 运行拓扑感知的分层分组测试：引擎拆分失败组、重跑两半，直到达到 minGroupSize，仍失败的组被标记为嫌疑节点，maxConcurrent 限制并发作业以免占满被测网络。 文中指出 64 节点 all-reduce 带宽偏低时每个节点都同样可疑，人工隔离可能耗费数天工程时间；NVCRE 自动输出少量嫌疑节点及各自失败原因，而非牵连整组。 文中描述了算法步骤与并发控制参数，并说明输出形式；未给出该诊断模式在真实集群上的成功率或耗时数据。

WorkloadRun 把多节点 GPU 工作负载的搭建工作自动化：只需提供容器镜像、选择框架（torch、mpi 或 exec 三选一）并指定节点数，NVCRE 生成对应的 Kubeflow TrainingRuntime、注入共享内存卷、设置 NCCL 与平台环境变量，并在硬件支持时启用 NVLink scale-up 网络。 文中指出 Kubernetes 没有类似 Slurm 单条 srun 命令的等价物，同样的测试需要 GPU 与 RDMA 资源请求、匹配网络结构的 NCCL 设置、足够大的共享内存卷以及保证所有 pod 同时启动；WorkloadRun 填补这些缺口，且作为普通 CRD 可被外部工具单独调用。 文中给出 WorkloadRun 的 YAML 示例与框架字段说明，并解释无 gang 调度器时可能死锁、spec.gangScheduler 可让所有 pod 等待整组一次性放置；属于机制说明与示例。

该工具面向在 Kubernetes 上运行 NVIDIA GPU 集群的平台与运维团队，用于 bring-up、burn-in、preproduction 到 production 各阶段中生产负载落地前的就绪验证；它要求 Kubernetes 1.29 及以上、kubectl、Helm 3.x 与 NVIDIA GPU Operator，GB200/GB300 NVL72 目录条目还需 DRA Driver，DCGM 四级类别需独立 DCGM 服务，繁忙共享集群建议配置 KAI Scheduler 等 gang 调度器。它记录失败节点与原因但不 cordon、taint 或修补节点状态，需与 NVSentinel 的 Certification Monitor 配合才能触发隔离、排空或外部修复。

文中未给出与人工排查的对照实验、诊断模式的成功率或耗时统计，也未说明内置目录之外的自定义测试如何验证；阈值默认不随附，示例中的 busBandwidthGBps >= 900、goodputRatio >= 0.9、avgTFLOPsPerGPU >= 800 仅标注为 GB200 NVL72 级系统的示意值，实际取值需读者自行确定。路线图提到对新 NVIDIA 架构、推理与自动化生命周期验证的支持，但未给出时间表。