NVIDIA DSX OS 是一套用于复现 GPU 集群配置基线、通过实际工作负载验证准备状态并监控运行故障的工具。集群运维团队可保留现有部署工具，检查新增容量和修复后的节点，并按配置自动执行隔离与恢复。

1. 用文件固定配置基线，衔接现有部署工具

负责配置基线的 NVIDIA AI Cluster Runtime（AICR）会创建配方，固定网络、存储、驱动程序等组件的版本。配方是一份配置蓝图，规定集群要安装哪些软件以及安装顺序。

AICR 将这份蓝图转换为现有部署工具可使用的产物，即工具生成的部署文件。实际部署和状态协调由现有工具负责，因此运维团队可继续使用当前流水线，也就是依次执行各工作步骤的流程。

配方还包含组件间的依赖关系，即哪些组件须先就绪，以及安装后的状态检查。因此，团队可以对基线进行版本管理和代码审查，也能检测手动变更造成的基线偏离。Kubernetes 可能将含有异常容器的 Pod 标记为运行中，因此逐个组件检查健康状态比仅检查 Pod 状态更重要。

以下命令将运行中的集群与配方基线进行对照，并在偏离基线时返回非 0 退出码，即表示命令执行结果的数字。

# 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

2. 运行实际工作负载，定位慢节点和失败原因

基本健康检查确认服务是否正常运行，而 NVIDIA Cluster Readiness Engine（NVCRE）则测试多个节点能否协同承担实际工作负载。它运行训练任务和 GPU 间通信测试，并记录结果及失败原因。

认证规范是一份列出检查对象和合格标准的文档，规定受检节点、测试类型和通过阈值，即判定是否通过的数值标准。示例配置选择通信与训练测试，并将总线带宽，即数据传输通道的处理能力，合格标准设为每秒至少 300GB。这不是测量结果，而是运维团队设定合格线的示例。

检查列表还包括 GPU 管理工具 DCGM 的级别 4 诊断，以及基于 NVIDIA NeMo Framework 的预训练，即在正式任务前预先训练模型的工作。也可将自有容器测试添加为认证检查。

若 64 个节点的通信测试显示带宽偏低，NVCRE 会反复拆分失败组，测试至最小组大小，并报告可疑节点及原因。单个节点的性能下降可能拖慢整个分布式训练，即多个 GPU 分担的训练任务，因此这有助于发现简单健康指标无法揭示的瓶颈，也就是拖慢整体处理速度的环节。

3. 将故障监控衔接至隔离、恢复后的重新验证

NVSentinel 监控 GPU 诊断和错误信号、网络接口（负责网络连接的设备）的状态，以及云维护事件。据 NVIDIA 介绍，监控不占用 GPU 时间，从而将资源留给正在运行的任务。

默认采用监控模式，将故障报告为节点状态。运维团队评估报告后，可启用自动隔离、任务排空（清空节点上运行任务的流程）和恢复。工具还提供安全机制，限制一定时间内可隔离的节点数量。

可配置为在新节点加入或修复后的节点返回时请求重新验证。验证期间会阻止分配新任务，待检查通过且其他检查的阻止原因也消除后解除限制。重试后仍失败的节点会保持受阻状态。

NVCRE 判断哪些节点因何失败，NVSentinel 则负责隔离与恢复。这种职责分离可减少两个系统重复阻止同一节点、导致清理状态不一致的情况。平台团队也可将认证结果传递给自有节点生命周期管理工具，即管理节点从创建到退役全过程的工具，由其负责运维。

4. 从监控开始引入，合格线与恢复规则由团队决定

这三款工具均以 Apache 2.0 许可证开源，并接受外部贡献。采用时须安装并配置各工具及测试运行环境。在运行中的集群上，可先查看监控报告，再为可信信号关联隔离与恢复规则。

配置自动恢复和重新验证后，可减少将节点修复、检查并重新纳入可用资源时的人工交接。但运维团队须设计并维护适合集群的测试、阈值、隔离规则、恢复限制及负责人响应流程。

性能阈值默认未设置，因此若不指定，低于目标速度的节点也可能通过。驱动程序、管理组件升级或网络变更后，验证不会自动启动，须由运维团队发起。

DSX OS 的价值在于衔接 GPU 集群的基线、验证与恢复，而其自动化范围取决于运维团队制定的检查和规则。