大模型学习笔记 09：分布式训练的瓶颈不只在 GPU，还在通信和集群

分布式训练看起来是在多张卡上重复一个循环：读数据、算局部梯度、做通信聚合、更新参数。但模型越大、设备越多，真正决定效率的往往不再只是 GPU，而是通信、数据通路和集群是否可靠。

同步如何达成

在数据并行中，不同设备各自得到梯度，再通过 AllReduce 等集体通信操作聚合，让副本保持一致。参数服务器则采用中心化角色汇总或分发参数和梯度。不同架构在同步方式、扩展性、通信负载和故障模式上各有取舍。

集群是一套系统，不是一堆 GPU

还要关注 CPU、内存、存储、数据读取、网络拓扑、作业调度和检查点写入。数据管道供应不上时，GPU 等数据；网络拥塞时，GPU 等通信；检查点太慢时，恢复成本上升。系统性能往往由最慢的一段决定。

DeepSpeed 这类工具的价值

书中用 DeepSpeed 展示训练工程实践，重点可以理解为：把并行、状态切分、内存优化和训练管理组织成可配置的基础设施。今天具体配置项和推荐用法可能变化，学习时要区分通用原理与某个版本的接口。

一个小型性能诊断流程

1. 记录每步数据加载、前向/反向、通信和优化器更新时间。
2. 查看 GPU 利用率、显存、网络吞吐和 CPU 等待。
3. 只改一个配置项，重复同样长度的短基准。
4. 同时看吞吐、收敛曲线和数值稳定性。

单看 tokens/second 可能会错过训练质量变化；单看 GPU 利用率也可能把忙碌但低效的通信当成有效计算。

看到这里，我觉得“大模型训练”更像分布式系统工程，而不只是深度学习脚本。硬件给出上限，数据通路、通信调度、检查点和故障恢复决定你能不能接近它。

通信里有一个很实际的矛盾：同步越及时，设备之间的参数越一致，但等待通信的时间也越多；同步做得少一些，吞吐可能提高，却可能影响优化过程。AllReduce、参数服务器和去中心化方案，都是在不同条件下处理这个矛盾。

另外，长时间训练一定要考虑中断。检查点不能只保存模型权重，还要保存优化器状态、学习率调度、数据位置和随机状态，否则恢复以后可能不是从原来的训练过程继续。工程上一次“成功跑完”不如能够稳定暂停、恢复和复盘更重要。

集群监控最好同时看 GPU 利用率、显存、网络吞吐、数据加载等待和 checkpoint 耗时。GPU 利用率高不一定代表训练有效，忙于通信或频繁换页时也可能很高。只有把这些指标放到同一条时间线上，才容易找到真正的瓶颈。

我会给训练任务设置几个简单的故障演练：主动终止一个进程、暂时让数据读取变慢、从最近检查点重新启动。演练的目的不是制造复杂事故，而是确认日志里能看到原因，恢复后 loss 曲线没有突然跳变，数据也没有重复或跳过。很多训练问题只有在真正中断后才会暴露。

参考：《大规模语言模型：从理论到实践》，第 4 章 4.3-4.4 节，PDF 第 106-129 页。本文为学习整理与独立阐释。