第 12 章 训练基础设施

学习目标

• 理解训练基础设施的四要素：计算、存储、网络、调度；
• 掌握 Kubernetes/Slurm/Volcano/KubeRay 的分工与选型；
• 理解多租户、配额、优先级、抢占的资源治理；
• 掌握实验管理、日志、指标、追踪的运维闭环；
• 掌握训练监控与故障排查的基本方法。

---

12.1 训练跑在什么上：四要素

一个能跑的分布式训练任务，背后是四类基础设施的协作（第 10、11 章讲的并行与通信，全部依赖它们）：

要素	内容	分布式训练里的关键点
计算	GPU/CPU/TPU/NPU 集群	异构、可用性、健康检查
存储	数据集、checkpoint、日志	高带宽读数据、异步写 checkpoint
网络	IB/RoCE/NVLink + 以太网控制面	三网分离（第 11 章）、拓扑
调度	任务排布、资源分配、优先级	多租户、抢占、失败重试

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart TD
    A[用户提交训练任务] --> B[调度器
K8s/Slurm/Volcano]
    B --> C[分配 GPU 资源]
    C --> D[拉起训练 Pod]
    D --> E[读数据集
对象存储/NFS]
    E --> F[集合通信
IB/RoCE]
    F --> G[写 Checkpoint
异步]
    G --> H[日志/指标/追踪]
    H -->|反馈| B

12.2 调度器：Slurm、Kubernetes、Volcano、KubeRay

12.2.1 Slurm：HPC 的老牌调度

学术界与部分大厂的预训练集群仍用 Slurm——它专为「独占 GPU 的批处理任务」设计，一个节点就是一组 GPU 的天然边界。优点：成熟、稳定、对 InfiniBand 拓扑友好；缺点：现代云原生（容器、弹性、多租户细粒度）能力弱。

12.2.2 Kubernetes：云原生的事实标准

K8s 已成为 AI 平台的事实底座。但裸 K8s 直接跑分布式训练有三个坑：

1. Gang Scheduling（群体调度）：训练任务要「全部 Pod 同时就绪」才能开始（一个缺失就白等甚至死锁）——K8s 默认逐个调度 Pod，不满足。Volcano 的 gang plugin 解决这个问题；
2. GPU 资源：需要 device plugin（nvidia-device-plugin）暴露 GPU，配合共享 GPU、MIG 切分（第 18 章）；
3. 分布式通信：Pod 间的网络（headless service、多网卡、RDMA）要专门配置，KubeRay 提供了便利。

12.2.3 Volcano & KubeRay：补 K8s 的短板

组件	解决什么	关键能力
Volcano	批处理调度的 K8s 原生增强	Gang scheduling、队列/配额、优先级抢占
KubeRay	Ray 的 K8s 部署与调度	RayCluster 编排、自动扩缩、与 K8s 资源整合

选型结论：需要强多租户与批调度 → Volcano 系；需要弹性 Ray 生态 → KubeRay；HPC 预训练 → Slurm；三者都可共存于大厂平台。中小团队的现实路径：单机/单节点用 Docker + 命令行即可，多机用 K8s + Volcano。

12.3 多租户、配额、优先级、抢占

多团队共享集群必然要资源治理。四个概念层层递进：

• 多租户：不同团队/项目隔离资源与权限（namespace + RBAC）；
• 配额（Quota）：租户最多能用多少资源（CPU/GPU/内存/网络）。配额是「上限承诺」，超了排队或拒绝；
• 优先级（Priority）：任务间的相对权重（P0 关键任务 > 实验任务）。用于抢占判断；
• 抢占（Preemption）：高优先级任务到来时，低优先级任务让出资源。抢占有代价（训练中断、checkpoint 浪费），要配 checkpoint 频率策略，让被抢占的损失可控。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[租户 A
配额 32 卡] --> C[集群资源池]
    B[租户 B
配额 16 卡] --> C
    C --> D{P0 任务抢占}
    D -->|是| E[抢占实验任务
让出 GPU]
    D -->|否| F[排队等待]

工程经验：训练任务最好支持「preemption-aware checkpoint」——被抢占前快速存一份增量 checkpoint，恢复成本从「从头再来」降到「从 5 分钟前继续」。这是弹性训练（第 11 章）的调度侧落地。

12.4 实验管理、日志、指标、追踪

12.4.1 实验管理

第 5 章讲了实验追踪的原则，这里落到基础设施：每次训练 = 一个可复现的单元。要素：代码版本（git commit）+ 数据版本（第 6 章）+ 超参 + 环境（容器镜像 hash）+ 指标。工具：MLflow、Weights & Biases、Neptune、TensorBoard。没有实验管理，多租户集群上「谁在跑什么、结果怎样」会失控。

12.4.2 日志、指标、追踪

训练任务的运维三件套：

层	内容	工具
日志	训练进度、错误栈、数据样本	Loki、ELK
指标	loss、PPL、梯度范数、GPU 利用率、温度	Prometheus + Grafana
追踪	分布式任务的跨度（各卡耗时、通信等待）	训练 Profile（NVIDIA Nsight、PyTorch Profiler）

训练 Profile 是性能问题的显微镜：MFU 低时，用 Profiler 看每个 kernel 的耗时与通信等待，定位是算子问题、通信问题还是负载不均（第 11 章排查法的工具化）。

12.5 训练监控与故障排查

12.5.1 监控什么

训练任务两类指标要分开监控：

• 系统健康（GPU 利用率、显存、温度、网络丢包、IB 链路状态）：故障先兆；
• 训练进程（loss、PPL、梯度范数、learning rate、checkpoint 写盘耗时）：训练是否正常收敛。

关键告警信号（结合第 7 章 loss spike 与第 11 章扩展效率）：

• 梯度范数突增 → loss spike 先兆；
• GPU 利用率骤降 → 数据加载瓶颈 / 通信等待 / 掉队；
• IB 链路 down → 集合通信退化；
• 温度异常 → 硬件降频（节流），性能神秘下降。

12.5.2 故障排查手册

一次「训练变慢」的排查顺序（可操作版）：

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart TD
    A[训练变慢/卡住] --> B{GPU 利用率?}
    B -->|接近 0| C[数据加载瓶颈
查存储 IO / dataloader]
    B -->|低于正常| D{单卡还是全体?}
    D -->|单卡| E[掉队节点
查该卡健康/网络]
    D -->|全体| F[通信瓶颈
查 IB 链路/拓扑/调度]
    B -->|正常但 loss 不降| G[训练问题
查学习率/数据/精度]
    C --> H[扩大 dataloader workers
或预取到本地]
    E --> I[剔除节点/软同步]
    F --> J[换拓扑/降并行度]

排查顺序原则：先系统（利用率/链路）→ 再通信（分布）→ 最后训练（loss）。多数「训练变慢」最终落在数据加载与网络两个「看不见的基础设施」上，而不是模型代码。

---

本章要点回顾

1. 训练基础设施四要素：计算、存储、网络、调度；训练任务的成败高度依赖「看不见的基础设施」。
2. 调度选型：HPC 预训练用 Slurm，云原生用 K8s；裸 K8s 跑分布式要补 Gang scheduling（Volcano）与 Ray 编排（KubeRay）。
3. 多租户治理四概念：租户隔离、配额上限、优先级、抢占；抢占要配 checkpoint 策略控制损失。
4. 实验管理 = 代码+数据+超参+环境+指标五要素对齐；日志/指标/追踪构成运维三件套。
5. 训练监控分系统健康与训练进程两层；排查顺序：系统 → 通信 → 训练。
6. 多数「训练变慢」的根因在数据加载与网络，不在模型代码。

习题

1. 为什么裸 Kubernetes 直接跑分布式训练会死锁？用 Gang scheduling 解释，并说明 Volcano 怎么解决。
2. 你的平台要支持「P0 预训练任务抢占实验微调任务」。设计抢占 + checkpoint 策略，让被抢占的微调损失控制在 10 分钟内。
3. 一个训练任务 GPU 利用率只有 20%，但 loss 正常下降。按 12.5.2 的顺序排查，列出每步的验证手段。
4. Slurm 和 K8s 各自适合什么场景？给出一个「从 Slurm 迁移到 K8s」的利弊清单。
5. 设计一套训练任务的告警体系：至少 8 条告警规则，每条给出指标、阈值、告警级别、触发后的动作。

延伸阅读

• Volcano 官方文档（Gang scheduling、队列、抢占）
• KubeRay 官方文档（Ray on Kubernetes）
• PyTorch Profiler 与 NVIDIA Nsight Systems 文档
• NVIDIA DCGM（Data Center GPU Manager）文档（GPU 遥测）
• Grattafiori et al., The Llama 3 Herd of Models, 2024（集群故障与训练监控实践）
• 各云厂商 AI 平台白皮书（AWS SageMaker、GCP Vertex AI、阿里云 PAI）

下一章预告

第 4 篇转向「模型上线前的两道工序」：第 13 章模型压缩（量化/剪枝/蒸馏/低秩分解）与第 14 章推理优化（KV Cache/PagedAttention/连续批处理/投机解码）——让模型跑得快、跑得省、放得下。