02 大规模训练稳定性保障

· 单节点 1.5% 的日故障率，扩到 1000 卡 → 系统日故障率高达 84.8%
· 10 万卡集群 → 平均每 18 分钟就有一次故障
· Llama 3 预训练 54 天窗口 → 466 次任务中断（其中 47 次是计划内维护）
· 千卡以上训练：平均每周 3-7 次 GPU 故障，掉卡就中断训练

中断恢复闭环（检测 → 中断 → checkpoint 恢复 → 重调度，尽量自动）
        ↓
慢节点检测（straggler：一张慢卡拖垮整个 all-reduce）
        ↓
NCCL 故障排查（hang / 超时 / 走错网卡）
        ↓
运维调度（排队 / 优先级 / 抢占 / Gang Scheduling）
        ↓
训练可观测（loss / 吞吐 / MFU / GPU 利用率波动 / 通信占比）

step N:  GPU0 ─┐
         GPU1 ─┤
         GPU2 ─┼─▶ all-reduce（同步屏障，等所有卡到齐）─▶ step N+1
         ...   │
         GPU999─┘
                 ↑
        任何一张卡慢/挂/网络卡 → 全部 999 张卡在这里干等

┌────────┐  ┌────────┐  ┌──────────────┐  ┌────────┐  ┌────────┐
│ 故障检测│─▶│ 任务中断│─▶│ checkpoint 恢复│─▶│ 重调度  │─▶│ 继续训练│
│Xid/hang│  │全局失败 │  │ 回到最近存档   │  │健康卡   │  │        │
└────────┘  └────────┘  └──────────────┘  └────────┘  └────────┘

运维关注点：
· 存储位置：checkpoint 落在哪？（共享存储 NFS/Lustre/对象存储）
· 存储带宽：千卡同时写 checkpoint 会打爆存储带宽 → 分片/异步写
· 存储频率：存太密 → IO 压力大、拖慢训练；存太疏 → 崩了丢进度多
· 恢复可用性：崩溃时最近的 checkpoint 必须完整可读（写坏的半个 checkpoint 是灾难）
· 容量治理：checkpoint 动辄 TB 级，要定期清理旧的，别把存储写满

恢复代价 = checkpoint 间隔时间 × 故障频率
存储代价 = checkpoint 频率 × 单次大小 × 存储带宽占用

千卡任务经验值：每 15-60 分钟一次 full checkpoint；
配合异步/分层 checkpoint（先写本地 NVMe 再后台刷共享存储）降低训练停顿。

# TorchElastic 弹性启动（节点故障后自动重组，从 checkpoint 续训）
torchrun \
  --nnodes=1:128 \                # 允许节点数在区间内弹性变化
  --nproc-per-node=8 \
  --max-restarts=3 \              # 故障最多自动重启 3 次
  --rdzv-backend=c10d \
  --rdzv-endpoint=$MASTER:29400 \
  train.py

· 慢卡：某张 GPU 降频（thermal throttle）、ECC 频繁纠错、隐性硬件劣化
· 慢网络：某一跳交换机/网卡/光模块质量差，某条 IB 链路误码率高
· 慢存储：某节点本地盘/数据加载慢，喂不上数据
· 数据倾斜：某 rank 分到的数据/序列更长（更偏框架，运维少见）

1. per-rank 吞吐对比：正常所有 rank 吞吐接近，某 rank 明显低 → 嫌疑
2. 通信等待时间：某 rank 在 all-reduce 上等待时间异常长（它在等别人 = 别人慢）
   反过来，某 rank 让别人等 = 它自己慢
3. GPU 降频信号：nvidia-smi throttle reason / DCGM SM 时钟
4. 网络侧：交换机端口错包计数、IB 链路 symbol error、PCIe replay counter

# 快速对比全集群各卡的时钟/温度/降频，揪出被 throttle 的慢卡
nvidia-smi --query-gpu=index,clocks.sm,temperature.gpu,clocks_throttle_reasons.active \
  --format=csv

# DCGM 采 per-GPU SM 活跃度和时钟，对比找离群卡
dcgmi dmon -e 100,101,155,203   # sm_clock, mem_clock, power, temp

# 检查 IB 链路误码（straggler 常见根因之一）
ibqueryerrors           # 查全网 IB 端口错误计数
mlnx_perf -i mlx5_0     # 单网卡性能计数

1. 定位到具体慢卡/慢链路
2. 该节点 cordon + 打标签
3. 下一次 checkpoint 恢复时把任务重调度到健康节点（避开慢节点）
4. 慢卡：dcgmi diag -r 3 压测确认；慢网络：换光模块/网卡/查交换机端口

# 排查第一步：打开 NCCL 详细日志，看它到底选了哪块网卡
export NCCL_DEBUG=INFO
export NCCL_DEBUG_SUBSYS=INIT,NET
# 日志里搜 "NET/IB" 和 "Using" 确认走的是 IB 还是 socket

# 以太网/RoCE：指定走哪块网卡（前缀匹配，^ 排除）
export NCCL_SOCKET_IFNAME=eth0        # 只用 eth0
export NCCL_SOCKET_IFNAME=^docker,lo  # 排除 docker/lo 这类假网卡

# InfiniBand：指定用哪块 HCA（RDMA 网卡）
export NCCL_IB_HCA=mlx5_0,mlx5_1

# 启用 IB（0=启用，默认值；=1 则彻底禁用 IB 只走 socket——多机会灾难性慢）
export NCCL_IB_DISABLE=0

# 集合通信超时在 PyTorch 层设（NCCL 本身没有 NCCL_TIMEOUT 这个环境变量，设了也不生效）
# init_process_group(backend="nccl", timeout=timedelta(minutes=30))
export TORCH_NCCL_BLOCKING_WAIT=1   # 让上面的 timeout 真正阻塞生效（默认是异步 watchdog）
                                    # 超时太短会误杀慢节点，太长故障发现慢

# InfiniBand Verbs 超时：实际等待 = 4.096µs × 2^NCCL_IB_TIMEOUT × NCCL_IB_RETRY_CNT
export NCCL_IB_TIMEOUT=22  # 大网络适当调大

现象：多机训练卡在启动 / 某 step 后 hang 住不动

1. NCCL_DEBUG=INFO 看日志停在哪
   · 卡在 init（bootstrap/ring 建立）→ 网卡选择/连通性问题
   · 卡在某次 all-reduce → 某 rank 挂了或某跳网络断了

2. 确认走对网卡：日志里是不是走了 IB？还是掉回了 socket？
   → 掉回 socket：配 NCCL_IB_HCA / NCCL_SOCKET_IFNAME 强制走 IB

3. 定位是哪个 rank 卡住：
   · 看哪个 rank 的进程还活着但不推进
   · 结合 Xid 日志：是不是那台机器掉卡了（Xid 79）

4. 网络连通性验证：
   · 节点间 IB 连通：ib_write_bw（点对点 IB 带宽测试）
   · 全集群通信基准：nccl-tests 的 all_reduce_perf

5. 分层定位（见实战）：GPU 故障？NCCL/网络？慢节点？存储？

# 用 nccl-tests 做集群通信健康基准（排除业务代码干扰）
# 8 卡单机
./build/all_reduce_perf -b 8 -e 256M -f 2 -g 8
# 多机（配合 mpirun/torchrun）：对比实测带宽 vs 理论带宽，低很多说明有慢链路

没有 Gang Scheduling：8 卡任务，只调度上 7 个 pod，第 8 个 pending
  → 7 张昂贵的 GPU 空转干等第 8 个，永远等不来（资源被占着又没产出）
  → 极端情况：多个任务互相卡着对方最后一张卡 → 死锁，谁都跑不起来

有 Gang Scheduling：8 个 pod 凑齐才一起调度，凑不齐就都不占资源
  → 避免「占着一半资源干等」的浪费

MFU 是训练效率的「体检总分」：
  MFU = 实测吞吐对应的 FLOPs / GPU 理论峰值 FLOPs
  MFU 低 → 卡没喂饱，钱在烧但没换算出训练进度
  运维排查方向：通信占比高？数据加载慢？某些卡降频？batch/并行配置？

· GPU 侧：DCGM Exporter → Prometheus（SM 活跃度、显存、温度、NVLink、Xid）
· 训练侧：框架指标（loss/吞吐/MFU/step time）→ Prometheus / TensorBoard / W&B
· 通信侧：per-rank 通信等待时间、nccl-tests 基准带宽
· 关键告警：
    - loss = NaN/Inf → critical（可能坏卡）
    - 吞吐较基线跌 > 20% 持续 N 分钟 → 查 straggler
    - 某 step 超时（> 正常 step 时间 × K）→ 疑似 hang
    - GPU util 集体掉零但进程还在 → 疑似通信 hang / checkpoint 卡住

┌─ ① GPU 故障（最常见，先查）
│    dmesg -T | grep -i xid   → 有 Xid 79 掉卡 / Xid 48 ECC？
│    nvidia-smi 各节点是不是有的只剩 7 张卡？
│    → 有 → 走专题 01 隔离换卡，任务从 checkpoint 恢复
│
├─ ② NCCL / 网络
│    NCCL_DEBUG=INFO 日志停在哪个集合操作？
│    是不是掉回 socket 走了管理网？
│    ib_write_bw / nccl-tests 验证节点间 IB 通不通、带宽正不正常
│    → 修网卡配置 / 换光模块 / 查交换机端口
│
├─ ③ 慢节点（没挂但拖死）
│    per-rank 吞吐/step 时间对比，找离群 rank
│    该 rank 的卡是不是降频了（throttle）？IB 链路是不是误码高？
│    → cordon 慢节点，恢复时避开
│
└─ ④ 存储
     是不是卡在 checkpoint 读写？NFS/Lustre 带宽被打满？
     数据加载 pipeline 是不是某节点本地盘慢？
     → 查存储带宽、数据加载 worker

目标闭环（无人干预）：
1. DCGM/NVSentinel 检测到 Xid 79 掉卡
2. 自愈系统自动 cordon + drain 坏节点
3. TorchElastic / training-operator 检测到 worker 失败，触发重组
4. Gang Scheduler 在健康节点上重新整组拉起（避开坏节点）
5. 任务从最近 checkpoint 加载，续训
6. 全程告警通知运维，但不需要运维手动操作

落地检查清单：
□ 训练用了弹性框架（torchrun --max-restarts / TorchElastic）
□ checkpoint 频率合理（15-60min），且写在共享存储、可靠可读
□ 调度器支持 Gang Scheduling（Volcano/Kueue/KAI）
□ 有自愈系统自动隔离坏节点（NVSentinel 或自研）
□ 集群有 buffer 健康节点可供重调度（不能满负荷零余量）
□ 恢复后有告警 + per-rank 吞吐验证（确认没恢复到另一张慢卡上）

认知基础    同步训练木桶效应：一张卡挂→全崩（fail-stop）；一张卡慢→全拖慢（fail-slow）
中断恢复    检测 → 中断 → checkpoint 恢复 → 重调度，追求「无人干预自动爬起来」
慢节点      主动对比 per-rank 吞吐/通信等待，靠离群检测揪出 straggler（不告警）
NCCL 排查   NCCL_DEBUG=INFO 看走对网卡没；走错管理网是 #1 元凶；nccl-tests 做基准
运维调度    Gang Scheduling 是训练必备；抢占的前提是能 checkpoint 恢复
可观测      loss/吞吐/MFU/step 时间/通信占比，尽早发现「跑歪或跑慢」