图形处理器节点故障后，云原生任务如何恢复？

图形处理器（GPU）节点故障在云原生环境中不是“会不会发生”的问题，而是“多久发生一次”的问题。大规模 GPU 集群中，XID 错误、ECC 内存错误、设备丢失、温度过高等硬件异常几乎是日常运维的一部分。恢复策略如果只围绕“重启 Pod”设计，长时训练任务依然会中断，推理服务依然会掉线。核心结论是：恢复策略必须按任务类型设计——无状态推理服务追求“快速转移”，有状态长时训练追求“断点续跑”，两者的检测手段、隔离粒度、重试语义和验收标准完全不同。自动重试只是恢复流程的一个环节，不等于业务恢复。

先分清两类任务：恢复目标完全不同

设计恢复策略之前，先回答一个问题：这个任务中断后，代价是什么？

无状态推理服务的典型形态是 Deployment 管理的多个副本，请求通过负载均衡分散到各个 GPU 节点。单个节点故障时，副本被重新调度到健康节点即可，用户侧感知到的可能只是少量请求超时或延迟抖动。这类任务的恢复核心是“快速转移”——缩短故障发现时间、加快重新调度速度、避免把新流量继续打到故障节点。

长时训练任务则完全不同。一个分布式训练任务可能运行数天甚至数周，依赖多个 GPU 节点协同工作，并且需要定期保存检查点（checkpoint）。节点故障意味着训练进程中断，如果检查点保存不及时，丢失的可能是一整天的计算进度。这类任务的恢复核心是“断点续跑”——从最近一次有效的检查点恢复训练状态，而不是从头开始。

把这两类任务混用同一套恢复策略，是运维中最常见的误区。给推理服务配置严格的故障转移没问题，但给训练任务也这么做，可能导致每次硬件抖动都触发全量重启；反过来，给推理服务配置训练任务那样的检查点机制，则完全是资源浪费。

健康检查：故障发现的速度决定恢复的下限

恢复流程的第一步是发现故障。Kubernetes 原生的节点状态检查（Node Condition）和容器探针（Probe）只能覆盖“进程是否存活”这一层面，对 GPU 硬件故障几乎无感知。GPU 设备可能已经出现 ECC 内存错误，但容器进程仍在运行，业务表现只是性能下降或偶发计算错误——这种“半死”状态比彻底宕机更难处理。

生产环境通常依赖 Node Problem Detector（NPD） 这类组件来扩展故障检测能力。NPD 运行在节点上，持续监控 GPU 设备状态，能够捕获 XID 错误、ECC 内存错误、温度异常、设备丢失等硬件级故障，并通过 Kubernetes Event、Node Condition 等方式上报。腾讯云 TKE 的 GPU 故障检测方案就是基于 NPD 实现实时检测，再配合 Node-Healing 组件执行自愈操作。阿里云 ACK 也提供了类似的 ack-node-problem-detector 组件。

检测到的故障需要分级处理。以阿里云 GPU-HPN 节点故障处理为例，节点异常时会通过 Node Label 标记（如 alibabacloud.com/node-anomaly: "true"）、增加污点（Taint）来阻止新 Pod 调度到故障节点，同时通过 Event 和 Condition 上报故障原因。华为云 CCE 的做法类似：单个 GPU 出现故障时自动隔离，其他正常 GPU 继续提供服务。

这里有一个容易被忽略的点：检测项要区分“节点级故障”和“设备级故障”。节点级故障（如宕机、网络分区）影响节点上所有 GPU，处理方式是整个节点下线；设备级故障（如单张 GPU 的 ECC 错误）只影响部分设备，如果节点上还有其他健康 GPU，可以考虑只隔离故障设备，而不是把整个节点清空。腾讯云的 TKE 支持按 GPU 设备维度配置自愈策略，正是为了减少不必要的任务迁移。

故障转移：隔离、驱逐、修复、恢复的完整链路

故障从发现到恢复，完整链路大致包含四个阶段：

标记与隔离。节点被标记异常后，调度器不会再往该节点分配新任务。这一步的关键是污点（Taint）的传播速度——如果标记延迟，新任务可能继续调度到故障节点，造成二次失败。

驱逐与排空。对节点上的已有 Pod 执行驱逐（Eviction），将它们从故障节点上移走。这里需要关注驱逐策略的差异化：推理服务可以立即驱逐并重新调度；训练任务则最好先等待进程保存检查点，或者由任务控制器自行决定何时安全退出。阿里的 ACS 提供了 acs-instance-helper 组件，支持硬件异常实例的自动轮转，本质上是把驱逐和重建流程自动化。

修复与自愈。节点被清空后，云厂商或自建平台会尝试修复故障——可能是重启节点、重置 GPU 驱动，也可能是直接更换物理设备。腾讯云的 Node-Healing 组件可以自动执行隔离、排空、重启等自愈操作，并支持配置 unhealthyConditions 和 nodeHealingPolicy 来控制自愈行为。

恢复与解除隔离。节点修复完成后，污点和异常标记被移除，节点重新回到调度池。这一步需要验证 GPU 设备确实恢复正常，而不是修复后带着隐性故障再次上线。

整个流程中，最容易出问题的是驱逐与训练任务检查点之间的协作。Kubernetes 的默认驱逐机制不会等待训练进程保存状态，直接杀掉 Pod 可能导致训练进度丢失。生产实践中通常有两种解法：一是训练框架自行处理节点故障（如 PyTorch 的弹性训练模式），Pod 被驱逐前通过 preStop 钩子触发检查点保存；二是利用任务控制器（如 Volcano、KubeFlow 的 Training Operator）的 PodGroup 和重调度策略，在节点故障时先触发检查点保存，再执行驱逐。

无状态推理与长时训练的恢复策略对比

两类任务在恢复策略的每个环节上都有不同选择，整理如下：

一个常见的认知误区是“自动重试 = 业务恢复”。对推理服务来说，副本重启后能正常处理请求，可以视为业务恢复；但对训练任务来说，Pod 重启只是恢复流程的开始，训练框架需要重新加载模型权重、恢复优化器状态、重新建立分布式通信组，这些步骤完成之前，训练任务并没有真正恢复。

以 PyTorch 分布式训练为例，节点故障后通常涉及 torch.distributed 的通信组重建。如果使用弹性训练模式（Elastic Training），torch.distributed.elastic 会检测到 worker 数量变化，触发新一轮的 rendezvous（会合），等待新 worker 加入后从检查点恢复训练。这个过程可能持续数分钟，期间 GPU 资源处于空闲状态——如果自动重试策略只关注“Pod 是否重建”，很可能在通信组尚未重建时又触发新一轮重启，形成“重启风暴”。

验收指标：用演练验证恢复能力

恢复策略不能只在故障发生时被动响应，需要通过演练验证和持续改进。建议从以下几个指标设计验收方案：

故障发现时间（MTTD）：从故障发生到系统感知的时间。可以通过人为注入 GPU 故障（如使用 nvidia-smi 模拟 XID 错误）来测量。目标值通常应控制在秒级到分钟级，取决于 NPD 的轮询频率和事件上报延迟。

故障转移时间（MTTR 的一部分）：从发现故障到业务恢复的时间。对推理服务，可以测量“故障注入 → 副本重新调度 → 新副本 Ready → 流量恢复”的完整链路耗时；对训练任务，则应测量“故障注入 → 检查点保存 → Pod 重建 → 训练恢复”的耗时。

恢复点目标（RPO）：训练任务最多能容忍丢失多少训练进度。RPO 取决于检查点保存频率——每 10 分钟保存一次检查点，RPO 就是最近 10 分钟的训练进度；每 2 小时保存一次，RPO 就是 2 小时。需要根据训练成本来权衡：检查点保存本身有 I/O 开销，频率越高，对训练性能的影响越大。

资源浪费率：故障转移过程中的 GPU 空闲时间。训练任务在等待检查点恢复时，已分配的 GPU 可能处于空闲状态，这部分资源成本需要在恢复策略中显式考虑。

演练的设计应该覆盖不同故障级别：单张 GPU 故障、整节点故障、节点网络分区、GPU 驱动异常。每一类故障的检测路径和处理路径都不同，只演练“节点宕机”这一种场景远远不够。

软盟资讯观察

GPU 故障自愈正在从“可用性工程”演变为“成本工程”。从腾讯云 NPD + Node-Healing 到阿里云 GPU-HPN 节点自动轮转，主流云厂商的恢复链路已经高度相似：检测、标记、驱逐、修复、恢复，流程标准化程度越来越高。但标准化也带来了新的权衡——自动隔离和自动重启降低了运维负担，却可能掩盖真正的故障根因。如果一张 GPU 反复出现 ECC 错误，每次都自动恢复而不追溯硬件质量，集群的“自愈能力”反而成了硬件劣化的遮羞布。

机会在于，弹性训练和检查点机制的成熟正在改变长时训练任务的恢复语义，RPO 可以压缩到分钟级，这为更激进的任务调度策略提供了空间。风险在于，恢复流程的自动化程度越高，对故障注入演练的要求也越高——没有经过演练验证的自愈策略，本质上只是“看起来很可靠”。冷思考是：平台工程师应该把 GPU 故障恢复当作一项持续投入的工程能力，而不是一次性配置。每一次故障都是一次免费的演练，关键是能否从故障数据中提炼出检测盲区和恢复瓶颈，让下一轮恢复更快、更省、更稳。