数据中心 / 云 使用 NVIDIA DSX OS 配置、认证和运维 Kubernetes GPU 集群 Glowing green modular cube with gauge, clock, and gear icons on a black background. 2026年11月5日 作者： Sowmyan Soman 和 Kai Wombacher 讨论 (0)

AI 生成的摘要

  • NVIDIA DSX AI 工厂平台 提供了一个名为 NVIDIA DSX OS 的开源软件层，用于配置、认证和维护加速的 Kubernetes 基础设施。
  • NVIDIA AI Cluster Runtime（AICR）定义了版本锁定的配置配方，包含固定版本、依赖关系图和健康断言，然后将其渲染为供 Argo CD、Flux 和 Helm 等部署工具使用的捆绑包。
  • NVIDIA Cluster Readiness Engine（NVCRE）通过运行 NCCL 通信测试和训练工作负载（可配置性能阈值）来验证工作负载就绪状态，并对失败的组进行二分定位以识别可疑节点。
  • NVSentinel 持续监控 GPU、节点和网络健康信号，发布节点状况，并在启用后可封锁、驱逐和修复故障节点，然后再触发 NVCRE 重新验证。
  • 生命周期控制器在节点加入集群或修复后返回时自动执行验证，使其在测试通过前保持门控状态，而 AICR 漂移检测 可在驱动升级等基础设施变更后触发认证运行。

后续步骤

由 NVIDIA Nemotron 提供支持。AI 生成的内容可能不完整地概括信息。请核实重要信息。 了解更多

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

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

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

NVIDIA NVIDIA DSX AI 工厂平台 汇集了用于设计、构建和运营高效、有韧性的 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。 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 在渲染 bundle 时解析依赖图，因此顺序已经编码在你的部署器所应用的产物中。你无需指定 cert-manager 排在 NVSentinel 之前，而且之后添加组件也不需要重新编号。
  • 各组件的健康断言： 每个条目都带有一个 healthCheckAsserts 安装后运行的块，用于检查组件是否满足其配置的健康标准。Kubernetes 可能报告某个 Pod 卡在 CrashLoopBackOff ， 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 集合通信库（NCCL）测试来验证工作负载就绪状态。 （NCCL） 测试。

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

步骤负责组件操作结果
1. 请求与门禁NVSentinel 生命周期管理器；用于升级或网络结构变更的运维操作器为新的或修复后的节点创建一个 ValidationRequest 对于新增或修复的节点。在升级或网络结构变更后，运维人员会封锁节点并创建请求。在验证期间，封锁（cordon）或污点（taint）会阻止在节点上进行调度。
2. 测试与归因NVCRE 通过 nvcre-provider运行工作负载和诊断测试。对失败的组进行二分定位，以识别可疑节点。测试结果会识别出可疑节点。NVCRE 不会改变节点状态。
3. 记录与评估NVCRE 与 NVSentinel 生命周期管理器NVCRE 会记录通过/失败结果、失败的节点 ID 以及失败原因，记录在 Certification 资源。生命周期管理器会评估结果。验证结果决定是否可以移除调度门禁。
4. 解除门禁NVSentinel 生命周期管理器根据验证结果以及任何剩余的测试，移除或保留调度门禁。通过： 在不再有其他测试占用该节点后，移除已配置的门禁。 重试后失败： 保持节点封锁。
表 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 数据中心 GPU 管理器（DCGM）第 4 级诊断套件，以及使用 NVIDIA NeMo Framework 和 80 亿与 560 亿参数模型进行的预训练工作负载。一个 WorkloadRun 资源会将你自己的容器化测试转变为认证检查。NVCRE 会从目标节点推断其余信息，因此清单在任何受支持的平台上都能保持简洁。

这些测试有助于发现遥测数据中不明显的性能问题。一块仅略低于其性能目标的 GPU 可能不会产生 Xid 错误、不会触发监控阈值，也不会导致节点指标出现异常。但这一块 GPU 就可能把同步训练作业拖慢到最慢的 rank 水平，而运维人员可能要数小时后才会发现，或者只有在用户投诉后才会察觉。NCCL 带宽测试可以揭示这种性能退化。

隔离原因同样重要。如果 64 节点全归约的带宽表现不佳，那么每个节点都有嫌疑，而手动二分排查可能非常耗时。NVCRE 会拆分失败的组并重新运行测试，直到达到最小分组规模，然后报告可疑节点并为每个节点给出原因。

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

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

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

NVSentinel 监控集群已经产生的信号：DCGM 健康检查、Xid 错误、网络接口卡（NIC）状态以及云服务商的维护事件。它不占用 GPU 时间，从而让 GPU 可用于工作负载。

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

检测功能会发布健康事件；故障隔离规则集会决定节点的后续处理方式。规则集会在你的 values 文件中使用通用表达式语言（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 节点数量来限制影响范围。 故障隔离配置指南 涵盖边界以及规则集的其余选项。

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

需要人工排查或支持介入的健康事件。 CONTACT_SUPPORT 需要人工排查或支持介入。

循环：就绪状态如何变为持续验证

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

配置后，有两个生命周期事件会自动触发重新验证。NVSentinel 的生命周期控制器会在节点加入集群时创建一个 ，并在节点修复后重新返回时再次创建。它使用封锁或污点对节点进行调度门控，然后使用 NVCRE 运行测试并记录结果。控制器会评估这些结果，并在测试通过后移除门控，因此仍然无法通过验证的节点无法悄悄重新加入资源池。当你配置 作为其测试提供程序时，这些测试就是通过 NVCRE 运行的 NCCL 或 NVIDIA Nemotron 运行：该 chart 会开启 n 生命周期控制器 会创建一个 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 将封锁（cordon）设置为验证的调度门控，并且 remove: true 测试通过后解除对节点的封锁。

对于就地驱动升级、Operator 升级或 Fabric 变更，流程有所不同。这些变更不会自动触发验证。由于基线是一个文件， 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 概述了这些工具负责处理的内容以及运维人员仍需管理的内容。

运维任务带来了哪些变化运维人员仍需管理的内容
维护软件基线AICR 提供版本锁定的配方，并为现有部署工具生成配置产物。运维人员可以审查与既定基线的偏差。批准基线变更，部署产物，运行漂移检查，并协调差异。
验证新增或修复的容量NVCRE 运行选定的工作负载和诊断，并记录就绪结果。配置生命周期验证后，NVSentinel 可以在节点恢复服务前协调测试。选择适合该集群的测试和阈值，并调查失败的结果。
恢复不健康的节点启用后，NVSentinel 会协调隔离、驱逐、修复和重新验证，减少这些操作之间的人工交接。定义隔离规则、修复限制和升级流程；处理自动修复无法解决的故障。
验证基础设施变更运维人员可以将基线检查和工作负载验证纳入其升级工作流。在就地更改驱动、算子或架构后触发验证；这些更改不会自动触发重新验证。
表 2. AICR、NVCRE 和 NVSentinel 如何改变运维任务，以及哪些职责仍由运维人员承担

开始使用

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

你还可以：

讨论（0）

标签

Agentic AI / 生成式 AI | 数据中心 / 云 | 开发者工具与技术 | 通用 | DSX | 中级技术 | 深入解析 | 云服务 | Kubernetes | 开源

关于作者

Avatar photo 关于 Sowmyan Soman
Sowmyan 是 NVIDIA DSX OS 团队的首席产品开发者关系经理。他与开发者、客户和生态系统合作伙伴合作，加速 NVIDIA AI 基础设施软件的采用，并与产品和工程团队协作，满足真实世界的需求。他专注于 Kubernetes、云原生平台、GPU 计算、编排和开源技术。他拥有信息技术学位，拥有近二十年的经验，致力于构建开发者生态系统，并帮助合作伙伴交付可扩展、可用于生产的 AI 基础设施。 查看 Sowmyan Soman 的所有文章 Kai Wombacher 关于 Kai Wombacher
Kai Wombacher 是 NVIDIA 的产品经理，专注于 AI 基础设施中 Kubernetes 的运维质量。他的工作核心是集群健康、可用性、性能和可观测性。他帮助定义健康的 GPU 集群应具备的特征，并构建工具，使团队能够在问题进入生产环境之前将其捕获。在加入 NVIDIA 之前，Kai 在 IBM/Kubecost 工作了三年半，领导 Kubernetes 成本优化、可观测性和 FinOps 的产品战略。他帮助平台团队在规模化场景下理解并控制 Kubernetes 支出。 查看 Kai Wombacher 的所有文章

评论