单张显卡训练一个千亿参数模型，结果通常是启动即失败，显存直接溢出；一万张显卡训练同一个模型，结果可能好不到哪去——集群利用率只有百分之三四十，大量GPU在空转等待通信，训练一天下来有效计算时间不足一半。
这两个现象背后，其实是同一个核心问题：分布式训练不是把更多显卡拼在一起跑那么简单。规模变大之后，算力反而不是最稀缺的资源，通信开销、故障恢复、内存管理、调度效率变成了决定项目成败的关键因素。
这篇文章作为“从比特到AI系统”系列的第三十五集，重点拆解从单卡到万卡所面临的分布式训练系统挑战。文章不会停留在概念层面，而是会讲清楚四类并行模式分别解决什么问题、万卡集群为什么容易“卡脖子”、PyTorch 生态下的 DDP 和 FSDP 到底怎么选怎么配置，以及大规模训练中常见的故障与排查手段。
1. 单卡训练到万卡集群，到底变了什么
很多人会下意识认为，从一张卡到一万张卡，就是把训练任务复制到更多设备上，速度自然能提升一万倍。实际工程中这个想法错得很远。Amdahl 定律告诉我们，任何不可并行化部分都会限制整体加速比。当卡数增加到万卡规模，一次同步、一次全局归约、一次故障恢复的时间，都可能抵消掉大量算力增长。
先看单卡训练的主要约束。单个 GPU 的显存是有限的，如果模型参数、梯度和优化器状态加起来超过显存，训练根本起不了步。以常见训练配置为例，一个 70B 参数模型仅参数就需要约 140GB 显存，如果采用 Adam 优化器，还需要额外保存一阶动量和二阶动量，显存需求会放大数倍。即便单卡显存已经做到 80GB，也只是勉强塞得下参数和梯度，数据并行、长序列训练、大 batch size 带来的中间激活值还需要更多显存。
单卡训练的逻辑很简单：加载模型、读取一个 batch、前向传播、反向传播、更新参数，循环往复。瓶颈是单卡算力和显存容量，系统层面的复杂度很低。一旦进入分布式环境，情况发生质变：
- 某个节点的计算必须和其他节点的结果保持一致。
- 梯度同步需要一个全局通信步骤，通信成本随并行策略的不同而有数量级差异。
- 任何一张卡故障，整个训练任务可能中断，必须设计检查点与恢复机制。
- 上万张卡的调度、监控、日志收集、故障定位，完全超出人工操作能力边界。
也就是说，单卡到万卡的本质变化，是问题重心从“每张卡算多快”转移到了“系统整体能多稳定、多高效地协同”。这正是分布式训练系统要解决的核心矛盾。
2. 四种核心并行策略与它们的系统含义
分布式训练领域讨论最多的基础并行策略有四类：数据并行、张量并行、流水线并行和序列并行。实际大规模训练几乎不会只用一种策略，而是组合成混合并行模式。
2.1 数据并行：最直观，也最容易遇到通信瓶颈
数据并行是工程中最常用的并行方式。每张卡保存一份完整的模型副本，只把训练数据切分到不同设备上，每个设备用自己的数据计算梯度，然后通过 AllReduce 全局归约操作同步梯度，保证所有设备上的模型参数保持一致。
数据并行的优点是容易理解和部署，PyTorch 生态里直接使用DistributedDataParallel（DDP）即可实现。但它有两个重要限制：一是每个设备都必须能够装下完整的模型参数、梯度和优化器状态，模型规模过大时显存装不下；二是梯度同步会产生大量通信量，通信量与模型大小成正比，与数据量无关。这意味着模型越大，数据并行训练的效率越低，网络带宽成为稀缺资源。
2.2 张量并行：解决单卡放不下权重的问题
张量并行把一个层的权重矩阵切分到多张卡上，每张卡只保存权重的一部分。计算时，多张卡之间需要进行频繁的矩阵乘法结果拼接和归约操作，通信量非常大，因此对卡间互联带宽要求极高。
实际工程中，张量并行通常限制在单机内部实施，因为 NVLink / NVSwitch 等机内互联能提供远高于跨机网络的带宽。如果跨节点使用张量并行，通信成本会急剧上升，性能收益往往被通信开销抵消掉。
2.3 流水线并行：减少通信，但引入流水线气泡
流水线并行把模型按层切分成多个阶段，每个阶段放在一张或一组卡上。数据依次流过各个阶段，类似工厂流水线。流水线并行的跨机通信量远小于张量并行，因为只需要传输每个阶段边界的激活值。
代价是流水线启动和排空阶段会产生“气泡”，即部分设备在等待输入时处于空闲状态。微批次数量越多，流水线越容易填满，气泡越小，但同时也带来更复杂的前后向调度逻辑。
2.4 序列并行与 MoE 并行：大模型时代的补充
序列并行主要针对长序列输入的注意力计算做切分，减少长序列带来的显存压力。MoE（Mixture of Experts）并行则把不同的专家网络分布到不同设备上，每个 token 只激活部分专家，用更小的计算量支撑更大的参数量。两者都不是通用方案，但在大语言模型训练中发挥着越来越重要的作用。
这四类并行策略的对比可以整理成下面这张表：
| 并行策略 | 切分对象 | 通信特点 | 适用场景 | 主要限制 |
|---|---|---|---|---|
| 数据并行 | 训练数据 | 同步梯度，通信量随模型增大 | 小模型、大规模数据 | 模型放不下单卡时失效 |
| 张量并行 | 权重维度和激活维度 | 每个前反向都有高频通信 | 单机多卡、大模型 | 对互联带宽要求高 |
| 流水线并行 | 模型层 | 只传输层边界激活值 | 跨机部署大模型 | 存在流水线气泡 |
| 序列并行 | 序列长度维度 | 依赖注意力算子的通信模式 | 长序列训练 | 实现复杂度高 |
真实训练场景里，一个 1000 亿参数的模型通常会把数据并行、张量并行和流水线并行组合起来使用：机内用张量并行，跨机用流水线并行，整体再用数据并行扩展规模。混合并行策略的搜索空间巨大，这也是为什么需要专门做并行策略规划，而不是靠人工拍脑袋决定。
3. 万卡集群的核心瓶颈：通信、故障与调度
如果说并行策略解决的是“模型在哪张卡上怎么算”，那么真正构建十万卡集群时，还要面对三大系统性挑战：集合通信、可靠性、资源调度。
3.1 集合通信：瓶颈往往不是 GPU
分布式训练离不开集合通信操作，最典型的就是数据并行中的 AllReduce。每次反向传播结束后，所有设备都要把自己的梯度广播出去并聚合出全局梯度，再进行参数更新。如果模型有 100 亿参数，一次 AllReduce 要传输的数据量就是数百 GB 级别，而这个操作每个训练步骤都会发生一次。
为什么说万卡集群真正拼的是网络和通信库？因为单卡算力提升和网络带宽提升之间存在剪刀差。过去几年 GPU 算力增长倍速高于网络带宽增长，如果并行策略设计不合理，GPU 会大量时间处于 idle 状态，等待梯度同步完成。
集合通信库（如 NVIDIA NCCL）承担了底层网络通信与拓扑感知的重任。它会根据 GPU 所在机器的拓扑结构自动选择通信路径，尽量通过 NVLink、InfiniBand 等高速链路传输，并对小数据包进行合并与优化。但集合通信库并非万能，它依赖正确的网络拓扑和容器网络配置。很多分布式训练性能问题的根源，其实是网络配置和通信模式不匹配。
3.2 容错：万卡集群的常态是故障
在万卡规模下，硬件故障不是“会不会发生”，而是“多久发生一次”。GPU 卡位损坏、网卡掉线、内存错误（ECC）、计算节点散热异常，在大型集群中几乎每天都会出现。一旦某个节点因为故障退出，整个训练作业若没有恢复机制，就会长时间停滞。
检查点（checkpoint）是最经典的容错手段。训练过程中定期把模型状态存储到磁盘或持久化存储系统，出现故障后从最近检查点恢复。检查点本身也是系统工程：大模型的检查点动辄几百 GB 甚至上 TB，频繁保存会拖慢训练，保存太少又会导致故障后丢失大量进度。业界通用的做法包括异步检查点、分层检查点存储，以及将检查点写入高性能并行文件系统。
3.3 调度：资源到得了，任务才有意义
有了算力、模型和并行策略，还需要一个能管理万卡集群的调度系统。调度器负责分配 GPU 资源、启动训练任务、监控资源和作业状态。常见的集群调度方案包括 SLURM 和 Kubernetes 结合 GPU 插件的方式。
万卡集群调度面临的核心问题包括：避免资源碎片化、感知 GPU 拓扑结构（同一节点、同一交换机组内卡间通信延迟不同）、处理抢占与排队、配合弹性训练进行节点增删。没有合理的调度策略，即使有一万张卡，任务也可能会在一个小点位上恶性排布，导致通信拓扑恶化，性能断崖式下降。
4. 环境准备与分布式训练基础设施选型
对于大多数开发者来说，直接操作万卡集群并不现实，但理解基础设施架构能帮助自己更快定位问题。这里从工程角度说明一套完整的分布式训练环境需要准备哪些东西。
4.1 硬件与网络拓扑
训练集群不是简单把许多台服务器堆在一起。推荐的最小验证环境是：
- 一台 8 卡 GPU 服务器：8 张 GPU 通过 NVLink 全互联，适合学习数据并行和张量并行。
- 两台以上服务器组建跨机集群：验证流水线并行和跨节点网络通信对训练的影响。
- InfiniBand 或 RoCE 高速网络：跨机通信的带宽与延迟直接决定数据并行的上限。
- 共享存储：用于保存数据集、日志和模型检查点，必须能承受高并发读写。
如果手上只有单机多卡，先跑通数据并行和 FSDP 就足够了，不必急于搭建跨机环境。分布式训练概念和故障模式是相通的。
4.2 Python 与训练框架版本
推荐使用当前主流的 Python 3 环境，并安装 PyTorch 及配套的分布式训练组件。由于不同显卡驱动版本的兼容性差异，这里不写死具体版本号。安装时注意以下几点：
- GPU 驱动必须与 CUDA 版本匹配，
nvidia-smi能正确显示显卡信息。 - PyTorch 版本的 CUDA 编译版本需要与显卡驱动兼容，不一定需要完全一致，但要保证能够调用 GPU。
- NCCL 通常随 PyTorch 预编译包附带，也可以通过环境变量
NCCL_DEBUG=INFO打开详细日志，便于排查通信问题。
建议在虚拟环境中安装，例如使用 conda 创建独立环境，避免多个项目的依赖互相干扰。
conda create -n dist_train python=3.10 conda activate dist_train pip install torch torchvision4.3 分布式训练运行方式
现代 PyTorch 推荐使用torchrun启动分布式任务，它代替了早期手动初始化进程组的方式，能自动设置RANK、WORLD_SIZE、LOCAL_RANK等环境变量。节点数为 1、单节点 8 卡时可以直接用下面命令：
torchrun --nnodes=1 --nproc_per_node=8 train_ddp.py多节点时，需要指定主节点的地址和端口，并为不同节点设置node_rank：
# 在节点 0 上执行 torchrun --nnodes=2 --nproc_per_node=8 \ --master_addr=192.168.1.10 --master_port=29500 \ --node_rank=0 \ train_ddp.py # 在节点 1 上执行 torchrun --nnodes=2 --nproc_per_node=8 \ --master_addr=192.168.1.10 --master_port=29500 \ --node_rank=1 \ train_ddp.py需要注意的是，master_addr必须能被所有节点访问。如果部署在云环境中，还应该确保安全组、防火墙放通了分布式训练所需的 TCP 端口，例如默认的 29500。
5. 核心代码实现：从 DDP 到 FSDP
这一节用一个最小示例演示数据并行到零冗余数据并行的实现差异，让读者能够直接跑起来看效果。
5.1 数据并行 DDP 最小示例
下面代码使用torch.multiprocessing的spawn启动多个进程，每个进程负责一张卡。为了演示分布式训练基本流程，用一个简单的线性回归模型代替真实 Transformer。
# 文件路径：train_ddp.py import os import torch import torch.distributed as dist import torch.multiprocessing as mp from torch.nn.parallel import DistributedDataParallel as DDP def setup(rank, world_size): os.environ['MASTER_ADDR'] = '127.0.0.1' os.environ['MASTER_PORT'] = '29500' dist.init_process_group(backend='nccl', rank=rank, world_size=world_size) def cleanup(): dist.destroy_process_group() def train(rank, world_size): setup(rank, world_size) model = torch.nn.Linear(1024, 1024).to(rank) ddp_model = DDP(model, device_ids=[rank]) loss_fn = torch.nn.MSELoss() optimizer = torch.optim.SGD(ddp_model.parameters(), lr=0.01) for step in range(200): inputs = torch.randn(64, 1024).to(rank) labels = torch.randn(64, 1024).to(rank) outputs = ddp_model(inputs) loss = loss_fn(outputs, labels) optimizer.zero_grad() loss.backward() optimizer.step() if step % 50 == 0 and rank == 0: print(f"step {step}, rank {rank}, loss {loss.item():.4f}") cleanup() if __name__ == "__main__": world_size = torch.cuda.device_count() mp.spawn(train, args=(world_size,), nprocs=world_size)这段代码的关键设计是：
dist.init_process_group初始化 NCCL 后端进程组，所有进程必须一致地调用该函数。DDP(model, device_ids=[rank])把模型包装为分布式模型，并在反向传播后自动执行梯度 AllReduce。- 只让
rank 0负责打印日志，避免多个进程同时输出造成的日志混乱。 - 训练结束后必须调用
dist.destroy_process_group()清理资源。
如果所有进程都在同一个节点上，使用torchrun替代spawn更为常见。spawn适合理解底层进程模型，torchrun适合真实项目使用。
5.2 FSDP 将参数分片到多卡
DDP 最大的问题是每张卡都持有完整模型参数，模型过大时单卡放不下。PyTorch 的FullyShardedDataParallel（FSDP）将模型参数、梯度和优化器状态切分到多张卡上，需要时再收集。它消除了“模型太大无法用数据并行”的硬边界。
下面是一段简化的 FSDP 训练示例：
# 文件路径：train_fsdp.py import torch import torch.nn as nn from torch.distributed.fsdp import FullyShardedDataParallel as FSDP from torch.distributed.fsdp.fully_sharded_data_parallel import CPUOffload, BackwardPrefetch class ToyModel(nn.Module): def __init__(self): super().__init__() self.net1 = nn.Linear(4096, 4096) self.relu = nn.ReLU() self.net2 = nn.Linear(4096, 4096) def forward(self, x): return self.net2(self.relu(self.net1(x))) def main(): torch.cuda.set_device(0) model = ToyModel().cuda() fsdp_model = FSDP( model, cpu_offload=CPUOffload(offload_params=True), backward_prefetch=BackwardPrefetch.BACKWARD_PRE ) optimizer = torch.optim.Adam(fsdp_model.parameters(), lr=1e-3) for step in range(50): inputs = torch.randn(32, 4096).cuda() outputs = fsdp_model(inputs) loss = outputs.sum() loss.backward() optimizer.step() if step % 10 == 0: print(f"step {step}, loss {loss.item():.4f}") if __name__ == "__main__": main()FSDP 的使用也不是零成本。参数分片之后，前向和反向过程中都需要额外通信来收集和释放参数分片。FSDP 特别适合在单机多卡以及跨机环境下训练数十亿参数的模型，但通信模式与 DDP 不同，实际训练时需要认真调整通信和计算的重叠策略。“模型太大就换 FSDP”并不是无脑方案，数据并行 DDP 简单高效，别在大模型场景之外盲目引入 FSDP。
5.3 用环境变量控制通信行为
大规模训练中，NCCL 行为可以通过环境变量调优。这里提供一个比较实用的组合：
export NCCL_DEBUG=INFO export NCCL_IB_DISABLE=0 export NCCL_SOCKET_IFNAME=eth0 export NCCL_IB_GID_INDEX=3 export OMP_NUM_THREADS=8这些配置的含义和风险点是：
NCCL_DEBUG=INFO：输出 NCCL 通信过程日志，适合排查通信异常，但日志量巨大，确认问题后应及时关闭。NCCL_IB_GID_INDEX：仅在 InfiniBand 环境需要调整，不同集群/IB 驱动的 GID 索引可能不同。OMP_NUM_THREADS：控制 CPU 端的数据加载和预处理并行度，设置过高反而可能造成 CPU 争抢。
实际项目中不建议直接复制这批环境变量，而应该根据当前集群的网卡名称和网络类型动态配置。
6. 运行效果与性能验证方法
分布式训练项目启动之后，不能只看 loss 有没有下降。需要从多个维度验证训练是否真正高效。
6.1 第一步：验证分布式环境是否正常
运行上面的 DDP 示例，如果一切正常，rank 0会周期性打印 loss：
step 0, rank 0, loss 1.0001 step 50, rank 0, loss 0.9893 step 100, rank 0, loss 0.8921 step 150, rank 0, loss 0.6357如果训练启动阶段卡住超过几分钟，优先怀疑进程组初始化失败，检查节点之间网络是否连通、端口是否可访问、不同进程的world_size是否一致。
6.2 判断训练效率的常用指标
光看 loss 下降不能说明系统高效。有两个指标值得记录：
- 吞吐量：每秒处理的样本数（samples/s）。同样 batch size 下，吞吐量越高，说明硬件利用越充分。
- 模型算力利用率（MFU）：实际浮点运算量除以理论峰值算力，越高越好。业界常见水平在 40% 到 60% 左右，多数情况下低于 40% 说明并行策略或网络配置存在问题。
计算吞吐量不复杂：总样本数除以训练总耗时。在完整训练过程中，可以用小批次定时打印方式统计。
6.3 使用nvidia-smi观察 GPU 状态
训练进程中执行nvidia-smi，可以观察每个 GPU 的显存占用和计算利用率。GPU 利用率长时间低于 90%，往往说明 GPU 在等待数据传输；显存占用异常低，说明模型或 batch size 太小，没有充分利用显存。集群场景下还可以借助 DCGM（NVIDIA Data Center GPU Manager）和 Prometheus 搭建监控面板。
训练失败后第一步该看哪里：日志中是否有 NCCL error、进程是否 out of memory、主节点是否被防火墙阻断。不要一上来就反复重启训练，先查日志和资源指标，定位问题来源。
7. 万卡级训练的常见问题与排查思路
以下问题在大规模分布式训练实践中非常常见，以表格形式整理成排查清单：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 进程启动后卡住 | 网络不通或端口被防火墙拦截 | 用nc -vz测试节点间连通性 | 放开训练端口，确保master_addr可达 |
| 训练开始几分钟后进程异常退出 | 某个节点离线或网卡故障 | 查看集群事件和 GPU 日志 | 设置检查点和自动重启机制 |
| 多卡性能没有提升 | 并行策略和通信拓扑不匹配 | 使用 profiler 分析通信占比 | 调整为张量并行与数据并行组合 |
| 显存溢出 OOM | batch size 过大或激活值太多 | 观察显存占用曲线 | 缩小 batch size，开启激活值重计算 |
| 训练后期 loss 震荡 | 学习率过高或 batch size 波动 | 检查阶梯式学习率策略 | 调整为 warmup 和余弦退火 |
| NCCL 报超时 | IB 网络或 socket 接口配置错误 | 打开NCCL_DEBUG=INFO | 配置正确的 IB 设备和网络接口名称 |
| 保存检查点很慢 | 存储带宽不足，模型过大 | 统计保存耗时 | 使用异步检查点和分层存储 |
这里要特别强调检查点策略。万卡规模下，训练进程被调度系统杀死或节点故障是常态，务必保证每训练一段时间就异步保存检查点。检查点保存不应阻塞主训练流程，可以在保存到内存后异步落盘，或者使用独立线程/进程执行。恢复流程也不能简单是“重跑一遍”，要确保不同 rank 从同一个检查点恢复时数据加载、学习率调度器状态、随机种子都能正确对齐。
8. 分布式训练的最佳实践与工程建议
从真实的工程经验看，下面几条建议对项目成败影响最大。
8.1 先做小规模实验，再上大规模集群
直接从一个 70B 模型开始调万卡集群，问题会被海量变量淹没。正确做法是先搭一个最小实验：用 8 卡跑通 DDP，确认数据加载、日志、检查点都正常；再用 32 卡验证跨机通信和并行策略；最后才切换到万卡规模。每一层规模都能暴露不同的系统问题。
8.2 把并行策略作为配置文件的一部分
并行策略不应该是散落在代码里的手工调整，而应该像资源规格一样被显式配置。例如使用 Megatron-LM 风格的并行配置时，将tensor_model_parallel_size、pipeline_model_parallel_size写入训练启动脚本或 YAML 配置文件。这样实验可复现，切换配置时也不用修改代码。
8.3 日志、指标和检查点都是基础设施
好的工程体系要求训练过程的每个环节都有日志：数据加载耗时、前向耗时、反向耗时、通信耗时、当前吞吐量。没有这些指标，你根本说不清训练瓶颈在哪里。推荐至少记录三者：
- 训练 loss 曲线：判断模型是否在收敛。
- 吞吐量：判断算力使用效率。
- 通信耗时占比：判断并行策略是否合理。
8.4 重视数据加载这个隐性瓶颈
大数据集训练中，GPU 等待数据是很常见的浪费。使用DataLoader时开启num_workers和prefetch_factor，有条件时使用高性能分布式文件系统存储训练数据，避免把数据放在每个节点本地磁盘反复拷贝。
8.5 尽量避免频繁变更模型结构和超参数
大规模训练的成本非常高，一次不合适的改动可能导致上万卡时浪费。在大规模实验前，先在小规模样本集上做消融实验，把模型结构、学习率、batch size 和并行策略确定下来，再上大规模集群。若必须变更，确保有检查点备份，并安排小规模验证后再全量切换。
8.6 安全与权限边界
分布式训练集群通常涉及多团队共享资源。生产环境变更（扩容、切换网络、修改调度配置）必须做到：先申请授权、再在测试环境验证、执行前做好备份、操作后要有回滚方案。最小权限原则同样适用，不随意给训练任务开放不必要的文件系统和网络访问权限。
9. 从万卡回到第一性原理
万卡分布式训练这套系统工程，核心矛盾并不在于单张 GPU 算力不够，而在于规模扩大之后，通信与协同成本开始左右一切。数据并行解决吞吐问题，张量并行解决单个算子放不下的问题，流水线并行解决层数过深的问题，混合并行解决综合效率的问题。它们各自有代价，真正的挑战是谁能设计出成本最低的组合。
对普通开发者和学习者来说，不必一上来就追求万卡实验。先用一台 8 卡服务器跑通 DDP，对比单卡和多卡的加速比，再逐步引入 FSDP 和混合并行策略，理解通信对训练的影响，这套认知比单纯拥有规模更重要。对于正在建设大规模训练基础设施的团队，则建议把精力优先放在网络拓扑、容错恢复和资源调度上，因为这些才是万卡集群真正容易出问题的地方。
分布式训练的复杂性，决定了它永远不会只是一个深度学习框架问题。它是网络、存储、调度、并行计算、深度学习算法和系统工程的整体交汇。理解“从单卡到万卡”的系统挑战，本质上是理解“规模如何改变问题性质”。希望这篇文章能帮你建立起这个认知框架，并在实际项目中少走弯路。
