01 GPU 集群运维与故障管理

哪张卡不健康？（监控）
它是硬件坏了还是业务代码写崩了？（故障定性）
坏了怎么不让新任务再调度上去？（隔离）
上面正在跑的任务怎么办？（排干）
坏卡怎么换、怎么走 RMA？（替换）
能不能不用人半夜爬起来处理？（自愈）

主动健康监控（nvidia-smi / DCGM / dcgmi diag / DCGM Exporter）
        ↓
故障谱系识别（Xid / SXid / ECC / 温度功耗 → 定性：硬件 or 业务）
        ↓
故障处理闭环（检测 → cordon → drain → 替换/RMA → 自愈）
        ↓
版本一致性治理（驱动 / CUDA / 固件 / Fabric Manager 匹配）

# 实时刷新总览（1 秒一次）
nvidia-smi -l 1

# 只看关键字段，脚本化采集友好
nvidia-smi --query-gpu=index,name,temperature.gpu,utilization.gpu,\
memory.used,memory.total,power.draw,ecc.errors.uncorrected.aggregate.total \
--format=csv,noheader,nounits

# 查询哪些进程占了哪张卡（定位是谁在用）
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv

# 查看降频原因（thermal / power / hw_slowdown）
nvidia-smi -q -d PERFORMANCE | grep -A6 "Clocks Throttle Reasons"

# 查看 ECC 错误明细
nvidia-smi -q -d ECC | grep -A20 "ECC Errors"

# 查看 NVLink 状态（多卡互联）
nvidia-smi nvlink -s

# 启动 DCGM 服务
nv-hostengine

# 查看所有 GPU 的实时健康状态
dcgmi health --check

# 查看某组 GPU 的监控字段
dcgmi dmon -e 155,203,204,1004  # 温度/功耗/util/显存等 field id

dcgmi diag -r 1   # Level 1：快速检查（软件/部署，秒级）
dcgmi diag -r 2   # Level 2：中等，加 PCIe/NVLink 等（分钟级）
dcgmi diag -r 3   # Level 3：深度压测（显存/PCIe/NVLink/SM stress 等多项测试），单节点耗时数分钟
dcgmi diag -r 4   # Level 4：最长最全的极限诊断

# 容器方式部署（K8s 里用 GPU Operator 会自动装好）
docker run -d --gpus all --rm -p 9400:9400 \
  nvcr.io/nvidia/k8s/dcgm-exporter:latest

curl localhost:9400/metrics | grep DCGM_FI_DEV

dmesg -T | grep -i xid
# NVRM: Xid (PCI:0000:3b:00): 79, GPU has fallen off the bus.

Single-bit（SBE，可纠正）：一个 bit 翻转，ECC 自动纠正，数据不受影响
  → 偶发正常（宇宙射线也会导致），高频增长才关注

Double-bit（DBE，不可纠正）：同一字里两个 bit 翻转，ECC 能检出但纠正不了
  → 数据已损坏，几乎都是物理 DRAM 老化
  → 运维铁律：出现 uncorrectable / double-bit ECC 的卡必须下线

# 查询 ECC 聚合计数
nvidia-smi --query-gpu=ecc.errors.uncorrected.aggregate.total --format=csv
# 或用 DCGM
dcgmi health --check   # 会直接标出 ECC 相关的 unhealthy

温度过高：
  > 85°C  → warning，检查风道/散热/机房空调
  > 90°C  → GPU 自动降频（thermal throttle），性能直接掉
  持续高温 → 加速硬件老化，ECC/掉卡概率上升

功耗异常：
  贴着 power cap → 满载正常
  远低于 cap 但任务在跑 → 可能被 throttle（查降频原因）

# 查降频原因（thermal / power / hw_slowdown 哪个触发）
nvidia-smi -q -d PERFORMANCE | grep -A8 "Clocks Throttle Reasons"

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│  检测     │──▶│  隔离     │──▶│  排干     │──▶│ 替换/RMA │──▶│  重上线   │
│ Xid/ECC/ │   │ cordon   │   │  drain   │   │ 换卡/送修 │   │ diag 验证 │
│ diag/温度 │   │ 禁新调度  │   │ 迁走任务  │   │           │   │ 再入池   │
└──────────┘   └──────────┘   └──────────┘   └──────────┘   └──────────┘

# K8s：标记节点不可调度（已有任务不动，新任务不再上）
kubectl cordon gpu-node-42

# 给节点打故障标签，方便后续筛选和自动化
kubectl label node gpu-node-42 gpu-health=faulty xid=79 --overwrite

# 驱逐节点上的 Pod（忽略 DaemonSet，删本地存储 Pod 前先确认）
kubectl drain gpu-node-42 \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --grace-period=120

现场处理：
  - 掉卡（Xid 79）：先整机重启，重启后 dcgmi diag -r 3 复测
    · 复测通过 → 偶发，观察后重新上线
    · 复测仍失败 / 反复掉卡 → 硬件坏，走 RMA
  - Double-bit ECC / uncontained：直接标记待换，不必反复试

RMA 流程（Return Merchandise Authorization，厂商保修换货）：
  - 记录：GPU 序列号（nvidia-smi -q | grep Serial）、Xid 日志、diag 报告
  - 提交厂商 → 换新卡 → 装机 → diag -r 3 验证 → 重新入池

# 采集 RMA 需要的信息
nvidia-smi -q | grep -E "Serial Number|GPU UUID|VBIOS"

NVIDIA 驱动 ── 决定 ──▶ 支持的最高 CUDA 运行时版本
   │
   ├── CUDA Toolkit（容器内）：可 ≤ 驱动支持版本（向后兼容）
   ├── Fabric Manager：版本必须与驱动严格一致（NVSwitch 机型）
   ├── NVIDIA Container Toolkit：容器透传 GPU
   └── GPU 固件 / VBIOS：厂商发布，偶尔需刷新

# 查驱动 + 驱动支持的 CUDA 版本（右上角 CUDA Version 是驱动支持的上限，不是安装的）
nvidia-smi

# 查实际安装的 CUDA Toolkit 版本
nvcc --version

# 查 Fabric Manager 状态（NVSwitch 机型必查）
systemctl status nvidia-fabricmanager
nv-fabricmanager --version

# 检查驱动内核模块是否正常加载
lsmod | grep nvidia

现象：容器里跑任务报 "CUDA driver version is insufficient"
  → 宿主机驱动太老，升级驱动，或容器换用低版本 CUDA 镜像

现象：多卡任务报 NVLink/NVSwitch 不可用，单卡任务正常
  → 查 Fabric Manager 是否运行、版本是否和驱动一致
  → systemctl restart nvidia-fabricmanager

现象：装完驱动 nvidia-smi 报 "couldn't communicate with driver"
  → 内核模块没加载（可能内核升级后 DKMS 没重编），或有旧模块残留

# 1. 确认哪张卡、什么错
dmesg -T | grep -i xid | tail -20
#   看到 Xid 79 → 掉卡；Xid 48 → double-bit ECC

# 2. 看这张卡还在不在（掉卡时 nvidia-smi 可能只剩 7 张）
nvidia-smi

# 3. 立即隔离，止血
kubectl cordon gpu-node-42
kubectl label node gpu-node-42 gpu-health=faulty --overwrite

# 4. 迁走任务
kubectl drain gpu-node-42 --ignore-daemonsets --delete-emptydir-data

# 5. 定性：整机重启后复测
#    reboot 后：
dcgmi diag -r 3
#    通过 → 偶发，观察后重新上线（kubectl uncordon）
#    仍失败/反复掉卡 → 采集序列号+日志走 RMA

陷阱：GPU-Util 是「有 kernel 在跑的时间占比」，不代表算力真的用满
  → 一个占 1% 算力的 kernel 一直跑，Util 也显示 100%

排查路径：
1. 看降频：nvidia-smi -q -d PERFORMANCE | grep Throttle
   → thermal/power throttle 会让「在跑但很慢」
2. 看真实算力占用：DCGM 的 DCGM_FI_PROF_SM_ACTIVE / PIPE_TENSOR_ACTIVE
   → SM_ACTIVE 低但 GPU_UTIL 高 = 算力没吃满（可能 batch 太小/CPU 瓶颈/IO 等待）
3. 看 PCIe/NVLink：DCGM_FI_DEV_PCIE_REPLAY_COUNTER 增长 = 链路差，数据搬运慢
4. 看显存带宽和 host↔device 拷贝：是不是卡在数据喂不进去

现象：新拉的容器任务起不来，报 CUDA driver version insufficient
排查：
1. nvidia-smi 右上角看驱动支持的最高 CUDA（如 12.4）
2. 容器镜像里 nvcc --version 看用的 CUDA（如 12.6）→ 超了
3. 解决：升级宿主机驱动 / 换低版本 CUDA 镜像
4. NVSwitch 机型额外查：systemctl status nvidia-fabricmanager 是否 running 且版本与驱动一致

主动监控    nvidia-smi（人工排障）+ DCGM（集群主动健康）+ DCGM Exporter → Prometheus
故障定性    Xid/SXid/ECC/温度功耗 → 快速判断「硬件坏 vs 业务代码」
处理闭环    检测 → cordon 隔离 → drain 排干 → 替换/RMA → diag 验证再上线
自愈        NVSentinel / QihooSMI 把闭环自动化，人只管物理换卡
版本治理    驱动 ⊃ CUDA（向后兼容）；Fabric Manager 必须与驱动精确匹配