Together GPU 集群自动修复系统解析：从 GPU 故障到健康节点

在集群规模下，GPU 故障是现实问题。Xid 错误、双比特 ECC 错误、GPU 从 PCIe 总线上掉线或 InfiniBand 链路抖动，都可能让分布式训练任务停滞，或使推理副本宕机。发现出了问题通常是最简单的部分。困难的是从故障发生到节点恢复健康之间的所有环节。

今年早些时候，我们宣布推出全自动节点修复功能。我们的 GPU 集群客户和内部推理平台一直在使用这项能力来提升工作负载韧性并最大限度减少停机时间。客户很喜欢这项能力，我们想花些时间拆解这个系统，解释它的工作原理以及我们为何这样设计。

我们首先实现了“被动健康”检查系统，它会持续监控每个节点，既在您的 VM 内部，也在其底层主机上。当检查发现故障时，自动修复会推荐最轻量的修复操作，并向您展示该推荐背后的支持证据。您可以预先逐个故障决定修复是等待批准还是自动执行。您还可以决定自动修复等待运行中工作负载结束的时长。您自己的检测器只需在节点上写入一条注解，就能通过同一管道发起修复。

‍可用性
现已正式可用：被动健康检查、修复建议、自动修复策略（包括按故障和按节点授权）、等待空闲控制、升级阶梯、安全护栏，以及 API 和控制台修复。
预览版：基于节点标签的修复契约，让您可以接入自己的检测系统，例如 NVSentinel 或自定义控制器。
我们正在不断添加新的检测信号和修复操作，以确保最大覆盖范围和最短恢复时间。

为什么 NotReady 还不够

大多数节点自动修复只依赖一个信号：节点变为 NotReady。无论节点是真的坏了还是只是短暂不可达，这个信号看起来都一样。当存储或网络事件同时影响许多节点时，每个受影响的节点都会掉到 NotReady。我们的系统内置了断路器，以防止大规模替换节点。NotReady 也无法说明节点为何失败，因此没有依据在重启和换新机器之间做选择。

因此自动修复遵循一条规则：没有失败的健康检查作为依据，就不进行任何节点修复，且每次修复都附带支持证据。

管道

该管道有四个阶段：检测故障、决定是否以及何时采取行动、修复节点、重新验证机器。前三个阶段在您的集群上运行。第四个阶段在我们这边运行，即在您的节点刚刚腾出的物理主机上。来自您自己检测工具的节点标签请求在决策阶段进入，并获得与我们完全相同的处理。

1. 从 hypervisor 两侧进行检测

Together GPU 集群中的 GPU 直通到您的 VM，以实现裸金属性能。这意味着 GPU 故障从 VM 内部可见，而主机和网络结构故障从主机可见。因此检测在 hypervisor 两侧运行，并汇聚到一处。

在您的 VM 内部，导出器会监控：

• 内核日志，用于检查 Xid 错误和 GPU 从 PCIe 总线上掉线的情况
• DCGM，用于检查 ECC 双比特错误、行重映射失败、PCIe 重放率和热节流
• Node Problem Detector，用于检查只读文件系统、XFS 关闭、内核死锁以及 kubelet 或 containerd 反复重启

在 Slurm 上，一个 exporter 会上报被标记为 DOWN 或 DRAIN 的节点。

在主机上，我们监控 InfiniBand rail 状态和链路抖动，并将其归属到拥有这些 rail 的 VM。我们还会监控主机可达性，因此一台宕机的主机会在你的节点上显示为问题，而不是表现为静默。

每条告警都会附带一个稳定的摘要、一段通俗易懂的描述，以及一份机器可读的证据载荷。对于 Xid，就是每个代码及其 NVIDIA 助记符。对于热节流，就是峰值温度和节流次数。控制平面会原样传递这些字符串，因此控制台、API（以 linked_alerts 形式）和你的通知始终表达相同的内容。

我们将观测到的与可操作的区分开来。每条与修复相关的告警都会被记录，并将你的节点标记为 Degraded。只有具备操作映射的信号才会创建修复。例如，磁盘压力会显示出来，但不会触发重启，因为重启无法解决它。没有映射的告警会被计数并记录，绝不会被静默丢弃，并会转交给我们的支持团队进行调查。

2. 策略：我们决定做什么，你决定是否做以及何时做

做什么由平台负责。每个信号都映射到能修复它的最轻量操作，因此你无需知道哪个 Xid 意味着什么：

是否做由你决定。在 Repairs 标签页中，Auto-remediation policy 默认为 Approve before repair：每条建议都会等待人工处理，由人工接受或覆盖该操作。你可以将默认值切换为 Fully automatic，但它不是一刀切的开关。Repair actions 清单按故障触发的修复对故障进行分组，你可以选择信任哪些修复来无人值守运行。在 Xid 组内，你可以按代码设置同意。一种常见设置会自动批准 Xid 119 和 95 的重启，并对迁移保持门控。如果你希望让一小部分故障自动运行，而其他所有故障都等待你审查，Xid 清单在 Approve before repair 下也同样有效。

何时做也由你决定。修复会排空节点，因此 Wait for idle 会一直保持，直到节点真正空闲。在 Kubernetes 上，这意味着节点上没有正在运行的 Pod 请求 GPU。在 Slurm 上，这意味着调度器报告该节点上没有分配。Maximum wait 会限制等待时长，默认 2 小时，上限 24 小时。Do not interrupt running jobs 会完全移除该限制。请将等待时间设置为至少等于你的检查点间隔。如果限制到期，修复会继续执行，并记录超时。

每次修复都会记录是谁请求的（自动修复为 Together Health Checker）、是谁批准的（具名用户或 Auto-Approved）、由哪条规则决定以及何时决定。

3. 自带检测器

运行大型 GPU 集群的团队已经拥有他们信任的检测手段：DCGM 仪表盘、NVSentinel、内部扫描器、作业级检查。每次修复，无论来源如何，都会在我们的控制平面中成为同一条记录。这为容量检查、审计和安全护栏提供了唯一的归属。

有三种接入方式：

• API。针对某个实例创建修复，需指定模式、可选的客户端提供 ID（用于幂等），以及可选地指定你作为证据引用的健康检查运行或告警。你还可以列出、获取、批准、拒绝和取消修复。
• 控制台。任意节点上的 ⋮ 菜单会打开 Repair 对话框，其中显示检测到的问题和建议的操作。
• 节点标签（预览）。任何拥有写入节点元数据 RBAC 权限的检测器，都可以通过向节点添加一个注解和一个标签来发起修复。注解携带检测器名称、稳定的请求 ID、修复模式、故障检测时间以及人类可读的原因。

我们的集群操作器会将节点 label 镜像到控制平面。修复记录中检测器作为外部请求者，因此始终可归因，且永远无法冒充用户。检测器名称加请求 ID 是整个集群的幂等键（包括已完成的修复），因此每次扫描都重复断言同一故障的检测器无法让节点重启两次。授权使用集群自身的 RBAC，无需 API 密钥，也无需入职工单。

注解请求可以要求 Reboot、Quick reprovision 或 Migrate。Remove 仅限人工操作。与控制台点击一样，这些请求会跳过审批队列，但仍需通过与其他所有操作相同的证据门禁、容量检查和预算限制。每集群上限意味着有缺陷的检测器造成的损害有限，而不会酿成灾难。

4. 修复操作与升级阶梯

每次修复都遵循相同的生命周期：cordon、等待（按你的策略）、drain、执行操作、重新加入。控制台会显示节点依次经历 Cordoning → Draining → Repairing / Migrating → Joining → Running。

操作按从轻到重排列：

• Reboot。就地重启 VM。本地 /scratch 和 /tmp 数据保留。
• Quick reprovision。在健康主机上从干净镜像重建 VM。本地数据丢失。
• Migrate to new host。在不同硬件上重建 VM，并将旧主机送去重新验证。
• Remove。将节点拉出以进行 RMA。始终由人工发起。

同一修复不会循环。如果同一操作已在同一台机器上执行过两次后故障再次出现，下一次建议会上升一级。第三轮 Xid 重启会变为重新置备，第三次重新置备会变为迁移。该阶梯按机器、集群、告警和 Xid 代码分别跟踪。超过一周的尝试不计入，已取消或自行解决的推荐也不计入。

迁移受证据门禁限制。Migrate 是唯一会消耗真实容量的操作。它要求节点上当前有严重告警正在触发，或同一机器在过去十天内有过严重告警。两个条件都不满足的请求将改为执行 Quick reprovision。

主机电源循环（预览）。某些故障（包括 Xid 79）需要 GPU 断电，而 VM 重启无法做到这一点，即使硬件可能完好。与其消耗新主机，我们可以对你当前所在的主机进行电源循环。系统中任何地方都不存在 BMC 凭据。启动 ID 检查可防止重试对已经恢复的主机再次进行电源循环。

需要保证替换窗口的集群可以预留热备容量，这样迁移会从该预留中取用，而不是从常规可用容量中取用。详情请咨询您的客户团队。

5. 假设告警风暴会发生的防护栏

一次糟糕的驱动推送、一次存储中断或一次网络分区，都可能让数十个节点同时看起来异常。节点级修复无法解决集群级原因，因此这些防护栏是分层且相互独立的：

• 持久性。信号必须持续达到每个信号的持续时间，才会成为建议。
• 冷却期。任何修复之后，节点大约有 30 分钟才会生成新的建议。
• 并发预算。预算根据集群节点数量确定，操作员一次在每个节点池中执行一次修复。
• 断路器。当一个集群产生突发性的相关自动修复时，断路器会跳闸。许多节点同时故障指向集群级原因，逐个修复节点无法解决。
• 每次修复一个目标。schema 强制要求这一点，因此一个 bug 无法扩散到多个节点。
• 自动解决。如果建议对应的告警在任何人采取行动之前清除，该建议会自动消失。

控制平面是复制的，每次写入都是幂等的，并会对照其预期的状态进行检查。两个副本在同一节点上竞争时，只会产生一次修复，而不是两次。

6. 机器会自我重新验证

当节点从一台机器迁移走，或从一台机器上移除时，该机器不应直接回到池中，也不应坐在队列中等待有人读取诊断信息。旧 VM 一消失，机器就会自动进入验证。测试 VM 会运行与每台全新机器加入集群前相同的 GPU、NCCL、InfiniBand 和存储检查。从您的节点离开到结果落地之间，没有人会碰这台机器。

共有三种结果：

• 通过。机器返回池中。不提交工单，也不呼叫任何人，因此瞬时故障保持为瞬时故障。
• 失败。自动提交硬件工单，并附上每项测试的结果和日志。机器会保持停用状态，直到修复并再次通过。
• 中止。检查无法运行，例如主机被重新分配或测试 VM 无法放置。机器会恢复到之前的状态，不会判定任何东西有问题。

只有明确的失败才会产生工单。

设计上可扩展到单一加速器之外

修复决策依据的是告警、节点和机器，而不是 GPU 厂商。GPU 类型对放置和容量很重要，但建议、策略、升级、预算、触发器和重新验证并不对其做特殊处理。厂商相关的部分是检测（Xid 和 DCGM 导出器）和诊断测试组。引入新的加速器意味着添加这些部分，下游的一切都会沿用。

使用方式

在控制台中打开您的集群，进入修复标签页。待处理的建议和历史记录都在那里，顶部是自动修复策略。API 中的每个修复都带有其 linked_alerts，因此您自己的工具看到的证据与控制台相同。

下一步

• NVSwitch 覆盖。SXid 故障，按节点合并，并提供可读的描述。
• 状态回写到节点。修复进度作为节点元数据写回，因此外部检测器可以在它们发现问题的地方闭环处理。
• 统一健康视图。从失败的检查点击到它触发的修复，再返回，另外还有每个节点的健康、事件和修复历史视图。

告诉我们你的集群上还有哪些我们尚未捕获的故障。这份清单将决定我们接下来构建什么。

-> 在控制台中开始使用
-> 文档：节点修复 · 健康检查