大模型多机并行训练与推理的 GPU 故障隔离：nvidia-smi drain 编排实战

大模型多机并行训练与推理的 GPU 故障隔离nvidia-smi drain 编排实战在大规模 GPU 集群中硬件故障率与显卡数量呈严格的正相关关系。当集群规模达到上千张 A100/H800/H100 显卡时每天几乎都会遇到不同程度的硬件亚健康与不可逆损坏显存双比特不可纠正 ECC 错误Uncorrectable ECC Error、NVLink 通信总线降速、GPU 掉卡GPU Fallen off the Bus、以及 XID 48/79 驱动级严重故障。在大促备战与演练期间如果缺乏一套标准化的 GPU 故障检测与优雅隔离Drain Cordon自动化编排体系单张显卡的硬件故障就会引发连锁反应——不仅正在运行的分布式 64 卡训练任务会瞬间崩溃还会导致调度器不断将新 Pod 派发到故障节点上造成大批量的 Pod 启动失败与雪崩重试。为了在大促期间实现 GPU 故障的秒级自动拦截与无感隔离必须深入结合 NVIDIA 驱动提供的nvidia-smi drain状态机、K8s Device Plugin 节点属性上报、以及自定义硬件异常自动隔离控制器。[GPU 物理硬件异常 / 驱动 XID 错误触发] │ ▼ [NVIDIA DCGM Exporter / 宿主机内核日志守护] - 捕获 XID 31 / 48 / 62 / 79 - 捕获 Uncorrectable ECC Errors │ ▼ [GPU 自动隔离控制器 (GPU Drain Controller)] ├── 步骤 1: 标记 GPU 状态为 Drain (阻止新 CUDA 上下文) ├── 步骤 2: 给 Kubernetes Node 打上专用故障污点 ├── 步骤 3: 向正在运行的分布式 Task 发送 Checkpoint 信号 └── 步骤 4: 执行无损 Pod 优雅驱逐 (Drain Node) │ ▼ [故障卡下线送修 ➔ 自动拉起热备节点替换]NVIDIA GPU Drain 状态机工作原理NVIDIA 官方驱动从 CUDA 11 引入了显卡级的排空Drain与重置机制Drain 模式启用通过nvidia-smi drain -p GPU_PCI_ID -m 1显卡进入“仅允许已有进程继续运行、拒绝任何新进程分配显存”的保护状态连接状态追踪驱动层持续监控显卡上的计算进程数Compute Processes。当所有已有进程自然退出或完成当前 Batch 计算后显卡进入完全空闲状态安全硬件重置在确认无进程占用后执行nvidia-smi --gpu-reset尝试无损恢复如果无法恢复则触发物理机下电维修。Kubernetes 节点污点与自动隔离控制器实现我们开发了基于 Go 语言的 Kubernetes GPU 故障隔离控制器实时监听节点硬件事件并执行自动化编排package gpudrain import ( context fmt os/exec time corev1 k8s.io/api/core/v1 metav1 k8s.io/apimachinery/pkg/apis/meta/v1 k8s.io/client-go/kubernetes ) type GPUHardwareManager struct { client kubernetes.Interface } func NewGPUHardwareManager(client kubernetes.Interface) *GPUHardwareManager { return GPUHardwareManager{client: client} } // DrainAndTaintFaultyNode 执行显卡物理 Drain 与 K8s 节点隔离 func (m *GPUHardwareManager) DrainAndTaintFaultyNode(ctx context.Context, nodeName string, pciBusID string, xidCode int) error { fmt.Printf(检测到节点 %s 上的 GPU [%s] 发生严重硬件故障 (XID: %d)启动隔离编排...\n, nodeName, pciBusID, xidCode) // 1. 在宿主机层将故障卡置为 Drain 状态阻止新 CUDA Context 创建 drainCmd : exec.Command(nvidia-smi, drain, -p, pciBusID, -m, 1) if err : drainCmd.Run(); err ! nil { fmt.Printf(警告: 设置 nvidia-smi drain 失败: %v\n, err) } // 2. 为 Kubernetes 节点添加 NoSchedule 污点防止调度器继续派发新 Pod node, err : m.client.CoreV1().Nodes().Get(ctx, nodeName, metav1.GetOptions{}) if err ! nil { return fmt.Errorf(获取 Node 失败: %w, err) } faultTaint : corev1.Taint{ Key: gpu.infra.status/hardware-fault, Value: fmt.Sprintf(xid-%d, xidCode), Effect: corev1.TaintEffectNoSchedule, TimeAdded: metav1.Time{Time: time.Now()}, } // 追加污点并更新 Node node.Spec.Taints append(node.Spec.Taints, faultTaint) _, err m.client.CoreV1().Nodes().Update(ctx, node, metav1.UpdateOptions{}) if err ! nil { return fmt.Errorf(为节点添加故障污点失败: %w, err) } // 3. 异步触发受影响 Pod 的优雅驱逐 (Graceful Eviction) go m.evictRunningWorkloads(context.Background(), nodeName) return nil } func (m *GPUHardwareManager) evictRunningWorkloads(ctx context.Context, nodeName string) { // 查询该节点上的非 DaemonSet Pod 并执行逐个安全驱逐 pods, err : m.client.CoreV1().Pods().List(ctx, metav1.ListOptions{ FieldSelector: fmt.Sprintf(spec.nodeName%s, nodeName), }) if err ! nil { return } var gracePeriod int64 60 for _, pod : range pods.Items { if pod.Namespace kube-system { continue } _ m.client.CoreV1().Pods(pod.Namespace).Delete(ctx, pod.Name, metav1.DeleteOptions{ GracePeriodSeconds: gracePeriod, }) } }关键 XID 故障严重等级分级与处置策略在生产运维中不能对所有 XID 报错都一刀切地直接重启物理机必须按严重程度建立分级响应机制P0 致命级必须立即隔离并下线XID 79GPU 掉卡PCIe 链路中断XID 48双比特不可纠正 ECC 显存损坏XID 62显卡固件内部死锁与 RPC 超时处置动作立即执行nvidia-smi drain 打 K8sNoSchedule污点 自动触发 Pod 迁移。P1 警告级允许跑完当前任务任务结束后重置XID 31GPU 页面非法访问通常为 CUDA 代码越界XID 45连续单比特 ECC 软错误纠偏超标处置动作禁止调度新任务等待现有任务结束后执行nvidia-smi --gpu-reset。大促期间的硬件托底防线在大促备战期间必须做到自动热备节点即时补位当 1 台 8 卡节点被隔离时自动从预留的 Standby 池中放行 1 台同规格健康节点进入调度池确保大促算力总盘不缩水分布式任务全自动断点续训分布式训练框架如 Megatron/DeepSpeed必须配合控制器在收到驱逐通知后 30 秒内完成最新 Checkpoint 保存并自动在健康节点组上拉起。