从单卡到万卡真正的难点从来不是“把卡堆多”而是让一万张卡像一张卡一样协同工作。很多人以为分布式训练就是把数据切碎、丢到更多 GPU 上但真实情况是通信瓶颈、故障概率、数据加载、稳定性、调度效率任何一环出问题整个集群的等效算力都会被打折。这一集《从比特到AI系统》第三十五集就聚焦“从单卡到万卡”这条主线拆解分布式训练背后的系统挑战。这里不是泛泛讲概念而是要回答几个非常实际的问题万卡训练为什么那么难为什么有时候一万张卡训练一千张卡加速比却不到 5 倍分布式训练里的通信、并行、容错、数据 I/O 到底怎么设计本文将把并行模式、通信开销、故障恢复、存储吞吐、性能评估和排查方法完整过一遍适合正在接触大模型训练、集群调度、AI 基础设施或者想搞清楚“大模型为什么要用几千张卡”的读者。1. 万卡分布式训练核心问题速览先给一张总览表把分布式训练从单卡到万卡的关键维度列清楚。这张表可以当作后面每个章节的索引也可以先收藏等真正需要排查问题时再回来看。维度关键内容训练规模单卡、单机多卡、多机多卡、千卡级、万卡级主要并行策略数据并行、张量并行、流水线并行、专家并行最大系统瓶颈通信开销、故障率、数据加载带宽、调度效率关键衡量指标吞吐量Tokens/s、MFU、有效训练时间占比通信基础设施NVLink、InfiniBand、RoCE 以太网、拓扑结构容错机制周期性 Checkpoint、异步保存、故障重启恢复常见框架PyTorch DDP/FSDP、Megatron-LM、DeepSpeed硬件约束GPU 显存、卡间带宽、跨机带宽、存储吞吐量主要挑战通信与计算重叠、负载均衡、长稳训练、成本控制适合读者大模型训练工程师、AI 平台开发、集群运维从这张表也能看出分布式训练涉及的已经不单是模型算法问题而是计算、网络、存储、调度、容错等多个系统的交叉问题。这也是为什么它被称作“AI 系统工程”而不是单纯的“训练代码优化”。2. 从单卡到万卡问题是怎么变大的回顾一下训练的基本流程就能看清“万卡”到底难在哪里。单卡训练时前向传播、反向传播、梯度更新都发生在同一张卡上数据从本机内存或磁盘读入模型参数也常驻在显存里整个过程不需要和其他设备交换数据。到了多卡数据并行每张卡保存一份完整模型副本各自处理不同的 batch然后通过 AllReduce 集合通信同步梯度保证每张卡上的模型更新一致。此时开始引入通信开销但规模在 4 卡、8 卡时这个开销通常还能接受。到了几百卡甚至万卡问题会从量变到质变。先看通信。数据并行下每步训练都需要同步梯度。以一个 7B 参数模型为例如果用 FP16 训练梯度大小约为 14GB 左右一次 AllReduce 需要做 reduce 和 broadcast 两轮传输整体通信量约等于 28GB 量级。这个数字在 8 卡时可以靠 NVLink 撑住但在万卡集群里跨机通信会经过交换机网络带宽和拓扑结构直接决定训练速度。再看故障。单卡训练的故障概率很低训练几小时可能不会遇到问题。但到万卡规模假设单卡每天故障概率是 0.1%一万张卡的期望故障数就是每天 10 张。也就是说每训练一段时间就可能出现卡掉线、通信超时、训练中断。如果没有完善的 Checkpoint 机制一个跑了一周的万卡训练任务可能因为一张卡故障全部重来。再看数据加载。单卡时数据读取压力低主存和本地磁盘就能满足。万卡训练时每张卡每分钟要消费大量样本存储系统需要提供极高的聚合吞吐量否则 GPU 会一直等数据造成巨大的算力浪费。所以万卡训练的本质挑战可以概括为四个词通信、容错、数据、稳定性。3. 四类主流并行策略切数据还是切模型分布式训练的并行策略不是单选而是组合使用。大规模训练中模型会被同时按多种方式切分这里逐一说明各类并行策略的特点和适用场景。3.1 数据并行数据并行的核心思想是“每张卡一份模型数据切分到不同卡”。每张卡完成自己的 batch 计算后通过 AllReduce 同步梯度确保模型一致。数据并行实现最简单PyTorch DDP、DeepSpeed ZeRO 都属于数据并行范畴。它的局限在于单卡显存必须能装下完整模型当模型规模达到数十亿甚至上百亿参数时单卡显存无法容纳完整模型和梯度就需要配合模型并行使用。3.2 张量并行张量并行把一个 Layer 内的参数切分成多份分布到多张卡上。例如计算一个线性层 y XW可以把权重矩阵 W 按列切分不同卡持有 W 的一部分前向传播时各自计算局部结果最后通过 AllReduce 合并。张量并行会显著增加通信频率因为每一层计算都要做一次聚合。它通常用在单机内部、同一节点上的多卡之间依赖 NVLink 或 PCIe 高速互联。跨机做张量并行对网络延迟非常敏感一般不推荐。3.3 流水线并行流水线并行按模型层进行切分比如把 96 层 Transformer 分成 4 段每张卡负责连续的若干层。数据像流水线一样依次经过各卡计算。流水线并行的优点是通信频率比张量并行低只需在段与段之间传递激活值和梯度。缺点是会引入流水线气泡bubble即部分卡在等待前序卡计算时处于空闲状态。层数越多、切分越均匀气泡越小。3.4 专家并行专家并行主要用在 MoEMixture of Experts模型上。MoE 模型把 FFN 层替换为多个专家子网络每次输入只激活部分专家。专家并行会把不同专家放到不同卡上通过路由机制把 token 分发给对应专家。专家并行的难点在于负载均衡如果某个 token 分布不均衡某些卡会被打满而另外一些卡空闲。这也是 MoE 训练比稠密模型更难优化的原因之一。3.5 怎么组合使用实际万卡训练很少只使用一种并行策略。常见做法是以数据并行作为基础维度在单机内部叠加张量并行在跨机维度叠加流水线并行MoE 模型再叠加专家并行。DeepSpeed、Megatron-LM 都提供类似组合能力。并行类型切分维度通信频率典型场景代表框架数据并行训练数据每步一次梯度同步小模型、大 batchPyTorch DDP、DeepSpeed张量并行层内权重每层多次聚合大模型单机多卡Megatron-LM流水线并行层间切分段间传输激活跨机大模型Megatron-LM、PipeDream专家并行MoE 专家路由分发MoE 大模型DeepSpeed-MoE4. 通信开销万卡集群的第一约束4.1 AllReduce 为什么会成为瓶颈数据并行训练中每张卡算完梯度后需要把所有卡的梯度加起来并广播给所有人这就是 AllReduce 操作。最原始的 AllReduce 实现是“单卡收集再广播”通信量随卡数线性增长万卡时完全不现实。现代框架使用 Ring AllReduce 等算法把通信量从 O(N) 降为 O(1)每张卡的通信量与卡数无关但通信延迟和网络拥塞问题依然存在。Ring AllReduce 的基本思路是把所有卡连成一个逻辑环每张卡只与相邻卡通信梯度先切块做 ring reduce再做 ring broadcast。这样单卡通信量约为 2 倍模型参数量和卡数无关。这是最容易理解也不需要额外硬件的优化方案。4.2 一次训练迭代的实际通信量估算以 7B 模型、FP16 梯度为例一次 AllReduce 大约要传输 2 × 2 × 7GB 28GB 数据。如果网络带宽是 200Gbps约 25GB/s理论上单次同步需要 1 秒以上。但如果单步计算本身只要 1 秒通信占比就会超过 50%训练效率很低。这也是为什么真正的万卡训练必须使用梯度压缩、通信与计算重叠、混合并行策略以及对网络拓扑做专门设计否则通信时间会占据大部分训练时间。4.3 网络拓扑与带宽从单机到万卡网络拓扑会经历几个阶段单机多卡主要走 NVLink带宽通常在 900GB/s 级别延迟极低。多机互联需要经过网卡和交换机常见方案是 InfiniBand 或 RoCE 以太网带宽从 200Gbps 到 800Gbps 不等。万卡集群通常采用分层拓扑成百上千台节点通过接入层交换机、汇聚层交换机、核心交换机连接。跨机通信的带宽比卡间 NVLink 低一个数量级以上所以训练框架会在设计并行策略时尽量避免频繁的跨机通信。5. 从单机多卡到跨机多卡集群拓扑设计的关键点万卡集群的拓扑设计直接影响通信性能而且问题往往是“木桶效应”决定的。5.1 多对一拥塞问题在数据并行训练中梯度同步时很多卡会同时向相同的目的卡发送数据。如果网络拓扑设计不合理交换机的上行端口带宽不足就会出现多对一拥塞大量数据在交换队列里排队延迟急剧增大。典型表现是GPU 利用率忽高忽低训练吞吐波动明显AllReduce 耗时从几十毫秒突增到几百毫秒。5.2 长尾延迟万卡集群中有成百上千台机器每台机器的硬件状态、网络链路质量都存在差异。整个 AllReduce 过程的耗时取决于最慢的那张卡。如果某台机器的网卡老化或网线松动它就会成为长尾节点拖累全局训练速度。运维上常用做法是定期做网络诊断测带宽、测延迟、跑集合通信基准测试提前发现潜在问题。5.3 拓扑设计与并行策略配合这里给一个通用设计原则把通信频繁的并行维度放在同一节点内。张量并行放在单机 8 卡的 NVLink 域内。把通信频率较低的维度放在跨机。数据并行、流水线并行可以跨机。尽量让跨机通信流量均匀分布避免把核心交换机的某条链路打满。如果一个集群采用 8 卡节点训练 70B 模型时常见的并行方案是8 卡张量并行、4 路流水线并行、跨 32 个节点做数据并行。这样跨机通信只发生在每个流水线阶段之间以及梯度同步阶段通信量可控。6. 故障、Checkpoint 与恢复6.1 万卡训练必然遇到故障前面提到万卡规模下故障是常态而不是偶然。常见的故障类型包括GPU 硬件故障比如显存报错、卡掉线。网络故障比如链路闪断、光模块不稳定。节点宕机比如电源、散热问题。软件故障比如 CUDA 版本冲突、框架崩溃、OOM。如果不做容错任何一张卡故障都会导致整个训练任务失败。对于跑了几周的训练任务损失会非常大。6.2 Checkpoint 机制应对故障的主要手段是周期性保存模型状态也就是 Checkpoint。Checkpoint 需要保存的内容通常包括模型权重、优化器状态、学习率调度器状态、当前训练步数、数据加载进度、随机数生成器状态。保存内容越多文件越大。一个 70B 模型用 Adam 优化器训练Checkpoint 大小可能达到数百 GB。如果频繁保存存储压力和保存耗时都会成为问题。常见做法是每 N 步保存一次并同时保存一个“恢复点”。恢复点保存频率较低但会保存一个完整可恢复的稳定版本。二者配合可以平衡恢复粒度和存储成本。6.3 分布式 Checkpoint 设计万卡训练还面临一个额外问题如果只有一张主卡保存 Checkpoint存储写入会成为瓶颈而且保存期间全集群要停顿等待。更合理的方式是分布式 Checkpoint每张卡只保存自己负责的那部分模型状态保存完毕后由调度系统把它们聚合成一个完整版本或者直接保存在分布式文件系统中。同时很多框架支持异步 Checkpoint内存中先把状态拷贝一份然后后台线程写盘训练主流程不阻塞。这样可以降低 Checkpoint 对训练吞吐的影响但对存储带宽要求更高。7. 数据加载与存储 I/O最容易被低估的瓶颈大语言模型训练对数据加载的要求非常高。如果 GPU 显存充足、计算密集但数据读取慢GPU 会出现“吃不饱”的情况训练吞吐直接下降。7.1 为什么单卡没问题万卡有问题单卡训练时数据加载可以依赖本地 NVMe 磁盘配合小型内存缓存就够了。万卡训练时假设每张卡每秒需要读取 500MB 数据一万张卡聚合吞吐量就是 5TB/s。这个数字已经远超单机存储系统能力必须依赖高性能分布式存储或者全内存缓存。7.2 常见优化手段在实际训练中数据加载一般会从几个方向优化预取与流水线CPU 提前读取下一批数据放入内存队列与 GPU 计算重叠。数据格式优化使用内存映射格式或者专门的训练数据格式减少随机小文件读取。本地缓存把常用数据预热到节点本地 NVMe 盘。数据去重与混合大规模预训练需要做数据混洗保证不同数据源的分布稳定。如果训练时发现 GPU 利用率低但 CPU 和内存占用不高大概率是数据加载没有跟上。8. 万卡训练的评估方法与性能观察分布式训练做得好不好不能只看训练脚本是否能跑起来还要看集群的有效算力是否被发挥出来。这里介绍几个最关键的评估角度。8.1 吞吐量吞吐量是最直接的指标分为两种全局吞吐量整个集群每秒处理的样本数或 token 数公式为 全局 batch size 除以单步训练耗时。单卡吞吐量用全局吞吐量除以卡数用来比较不同规模配置下的单卡效率。如果从 1000 卡扩展到 2000 卡单卡吞吐量明显下降说明扩展性出了问题通常是通信或负载不均衡导致。8.2 MFUModel FLOPS UtilizationMFU 是实际计算吞吐和硬件理论峰值算力的比值衡量 GPU 算力利用效率。MFU 的计算公式可以理解为实际每秒浮点运算次数 除以 硬件理论峰值浮点运算次数。在大模型训练实践中MFU 达到 40% 以上已经算不错顶尖优化可以做到 50% 甚至更高。如果 MFU 只有 10%说明大量算力都浪费在等待、通信或低效计算上。8.3 显存与资源监控训练过程中需要持续观察显存和 GPU 利用率。最常用的命令是# 实时查看 GPU 利用率、显存占用、温度、功耗 nvidia-smi # 以 1 秒间隔持续监控某个 GPU 的利用率 nvidia-smi dmon -s pucvmet -i 0如果 GPU 利用率长期低于 90%就需要排查是否数据加载过慢、通信等待时间过长或者 batch size 设置过小。8.4 Profiler 定位瓶颈只用 nvidia-smi 难以确定问题出在哪个环节。建议使用 PyTorch Profiler 或 NVIDIA Nsight Systems 这类工具追踪每个算子的耗时、通信等待时间和数据加载耗时。import torch with torch.profiler.profile( activities[ torch.profiler.ProfilerActivity.CPU, torch.profiler.ProfilerActivity.CUDA, ], scheduletorch.profiler.schedule(wait1, warmup1, active3) ) as prof: for step in range(10): train_step() prof.step() print(prof.key_averages().table(sort_bycuda_time_total))通过 Profiler 可以清楚看到单个 step 中计算占多少时间、通信占多少时间、数据加载占多少时间从而判断优化方向。9. 常见问题与排查方法万卡训练中总会遇到性能不佳或任务中断的问题。下面整理了一张排查表覆盖最常见的几类情况。问题现象可能原因排查方式解决方案训练 loss 不收敛或震荡学习率过大、数据顺序问题、batch size 突变检查学习率曲线、数据混洗逻辑调低学习率增加 warmup修复数据顺序GPU 利用率低数据加载慢、通信等待、batch size 太小查看 dmon 和 Profiler增加预取线程、加大 batch、优化数据格式多卡训练吞吐不增长并行策略不合理、通信占比过高对比单卡和 N 卡吞吐调整张量并行、流水线并行组合训练过程中断网络闪断、GPU 掉卡、驱动崩溃查看系统日志和 NCCL 报错启用 Checkpoint定期重启任务检查硬件通信超时网络拥塞、交换机故障、网卡异常跑 NCCL 基准测试排查链路、更换故障设备、调整拓扑显存不足 OOMbatch size 过大、序列过长、激活值太多查看显存占用趋势减小 batch、开启梯度检查点、使用 ZeRO 或显存卸载数据加载成为瓶颈存储带宽不足、小文件随机读查看数据加载耗时占比使用本地缓存、预取、合并小文件保存 Checkpoint 卡顿写盘速度慢、全局同步等待查看磁盘写入速率使用异步 Checkpoint、分布式保存这些问题的共性特点是现象往往在 GPU 利用率或训练日志上先反映出来但根因可能来自网络、存储或代码逻辑。排查时不要只盯 GPU要把 CPU、内存、网络、磁盘一起纳入观察范围。10. 工程最佳实践从小规模验证到大规模集群万卡训练不是直接把数据、模型丢上去就能跑通的。合理的工程节奏是先小规模验证再渐进式扩卡最后做大集群长稳训练。建议按下面四步推进。第一步单卡或小规模测试。先用小 batch、小模型、少量数据跑通完整训练流程确认 loss 能正常下降模型代码没有逻辑错误。第二步单机多卡测试。切成 8 卡或 16 卡观察吞吐提升比例。如果加速比不理想优先排查通信等待和数据加载。第三步小规模跨机测试。建议先跑 32 卡或 64 卡验证跨机网络、NCCL 通信、分布式 Checkpoint 是否正常。第四步扩展到千卡或万卡。在前三步都通过的基础上逐步增加节点数。每增加一批节点观察单卡吞吐量和通信耗时确认线性扩展能力。配置管理方面建议把训练参数、模型并行策略、数据路径统一放到配置文件中避免每次扩容都要手改脚本。下面给一个参考配置实际使用时按项目调整train: model_size: 7B seq_len: 2048 global_batch_size: 1024 micro_batch_size: 4 learning_rate: 3.0e-4 warmup_steps: 2000 max_steps: 100000 precision: bf16 parallelism: data_parallel_size: 64 tensor_parallel_size: 8 pipeline_parallel_size: 4 checkpoint: save_interval: 500 save_dir: /data/checkpoints/ async: true logging: log_interval: 10 save_loss_to_wandb: true实际操作中建议把 Checkpoint 保存失败的次数、通信基准测试结果、GPU 利用率曲线都纳入训练日志。这些数据在后续排查问题时非常关键。还需要注意的是训练数据涉及真实业务或个人信息时要确认数据来源合法、经过必要的脱敏处理模型权重如果来自第三方开源项目也要阅读其许可证确认是否允许商用、修改和再分发。人脸、声音、版权素材等高风险内容尤其在生成类模型训练中必须取得明确授权后再使用。11. 总结与下一步这一集的核心结论是从单卡到万卡分布式训练最大的系统挑战并不是算法本身而是通信、容错、数据加载和稳定性的综合工程问题。并行策略决定了模型和数据如何被切分通信拓扑决定了数据流动效率Checkpoint 机制决定了故障后的恢复成本而数据 I/O 决定了 GPU 能否被真正喂饱。如果只记住一个判断方法那就是从 100 卡扩展到 1000 卡时重点看单卡吞吐量和 MFU 是否保持稳定。如果掉得厉害问题大概率出在通信和负载均衡上而不是模型代码上。如果后续继续深入建议按这个顺序展开先掌握 PyTorch DDP 和 torchrun 的用法再研究 DeepSpeed ZeRO 的显存优化原理接着读 Megatron-LM 的张量并行实现最后再看万卡集群的调度和网络拓扑设计。这条路走下来基本上就能把多数大模型训练的系统和工程问题看得比较清楚。建议把本文收藏备用尤其是里面的排查表和性能评估方法在真正搭建或运维分布式训练环境时可以直接对照使用。 从单卡到万卡：分布式训练的系统挑战与工程实践
从单卡到万卡真正的难点从来不是“把卡堆多”而是让一万张卡像一张卡一样协同工作。很多人以为分布式训练就是把数据切碎、丢到更多 GPU 上但真实情况是通信瓶颈、故障概率、数据加载、稳定性、调度效率任何一环出问题整个集群的等效算力都会被打折。这一集《从比特到AI系统》第三十五集就聚焦“从单卡到万卡”这条主线拆解分布式训练背后的系统挑战。这里不是泛泛讲概念而是要回答几个非常实际的问题万卡训练为什么那么难为什么有时候一万张卡训练一千张卡加速比却不到 5 倍分布式训练里的通信、并行、容错、数据 I/O 到底怎么设计本文将把并行模式、通信开销、故障恢复、存储吞吐、性能评估和排查方法完整过一遍适合正在接触大模型训练、集群调度、AI 基础设施或者想搞清楚“大模型为什么要用几千张卡”的读者。1. 万卡分布式训练核心问题速览先给一张总览表把分布式训练从单卡到万卡的关键维度列清楚。这张表可以当作后面每个章节的索引也可以先收藏等真正需要排查问题时再回来看。维度关键内容训练规模单卡、单机多卡、多机多卡、千卡级、万卡级主要并行策略数据并行、张量并行、流水线并行、专家并行最大系统瓶颈通信开销、故障率、数据加载带宽、调度效率关键衡量指标吞吐量Tokens/s、MFU、有效训练时间占比通信基础设施NVLink、InfiniBand、RoCE 以太网、拓扑结构容错机制周期性 Checkpoint、异步保存、故障重启恢复常见框架PyTorch DDP/FSDP、Megatron-LM、DeepSpeed硬件约束GPU 显存、卡间带宽、跨机带宽、存储吞吐量主要挑战通信与计算重叠、负载均衡、长稳训练、成本控制适合读者大模型训练工程师、AI 平台开发、集群运维从这张表也能看出分布式训练涉及的已经不单是模型算法问题而是计算、网络、存储、调度、容错等多个系统的交叉问题。这也是为什么它被称作“AI 系统工程”而不是单纯的“训练代码优化”。2. 从单卡到万卡问题是怎么变大的回顾一下训练的基本流程就能看清“万卡”到底难在哪里。单卡训练时前向传播、反向传播、梯度更新都发生在同一张卡上数据从本机内存或磁盘读入模型参数也常驻在显存里整个过程不需要和其他设备交换数据。到了多卡数据并行每张卡保存一份完整模型副本各自处理不同的 batch然后通过 AllReduce 集合通信同步梯度保证每张卡上的模型更新一致。此时开始引入通信开销但规模在 4 卡、8 卡时这个开销通常还能接受。到了几百卡甚至万卡问题会从量变到质变。先看通信。数据并行下每步训练都需要同步梯度。以一个 7B 参数模型为例如果用 FP16 训练梯度大小约为 14GB 左右一次 AllReduce 需要做 reduce 和 broadcast 两轮传输整体通信量约等于 28GB 量级。这个数字在 8 卡时可以靠 NVLink 撑住但在万卡集群里跨机通信会经过交换机网络带宽和拓扑结构直接决定训练速度。再看故障。单卡训练的故障概率很低训练几小时可能不会遇到问题。但到万卡规模假设单卡每天故障概率是 0.1%一万张卡的期望故障数就是每天 10 张。也就是说每训练一段时间就可能出现卡掉线、通信超时、训练中断。如果没有完善的 Checkpoint 机制一个跑了一周的万卡训练任务可能因为一张卡故障全部重来。再看数据加载。单卡时数据读取压力低主存和本地磁盘就能满足。万卡训练时每张卡每分钟要消费大量样本存储系统需要提供极高的聚合吞吐量否则 GPU 会一直等数据造成巨大的算力浪费。所以万卡训练的本质挑战可以概括为四个词通信、容错、数据、稳定性。3. 四类主流并行策略切数据还是切模型分布式训练的并行策略不是单选而是组合使用。大规模训练中模型会被同时按多种方式切分这里逐一说明各类并行策略的特点和适用场景。3.1 数据并行数据并行的核心思想是“每张卡一份模型数据切分到不同卡”。每张卡完成自己的 batch 计算后通过 AllReduce 同步梯度确保模型一致。数据并行实现最简单PyTorch DDP、DeepSpeed ZeRO 都属于数据并行范畴。它的局限在于单卡显存必须能装下完整模型当模型规模达到数十亿甚至上百亿参数时单卡显存无法容纳完整模型和梯度就需要配合模型并行使用。3.2 张量并行张量并行把一个 Layer 内的参数切分成多份分布到多张卡上。例如计算一个线性层 y XW可以把权重矩阵 W 按列切分不同卡持有 W 的一部分前向传播时各自计算局部结果最后通过 AllReduce 合并。张量并行会显著增加通信频率因为每一层计算都要做一次聚合。它通常用在单机内部、同一节点上的多卡之间依赖 NVLink 或 PCIe 高速互联。跨机做张量并行对网络延迟非常敏感一般不推荐。3.3 流水线并行流水线并行按模型层进行切分比如把 96 层 Transformer 分成 4 段每张卡负责连续的若干层。数据像流水线一样依次经过各卡计算。流水线并行的优点是通信频率比张量并行低只需在段与段之间传递激活值和梯度。缺点是会引入流水线气泡bubble即部分卡在等待前序卡计算时处于空闲状态。层数越多、切分越均匀气泡越小。3.4 专家并行专家并行主要用在 MoEMixture of Experts模型上。MoE 模型把 FFN 层替换为多个专家子网络每次输入只激活部分专家。专家并行会把不同专家放到不同卡上通过路由机制把 token 分发给对应专家。专家并行的难点在于负载均衡如果某个 token 分布不均衡某些卡会被打满而另外一些卡空闲。这也是 MoE 训练比稠密模型更难优化的原因之一。3.5 怎么组合使用实际万卡训练很少只使用一种并行策略。常见做法是以数据并行作为基础维度在单机内部叠加张量并行在跨机维度叠加流水线并行MoE 模型再叠加专家并行。DeepSpeed、Megatron-LM 都提供类似组合能力。并行类型切分维度通信频率典型场景代表框架数据并行训练数据每步一次梯度同步小模型、大 batchPyTorch DDP、DeepSpeed张量并行层内权重每层多次聚合大模型单机多卡Megatron-LM流水线并行层间切分段间传输激活跨机大模型Megatron-LM、PipeDream专家并行MoE 专家路由分发MoE 大模型DeepSpeed-MoE4. 通信开销万卡集群的第一约束4.1 AllReduce 为什么会成为瓶颈数据并行训练中每张卡算完梯度后需要把所有卡的梯度加起来并广播给所有人这就是 AllReduce 操作。最原始的 AllReduce 实现是“单卡收集再广播”通信量随卡数线性增长万卡时完全不现实。现代框架使用 Ring AllReduce 等算法把通信量从 O(N) 降为 O(1)每张卡的通信量与卡数无关但通信延迟和网络拥塞问题依然存在。Ring AllReduce 的基本思路是把所有卡连成一个逻辑环每张卡只与相邻卡通信梯度先切块做 ring reduce再做 ring broadcast。这样单卡通信量约为 2 倍模型参数量和卡数无关。这是最容易理解也不需要额外硬件的优化方案。4.2 一次训练迭代的实际通信量估算以 7B 模型、FP16 梯度为例一次 AllReduce 大约要传输 2 × 2 × 7GB 28GB 数据。如果网络带宽是 200Gbps约 25GB/s理论上单次同步需要 1 秒以上。但如果单步计算本身只要 1 秒通信占比就会超过 50%训练效率很低。这也是为什么真正的万卡训练必须使用梯度压缩、通信与计算重叠、混合并行策略以及对网络拓扑做专门设计否则通信时间会占据大部分训练时间。4.3 网络拓扑与带宽从单机到万卡网络拓扑会经历几个阶段单机多卡主要走 NVLink带宽通常在 900GB/s 级别延迟极低。多机互联需要经过网卡和交换机常见方案是 InfiniBand 或 RoCE 以太网带宽从 200Gbps 到 800Gbps 不等。万卡集群通常采用分层拓扑成百上千台节点通过接入层交换机、汇聚层交换机、核心交换机连接。跨机通信的带宽比卡间 NVLink 低一个数量级以上所以训练框架会在设计并行策略时尽量避免频繁的跨机通信。5. 从单机多卡到跨机多卡集群拓扑设计的关键点万卡集群的拓扑设计直接影响通信性能而且问题往往是“木桶效应”决定的。5.1 多对一拥塞问题在数据并行训练中梯度同步时很多卡会同时向相同的目的卡发送数据。如果网络拓扑设计不合理交换机的上行端口带宽不足就会出现多对一拥塞大量数据在交换队列里排队延迟急剧增大。典型表现是GPU 利用率忽高忽低训练吞吐波动明显AllReduce 耗时从几十毫秒突增到几百毫秒。5.2 长尾延迟万卡集群中有成百上千台机器每台机器的硬件状态、网络链路质量都存在差异。整个 AllReduce 过程的耗时取决于最慢的那张卡。如果某台机器的网卡老化或网线松动它就会成为长尾节点拖累全局训练速度。运维上常用做法是定期做网络诊断测带宽、测延迟、跑集合通信基准测试提前发现潜在问题。5.3 拓扑设计与并行策略配合这里给一个通用设计原则把通信频繁的并行维度放在同一节点内。张量并行放在单机 8 卡的 NVLink 域内。把通信频率较低的维度放在跨机。数据并行、流水线并行可以跨机。尽量让跨机通信流量均匀分布避免把核心交换机的某条链路打满。如果一个集群采用 8 卡节点训练 70B 模型时常见的并行方案是8 卡张量并行、4 路流水线并行、跨 32 个节点做数据并行。这样跨机通信只发生在每个流水线阶段之间以及梯度同步阶段通信量可控。6. 故障、Checkpoint 与恢复6.1 万卡训练必然遇到故障前面提到万卡规模下故障是常态而不是偶然。常见的故障类型包括GPU 硬件故障比如显存报错、卡掉线。网络故障比如链路闪断、光模块不稳定。节点宕机比如电源、散热问题。软件故障比如 CUDA 版本冲突、框架崩溃、OOM。如果不做容错任何一张卡故障都会导致整个训练任务失败。对于跑了几周的训练任务损失会非常大。6.2 Checkpoint 机制应对故障的主要手段是周期性保存模型状态也就是 Checkpoint。Checkpoint 需要保存的内容通常包括模型权重、优化器状态、学习率调度器状态、当前训练步数、数据加载进度、随机数生成器状态。保存内容越多文件越大。一个 70B 模型用 Adam 优化器训练Checkpoint 大小可能达到数百 GB。如果频繁保存存储压力和保存耗时都会成为问题。常见做法是每 N 步保存一次并同时保存一个“恢复点”。恢复点保存频率较低但会保存一个完整可恢复的稳定版本。二者配合可以平衡恢复粒度和存储成本。6.3 分布式 Checkpoint 设计万卡训练还面临一个额外问题如果只有一张主卡保存 Checkpoint存储写入会成为瓶颈而且保存期间全集群要停顿等待。更合理的方式是分布式 Checkpoint每张卡只保存自己负责的那部分模型状态保存完毕后由调度系统把它们聚合成一个完整版本或者直接保存在分布式文件系统中。同时很多框架支持异步 Checkpoint内存中先把状态拷贝一份然后后台线程写盘训练主流程不阻塞。这样可以降低 Checkpoint 对训练吞吐的影响但对存储带宽要求更高。7. 数据加载与存储 I/O最容易被低估的瓶颈大语言模型训练对数据加载的要求非常高。如果 GPU 显存充足、计算密集但数据读取慢GPU 会出现“吃不饱”的情况训练吞吐直接下降。7.1 为什么单卡没问题万卡有问题单卡训练时数据加载可以依赖本地 NVMe 磁盘配合小型内存缓存就够了。万卡训练时假设每张卡每秒需要读取 500MB 数据一万张卡聚合吞吐量就是 5TB/s。这个数字已经远超单机存储系统能力必须依赖高性能分布式存储或者全内存缓存。7.2 常见优化手段在实际训练中数据加载一般会从几个方向优化预取与流水线CPU 提前读取下一批数据放入内存队列与 GPU 计算重叠。数据格式优化使用内存映射格式或者专门的训练数据格式减少随机小文件读取。本地缓存把常用数据预热到节点本地 NVMe 盘。数据去重与混合大规模预训练需要做数据混洗保证不同数据源的分布稳定。如果训练时发现 GPU 利用率低但 CPU 和内存占用不高大概率是数据加载没有跟上。8. 万卡训练的评估方法与性能观察分布式训练做得好不好不能只看训练脚本是否能跑起来还要看集群的有效算力是否被发挥出来。这里介绍几个最关键的评估角度。8.1 吞吐量吞吐量是最直接的指标分为两种全局吞吐量整个集群每秒处理的样本数或 token 数公式为 全局 batch size 除以单步训练耗时。单卡吞吐量用全局吞吐量除以卡数用来比较不同规模配置下的单卡效率。如果从 1000 卡扩展到 2000 卡单卡吞吐量明显下降说明扩展性出了问题通常是通信或负载不均衡导致。8.2 MFUModel FLOPS UtilizationMFU 是实际计算吞吐和硬件理论峰值算力的比值衡量 GPU 算力利用效率。MFU 的计算公式可以理解为实际每秒浮点运算次数 除以 硬件理论峰值浮点运算次数。在大模型训练实践中MFU 达到 40% 以上已经算不错顶尖优化可以做到 50% 甚至更高。如果 MFU 只有 10%说明大量算力都浪费在等待、通信或低效计算上。8.3 显存与资源监控训练过程中需要持续观察显存和 GPU 利用率。最常用的命令是# 实时查看 GPU 利用率、显存占用、温度、功耗 nvidia-smi # 以 1 秒间隔持续监控某个 GPU 的利用率 nvidia-smi dmon -s pucvmet -i 0如果 GPU 利用率长期低于 90%就需要排查是否数据加载过慢、通信等待时间过长或者 batch size 设置过小。8.4 Profiler 定位瓶颈只用 nvidia-smi 难以确定问题出在哪个环节。建议使用 PyTorch Profiler 或 NVIDIA Nsight Systems 这类工具追踪每个算子的耗时、通信等待时间和数据加载耗时。import torch with torch.profiler.profile( activities[ torch.profiler.ProfilerActivity.CPU, torch.profiler.ProfilerActivity.CUDA, ], scheduletorch.profiler.schedule(wait1, warmup1, active3) ) as prof: for step in range(10): train_step() prof.step() print(prof.key_averages().table(sort_bycuda_time_total))通过 Profiler 可以清楚看到单个 step 中计算占多少时间、通信占多少时间、数据加载占多少时间从而判断优化方向。9. 常见问题与排查方法万卡训练中总会遇到性能不佳或任务中断的问题。下面整理了一张排查表覆盖最常见的几类情况。问题现象可能原因排查方式解决方案训练 loss 不收敛或震荡学习率过大、数据顺序问题、batch size 突变检查学习率曲线、数据混洗逻辑调低学习率增加 warmup修复数据顺序GPU 利用率低数据加载慢、通信等待、batch size 太小查看 dmon 和 Profiler增加预取线程、加大 batch、优化数据格式多卡训练吞吐不增长并行策略不合理、通信占比过高对比单卡和 N 卡吞吐调整张量并行、流水线并行组合训练过程中断网络闪断、GPU 掉卡、驱动崩溃查看系统日志和 NCCL 报错启用 Checkpoint定期重启任务检查硬件通信超时网络拥塞、交换机故障、网卡异常跑 NCCL 基准测试排查链路、更换故障设备、调整拓扑显存不足 OOMbatch size 过大、序列过长、激活值太多查看显存占用趋势减小 batch、开启梯度检查点、使用 ZeRO 或显存卸载数据加载成为瓶颈存储带宽不足、小文件随机读查看数据加载耗时占比使用本地缓存、预取、合并小文件保存 Checkpoint 卡顿写盘速度慢、全局同步等待查看磁盘写入速率使用异步 Checkpoint、分布式保存这些问题的共性特点是现象往往在 GPU 利用率或训练日志上先反映出来但根因可能来自网络、存储或代码逻辑。排查时不要只盯 GPU要把 CPU、内存、网络、磁盘一起纳入观察范围。10. 工程最佳实践从小规模验证到大规模集群万卡训练不是直接把数据、模型丢上去就能跑通的。合理的工程节奏是先小规模验证再渐进式扩卡最后做大集群长稳训练。建议按下面四步推进。第一步单卡或小规模测试。先用小 batch、小模型、少量数据跑通完整训练流程确认 loss 能正常下降模型代码没有逻辑错误。第二步单机多卡测试。切成 8 卡或 16 卡观察吞吐提升比例。如果加速比不理想优先排查通信等待和数据加载。第三步小规模跨机测试。建议先跑 32 卡或 64 卡验证跨机网络、NCCL 通信、分布式 Checkpoint 是否正常。第四步扩展到千卡或万卡。在前三步都通过的基础上逐步增加节点数。每增加一批节点观察单卡吞吐量和通信耗时确认线性扩展能力。配置管理方面建议把训练参数、模型并行策略、数据路径统一放到配置文件中避免每次扩容都要手改脚本。下面给一个参考配置实际使用时按项目调整train: model_size: 7B seq_len: 2048 global_batch_size: 1024 micro_batch_size: 4 learning_rate: 3.0e-4 warmup_steps: 2000 max_steps: 100000 precision: bf16 parallelism: data_parallel_size: 64 tensor_parallel_size: 8 pipeline_parallel_size: 4 checkpoint: save_interval: 500 save_dir: /data/checkpoints/ async: true logging: log_interval: 10 save_loss_to_wandb: true实际操作中建议把 Checkpoint 保存失败的次数、通信基准测试结果、GPU 利用率曲线都纳入训练日志。这些数据在后续排查问题时非常关键。还需要注意的是训练数据涉及真实业务或个人信息时要确认数据来源合法、经过必要的脱敏处理模型权重如果来自第三方开源项目也要阅读其许可证确认是否允许商用、修改和再分发。人脸、声音、版权素材等高风险内容尤其在生成类模型训练中必须取得明确授权后再使用。11. 总结与下一步这一集的核心结论是从单卡到万卡分布式训练最大的系统挑战并不是算法本身而是通信、容错、数据加载和稳定性的综合工程问题。并行策略决定了模型和数据如何被切分通信拓扑决定了数据流动效率Checkpoint 机制决定了故障后的恢复成本而数据 I/O 决定了 GPU 能否被真正喂饱。如果只记住一个判断方法那就是从 100 卡扩展到 1000 卡时重点看单卡吞吐量和 MFU 是否保持稳定。如果掉得厉害问题大概率出在通信和负载均衡上而不是模型代码上。如果后续继续深入建议按这个顺序展开先掌握 PyTorch DDP 和 torchrun 的用法再研究 DeepSpeed ZeRO 的显存优化原理接着读 Megatron-LM 的张量并行实现最后再看万卡集群的调度和网络拓扑设计。这条路走下来基本上就能把多数大模型训练的系统和工程问题看得比较清楚。建议把本文收藏备用尤其是里面的排查表和性能评估方法在真正搭建或运维分布式训练环境时可以直接对照使用。