大模型学习笔记 07：为什么训练大模型要分布式？先看算力和显存账

我以前把分布式训练简单理解成“多插几张 GPU，让训练快一点”。真正算过显存以后才发现，单卡的问题往往不是慢，而是参数、梯度、优化器状态和中间激活根本放不下。分布式训练要解决的是容量、计算和通信的共同问题。

显存里装的不只有权重

训练时通常要存储模型参数、梯度、优化器状态，以及反向传播所需的激活。混合精度、梯度检查点、优化器状态分片等方法，分别从数值表示、重复计算和状态分布方面节省内存，但都有成本：精度变化、额外计算或更复杂的通信。

粗略估算显存时，不要只看模型参数量。训练配置、序列长度、batch size、优化器和框架实现都可能显著改变需求。具体数字应按目标模型与框架实测。

扩卡不等于线性加速

更多 GPU 可以增加并行计算能力，但设备之间还要交换梯度、激活或参数分片。如果通信成为瓶颈，GPU 会等待数据，利用率下降。集群带宽、拓扑、故障恢复和数据加载同样影响有效吞吐。

端到端训练时间 = 有效计算 + 数据准备 + 通信同步 + 等待/故障恢复

上式不是精确性能公式，却是很实用的排查清单。优化之前先测量每段耗时，否则容易把资源投到不是真正的瓶颈上。

训练可复现也是成本的一部分

一次能跑完的训练还不够。需要记录代码版本、数据版本、随机种子、并行配置、检查点和故障恢复策略。大规模任务持续时间长，硬件或进程失败是系统设计必须考虑的情况。

分布式训练并不是把一台机器简单变成很多台，而是用通信换取容量和吞吐。最后能不能提速，要看计算、内存和网络这本总账，而不是只数 GPU 数量。

训练时显存里还会出现一个经常被忽略的部分：优化器状态。以常见的 Adam 为例，除了参数本身，还要维护一阶和二阶动量；如果使用混合精度，可能同时保留不同精度的副本。于是“模型有多少参数”和“训练需要多少显存”之间并不是简单的一比一关系。

这也是梯度累积、激活检查点、参数分片和混合精度等技术存在的原因。它们不是凭空减少工作，而是在显存、计算时间、通信和数值稳定性之间重新分配成本。理解这一点以后，看 DeepSpeed 或其他训练框架的配置就不会只停留在复制参数，而会去问每个开关到底省了哪一部分资源。

训练前做一个粗略的资源预算很有必要：模型参数需要多少显存，梯度和优化器状态需要多少，序列长度和 batch size 会增加多少激活，通信和检查点又需要多少额外空间。预算不可能一次算得完全准确，但它能提前暴露“这套配置根本跑不起来”的问题。

设备数量增加后，故障概率也会上升。一个进程退出，可能让整轮训练作废；数据读取慢，所有 GPU 都会一起等。分布式系统的工程质量，最终体现在资源利用率、恢复时间和可观测性上，而不是启动命令有多长。

资源预算最好在训练前就写成一张表：参数、梯度、优化器状态、激活、通信缓冲区和检查点分别占多少，哪些部分可以通过混合精度或分片降低。预算不必精确到最后一 GB，但至少要能回答“序列长度翻倍以后，哪一项先成为瓶颈”。

还要把失败当成正常情况来设计。检查点保存频率太低，故障后损失的计算时间很长；保存太频繁，又会让训练停在 I/O 上。比较稳妥的做法是先用短任务验证保存、加载和断点续训，再决定正式任务的间隔和保留数量。

参考：《大规模语言模型：从理论到实践》，第 4 章 4.1 节、4.2.4 节及 4.3 节，PDF 第 86-88、102-113 页。本文为学习整理与独立阐释。