大模型训练平台设计¶
面试方向：AI Infra / MLOps / 大模型预训练方向 考察重点：分布式训练、故障恢复、资源调度
1. 大模型训练的工程挑战¶
Text Only
训练一个70B参数模型:
- 数据: 15T tokens(数PB原始文本)
- 算力: 2048×H100, 训练数月
- 显存: 单卡80GB, 模型参数+优化器状态+激活值 >> 80GB
- 投入: 数亿元人民币
- 失败代价: 任何节点故障都可能浪费数天训练进度
→ 这是一个极端的分布式系统工程问题
2. 完整训练平台架构¶
Text Only
┌────────────── 数据层 ──────────────────────────┐
│ │
│ 原始数据(Common Crawl/网页/书籍/代码) │
│ → 数据清洗流水线(Spark/Dataflow): │
│ 去重(MinHash) → 质量过滤(分类器) → 毒性过滤 │
│ → 语言识别 → 领域分类 → Tokenize │
│ → 训练数据集(分片存储在HDFS/S3) │
│ → 数据加载器(WebDataset/Mosaic StreamingDataset) │
│ │
└──────────────────┬──────────────────────────────┘
↓
┌────────────── 训练层 ──────────────────────────┐
│ │
│ 分布式训练框架: │
│ ┌─────────────────────────────────────────┐ │
│ │ 数据并行(DP): 每卡完整模型, 不同数据 │ │
│ │ 张量并行(TP): 模型切分到同机多卡 │ │
│ │ 流水线并行(PP): 模型层切分到不同机器 │ │
│ │ 序列并行(SP): 长序列切分到多卡 │ │
│ │ 专家并行(EP): MoE模型专家分布到不同卡 │ │
│ │ │ │
│ │ 组合策略(3D并行): │ │
│ │ TP=4(机内) × PP=8(跨机) × DP=64 │ │
│ │ = 2048 GPU │ │
│ └─────────────────────────────────────────┘ │
│ │
│ 框架选择: │
│ - Megatron-LM(NVIDIA): 性能最优, 大厂首选 │
│ - DeepSpeed(Microsoft): ZeRO优化, 易用性好 │
│ - FSDP(PyTorch原生): 与PyTorch生态深度集成 │
│ - Megatron-DeepSpeed: Megatron+DeepSpeed混合 │
│ │
└──────────────────┬──────────────────────────────┘
↓
┌────────────── 调度层 ──────────────────────────┐
│ │
│ GPU集群管理: │
│ - K8s + 自研GPU调度器(考虑拓扑感知) │
│ - SLURM(HPC传统方案, 学术界/部分大厂) │
│ │
│ 任务调度: │
│ - 抢占式调度(高优任务可抢占低优) │
│ - 弹性训练(节点故障自动缩减/恢复) │
│ - 网络拓扑感知(TP在NVLink内, PP在IB网络) │
│ │
└──────────────────┬──────────────────────────────┘
↓
┌────────────── 可靠性层 ────────────────────────┐
│ │
│ Checkpoint: │
│ - 定期保存(每1000步或每小时) │
│ - 异步写入(不阻塞训练) │
│ - 分布式存储(每张卡保存自己的分片) │
│ │
│ 故障检测与恢复: │
│ - GPU健康监控(DCGM指标) │
│ - NCCL通信超时检测 │
│ - 自动故障恢复: │
│ 节点故障 → 检测(30s) → 替换节点(5min) │
│ → 加载checkpoint → 恢复训练(10min) │
│ → 总停机时间: 约15-20min/次 │
│ │
└──────────────────┬──────────────────────────────┘
↓
┌────────────── 实验管理层 ──────────────────────┐
│ │
│ W&B / MLflow: │
│ - 训练曲线(Loss/LR/梯度范数) │
│ - 超参记录 │
│ - 评估指标(定期在验证集上eval) │
│ - 模型版本管理 │
│ │
└────────────────────────────────────────────────┘
3. 分布式并行策略（面试核心）¶
3.1 为什么需要并行¶
Text Only
70B模型显存需求：
参数: 70B × 2B(FP16) = 140GB
梯度: 70B × 2B = 140GB
优化器状态: 70B × 8B(Adam: FP32参数+FP32动量+FP32方差+FP32梯度) = 560GB
激活值: 随batch size变化, 通常100-500GB
─────────────────────────────────
总计: 940GB-1340GB >> 单卡80GB
→ 必须切分到多张GPU
3.2 三大并行策略对比¶
| 策略 | 切分什么 | 通信量 | 适用场景 |
|---|---|---|---|
| 数据并行(DP) | 数据batch切分，每卡全量模型 | AllReduce梯度(大) | 模型放得下单卡 |
| 张量并行(TP) | 模型的每一层切分到多卡 | AllReduce中间激活(频繁) | 机内多卡(NVLink) |
| 流水线并行(PP) | 模型按层切分到不同机器 | 前向/反向传递激活(小) | 跨机(IB网络) |
3.3 DeepSpeed ZeRO（面试高频）¶
Text Only
ZeRO-1: 切分优化器状态
每卡只存1/N的优化器状态 → 显存节省4x(N=GPU数)
ZeRO-2: 切分优化器状态 + 梯度
每卡只存1/N的梯度 → 在ZeRO-1基础上进一步节省
ZeRO-3: 切分优化器状态 + 梯度 + 参数
每卡只存1/N的参数 → 最大节省
代价: 前向/反向时需要AllGather收集参数(通信开销增加)
实践选择:
- 模型放得下单卡 → DP + ZeRO-1 (通信最小)
- 模型放不下但很大 → 3D并行(TP + PP + ZeRO-1 DP)
- 微调场景 → ZeRO-3 + Offload(参数卸载到CPU)
3.4 混合精度训练¶
Text Only
混合精度(AMP)原理:
- 前向传播: FP16(快, 省显存)
- Loss计算: FP32(防下溢)
- 反向传播: FP16(快)
- 参数更新: FP32主副本(精度保证)
BF16 vs FP16:
FP16: 指数5位, 尾数10位 → 范围小(6.5e4), 精度高
BF16: 指数8位, 尾数7位 → 范围大(3.4e38), 精度低
→ BF16训练更稳定(不易溢出), 现代GPU(A100+)首选
FP8(H100+):
E4M3: 训练前向 → 更多精度
E5M2: 训练反向 → 更大范围
→ 相比BF16进一步2x加速(H100 Transformer Engine)
4. 故障恢复设计（面试重点追问）¶
2000+GPU集群，单GPU年故障率约5-10%：
Text Only
MTBF计算(Mean Time Between Failures):
单GPU MTBF: ~2000小时
2000 GPU集群 MTBF: 2000/2000 = 1小时
→ 平均每小时会有一次GPU相关故障!
4.1 Checkpoint策略¶
Text Only
策略对比:
┌────────────────┬──────────────┬──────────────┬────────────────┐
│ 策略 │ 保存时间 │ 恢复时间 │ 存储量/次 │
├────────────────┼──────────────┼──────────────┼────────────────┤
│ 全量同步保存 │ 10-30min │ 10-30min │ 模型全量 │
│ (阻塞训练) │ (训练停止) │ │ (70B→1.3TB) │
├────────────────┼──────────────┼──────────────┼────────────────┤
│ 异步保存 │ 不阻塞训练 │ 10-30min │ 同上 │
│ (后台写入) │ 有一致性问题 │ │ │
├────────────────┼──────────────┼──────────────┼────────────────┤
│ 分布式分片保存 │ 3-5min │ 5-10min │ 每卡保存自己 │
│ (推荐) │ │ │ 的分片(小) │
├────────────────┼──────────────┼──────────────┼────────────────┤
│ 内存冗余 │ 0(无IO) │ 秒级 │ 备份到邻居GPU │
│ (最前沿) │ │ │ 的显存/内存 │
└────────────────┴──────────────┴──────────────┴────────────────┘
4.2 弹性训练¶
Text Only
场景: 训练中某个节点挂了
传统方案:
检测故障(1min) → 手动替换节点 → 重启所有进程 → 加载checkpoint → 恢复
停机时间: 30min-2h
弹性训练方案(Torch Elastic / DeepSpeed Elastic):
检测故障(30s) → 自动从进程组中移除故障节点
→ 剩余节点重新组网(重新划分DP组)
→ 加载最近checkpoint → 以N-1个节点继续训练
→ 新节点加入后，再扩展回N个节点
停机时间: 5-15min
5. 性能估算¶
Text Only
训练70B模型, 15T tokens:
计算量(FLOPs):
C ≈ 6 × N × D = 6 × 70B × 15T = 6.3e24 FLOPs
训练时间:
2048 × H100(每卡990 TFLOPS BF16):
集群理论算力: 2048 × 990e12 = 2.03e18 FLOPS
MFU(模型算力利用率)约45%: 有效算力 = 0.91e18 FLOPS
训练时间: 6.3e24 / 0.91e18 / 3600 / 24 ≈ 80天
成本:
2048 × H100 × ¥50/GPU·小时 × 80天 × 24小时 ≈ ¥1.97亿
+ 网络/存储/电力/冷却 → 总投入约¥2.5-3亿
MFU(Model FLOPs Utilization)的意义:
理论峰值 → bubble损失(PP空闲) → 通信overhead → 显存管理
业界水平: 40-55%是优秀, <30%需要优化
6. 面试高频追问¶
Q: TP和PP应该怎么组合？
Text Only
原则:
TP(张量并行) → 放在机内(NVLink 900GB/s带宽)
因为TP每个前向/反向步都需要AllReduce，对带宽要求极高
PP(流水线并行) → 放在跨机(InfiniBand 200-400Gb/s)
因为PP只在层间传递激活值，通信量较小
DP(数据并行) → 最外层，跨机
因为DP只在梯度同步时通信(AllReduce)
示例(2048 GPU):
8 GPU/机 → TP=4(机内), PP=8(跨机), DP=64(最外层)
4 × 8 × 64 = 2048 ✓
Q: 训练中Loss突然飙升(spike)怎么办？
Text Only
诊断步骤:
1. 检查数据: 是否遇到了异常数据batch(重复/乱码/极长序列)
2. 检查梯度: 梯度范数是否异常大 → 梯度裁剪阈值是否合适
3. 检查学习率: 是否在学习率调度的关键节点
4. 检查硬件: GPU ECC错误? 通信故障导致参数不一致?
处理:
- 轻度spike(自动恢复): 记录但继续训练
- 严重spike(不恢复): 回滚到上一个健康checkpoint
- 频繁spike: 降低学习率/增大batch size/调整梯度裁剪
Q: 数据并行中梯度同步的具体实现？
Text Only
AllReduce的Ring实现:
N张GPU排成环: GPU-0 → GPU-1 → ... → GPU-N-1 → GPU-0
阶段1(Scatter-Reduce): 每步发送1/N的梯度给下一个节点
N-1步后，每个节点有1/N梯度的完整聚合结果
阶段2(AllGather): 每步把完整的1/N广播给下一个节点
N-1步后，所有节点拥有完整的聚合梯度
通信量: 2 × (N-1)/N × 梯度大小 ≈ 2 × 梯度大小(N大时)
不随GPU数量增长! → 扩展性好
最后更新：2026年2月