发布于 2026 年 10 月 27 日
Together GPU 集群的自动修复：从 GPU 故障到健康节点健康检查发现故障，平台选择最轻量的修复措施，而您决定在无需人工介入的情况下运行什么，直至具体的 Xid 代码。
作者
Pavneet Ahluwalia、Dongsheng Zhang、Barbara Kazanowska
目录
本文中的链接
在集群规模下，GPU 故障是现实。Xid 错误、双比特 ECC 错误、GPU 从 PCIe 总线上掉线或 InfiniBand 链路抖动，都可能使分布式训练任务停滞，或导致推理副本下线。发现出了问题通常是最简单的部分。困难的是从故障到节点再次恢复健康之间的所有环节
今年早些时候，我们宣布推出全自动节点修复功能。我们的 GPU 集群客户和内部推理平台一直在使用这一能力，以帮助提升工作负载韧性并最大限度减少停机时间。我们的客户非常喜欢这一能力，我们想花些时间拆解这个系统，解释它的工作原理以及我们为何这样设计。
我们首先实现了“被动健康”检查系统，它会持续监控每个节点，既在您的 VM 内部，也在其底层主机上。当检查发现故障时，自动修复会推荐最轻量的修复措施，并向您展示该推荐背后的支持证据。您可以预先逐个故障决定修复是等待批准还是自行运行。您还可以决定自动修复等待运行中工作负载完成的时间。您自己的检测器可以通过在节点上写入单个注解，经由同一流水线发起修复。
可用性
现已正式提供： 被动健康检查、修复建议、自动修复策略（包括按故障和按节点授权）、等待空闲控制、升级阶梯、安全护栏，以及 API 和控制台修复。
预览： 基于节点标签的修复契约，让您可以接入自己的检测系统，例如 NVSentinel 或自定义控制器。
我们不断添加新的检测信号和修复操作，以确保最大覆盖范围和最短恢复时间。
为什么 NotReady 还不够
大多数节点自动修复都依赖单一信号：节点变为 NotReady。无论节点是真的坏了还是只是短暂不可达，这个信号看起来都一样。当存储或网络事件同时影响许多节点时，每个受影响的节点都会降为 NotReady。我们的系统内置了熔断机制，以防止大规模替换节点。NotReady 也无法说明节点为何失败，因此没有依据在重启和更换新机器之间做出选择。
因此自动修复遵循一条规则： 没有失败的健康检查作为依据，就不会进行任何节点修复，而且每次修复都附带其支持证据。
流水线
该流水线有四个阶段：检测故障、决定是否以及何时采取行动、修复节点、重新验证机器。前三个阶段在您的集群上运行。第四个阶段在我们这边运行，在您的节点刚刚腾出的物理主机上执行。来自您自己检测工具的节点标签请求在决策阶段进入，并获得与我们完全相同的处理。
1. 从虚拟机监控程序两侧进行检测
Together GPU 集群中的 GPU 直通到您的 VM，以实现裸金属性能。这意味着 GPU 故障从 VM 内部可见，而主机和网络结构故障从主机可见。因此检测在虚拟机监控程序两侧运行，并汇聚到一处。
在您的 VM 内部, 导出器监控：
- 内核日志，用于发现 Xid 错误和 GPU 从 PCIe 总线上掉线
- DCGM，用于发现 ECC 双比特错误、行重映射失败、PCIe 重放率和热降频
- 节点问题检测器，用于发现只读文件系统、XFS 关闭、内核死锁以及 kubelet 或 containerd 反复重启
在 Slurm 上，导出器会报告被标记为 DOWN 或 DRAIN 的节点。
在主机上, 我们监控 InfiniBand 通道状态和链路抖动，并将其归因于拥有这些通道的 VM。我们还监控主机可达性，因此死掉的主机会在您的节点上显示为问题，而不是一片沉默。
每个告警都附带稳定的摘要、通俗语言的描述和机器可读的证据载荷。对于 Xid，就是每个代码及其 NVIDIA 助记符。对于热降频，就是峰值温度和降频次数。控制平面原样传递这些字符串，因此控制台、API（作为 linked_alerts）和您的通知始终表达相同的内容。
我们将观测与可操作区分开来。每个与修复相关的告警都会被记录，并将您的节点标记为 Degraded. 只有具有操作映射的信号才会创建修复。例如，磁盘压力会显示出来，但不会触发重启，因为重启无法解决它。没有映射的告警会被计数并记录，绝不会被静默丢弃，并会转交我们的支持团队进行调查。
2. 策略：我们决定做什么，您决定是否以及何时做
做什么 由平台负责。每个信号都映射到能修复它的最轻量操作，因此您无需知道哪个 Xid 意味着什么：
是否 由您决定。在“修复”选项卡中， 自动修复策略 默认为 修复前批准: 每个建议都等待人工处理，人工可以接受或覆盖该操作。您可以将默认值切换为 全自动, 但它不是一刀切的开关。 修复操作 检查清单会按故障所触发的修复操作对故障进行分组，你只需选择那些你信任、可无人值守运行的项。在 Xid 分组内，你可以按代码设置是否同意。一种常见配置会自动批准 Xid 119 和 95 的重启，而对迁移保持需审批。如果你希望只让一小部分故障自动运行、其余都等待你审核，Xid 检查清单在“修复前批准”模式下同样适用。
“何时” 也由你决定。修复会排空节点，因此“ 等待空闲 ”会一直保持，直到节点真正空闲。在 Kubernetes 上，这意味着节点上没有正在运行的 Pod 请求 GPU。在 Slurm 上，这意味着调度器报告该节点上没有分配。 “最长等待” 会限制保持时长，默认 2 小时，上限 24 小时。 “不中断正在运行的作业” 会完全移除该限制。请将等待时间设置为至少等于你的检查点间隔。如果限制到期，修复会继续执行，并记录超时。
每次修复都会记录是谁请求的（Together Health Checker 表示自动修复）、是谁批准的（具名用户或 “自动批准”）、由哪条规则决定，以及何时发生。
3. 自带检测器
运行大规模 GPU 集群的团队已经有自己信任的检测手段：DCGM 仪表盘、NVSentinel、内部扫描器、作业级检查。无论来源如何，每次修复在我们的控制平面中都会成为同一种记录。这样，容量检查、审计和安全护栏就只有一个统一入口。
接入方式有三种：
- API。 针对某个实例创建修复，指定模式、可选的客户端提供 ID（用于幂等），以及可选地指定你作为证据引用的健康检查运行或告警。你还可以列出、获取、批准、拒绝和取消修复。
- 控制台。 任意节点上的 ⋮ 菜单会打开 “修复” 对话框，其中显示检测到的问题和推荐操作。
- 节点标签（预览）。 任何拥有写入节点元数据 RBAC 权限的检测器，都可以通过向节点添加一个注解和一个标签来发起修复。注解携带检测器名称、稳定的请求 ID、修复模式、故障检测时间以及人类可读的原因。
我们的集群操作器会将节点 label 同步到控制平面。修复会以检测器作为外部请求者记录，因此始终可归因，且绝不能冒充用户。检测器名称加请求 ID 是跨集群的幂等键，已完成的修复也包括在内，因此每次扫描都重复断言同一故障的检测器无法让节点重启两次。授权使用你集群自身的 RBAC，无需 API 密钥，也无需入职工单。
注解请求可以要求重启、快速重新置备或迁移。移除仍仅限人工操作。与控制台点击一样，这些请求会跳过审批队列，但仍会像其他所有请求一样通过相同的证据门禁、容量检查和预算限制。每集群上限意味着有缺陷的检测器只会造成有限损害，而不是灾难。
4. 修复操作与升级阶梯
每次修复都遵循相同的生命周期：封锁、等待（按你的策略）、排空、执行、重新加入。控制台会显示节点依次经历 “封锁 → 排空 → 修复/迁移 → 加入 → 运行”.
这些操作从最轻到最重依次为：
- 重启。 就地重启 VM。本地
/scratch和/tmp数据会保留。 - 快速重新置备。 在健康主机上从干净镜像重建 VM。本地数据会丢失。
- 迁移到新主机。 在不同硬件上重建 VM，并将旧主机送去重新验证。
- 移除。 将节点拉出以进行 RMA。始终由人工发起。
同一修复不会循环。 如果同一台机器上同一故障在同一操作已执行两次后再次出现，下一次建议会上升一级。第三轮 Xid 重启会变为重新置备，第三次重新置备会变为迁移。该阶梯按机器、集群、告警和 Xid 代码分别跟踪。超过一周的尝试不计入，已取消或自行解决的推荐也不计入。
迁移受证据门禁限制。 迁移是唯一会消耗真实容量的操作。它要求节点上当前有严重告警正在触发，或同一机器在过去十天内出现过严重告警。两个条件都不满足的请求会改为执行快速重新置备。
主机电源循环（预览）。 某些故障（包括 Xid 79）需要 GPU 断电，而 VM 重启无法做到这一点，即使硬件可能完好。我们不必消耗新主机，而是可以对当前所在主机执行电源循环。系统中任何地方都不存在 BMC 凭据。启动 ID 检查可防止重试时对已经恢复的主机再次执行循环。
需要保证替换窗口的集群可以预留 热备 容量，这样迁移会从该预留中取用，而不是从一般可用容量中取用。详情请联系你的客户团队。
5. 假设告警风暴一定会发生的护栏
一次糟糕的驱动推送、一次存储中断或一次网络分区，都可能让数十个节点同时看起来异常。节点级修复无法解决集群级原因，因此护栏是分层且相互独立的：
- 持续性。 信号必须持续达到每个信号对应的时长，才会成为推荐。
- 冷却期。 任何修复之后，节点大约有 30 分钟才会生成新的推荐。
- 并发预算。 预算根据集群节点数量设定，操作器每个节点池一次只运行一个修复。
- 断路器。 当一个集群产生一批相关的自动修复时，断路器会跳闸。许多节点同时故障指向集群级原因，逐个修复节点无法解决。
- 每次修复只有一个目标。 模式强制要求这一点，因此缺陷无法扩散到多个节点。
- 自动解决。 如果推荐对应的告警在任何人采取行动前已清除，该推荐会自动消失。
控制平面是复制的，每次写入都是幂等的，并会对照其预期状态进行检查。两个副本在同一节点上竞争只会产生一次修复，而不是两次。
6. 机器会自我重新验证
当节点从某台机器迁移走或被移除时，该机器不应直接回到资源池，也不应排队等待有人查看诊断信息。旧虚拟机一消失，机器就会自动进入验证流程。测试虚拟机会运行与每台全新机器加入集群前相同的 GPU、NCCL、InfiniBand 和存储检查。从你的节点离开到结果产生，全程无需人工介入。
共有三种判定结果：
- 通过。 机器返回资源池。不会创建工单，也不会有人被呼叫，因此瞬时故障仍保持为瞬时故障。
- 失败。 系统会自动创建硬件工单，并附上各项测试结果和日志。机器会保持停用状态，直到修复并再次通过检查。
- 中止。 检查无法运行，例如主机被重新分配或测试虚拟机无法放置。机器会恢复到之前的状态，不会有任何机器被判定为故障。
只有明确的失败才会产生工单。
设计上可扩展到单一加速器之外
修复决策依据的是告警、节点和机器，而不是 GPU 厂商。GPU 类型对放置和容量有影响，但推荐、策略、升级、预算、触发器和重新验证都不会对其做特殊处理。与厂商相关的部分是检测（Xid 和 DCGM 导出器）和诊断测试组。接入新的加速器意味着添加这些部分，而下游的一切都可以沿用。
使用方式
在控制台中打开你的集群，然后转到 修复 标签页。待处理的推荐和历史记录都在那里，顶部是 自动修复策略 。API 中的每个修复都带有其 linked_alerts,因此你自己的工具能看到与控制台相同的证据。
后续计划
- NVSwitch 覆盖。 SXid 故障，按节点合并，并提供可读的描述。
- 状态回写到节点。 修复进度会作为节点元数据写回，这样外部检测器可以在它们发现问题的地方闭环。
- 统一健康视图。 从失败的检查点击到它导致的修复，再点击返回，另外还有每个节点的健康、事件和修复历史视图。
告诉我们你的集群上还有哪些我们尚未捕获的故障。这份清单将决定我们接下来构建什么。
-> 在控制台中开始使用
-> 文档： 节点修复 · 健康检查