掉卡怎么确认
掉卡时设备会从监控命令里消失或句柄报错，服务侧出现各类加速器相关错误。检测靠三条线一起看：设备数量、内核日志里的硬件错误、以及引擎自身的错误日志。任何一条异常都要人工确认，只看其中一条容易误判。
基本信息
| 设备侧 | 设备数量或句柄异常 |
|---|---|
| 内核侧 | 驱动报错与硬件事件 |
| 服务侧 | 引擎抛出的加速器错误 |
| 核对方式 | 三条线交叉确认 |
| 处置 | 摘除节点并排障 |
典型使用场景
- 巡检任务定期比对设备数量与基线
- 监控里配置硬件事件告警
- 推理异常时快速判断是否为节点问题
- 为硬件报修收集证据材料
- 把掉卡时间与业务错误时间线对齐，确认影响面
现场确认
现场确认
nvidia-smi -L # 设备数量是否比基线少
nvidia-smi | head -20 # 是否提示无法获取设备句柄
dmesg -T | grep -i -E 'xid|fell off|nvrm' | tail
# 监控侧：硬件错误指标出现增量即告警三条线怎么对
| 线索 | 正常表现 | 异常表现 |
|---|---|---|
| 设备数量 | 与基线一致 | 少了或读不到 |
| 内核日志 | 无新硬件错误 | 出现新的错误行 |
| 服务日志 | 无加速器异常 | 大量同类报错 |
硬件脱落类的错误通常无法靠单卡重置恢复：按节点排障流程处理并联系厂商支持，不要反复尝试恢复。
自动摘卡要配好：检测到异常后让调度器停止向该节点派发任务，否则故障面会随时间持续扩大。
设备数量比对要自动化：人工巡检容易漏，把基线写进监控规则里才能真正发现数量减少。
同机多卡时逐卡记录：一台机器上某一张卡异常，不代表整机都要下线，处置粒度越细损失越小。
硬件告警要接进值班通道：只做巡检不做告警，故障被发现的时间就完全取决于运气。