NVIDIA DSX OS：用开源工具配置、认证与运维Kubernetes GPU集群

一个性能不佳的 GPU 可能会拖慢整个分布式训练作业。该节点可能通过基本健康检查并显示正常利用率，导致运维人员只有在工作负载运行后才发现问题。

这些问题可能出现在集群生命周期的任何时间点。一个在交接时通过就绪检查的 GPU 集群，会随着节点更换、驱动打补丁和容量增加而发生变化。如果没有重复验证，最初的认证就不再反映集群的实际状况。

这种可见性缺口会在故障节点上浪费计算资源，并出于谨慎让健康节点闲置。利用率指标可能掩盖这些损失。有效吞吐量（goodput），即成功完成的工作量，提供了更有用的集群效率衡量标准。保持集群就绪状态需要在集群的整个运营生命周期中进行验证——在配置变更后、容量增长时，以及修复后的节点重新投入使用前。

NVIDIA DSX AI Factory Platform 汇集了用于设计、构建和运营高效、弹性 AI 工厂的技术。其开源软件层 NVIDIA DSX OS 包含用于配置、认证和维护加速 Kubernetes 基础设施健康的工具。

• 配置：NVIDIA AI Cluster Runtime (AICR) 为 GPU 优化的 Kubernetes 基础设施建立可复现的基线。
  • 为网络、存储和驱动等组件定义版本锁定的配置配方。
  • 将配方渲染为现有部署工具可用的捆绑包。
• 认证：NVIDIA Cluster Readiness Engine (NVCRE) 验证集群是否准备好运行生产工作负载。
  • 使用 AI 工作负载和诊断工具测试 GPU、网络和存储。
  • 记录认证结果并帮助识别故障节点。
• 运营：NVSentinel 监控集群健康并支持故障修复和重新验证。
  • 基于 GPU、节点和网络健康状况发布节点状况。
  • 配置后，封锁或污点不健康的节点，驱逐工作负载，并修复故障。
  • 可以在节点重新投入使用前触发 NVCRE 重新验证。

这三个项目都是 Apache 2.0 许可下的开源项目，欢迎外部贡献。

开始之前，请使用各自的安装指南安装并配置 AICR、NVCRE 和 NVSentinel。示例假设可以访问一个 Kubernetes GPU 集群，并已配置所需的 CLI、控制器、依赖项和 NVCRE 测试提供程序。

本演练跟随一个集群经历其生命周期：从配方进行配置，生产使用前认证，运营期间监控，以及修复后重新认证。每个命令都是该序列中的一个步骤。

配置：可复现的基线

AICR 在版本控制的文件中定义集群的软件基线，并将其渲染为现有部署工具可应用的工件。它生成并验证；您的部署器应用并协调它们。声明式模板有助于检测手动更改导致的配置漂移，并在修复后保持节点配置一致。

您描述目标环境。AICR 根据经过验证的覆盖库解析它并生成配方：

aicr recipe --service eks --accelerator h100 --os ubuntu \
  --intent inference --platform dynamo -o recipe.yaml

结果配方中的每个组件条目都固定一个版本，并声明在安装组件之前必须健康的依赖项：

apiVersion: aicr.run/v1alpha2
componentRefs:
  - name: dynamo-platform
    chart: dynamo-platform
    namespace: dynamo-system
    source: https://helm.ngc.nvidia.com/nvidia/ai-dynamo
    type: Helm
    version: 1.4.2
    valuesFile: components/dynamo-platform/values.yaml
    dependencyRefs:
      - grove
      - cert-manager
      - kube-prometheus-stack
      - gpu-operator
      - kai-scheduler

配方包含三个关键属性：

• 固定版本：版本是固定的，有助于您复现软件配置并调查故障。相比之下，浮动标签可能随时间指向不同的软件版本，使故障更难复现。
• 依赖图：dependencyRefs 声明必须先安装并健康的组件。AICR 在渲染捆绑包时解析依赖图，因此顺序已编码在您的部署器应用的工件中。您无需指定 cert-manager 在 NVSentinel 之前，以后添加组件也无需重新编号。
• 每个组件的健康断言：每个条目都带有一个 healthCheckAsserts 块，在安装后运行，检查组件是否满足其配置的健康标准。Kubernetes 可能将卡在 CrashLoopBackOff 的 Pod 报告为 Running，因此仅基于 Pod 阶段的检查可能会遗漏损坏的组件。随附的断言根据容器等待原因进行过滤，而不仅仅是 Pod 阶段。

渲染配方是一个单独的步骤，将 AICR 连接到您现有的流水线：

aicr bundle --recipe recipe.yaml --deployer argocd --output ./bundles

--deployer 接受 helm、argocd、argocd-helm、flux 或 helmfile，因此相同的已验证配方可变为 Argo CD Application 清单、Flux 资源、Helmfile 发布图或纯 Helm 命令。您可以保留现有的部署工具，并使用 AICR 生成其配置工件。

由于配方是一个文件，您可以使用版本历史、代码审查和漂移检测来管理基线。

# Check a live cluster against the recipe's constraints
aicr validate --recipe recipe.yaml

# Compare a golden baseline against the live cluster, non-zero exit on drift
aicr diff --baseline ./golden.yaml --target cm://default/aicr-snapshot --fail-on-drift

--fail-on-drift 将漂移检查转变为持续集成（CI）门禁，而不仅仅是报告。

认证：证明集群将运行作业

集群现在已构建到已知基线。它仍然需要工作负载验证。标准健康检查确认基本服务正在运行。它们不确认集群能否在其互连上运行要求苛刻的多节点作业而不停滞。NVCRE 通过运行训练作业和 NVIDIA Collective Communication Library (NCCL) 测试来验证工作负载就绪状态。

NVSentinel 管理验证请求、调度门控、隔离和修复，而 NVCRE 运行测试并记录结果。表 1 显示了这些职责如何融入节点验证生命周期。

表 1. 节点验证职责、操作和结果

认证会确定要测试的节点、要运行的类别，以及决定测试通过或失败的阈值：

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
  options:
    thresholds:
      busBandwidthGBps: "value >= 300"

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

报告显示每个类别的状态、运行时间、实测带宽，以及任何失败节点的原因。

阈值使认证成为性能门控。默认不配置任何阈值。如果没有上述 options.thresholds 块，一次运行会报告其测量结果，并在测试无法启动时失败。性能低于目标的节点可以通过。阈值有助于发现性能退化，而不是故障。

该目录涵盖 NCCL 通信变体、NVIDIA Data Center GPU Manager（DCGM）第 4 级诊断套件，以及使用 NVIDIA NeMo Framework 和 80 亿及 560 亿参数模型的预训练工作负载。WorkloadRun 资源可将你自己的容器化测试转变为认证检查。NVCRE 会从目标节点推断其余内容，因此清单在任何受支持的平台上都保持简洁。

这些测试有助于识别遥测中不明显的性能问题。一块性能略低于目标的 GPU 可能不会产生 Xid 错误、不会突破监控阈值，也不会导致节点指标出现异常。这一块 GPU 可能使同步训练作业慢到最慢 rank 的速度，而运维人员可能在数小时后才发现，或者只有在用户投诉后才发现。NCCL 带宽测试可以发现这种性能退化。

隔离原因同样重要。如果 64 节点 all-reduce 产生较差的带宽，那么每个节点都可疑，手动二分排查可能非常耗时。NVCRE 会拆分失败的组并重新运行测试，直到达到最小分组规模，然后报告可疑节点及每个节点的原因。

在将集群或新容量交给租户之前，以及修复后的硬件重新加入资源池时，运行 NVCRE。

运维：负载下的检测与修复

经过认证的集群现在正在运行工作负载，并且需要保持健康。AICR 和 NVCRE 提供时间点验证。NVSentinel 与工作负载一起持续运行。

NVSentinel 监视集群已经产生的信号：DCGM 健康检查、Xid 错误、网络接口卡（NIC）状态和云提供商维护事件。它不消耗 GPU 时间，使 GPU 可供工作负载使用。

NVSentinel 默认以监控模式安装：它将故障报告为节点状况，不会封锁、驱逐或修复节点。你可以在评估其报告的同时，在运行中的集群上推出它。一旦你信任所报告的信号，就可以启用隔离、排空和修复。

检测会发布健康事件；Fault Quarantine 规则集决定节点会发生什么。规则集在 values 文件中使用 Common Expression Language（CEL）表达式：

fault-quarantine:
  ruleSets:
    - enabled: true
      version: "1"
      name: "GPU fatal error ruleset"
      priority: 100
      match:
        all:
          - kind: "HealthEvent"
            expression: "event.agent == 'gpu-health-monitor' && event.componentClass == 'GPU' && event.isFatal == true"
          - kind: "Node"
            expression: |
              !('k8saas.nvidia.com/ManagedByNVSentinel' in node.metadata.labels &&
                node.metadata.labels['k8saas.nvidia.com/ManagedByNVSentinel'] == "false")
      cordon:
        shouldCordon: true
      taint:
        key: "nvidia.com/gpu-error"
        value: "fatal"
        effect: "NoSchedule"

封锁或污点提供了一种信号，你的调度器、告警和生命周期工具可以使用它，而无需直接与 NVSentinel 集成。

断路器通过限制在滑动窗口内可被隔离的 GPU 节点数量来限制影响。Fault Quarantine 配置指南涵盖了边界和其余规则集选项。

并非每个故障都走相同的路径。已知的致命错误会直接进入修复。健康事件分析器通过检测节点故障历史中的模式来处理其他情况，因此反复失败的节点会根据累积记录而非任何单一事件而变得可调查。

推荐操作为 CONTACT_SUPPORT 的健康事件需要手动调查或支持干预。

闭环：就绪状态如何变为持续状态

节点发生故障、被修复，并需要重新加入资源池。节点恢复服务前的验证闭合了运维闭环，但手动交接可能会中断该过程。手动认证产生的是时间点结果，日常运维可能使其过时。必须有人注意到集群发生了变化，重新运行验证，然后读取输出并据此采取行动。NVSentinel 和 NVCRE 可以帮助自动化这一过程。

配置后，两个生命周期事件会自动触发重新验证。当节点加入集群时，以及当节点在修复后返回时，NVSentinel 生命周期控制器会创建 ValidationRequest。它使用封锁或污点对节点上的调度进行门控，然后使用 NVCRE 运行测试并记录结果。控制器评估这些结果，并在测试通过后移除门控，因此仍然无法通过验证的节点不能悄悄重新加入资源池。当你将 nvcre-provider 配置为其测试提供程序时，这些测试就是通过 NVCRE 运行的 NCCL 或 NVIDIA Nemotron 运行：

global:
  lifecycleManager:
    enabled: true

fault-quarantine:
  validation:
    enabled: true

lifecycle-manager:
  config:
    schedulingGate:
      cordon:
        remove: true

lifecycle-manager chart 开启新节点验证；fault-quarantine 标志单独选择启用修复后验证。schedulingGate.cordon 将封锁设置为验证的调度门控，remove: true 在节点测试通过后解除封锁。

对于就地驱动升级、operator 升级或结构变更，过程有所不同。这些变更不会自动触发验证。由于基线是一个文件，当运行中的集群偏离其 recipe 时，aicr diff --fail-on-drift 会使流水线阶段失败，从而为在同一流水线中执行认证运行提供触发条件。

封锁受影响的节点，然后创建一个验证请求，指定这些节点和要运行的测试：

apiVersion: nvsentinel.nvidia.com/v1alpha1
kind: ValidationRequest
metadata:
  name: post-driver-upgrade
spec:
  nodes:
    - name: node-a
    - name: node-b
  tests:
    - nccl-all-reduce
    - nemotron-5b

控制器还会根据结果采取行动。如果请求通过，它会在没有其他测试占用该节点后移除调度门控。如果测试在重试后仍然失败，节点将保持封锁状态。

故障也可能在验证期间出现：GPU 可能在训练测试期间开始热降频。NVSentinel 会隔离该节点，控制器会在修复后重试测试。节点会一直保持门控状态，直到验证通过。

请求和节点都带有可查询的状态：

kubectl get validationrequests
kubectl get nodes -l nvsentinel.nvidia.com/validation-state=validation-failed

恢复无需手动编辑节点：后续通过相同测试的请求会清除失败状态并移除门控。删除所有引用该节点的失败验证请求，可以在不重新运行验证的情况下释放该节点。

交接有明确的边界。NVCRE 止于归因，记录哪些节点失败以及原因；NVSentinel 负责隔离和修复。两个系统同时封锁同一节点可能会产生双重封锁和不同步的清理。

这种分离还使您能够使用自己的节点生命周期工具。平台团队可以消费相同的认证结果并接管 NVSentinel 的角色。扩展该技术栈意味着编写规则集或策略，而不是分叉一个项目。

这对运维人员意味着什么

AICR、NVCRE 和 NVSentinel 帮助运维人员使配置、验证和恢复可重复。启用修复和生命周期验证后，NVSentinel 可以在节点恢复服务前协调修复和测试，减少手动交接。表 2 概述了这些工具处理的内容以及运维人员仍需管理的内容。

表 2. AICR、NVCRE 和 NVSentinel 如何改变运维任务以及哪些职责仍由运维人员承担

开始使用

从项目仓库开始获取安装说明和示例：

• NVIDIA AI Cluster Runtime (AICR)
• NVIDIA Cluster Readiness Engine (NVCRE)
• NVSentinel

您还可以：

• 在 NVIDIA DSX OS AI Inference and Contributor Workshop 上亲身体验这些工具，该活动与 KubeCon + CloudNativeCon North America 同期举行。需要单独注册，座位有限。
• 访问 KubeCon 上的 NVIDIA 170 号展位，了解更多 Kubernetes 深入探讨和现场演示。
• 加入 DSX AI Factory Slack 社区 继续交流。
• 在 NVIDIA DSX AI Factory GitHub 中探索开源、模块化组件。