大模型训练集群运维重点
在大模型训练集群里，运维工作的重点和普通 Kubernetes 集群不太一样。普通集群更多关注“服务是否可用”，而训练集群还必须关注 GPU 是否高效、分布式通信是否稳定、任务是否能持续推进、数据链路是否成为瓶颈、故障是否会导致大量训练成本浪费。
可以把重点分成六层：硬件、节点、网络通信、存储与数据、调度与任务、监控与恢复。
1. 第一优先级：GPU 硬件是否健康且高效
训练集群里最贵的资源通常是 GPU，所以首要目标不是单纯“GPU 没坏”，而是：
GPU 有没有真正持续做有效计算。
重点看：
- GPU Utilization
- SM Active
- Tensor Core Active
- HBM 使用量
- HBM 带宽
- GPU 温度
- 功耗
- SM Clock
- ECC Error
- Xid Error
- PCIe / NVLink 状态
例如一个训练任务：
GPU Util 95%
Tensor Active 90%
HBM Used 85%
Temperature 72℃
Power 接近正常训练功耗
Clock 稳定通常说明 GPU 使用比较健康。
但如果：
GPU Util 25%
HBM Used 90%
CPU Util 100%这往往不是 GPU 故障，而是 GPU 在等 CPU 数据预处理。
所以 GPU 运维不能只看单指标，而要结合硬件链路判断。
2. 第二优先级：节点健康
一个训练节点不仅有 GPU，还包括：
CPU
RAM
GPU
PCIe
NIC
NVMe
OS
Driver
CUDA
Container Runtime任何一个环节异常，都可能导致训练性能下降。
例如典型数据路径：
训练数据
↓
NVMe / 网络存储
↓
CPU RAM
↓
数据预处理
↓
PCIe
↓
GPU HBM
↓
SM / Tensor Core因此节点侧通常需要重点监控：
2.1. CPU
关注：
- CPU utilization
- load average
- iowait
- context switch
- NUMA
如果 GPU 利用率低而 CPU 满载，很可能 DataLoader 或数据解码成为瓶颈。
2.2. 内存
关注：
- available memory
- swap
- OOM
- page fault
- NUMA locality
训练过程中 host memory 不足可能导致：
DataLoader异常
进程被OOM Kill
训练中断2.3. 磁盘
尤其是本地 NVMe：
- IOPS
- throughput
- latency
- utilization
如果数据集放 NVMe，而磁盘 latency 上升，GPU 很容易出现周期性空闲。
3. 第三优先级：GPU 间通信
这是大模型训练区别于普通 GPU 任务的地方。
单卡训练主要看 GPU 自身，多卡训练则必须重点看：
GPU ↔ GPU通信。
现代大模型通常使用：
- Data Parallel
- Tensor Parallel
- Pipeline Parallel
- Expert Parallel
这些模式都需要频繁交换数据。
典型链路：
GPU0
│
NVLink / NVSwitch
│
GPU1跨节点则：
GPU
↓
PCIe
↓
NIC
↓
RoCE / InfiniBand
↓
NIC
↓
PCIe
↓
GPU因此要重点关注：
- NVLink bandwidth
- NVLink error
- PCIe throughput
- NCCL latency
- NCCL timeout
- IB/RDMA throughput
- packet loss
- retransmission
- NIC error
- PFC / ECN
4. NCCL 是训练集群非常关键的观察对象
NVIDIA Collective Communications Library，简称 NCCL，是多 GPU 通信的核心库。
大模型训练经常执行：
AllReduce
AllGather
ReduceScatter
Broadcast例如 Data Parallel：
每个 GPU 算完梯度：
GPU0 gradient
GPU1 gradient
GPU2 gradient
GPU3 gradient
↓
AllReduce
↓
所有GPU得到统一梯度如果 NCCL 出问题，训练通常不会表现为“GPU完全坏了”，而可能表现成：
某些 GPU 100%
某些 GPU 0%
训练 step 卡住甚至：
NCCL watchdog timeout因此生产环境里经常要监控：
- NCCL collective latency
- NCCL throughput
- straggler GPU
- timeout
- rank failure
5. 第四优先级：训练任务有没有持续推进
训练任务和普通 Web 服务最大的区别之一是：
Pod Running 不代表训练正常。
例如：
kubectl get pod
Running但是训练可能已经：
卡住2小时所以必须监控训练业务指标。
最重要的包括：
- training step
- iteration time
- samples/sec
- tokens/sec
- loss
- learning rate
- checkpoint time
- data loading time
例如：
正常：
step 1000
step 1001
step 1002异常：
step 1000
10分钟过去
仍然 step 1000这就是训练 Hang。
6. 训练吞吐量是非常重要的 SLI
大模型训练真正关心的不是：
GPU Utilization本身，而是：
Tokens / second或者：
Samples / second因为 GPU 100% 并不一定代表效率高。
例如：
机器 A：
GPU Util 100%
1000 tokens/s机器 B：
GPU Util 95%
1800 tokens/s显然 B 更高效。
所以运维层面最终应该围绕：
单位时间真正完成了多少有效训练工作。
7. 第五优先级：Straggler 问题
这是大规模训练集群里非常重要的问题。
假设有 1024 张 GPU。
每一步训练需要所有 GPU 同步。
如果其中一张：
比其他GPU慢20%那么：
其他1023张GPU都要等它结果整个集群吞吐量下降。
这就是：
Straggler，慢节点 / 慢 GPU。
例如：
GPU0 step time 1.0s
GPU1 step time 1.0s
GPU2 step time 1.0s
GPU3 step time 1.5s整个 iteration：
≈1.5s而不是 1.0s。
可能原因包括：
- GPU thermal throttling
- ECC 问题
- PCIe 降速
- NVLink异常
- NIC异常
- CPU瓶颈
- NVMe latency
- NUMA问题
因此大规模训练集群运维的核心能力之一就是：
找出慢 GPU / 慢节点。
8. 第六优先级：存储和数据链路
很多 GPU 低利用率问题其实不是 GPU 问题，而是数据没喂上。
训练数据可能来自：
Object Storage
NFS
Lustre
Ceph
Local NVMe数据链路：
Storage
↓
Network
↓
CPU RAM
↓
Preprocessing
↓
GPU因此要监控：
- storage throughput
- read latency
- metadata latency
- cache hit ratio
- DataLoader latency
- I/O wait
例如：
GPU Util 30%
CPU 20%
Disk Util 100%
Disk latency 高很明显：
GPU在等磁盘。
9. Checkpoint 是训练运维非常重要的一部分
大模型可能训练：
几天
几周
几个月如果训练到第 20 天：
GPU故障没有 checkpoint：
训练可能全部重来。
因此运维需要关注：
- checkpoint 是否成功
- checkpoint 时间
- checkpoint 大小
- checkpoint 上传速度
- 最近 checkpoint 时间
例如：
训练step 100000
最近checkpoint:
step 60000这是很危险的状态。
10. 故障恢复能力
训练集群运维和普通业务运维最大的不同之一是：
一次故障可能直接浪费数十万甚至数百万 GPU 小时。
所以非常强调：
- checkpoint
- auto restart
- elastic training
- node replacement
- GPU isolation
例如：
GPU Xid error
↓
标记GPU异常
↓
cordon node
↓
终止训练worker
↓
从checkpoint恢复
↓
替换节点11. Kubernetes / 调度层重点
如果训练集群基于 Kubernetes，还需要重点看：
11.1. GPU Resource
resources:
limits:
nvidia.com/gpu: 8关注：
- allocatable GPU
- allocated GPU
- idle GPU
- fragmentation
例如：
一个节点：
8 GPU现在剩：
3 GPU但是任务需要：
4 GPU虽然总集群还有很多空闲 GPU，却调度不了。
这叫：
GPU fragmentation。
12. Gang Scheduling
分布式训练常常需要：
64 GPU任务必须同时启动。
不能：
先分配10张
等另外54张否则前面10张一直空等。
因此通常使用：
- Volcano
- Kueue
之类实现 Gang Scheduling。
例如：
需要 64 GPU
当前只有 50 GPU
↓
整个任务等待
而不是先启动50个worker这对提升 GPU 利用率非常关键。
13. GPU 集群的核心监控面
生产 GPU 训练集群的监控至少可以分为以下几层：
| 层级 | 重点 |
|---|---|
| GPU硬件 | SM、HBM、温度、功耗、ECC、Xid |
| 节点 | CPU、RAM、NVMe、PCIe |
| GPU通信 | NVLink、NVSwitch |
| 网络 | IB/RDMA、RoCE、NIC |
| 分布式通信 | NCCL |
| 存储 | 吞吐、latency、IOPS |
| 训练任务 | step、loss、tokens/s |
| 调度 | GPU分配、Pending、碎片率 |
| 恢复 | checkpoint、restart |
| 成本 | GPU utilization、有效GPU小时 |
14. 最值得关注的不是“GPU利用率”，而是 GPU 有效利用率
一个训练集群可能：
GPU Utilization = 90%看起来很好。
但是：
- NCCL等通信占了很多时间
- DataLoader等待
- checkpoint频繁
- straggler严重
最后真正用于 Tensor Core 计算的时间可能只有：
50%因此大型 AI Infra 会越来越关注类似：
MFU（Model FLOPs Utilization）
MFU 可以粗略理解为：
例如：
H100 理论能力非常高。
但是训练实际只发挥：
40%那么：
MFU ≈ 40%对于大模型训练，这比单纯 GPU Util=100% 更有意义。
15. 运维排障时推荐的思考顺序
以后如果遇到：
“训练速度突然下降 30%”
不要直接看 Kubernetes Pod。
建议按照数据流查：
Training throughput
↓
Step time
↓
GPU compute
↓
GPU memory
↓
NVLink/NCCL
↓
PCIe
↓
CPU
↓
Storage
↓
Network例如看到：
tokens/s ↓40%
GPU Util ↓
CPU正常
Disk正常
NVLink TX/RX ↑
NCCL latency ↑那么问题很可能在：
GPU-GPU 通信。
而不是 GPU 本身。
16. 训练集群运维的五项核心能力
从运维与 SRE 视角，可以按以下顺序确定排查优先级：
- 能判断 GPU 是计算瓶颈、显存瓶颈、数据瓶颈还是通信瓶颈。
- 能定位 Straggler GPU / Node。
- 能排查 NCCL、RDMA、NVLink 等分布式通信问题。
- 能设计 checkpoint、任务恢复和故障节点隔离机制。
- 能从集群视角优化 GPU utilization、MFU 和 GPU-hour 成本。
换句话说，大模型训练集群运维的最终目标不是：
“保证 Kubernetes Pod Running。”
而是：
让昂贵的 GPU 尽可能长时间稳定地做有效计算，并且发生故障时尽可能少损失训练进度。
这也是传统 Kubernetes 运维向 AI Infrastructure / GPU SRE 转型之后最大的思维变化。
关联文档
- AI 基础设施软件栈：理解训练集群中的驱动、计算框架与平台软件。
- GPU监控指标：建立训练节点的 GPU 性能与健康观测体系。
- Kubernetes GPU 调度完整详解：补充 GPU 训练任务的资源发现与调度机制。