奇链 奇链
← 文章 / 云原生与基础设施
NVIDIA 开发者博客 2小时前 · 2026-09-24 04:10:43 · 1 阅读

AI 工作负载部署前验证 GPU 集群就绪状态

GPU 集群可能通过所有健康检查，却依然无法运行 AI 工作负载。即使每个 GPU、网络链路和 Pod 状态都显示正常，一项使用 512 个 GPU 的训练任务仍可能出现性能低下或失败。原因可能是一块落后的 GPU、一条在负载下性能衰退的链路，或者某个将流量悄悄路由到较慢路径的配置。运维人员往往要等到运行数小时后才发现问题，甚至是客户提交了工单才得知。团队随后可能要花几天时间二分排查集群以找出根源，而在此期间算力资源只能闲置。

NVIDIA Cluster Readiness Engine (NVCRE) 是一个开源的 Kubernetes 控制器，能在生产工作负载上线前，将排查范围缩小到相关的具体节点。它会在拓扑感知的节点组中运行真实的分布式工作负载，测量结果并报告哪些节点在每项测试中失败。运维人员不再需要手动编写 NVIDIA Collective Communications Library (NCCL) 清单、手动二分机架，或依靠客户工单来发现性能下降的硬件。集群的“就绪”状态从此成为经过验证的属性，而非单纯的假设。

证明就绪状态需要什么

GPU 集群的就绪是一个分阶段过程。它会经历部署、压力测试、预生产和生产各个阶段，每个阶段设定的标准各不相同。通过冒烟测试的节点，未必准备好加入 512-GPU 的训练任务。

平台团队通常会将这一进度流程编写到运维手册、电子表格，或是包裹在 NCCL 测试中的 shell 脚本里。这就变成了一个他们必须伴随节点配置、GPU 共享和工作负载编排一同构建和维持的额外系统。

集群可能通过标准诊断，却在真实的分布式作业下失败，因此测试就绪状态的最佳方式是运行工作负载。在 Slurm 上，只需一条 srun 命令即可。Kubernetes 没有内置的等价机制，同样的测试需要 GPU 和远程直接内存访问 (RDMA) 资源请求、与网络架构匹配的 NCCL 设置、足够大的共享内存卷，以及确保所有 Pod 同时启动的方法。

NVCRE 弥补了 Kubernetes 上的这些空白。它运行能暴露真实硬件问题的工作负载，并准确指出每个故障是由哪个节点引起的。

communication/nccl-all-reduce
Status:       Failed
Runtime:      42m 18s
Scale:        full-scale
Nodes/Job:    8

Failed Nodes:
  gpu-node-07  ThresholdViolation
  gpu-node-12  HardwareFailureDetected

Summary
Categories:   1/2 passed
Failed Nodes: 2
Result:       FAILED

NVCRE 工作原理

API 是产品的核心界面。自定义资源定义（CRD）负责定义每种资源，支持通过 kubectl 查看以及通过 GitOps 流程管理。

分层 API

API 包含按层级排列的三类资源。

  • Certification（认证）：用户创建的顶层资源，用于指定待测节点列表和需要执行的测试类别。
  • Workflow（工作流）：管理单个类别，负责应用目录、平台和 GPU 覆盖配置，管理迭代次数，设定编排目标，并创建子任务。
  • Job（任务）：在目标节点组上运行负载，监控节点健康状态，记录测量数据和故障信息。

一次认证会按类别生成独立的工作流，每个工作流再创建相应的子任务。

结果会逐级向上汇总。任务记录具体哪些节点失败及原因，工作流上报测试结论，认证层则按类别对结果进行聚合。

该层级结构确保每项故障都能精准定位到具体的节点和类别。例如，某次运行可能会报告：gpu-01 在运行 NCCL 时发生硬件故障，而 gpu-02 未达到带宽目标。

集群验证

以下示例展示认证资源如何指定测试目标和执行类别。

apiVersion: nvcre.nvidia.com/v1alpha1
kind: Certification
metadata:
  name: gpu-cluster-cert
spec:
  target:
    nodeSelector:
      nvidia.com/gpu.present: "true"
  categories:
    - domain: communication
      variant: nccl-all-reduce
    - domain: training
      variant: nemotron5-8b

$ kubectl apply -f certification.yaml
$ kubectl get certifications.nvcre.nvidia.com -w

内置目录当前覆盖三大领域：五类 NCCL 通信变体（all-reduce、all-gather、all-to-all、loopback 及跨 NVIDIA NVSwitch 的 loopback）、NVIDIA Data Center GPU Manager（DCGM）第四级诊断套件，以及基于 8B 和 56B 参数量 NVIDIA Nemotron 5 模型的 NVIDIA NeMo 预训练任务。每个条目均包含针对不同平台的默认配置。

NVCRE 会自动检测目标节点的 GPU 架构和云平台，并据此推导出其余配置，包括每个节点的 GPU 数量、NCCL 环境以及平台特定的网络设置。

用表达式定义通过标准

通过与否的判定标准采用 Common Expression Language（CEL）编写，基于实测指标进行求值。默认不内置任何阈值，下表仅为 NVIDIA GB200 NVL72 级别系统的示例值。

  categories:
    - domain: communication
      variant: nccl-all-reduce
      options:
        thresholds:
          busBandwidthGBps: "value >= 900"
    - domain: training
      variant: nemotron5-8b
      options:
        thresholds:
          goodputRatio: "value >= 0.9"
          avgTFLOPsPerGPU: "value >= 800"

当某个实测指标未达标时，NVCRE 会设置 ValidationFailed 条件，并与任务本身的运行成败分开记录。也就是说，即使任务跑完了，但没达到目标，依然会被判定为失败。

在故障真正出现的规模下测试

有些故障只在特定规模下才会暴露，因此分组策略必须明确指定，由 testScale 字段选择：

  • Intra-node：每个节点独立测试。
  • Intra-rack：使用 nvidia.com/gpu.clique 标签按拓扑域划分节点。
  • Full-scale：所有节点归入同一个组。
  • Diagnose：运行自适应故障隔离（下文介绍）。

选择哪种策略决定了测量的是什么。单个 NVIDIA NVLink 域内的 NCCL 测试测的是 NVLink 带宽，而同样的测试横跨三个机架测的就是 scale-out 网络——两者测的根本不是一回事。

自适应故障隔离

多节点验证中最棘手的情况，是故障无法归因到任何单个节点。比如一个 64 节点的 all-reduce 返回了很低的带宽，组内每个节点都同样可疑，靠人工排查可能要耗费数天的工程时间。

NVCRE 自动完成故障隔离。设置 testScale: diagnose 后，系统会运行拓扑感知的分层分组测试。引擎会拆分每个故障组，重新运行拆分后的半组，并持续该过程直到组大小达到 minGroupSize。在该最小规模下仍然失败的组会被标记为疑似故障节点。maxConcurrent 限制了并发作业数量，以防止被测网络 fabric 过载。

输出结果只指出少数几个疑似故障节点，而不是将整个组都列为嫌疑，并给出每个节点失败的具体原因。

运行任意工作负载：WorkloadRun API

在 Kubernetes 上运行多节点 GPU 工作负载需要平台检测、特定框架的运行时配置、GPU 和网络资源请求，以及失败运行后的清理工作。这些配置步骤重复且容易出错。

WorkloadRun 自动处理这些配置：只需提供容器镜像，选择框架，并指定节点数量。

apiVersion: nvcre.nvidia.com/v1alpha1
kind: WorkloadRun
metadata:
  name: nccl-all-reduce
spec:
  image: nvcr.io/nvidia/pytorch:26.01-py3
  framework:
    mpi:
      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
    testType: all_reduce

framework 字段仅支持 torch（通过 torchrun 进行分布式训练）、mpi（NCCL 测试及其他 MPI 工作负载）或 exec（任意命令）三者之一。NVCRE 会生成对应的 Kubeflow TrainingRuntime，注入共享内存卷，设置 NCCL 和平台环境变量，并在硬件支持时启用 NVIDIA NVLink 纵向扩展网络。

如果没有 gang scheduler，默认的 Kubernetes 调度器会独立放置 pod，各 rank 会在框架 rendezvous 阶段等待其他 peer。在繁忙集群上，这可能导致死锁：部分已放置的 pod 占用 GPU，但等待的 peer 永远无法到达。设置 spec.gangScheduler 可让所有工作负载 pod 接入支持 gang 的调度器（如 KAI Scheduler），该调度器会保留所有 pod，直到整个 gang 能一次性全部放置。

WorkloadRun 是一个标准的 CRD，外部工具无需引入 NVCRE 的其他组件，即可通过它来运行工作负载。NVCRE 提供执行路径，而调用方工具负责提供测试用例。

大规模配置、验证和监控 AI 集群

集群在投入生产前必须回答三个问题：配置是否正确？是否准备好运行真实的 AI 工作负载？当前是否健康？NVIDIA DSX OS 的不同层级分别对应这三个问题。

NVIDIA AI Cluster Runtime（AICR）负责建立并维持经过验证的集群配置。AICR 将经过验证的驱动、Operator、内核及系统设置组合封装为版本锁定的配方。团队可以跨集群复现相同的优化配置，验证实时状态并检测配置漂移。这有助于减少性能差异，避免在昂贵的 GPU 闲置期间浪费数天进行调优。

NVCRE 验证集群是否具备运行真实 AI 工作负载的条件。作为一个主动的、由工作负载驱动的层级，它会生成实际负载，从而发现那些不产生遥测数据的故障。例如，单块 GPU 性能下降会使同步训练任务的速度受制于最慢的 rank，而 NCCL 带宽测试能在几分钟内定位此类问题。

NVIDIA NVSentinel 持续监控集群健康状况。作为被动的、由遥测数据驱动的层级，它监控集群自身产生的信号，包括 DCGM 指标、Xid 错误、系统日志以及云提供商的维护事件。它能检测运行时故障，并驱动隔离、排空和修复工作流。由于不占用 GPU 时间，它可以在生产环境中持续运行，而无需像主动测试那样占用 GPU 资源。

每个项目都能独立提供价值，并与其他组件集成，服务于运行全栈的团队。

示意图：对比六 GPU 集群上 NVSentinel 的被动监控与 NVCRE 的主动验证。NVSentinel 采集 DCGM 指标、Xid 错误、系统日志和云事件来检测故障，并驱动隔离（cordon）、驱逐（drain）和修复操作。NVCRE 将其测试目录依次经过认证、工作流和作业阶段，生成负载并测量结果，发现 gpu-02 虽然没有任何遥测输出，但运行速度慢了 8%。两个工具按顺序配合：NVCRE 识别故障节点，NVSentinel 对其进行修复。
图 1. NVSentinel 被动接收集群遥测数据，而 NVCRE 主动生成负载，找出那些不产生任何遥测信息的故障

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 level-4 类别则需要独立的 DCGM 服务。 gang-aware 调度器（如 KAI Scheduler）是可选项，但在繁忙的共享集群上建议启用。

安装 CLI 并完成集群初始化。nvcrectl setup init 命令会安装 CRD、控制器、Kubeflow Trainer 以及默认日志配置。

$ curl -fsSL https://github.com/NVIDIA/cluster-readiness-engine/releases/latest/download/installer | bash
$ nvcrectl setup init

然后执行一次端到端验证。

$ nvcrectl certification run --cert-file certification.yaml --wait
$ nvcrectl certification report gpu-cluster-cert -n <namespace>

报告将列出各分类的状态、运行时时长、实测带宽以及发生故障的节点，并附上每次故障的具体原因。

Certification Report

Name:     gpu-cluster-cert
Platform: aws
GPU:      gb300
Nodes:    16

communication/nccl-all-reduce
Status:       Succeeded
Runtime:      3m 56s
Scale:        full-scale
Nodes/Job:    16
MNNVL:        Enabled

Bandwidth:
  Size       AlgBW        BusBW        Samples
  16 GB      473.44 GB/s  932.09 GB/s  9

Summary
Categories:   1/1 passed
Failed Nodes: none
Result:       PASSED

参与贡献

NVCRE 采用 Apache 2.0 协议开源开发。在提交 Pull Request 之前，请先在 GitHub 上报 bug、提需求或提议变更。你还可以贡献目录条目、工作负载适配器、测试用例和文档。

使用引擎在生产环境中验证 GPU 集群。其共享工作流和测试目录在 Kubernetes 集群上运行一致，并将在路线图后续阶段支持新的 NVIDIA 架构、推理场景和自动化生命周期验证。

在下一次生产级工作负载上线前，先验证你的 GPU 集群。

该项目是 NVIDIA DSX OS 的一部分，也是NVIDIA DSX AI 工厂平台 的操作系统层。

原始来源： NVIDIA 开发者博客

评论 (0)