GPU 作业长时间没有进度，最直接的处理是终止进程或重启节点，但这往往同时清除了能区分应用死锁、通信等待、驱动事件与硬件异常的现场。反过来，为了取证让关键业务无限等待也不可接受。生产流程需要预先定义分级：何时只采集轻量状态，何时允许抓取进程栈和系统转储，何时必须立即隔离或重启。每个动作都要记录统一时间，才能把应用、调度器、GPU 与网络事件对齐。
先确认“卡住”是没有进度而不是任务本来就慢
应选择能代表业务进度的信号，例如训练 step、已处理样本、生成 Token、检查点或通信心跳，而不是只看 GPU 利用率。某些计算阶段可能长时间满载，某些同步阶段利用率又会下降。平台应保存正常任务各阶段的持续时间基线，并在超过合理窗口后触发调查。没有基线的固定超时，容易误杀大输入或首次编译任务。
轻量证据应能快速自动采集
第一层证据包括作业与容器身份、进程树、CPU 与内存、GPU UUID、设备利用与显存、当前进程、驱动和 CUDA 版本、最近内核日志、Xid/ECC 事件、网络连接与调度器状态。采集脚本必须设超时，避免某个命令自身阻塞。输出写到节点外或受控目录，并附主机时间与统一时钟偏差。不要在脚本中收集业务输入、密钥或无关环境变量。
进程栈与系统状态要按权限分级
应用栈能判断线程是在计算、锁、文件 IO 还是通信等待，但附加调试器可能暂停进程或触及敏感内存。应由经过授权的角色执行，并先评估业务影响。容器环境需同时保存宿主 PID 与命名空间 PID。若多个 rank 参与分布式作业，应在相近时间采集代表性成员，单看一个等待进程可能把正常屏障误认成根因。
Xid 是线索而不是自动结论
Xid 事件提供驱动检测到的错误类别和设备上下文，但需要结合官方说明、频率、同一设备历史和应用时间线解释。看到 Xid 不能直接宣布硬件损坏，也不能因重试成功就忽略。应记录事件前后的温度、功耗、PCIe、ECC、进程与节点操作，并判断是否在不同工作负载中复现。必要时隔离节点，等待进一步诊断或厂商支持，而不是继续随机承载生产。
重置与重启要有明确边界
终止单进程、重建容器、重置 GPU、重载驱动和重启节点影响范围逐级扩大，是否可用也受设备拓扑和当前进程影响。流程应选择最小可行恢复动作，并确认没有其他租户或 Fabric 依赖。操作后要验证设备枚举、错误状态、驱动服务、容器运行时和代表性负载，而不是看到节点重新上线就完成。
一次可复盘的处置
- 记录最后业务进度与异常发现时间，冻结自动重试次数，防止现场被连续覆盖。
- 在限定时间内采集作业、进程、GPU、驱动、系统和网络轻量证据。
- 按授权决定是否抓取进程栈或更深入诊断，并明确对运行任务的影响。
- 选择最小恢复动作，保存动作前后状态和所有退出码。
- 恢复后执行健康与代表性任务验证，将根因、未知项和再发条件写入记录。
NVIDIA 对 Xid 消息的含义和调查入口可参考 NVIDIA Xid Errors 文档。具体事件的处置应结合当前驱动、GPU 平台与厂商支持建议。本文不给出“出现某个编号就必须更换硬件”的简化结论，也不替代业务自己的超时与恢复设计。
WeChat
Profile