训练资源账：显存、通信与重算的权衡
1. 场景：训练为什么比推理"更吃资源"
推理是固定权重的前向；训练要在每步更新前保存更多状态，并在多卡之间同步梯度。本文沿用前几篇的三本账框架，把训练系统的显存、通信与重算摊开量化，衔接 12 章 llm-lab 系列（DDP/TP/Allreduce）与 03 章集群实测（80 节点 HPL 的通信观察）。
2. 显存账：四份状态叠罗汉
训练时每份参数同时有四份拷贝：
| 状态 | 每参数字节（FP16/FP32 混合） | 7B 模型 |
|---|---|---|
| 权重（FP16） | 2 | 14 GB |
| 梯度（FP16） | 2 | 14 GB |
| 优化器状态（Adam: m+v，FP32） | 8 | 56 GB |
| 激活/中间张量 | 随 batch×seq 增长 | 数 GB~数十 GB |
合计：7B 模型 FP16 训练仅固定状态就约 84 GB，远超推理的 14 GB——这就是"训练卡数按推理的 2-4 倍起"的出处。优化器状态常是最大头（Adam 的 8 bytes/param），混合精度/ZeRO 分片第一个要打的就是它。
3. 通信账：All-Reduce 与并行度
数据并行（DDP）每步要做一次全量梯度 All-Reduce。通信量：
- P=并行卡数，N=参数量。7B FP16 梯度 14 GB，每步在 8 卡上要全量交换。
- 关键观察（03 章 HPL 实测同理）：通信量随卡数线性增长、带宽利用率决定扩展效率。卡间互联慢（如仅 TCP）时，小模型大集群反而更慢——扩展效率 = 算力增速 / 通信代价增速。
- 解法谱系（12 章 llm-lab 已实测）：梯度压缩/延迟同步（DDP 改进）→ ZeRO 分片（省优化器状态+梯度通信量降为分片）→ 张量并行/序列并行（把通信挪进层内，配合高速 scale-up 互联）→ 流水并行（通信少但气泡大）。选择依据：显存账 vs 通信账的交叉点，即"状态放不下"先于"通信跟不上"时用分片，反之用并行切分。
4. 重算账：以算力换显存
激活张量是训练显存的弹性大头。重算（recomputation/activation checkpointing）：前向时丢弃部分激活，反向时重算——省显存、加倍前向算力（约 30-50% 总开销换 50-70% 激活显存）。
何时值得：显存是硬约束（卡装不下 batch）时，重算换来的 batch 提升 > 算力损失；卡有余量时优先关掉。这与 03 章 HPL 的"NB 分块"同一逻辑：分块/丢弃都是为了把数据搬移量压到片上/显存放得下。
5. 训练系统选型决策清单
- [ ] 先算固定状态账（权重+梯度+优化器），它决定卡数与分片必要性；优化器状态是最大头
- [ ] 通信账按并行度重算：每加一倍卡，All-Reduce 通信量如何变化，互联带宽是否接得住（实测方法见 03 章 ping-pong 与 04 章网络篇）
- [ ] 显存不够优先顺序：减小 batch → 重算 → 混合精度/ZeRO 分片 → 换更大卡，按账算而非凭感觉
- [ ] 多机训练先跑通信微基准（ping-pong/Allreduce），确认扩展效率不为负
- [ ] 与推理账对照：同一集群"训练态"与"推理态"的资源画像不同，容量规划要分开做
方法参考：显存/通信/重算三账框架参考开源书稿《深入理解 AI Infra：量化分析与系统设计》（李博杰，Apache-2.0，bojieli.github.io/ai-infra-book）；本文推导与口径为本站自行整理，实测细节见 12 章 llm-lab 系列与 03 章集群实测。