1. 大模型训练为什么必须突破单卡限制1.1 从一个现实困境说起先抛一个我亲身踩过的场景。早两年做一个小规模的语言模型微调参数量大概在1.5B左右当时手里只有一张24G显存的消费级卡。加载模型权重、优化器状态、梯度、激活值还没开始训练显存就已经红了。我试过梯度累积、混合精度、梯度检查点能省的地方全抠了一遍勉强能跑起来但batch size只能压到1训练速度慢到让人怀疑人生。这个困境不是个例。当模型参数量从亿级跨到百亿、千亿甚至万亿级时单张GPU的显存容量、显存带宽、算力上限三座大山同时压过来。一张H100有80G显存听起来不小但一个70B参数的模型光是FP16权重就要140G再加上优化器状态Adam的话通常是参数量的2倍、梯度、激活值轻松突破500G。单卡根本装不下。所以问题就变成了怎么把一个大模型拆开放到多张卡上让它们协同工作这就是分布式训练要解决的核心问题。而拆的方式不同就衍生出了数据并行、流水线并行、张量并行、混合专家模型这几条主流技术路线。1.2 四种并行策略的定位差异很多刚接触分布式训练的朋友容易把这几种并行方式搞混觉得它们是互相替代的关系。实际上它们更像是不同维度的拆分工具各自解决不同层面的问题。数据并行解决的是“数据太多、算力不够”的问题——每张卡拿一份完整的模型副本喂不同的数据算完梯度再同步。流水线并行解决的是“模型太深、单卡放不下”的问题——把模型按层切成几段每张卡负责一段数据像流水线一样依次流过。张量并行解决的是“单层太大、一张卡装不下”的问题——把矩阵乘法拆开同一层的计算分到多张卡上。混合专家模型则是从模型架构层面做文章让不同的输入只激活部分参数用稀疏性来降低计算量。这四种策略不是非此即彼的选择实际的大模型训练往往是组合使用。比如一个千亿级模型可能同时用到张量并行层内拆分、流水线并行层间拆分、数据并行数据拆分再加上混合专家架构来提升参数效率。接下来我逐个拆解每种策略的核心原理、实操要点和踩坑经验。2. 数据并行最成熟但也最容易踩坑的方案2.1 数据并行的核心原理与通信机制数据并行的逻辑最直观你有8张卡就把一份完整的模型复制8份每张卡用不同的数据子集做前向和反向传播然后通过AllReduce操作把所有卡上的梯度求平均再用平均后的梯度更新各自的模型参数。因为每张卡的模型初始参数相同、更新梯度也相同所以训练过程中模型始终保持一致。听起来很简单对吧但这里有个关键问题AllReduce的通信开销。假设模型有10B参数FP16精度下梯度就是20G。每次迭代都要在8张卡之间同步这20G的数据如果卡间带宽不够通信时间可能比计算时间还长。这就是为什么数据并行在小模型上很香但到了大模型就力不从心——通信量跟模型参数量成正比模型越大通信瓶颈越严重。为了解决这个问题业界提出了梯度累积和通信压缩两种思路。梯度累积是让每张卡先算几个batch的梯度攒在一起再同步减少通信频率。通信压缩则是对梯度做量化或稀疏化比如把FP32梯度压成FP16甚至INT8再传输牺牲一点精度换带宽。注意梯度累积虽然能减少通信次数但会增大等效batch size可能影响收敛性。我一般建议在显存允许的情况下优先用更大的单卡batch而不是靠累积硬撑。2.2 从DP到DDP再到ZeRO的演进路线最早的数据并行实现是PyTorch的DataParallelDP但它有个致命缺陷所有卡的梯度都要汇总到主卡上做平均主卡的显存和带宽成为瓶颈。后来出现了DistributedDataParallelDDP用Ring AllReduce算法让每张卡只跟相邻卡通信带宽利用率大幅提升。但DDP仍然要求每张卡存一份完整的模型、梯度、优化器状态。一个10B模型用Adam优化器FP16混合精度下权重20G、梯度20G、优化器状态FP32的momentum和variance80G加起来120G单卡根本放不下。于是微软提出了ZeROZero Redundancy Optimizer核心思想是把冗余的部分切分到各张卡上。ZeRO有三个阶段Stage 1切分优化器状态Stage 2再切分梯度Stage 3连模型参数也切分。每推进一个阶段单卡显存占用就降一截但通信量会相应增加。策略单卡显存占用相对值通信量相对值适用场景朴素DP1.01.0小模型、单机多卡DDP1.00.8中等模型、多机多卡ZeRO-10.61.2大模型、优化器状态占大头ZeRO-20.41.5大模型、梯度也占大头ZeRO-30.22.0超大模型、单卡装不下参数实际用的时候ZeRO-3虽然省显存但通信开销大训练速度会明显下降。我的经验是如果ZeRO-2能跑起来就别上ZeRO-3。只有当模型大到ZeRO-2也装不下时才考虑ZeRO-3配合CPU Offload。2.3 数据并行的实操配置与避坑指南以PyTorch的DDP为例一个典型的启动脚本大概长这样torchrun --nproc_per_node8 --nnodes2 --node_rank0 \ --master_addr192.168.1.1 --master_port29500 \ train.py --batch_size 32 --lr 1e-4关键配置项包括nproc_per_node是每台机器的GPU数nnodes是机器总数master_addr是主节点地址。训练脚本里需要用DistributedSampler来切分数据确保每张卡拿到不重叠的子集。踩过的坑里最常见的是数据加载不均衡。如果数据集大小不能被GPU数整除最后几个batch会出现有的卡有数据、有的卡没数据的情况导致AllReduce卡住。解决办法是设置drop_lastTrue或者用DistributedSampler的drop_last参数。另一个坑是学习率缩放。数据并行下等效batch size变成了单卡batch乘以卡数学习率通常需要线性缩放。比如单卡batch 8、学习率1e-4换成8卡后等效batch 64学习率应该调到8e-4左右。但这不是铁律大batch下可能需要用平方根缩放或者warmup来稳定训练。实操心得DDP启动时如果卡在NCCL初始化先检查防火墙和网卡配置。我遇到过因为MTU设置不一致导致NCCL握手失败的情况把MTU统一改成9000就解决了。3. 流水线并行把模型切成段让数据流起来3.1 流水线并行的基本逻辑与气泡问题流水线并行的思路很朴素模型有80层我有8张卡那就每张卡放10层数据从第一张卡进去算完10层传给第二张卡依次往后传。这样每张卡只需要存1/8的模型参数显存压力大幅降低。但问题来了如果只有一份数据在流水线上跑那同一时刻只有一张卡在干活其他7张卡都在等。这就是所谓的流水线气泡。为了解决这个问题需要把数据切成多个micro-batch让它们像工厂流水线一样错开时间进入。比如第一个micro-batch在卡1上算的时候卡2可以处理上一个micro-batch的数据以此类推。气泡的大小取决于流水线深度和micro-batch数量。假设有P个流水线阶段M个micro-batch那气泡占比大约是(P-1)/(MP-1)。想让气泡小要么减少流水线阶段数要么增加micro-batch数。但micro-batch太多又会增加通信次数和显存占用需要权衡。3.2 GPipe与PipeDream的调度差异最早的流水线并行方案是GPipe它把所有micro-batch的前向算完再统一做反向传播。这种方式显存占用高因为要保存所有micro-batch的中间激活值。后来PipeDream提出了1F1BOne Forward One Backward调度前向和反向交替进行显存占用大幅降低。实际用的时候PyTorch的torch.distributed.pipeline.sync.Pipe和DeepSpeed的Pipeline模块都支持1F1B调度。配置上主要关注chunks参数即micro-batch数量和balance参数各阶段层数分配。层数分配是个技术活。如果每张卡算力相同平均分配就行。但如果卡型不一致比如有的A100有的V100就需要按算力比例分配层数否则快的卡要等慢的卡整体效率被拖累。调度方式显存占用气泡占比实现复杂度GPipe高中低1F1B中中中Interleaved 1F1B低低高Interleaved 1F1B是更进阶的方案它把每张卡负责的层再切成多个chunk进一步缩小气泡。但实现复杂度也更高一般用现成框架就好不建议自己手写。3.3 流水线并行的实际部署经验我在一个跨节点场景下部署过流水线并行8台机器每台8卡总共64卡。踩的最大的坑是跨节点通信延迟。流水线并行需要频繁地在相邻阶段之间传激活值如果相邻阶段跨了节点走网络传输的延迟比走NVLink高一个数量级。解决办法是尽量让相邻流水线阶段在同一节点内。比如8卡机器可以分配4个流水线阶段每个阶段2张卡做张量并行这样阶段间的通信走NVLink快很多。另一个经验是micro-batch数量要调优。太少气泡大太多显存爆。我一般从4开始试逐步增加到8、16观察显存和吞吐的变化。通常8到16之间能找到比较好的平衡点。注意流水线并行下每个阶段的输出需要缓存起来给反向传播用。如果micro-batch太多激活值缓存会吃掉大量显存。可以用梯度检查点技术来换显存代价是计算量增加约30%。4. 张量并行把矩阵乘法拆到多张卡上4.1 张量并行的数学原理拆解张量并行跟流水线并行的思路完全不同。流水线并行是“按层切”张量并行是“按计算切”。拿一个简单的矩阵乘法Y XA来说如果A太大放不下一张卡可以按列切成A [A1, A2]让卡1算XA1、卡2算XA2最后把结果拼起来。但Transformer里的注意力层和前馈层结构更复杂需要更精细的切分策略。Megatron-LM提出的方案是对前馈层的第一个矩阵按列切第二个矩阵按行切这样中间不需要通信只在最后做一次AllReduce。注意力层则按头切分每个卡负责几个注意力头天然并行。这种切分方式的好处是通信量相对可控。假设隐藏维度是4096按8卡切分每张卡负责512维。前向传播只需要在特定位置做AllReduce通信量跟隐藏维度成正比而不是跟参数量成正比。4.2 列切与行切的组合策略具体来说前馈层通常包含两个线性变换先升维再降维。假设输入X维度是(batch, hidden)第一个权重W1维度是(hidden, 4hidden)第二个权重W2维度是(4hidden, hidden)。按列切W1每张卡拿到W1的一部分比如8卡就是(hidden, 0.5hidden)。每张卡算完得到部分激活值不需要通信。然后按行切W2每张卡拿到W2的一部分(0.5hidden, hidden)。每张卡用自己的部分激活值乘以自己的W2部分得到一个部分结果最后所有卡的结果相加AllReduce得到最终输出。这种“列切行切”的组合使得前向传播只需要一次AllReduce反向传播也只需要一次。通信量是2batchhidden相比数据并行的梯度同步参数量级别小了很多。切分方式通信位置通信量适用场景仅列切输出拼接大不推荐仅行切输入广播大不推荐列切行切中间一次AllReduce小推荐4.3 张量并行的通信开销与卡数限制张量并行最大的问题是通信频繁且延迟敏感。每次前向和反向都要做AllReduce如果卡间带宽不够计算单元就会饿死。所以张量并行通常限制在单节点内用NVLink或NVSwitch互联带宽能到几百GB/s。跨节点做张量并行除非有InfiniBand这种高速网络否则性能会惨不忍睹。另外张量并行的卡数不能无限增加。因为每增加一张卡通信量虽然不变但通信的参与方变多延迟会增加。一般来说张量并行度控制在8以内比较合适超过8之后加速比会明显下降。我实测过一个13B模型用8卡张量并行单卡吞吐大概是用4卡时的1.6倍而不是理想的2倍。原因就是通信开销吃掉了部分收益。所以张量并行不是越多越好要找到通信和计算的平衡点。实操心得张量并行下NCCL的算法选择很关键。默认的Ring AllReduce在小消息量下延迟高可以试试Tree AllReduce或者NVLSNVLink SHARP。在NCCL环境变量里设置NCCL_ALGOTree有时候能提升10%以上的吞吐。5. 混合专家模型用稀疏性换参数效率5.1 MoE的核心思想与路由机制混合专家模型Mixture of ExpertsMoE的思路跟前三种并行策略不在一个维度。前三种是“怎么把现有模型拆开”MoE是“怎么设计一个更高效的模型架构”。MoE的核心是在Transformer的前馈层里放多个“专家”每个专家是一个独立的前馈网络。然后加一个路由网络Router根据输入决定激活哪几个专家。比如有64个专家每次只激活2个那实际计算量只有稠密模型的2/64但参数量是64倍。这就是用稀疏性换参数效率。路由机制通常是一个简单的线性层加Softmax输出每个专家的权重。然后取Top-K个专家把输入分别送给它们最后按权重加权求和。K通常取1或2取1的话计算量最省取2的话效果更好但计算量翻倍。5.2 负载均衡与专家坍塌问题MoE训练最大的坑是专家坍塌。如果路由网络总是把输入送给少数几个专家其他专家得不到训练就退化了。极端情况下所有输入都涌向同一个专家MoE退化成稠密模型参数量优势荡然无存。解决办法是加负载均衡损失。在训练损失里加一项惩罚专家使用的不均衡。具体来说计算每个专家被选中的频率然后跟均匀分布的差异做平方乘以一个系数加到总损失里。这个系数需要调太大影响主任务收敛太小起不到均衡作用。另一个技巧是专家容量限制。给每个专家设一个最大处理量超过的输入直接跳过走残差连接。这样能防止某个专家被压垮但也可能丢信息。实际用的时候容量系数一般设1.25到2之间。问题现象解决方案专家坍塌少数专家承担大部分输入负载均衡损失、噪声路由容量溢出专家处理不过来丢token增大容量系数、增加专家数通信瓶颈专家分散在不同卡上专家并行AllToAll优化5.3 MoE与并行策略的组合实践MoE通常跟其他并行策略组合使用。专家可以分布在不同卡上形成专家并行。输入经过路由后需要通过AllToAll通信把token发送到对应的专家所在卡上算完再发回来。这个AllToAll通信是MoE的瓶颈尤其是跨节点的时候。实际部署中我一般把专家并行度控制在单节点内配合张量并行和数据并行。比如一个64专家的MoE模型8卡节点内做专家并行每卡8个专家跨节点做数据并行。这样AllToAll走NVLink速度快很多。训练稳定性方面MoE对学习率很敏感。我试过用跟稠密模型一样的学习率结果路由网络震荡得厉害。后来把路由网络的学习率单独调低一个数量级才稳定下来。另外MoE模型通常需要更长的warmup让路由网络先学会合理分配。注意MoE的显存占用跟专家总数成正比而不是激活的专家数。所以虽然计算量小但显存需求可能比稠密模型还大。部署时要算清楚显存账别被“稀疏”两个字骗了。6. 四种策略的组合选型与实战建议6.1 不同规模模型的并行方案推荐说了这么多实际做项目的时候到底怎么选我按模型规模给个参考模型规模推荐方案理由1B以下数据并行DDP单卡能放下数据并行最简单1B-10BZeRO-2 数据并行优化器状态和梯度切分通信可控10B-100B张量并行 流水线并行 ZeRO-1层内层间都拆优化器状态切分100B以上张量并行 流水线并行 专家并行 ZeRO-1多维度拆分稀疏架构降计算量这个表是经验值具体还要看硬件配置。比如如果只有单节点8卡那张量并行度最多8流水线并行度也受限。如果有多个节点可以跨节点做流水线并行和数据并行但张量并行尽量留在节点内。6.2 通信瓶颈的定位与优化思路分布式训练的性能瓶颈十有八九出在通信上。定位方法很简单用NVIDIA的Nsight Systems或者PyTorch Profiler抓一下时间线看AllReduce、AllToAll、Send/Recv这些通信操作占了多大比例。如果超过30%说明通信是瓶颈。优化手段有几个方向一是重叠通信和计算比如在反向传播算梯度的时候同时做上一层的AllReduce二是压缩通信量用FP16甚至INT8做梯度同步三是换更快的互联NVLink比PCIe快InfiniBand比以太网快。我踩过的一个坑是NCCL版本不匹配。不同节点的NCCL版本不一致导致通信性能忽高忽低。后来统一了NCCL版本问题消失。所以多机训练前一定要检查各节点的软件环境是否一致。6.3 显存优化的几个实用技巧显存不够是分布式训练最常见的报错。除了上面说的并行策略还有几个通用技巧梯度检查点不保存中间激活值反向传播时重新算一遍。显存降一半计算量增30%左右。适合显存极度紧张的场景。混合精度用FP16或BF16做前向反向FP32做参数更新。显存降一半速度还能提升。但要注意loss scaling防止梯度下溢。CPU Offload把优化器状态甚至参数放到CPU内存里用的时候再搬到GPU。显存降很多但速度慢。适合显存实在不够、又不想加卡的场景。激活值重计算跟梯度检查点类似但更细粒度可以选择性地重算某些层的激活值。这几个技巧可以组合使用。我一般优先用混合精度不够再上梯度检查点还不行才考虑Offload。因为Offload对速度的影响太大了能不用就不用。实操心得显存报错的时候别急着加卡。先用torch.cuda.memory_summary()看看显存到底花在哪了。有时候是数据加载的pin memory占多了有时候是日志里存了太多中间变量。定位清楚再对症下药比盲目加卡省钱多了。7. 几个容易被忽略的工程细节7.1 随机种子与可复现性分布式训练下随机种子的设置比单卡复杂得多。数据切分、Dropout、初始化每个环节都涉及随机性。如果种子没设好两次训练结果可能差很多调参的时候根本分不清是参数变了还是随机性导致的。我的做法是给每张卡设不同的种子seed rank但数据切分的种子固定。这样每张卡看到的数据顺序是确定的但模型内部的随机性各卡独立。另外用torch.backends.cudnn.deterministic True可以强制cuDNN用确定性算法代价是速度稍慢。7.2 检查点保存与恢复大模型训练动辄几天几周中间难免出问题。检查点机制必须做好。但分布式下的检查点不是简单存个state_dict就行要考虑各卡的参数切分方式。ZeRO-3下每张卡只存了部分参数保存的时候需要汇总。DeepSpeed提供了save_checkpoint接口能自动处理。但如果自己实现就要小心别存了个残缺的模型。恢复的时候更麻烦。如果并行度变了比如从8卡换成16卡检查点需要重新切分。DeepSpeed支持这种resize但有些框架不支持。所以最好在训练开始前就确定好并行配置别中途改。7.3 监控与日志分布式训练的监控比单卡重要得多。每张卡的loss、梯度范数、学习率、吞吐都要记录。如果某张卡明显慢于其他卡可能是硬件问题或者数据不均衡。我一般用TensorBoard或者Weights Biases做可视化同时用Prometheus Grafana监控GPU利用率、显存、温度、功耗。有一次发现某张卡的温度比其他卡高10度查下来是散热风扇坏了换了风扇就正常了。如果没有监控这种问题很难发现。日志方面建议每张卡单独写日志文件文件名带rank号。这样出问题的时候能快速定位是哪张卡。另外日志级别别设太低不然IO会成为瓶颈。我一般用INFO级别DEBUG只在排查问题时临时开。8. 写在最后的一些个人体会分布式训练这个领域理论看着不难但实操中全是细节。我见过太多人照着论文配了一遍结果跑不起来或者速度远低于预期。问题往往不在算法本身而在环境配置、通信调优、显存管理这些工程细节上。我的建议是先从小的并行配置开始跑通了再逐步扩大。比如先单机8卡数据并行再加张量并行再加流水线并行。每加一种并行都仔细测一下吞吐和显存确认没有性能回退。别一上来就搞64卡全并行出了问题根本不知道从哪查。另外框架的选择很重要。DeepSpeed、Megatron-LM、FairScale这些框架各有优劣但都比自己手写靠谱。手写分布式训练代码光是AllReduce的正确性就够你调一周的。用现成框架把精力放在模型和调参上效率高得多。最后说个小心得分布式训练的性能调优80%的收益来自20%的改动。通常把通信重叠做好、把NCCL参数调对、把micro-batch数量调合适性能就能提升一大截。剩下的边边角角投入产出比不高别过度优化。先把模型训出来再考虑榨干硬件。 
长河君 · 2026/10/14 11:06:11 · 阅读 1.2k 大模型分布式训练：数据并行、流水线并行、张量并行与MoE实战解析
1. 大模型训练为什么必须突破单卡限制1.1 从一个现实困境说起先抛一个我亲身踩过的场景。早两年做一个小规模的语言模型微调参数量大概在1.5B左右当时手里只有一张24G显存的消费级卡。加载模型权重、优化器状态、梯度、激活值还没开始训练显存就已经红了。我试过梯度累积、混合精度、梯度检查点能省的地方全抠了一遍勉强能跑起来但batch size只能压到1训练速度慢到让人怀疑人生。这个困境不是个例。当模型参数量从亿级跨到百亿、千亿甚至万亿级时单张GPU的显存容量、显存带宽、算力上限三座大山同时压过来。一张H100有80G显存听起来不小但一个70B参数的模型光是FP16权重就要140G再加上优化器状态Adam的话通常是参数量的2倍、梯度、激活值轻松突破500G。单卡根本装不下。所以问题就变成了怎么把一个大模型拆开放到多张卡上让它们协同工作这就是分布式训练要解决的核心问题。而拆的方式不同就衍生出了数据并行、流水线并行、张量并行、混合专家模型这几条主流技术路线。1.2 四种并行策略的定位差异很多刚接触分布式训练的朋友容易把这几种并行方式搞混觉得它们是互相替代的关系。实际上它们更像是不同维度的拆分工具各自解决不同层面的问题。数据并行解决的是“数据太多、算力不够”的问题——每张卡拿一份完整的模型副本喂不同的数据算完梯度再同步。流水线并行解决的是“模型太深、单卡放不下”的问题——把模型按层切成几段每张卡负责一段数据像流水线一样依次流过。张量并行解决的是“单层太大、一张卡装不下”的问题——把矩阵乘法拆开同一层的计算分到多张卡上。混合专家模型则是从模型架构层面做文章让不同的输入只激活部分参数用稀疏性来降低计算量。这四种策略不是非此即彼的选择实际的大模型训练往往是组合使用。比如一个千亿级模型可能同时用到张量并行层内拆分、流水线并行层间拆分、数据并行数据拆分再加上混合专家架构来提升参数效率。接下来我逐个拆解每种策略的核心原理、实操要点和踩坑经验。2. 数据并行最成熟但也最容易踩坑的方案2.1 数据并行的核心原理与通信机制数据并行的逻辑最直观你有8张卡就把一份完整的模型复制8份每张卡用不同的数据子集做前向和反向传播然后通过AllReduce操作把所有卡上的梯度求平均再用平均后的梯度更新各自的模型参数。因为每张卡的模型初始参数相同、更新梯度也相同所以训练过程中模型始终保持一致。听起来很简单对吧但这里有个关键问题AllReduce的通信开销。假设模型有10B参数FP16精度下梯度就是20G。每次迭代都要在8张卡之间同步这20G的数据如果卡间带宽不够通信时间可能比计算时间还长。这就是为什么数据并行在小模型上很香但到了大模型就力不从心——通信量跟模型参数量成正比模型越大通信瓶颈越严重。为了解决这个问题业界提出了梯度累积和通信压缩两种思路。梯度累积是让每张卡先算几个batch的梯度攒在一起再同步减少通信频率。通信压缩则是对梯度做量化或稀疏化比如把FP32梯度压成FP16甚至INT8再传输牺牲一点精度换带宽。注意梯度累积虽然能减少通信次数但会增大等效batch size可能影响收敛性。我一般建议在显存允许的情况下优先用更大的单卡batch而不是靠累积硬撑。2.2 从DP到DDP再到ZeRO的演进路线最早的数据并行实现是PyTorch的DataParallelDP但它有个致命缺陷所有卡的梯度都要汇总到主卡上做平均主卡的显存和带宽成为瓶颈。后来出现了DistributedDataParallelDDP用Ring AllReduce算法让每张卡只跟相邻卡通信带宽利用率大幅提升。但DDP仍然要求每张卡存一份完整的模型、梯度、优化器状态。一个10B模型用Adam优化器FP16混合精度下权重20G、梯度20G、优化器状态FP32的momentum和variance80G加起来120G单卡根本放不下。于是微软提出了ZeROZero Redundancy Optimizer核心思想是把冗余的部分切分到各张卡上。ZeRO有三个阶段Stage 1切分优化器状态Stage 2再切分梯度Stage 3连模型参数也切分。每推进一个阶段单卡显存占用就降一截但通信量会相应增加。策略单卡显存占用相对值通信量相对值适用场景朴素DP1.01.0小模型、单机多卡DDP1.00.8中等模型、多机多卡ZeRO-10.61.2大模型、优化器状态占大头ZeRO-20.41.5大模型、梯度也占大头ZeRO-30.22.0超大模型、单卡装不下参数实际用的时候ZeRO-3虽然省显存但通信开销大训练速度会明显下降。我的经验是如果ZeRO-2能跑起来就别上ZeRO-3。只有当模型大到ZeRO-2也装不下时才考虑ZeRO-3配合CPU Offload。2.3 数据并行的实操配置与避坑指南以PyTorch的DDP为例一个典型的启动脚本大概长这样torchrun --nproc_per_node8 --nnodes2 --node_rank0 \ --master_addr192.168.1.1 --master_port29500 \ train.py --batch_size 32 --lr 1e-4关键配置项包括nproc_per_node是每台机器的GPU数nnodes是机器总数master_addr是主节点地址。训练脚本里需要用DistributedSampler来切分数据确保每张卡拿到不重叠的子集。踩过的坑里最常见的是数据加载不均衡。如果数据集大小不能被GPU数整除最后几个batch会出现有的卡有数据、有的卡没数据的情况导致AllReduce卡住。解决办法是设置drop_lastTrue或者用DistributedSampler的drop_last参数。另一个坑是学习率缩放。数据并行下等效batch size变成了单卡batch乘以卡数学习率通常需要线性缩放。比如单卡batch 8、学习率1e-4换成8卡后等效batch 64学习率应该调到8e-4左右。但这不是铁律大batch下可能需要用平方根缩放或者warmup来稳定训练。实操心得DDP启动时如果卡在NCCL初始化先检查防火墙和网卡配置。我遇到过因为MTU设置不一致导致NCCL握手失败的情况把MTU统一改成9000就解决了。3. 流水线并行把模型切成段让数据流起来3.1 流水线并行的基本逻辑与气泡问题流水线并行的思路很朴素模型有80层我有8张卡那就每张卡放10层数据从第一张卡进去算完10层传给第二张卡依次往后传。这样每张卡只需要存1/8的模型参数显存压力大幅降低。但问题来了如果只有一份数据在流水线上跑那同一时刻只有一张卡在干活其他7张卡都在等。这就是所谓的流水线气泡。为了解决这个问题需要把数据切成多个micro-batch让它们像工厂流水线一样错开时间进入。比如第一个micro-batch在卡1上算的时候卡2可以处理上一个micro-batch的数据以此类推。气泡的大小取决于流水线深度和micro-batch数量。假设有P个流水线阶段M个micro-batch那气泡占比大约是(P-1)/(MP-1)。想让气泡小要么减少流水线阶段数要么增加micro-batch数。但micro-batch太多又会增加通信次数和显存占用需要权衡。3.2 GPipe与PipeDream的调度差异最早的流水线并行方案是GPipe它把所有micro-batch的前向算完再统一做反向传播。这种方式显存占用高因为要保存所有micro-batch的中间激活值。后来PipeDream提出了1F1BOne Forward One Backward调度前向和反向交替进行显存占用大幅降低。实际用的时候PyTorch的torch.distributed.pipeline.sync.Pipe和DeepSpeed的Pipeline模块都支持1F1B调度。配置上主要关注chunks参数即micro-batch数量和balance参数各阶段层数分配。层数分配是个技术活。如果每张卡算力相同平均分配就行。但如果卡型不一致比如有的A100有的V100就需要按算力比例分配层数否则快的卡要等慢的卡整体效率被拖累。调度方式显存占用气泡占比实现复杂度GPipe高中低1F1B中中中Interleaved 1F1B低低高Interleaved 1F1B是更进阶的方案它把每张卡负责的层再切成多个chunk进一步缩小气泡。但实现复杂度也更高一般用现成框架就好不建议自己手写。3.3 流水线并行的实际部署经验我在一个跨节点场景下部署过流水线并行8台机器每台8卡总共64卡。踩的最大的坑是跨节点通信延迟。流水线并行需要频繁地在相邻阶段之间传激活值如果相邻阶段跨了节点走网络传输的延迟比走NVLink高一个数量级。解决办法是尽量让相邻流水线阶段在同一节点内。比如8卡机器可以分配4个流水线阶段每个阶段2张卡做张量并行这样阶段间的通信走NVLink快很多。另一个经验是micro-batch数量要调优。太少气泡大太多显存爆。我一般从4开始试逐步增加到8、16观察显存和吞吐的变化。通常8到16之间能找到比较好的平衡点。注意流水线并行下每个阶段的输出需要缓存起来给反向传播用。如果micro-batch太多激活值缓存会吃掉大量显存。可以用梯度检查点技术来换显存代价是计算量增加约30%。4. 张量并行把矩阵乘法拆到多张卡上4.1 张量并行的数学原理拆解张量并行跟流水线并行的思路完全不同。流水线并行是“按层切”张量并行是“按计算切”。拿一个简单的矩阵乘法Y XA来说如果A太大放不下一张卡可以按列切成A [A1, A2]让卡1算XA1、卡2算XA2最后把结果拼起来。但Transformer里的注意力层和前馈层结构更复杂需要更精细的切分策略。Megatron-LM提出的方案是对前馈层的第一个矩阵按列切第二个矩阵按行切这样中间不需要通信只在最后做一次AllReduce。注意力层则按头切分每个卡负责几个注意力头天然并行。这种切分方式的好处是通信量相对可控。假设隐藏维度是4096按8卡切分每张卡负责512维。前向传播只需要在特定位置做AllReduce通信量跟隐藏维度成正比而不是跟参数量成正比。4.2 列切与行切的组合策略具体来说前馈层通常包含两个线性变换先升维再降维。假设输入X维度是(batch, hidden)第一个权重W1维度是(hidden, 4hidden)第二个权重W2维度是(4hidden, hidden)。按列切W1每张卡拿到W1的一部分比如8卡就是(hidden, 0.5hidden)。每张卡算完得到部分激活值不需要通信。然后按行切W2每张卡拿到W2的一部分(0.5hidden, hidden)。每张卡用自己的部分激活值乘以自己的W2部分得到一个部分结果最后所有卡的结果相加AllReduce得到最终输出。这种“列切行切”的组合使得前向传播只需要一次AllReduce反向传播也只需要一次。通信量是2batchhidden相比数据并行的梯度同步参数量级别小了很多。切分方式通信位置通信量适用场景仅列切输出拼接大不推荐仅行切输入广播大不推荐列切行切中间一次AllReduce小推荐4.3 张量并行的通信开销与卡数限制张量并行最大的问题是通信频繁且延迟敏感。每次前向和反向都要做AllReduce如果卡间带宽不够计算单元就会饿死。所以张量并行通常限制在单节点内用NVLink或NVSwitch互联带宽能到几百GB/s。跨节点做张量并行除非有InfiniBand这种高速网络否则性能会惨不忍睹。另外张量并行的卡数不能无限增加。因为每增加一张卡通信量虽然不变但通信的参与方变多延迟会增加。一般来说张量并行度控制在8以内比较合适超过8之后加速比会明显下降。我实测过一个13B模型用8卡张量并行单卡吞吐大概是用4卡时的1.6倍而不是理想的2倍。原因就是通信开销吃掉了部分收益。所以张量并行不是越多越好要找到通信和计算的平衡点。实操心得张量并行下NCCL的算法选择很关键。默认的Ring AllReduce在小消息量下延迟高可以试试Tree AllReduce或者NVLSNVLink SHARP。在NCCL环境变量里设置NCCL_ALGOTree有时候能提升10%以上的吞吐。5. 混合专家模型用稀疏性换参数效率5.1 MoE的核心思想与路由机制混合专家模型Mixture of ExpertsMoE的思路跟前三种并行策略不在一个维度。前三种是“怎么把现有模型拆开”MoE是“怎么设计一个更高效的模型架构”。MoE的核心是在Transformer的前馈层里放多个“专家”每个专家是一个独立的前馈网络。然后加一个路由网络Router根据输入决定激活哪几个专家。比如有64个专家每次只激活2个那实际计算量只有稠密模型的2/64但参数量是64倍。这就是用稀疏性换参数效率。路由机制通常是一个简单的线性层加Softmax输出每个专家的权重。然后取Top-K个专家把输入分别送给它们最后按权重加权求和。K通常取1或2取1的话计算量最省取2的话效果更好但计算量翻倍。5.2 负载均衡与专家坍塌问题MoE训练最大的坑是专家坍塌。如果路由网络总是把输入送给少数几个专家其他专家得不到训练就退化了。极端情况下所有输入都涌向同一个专家MoE退化成稠密模型参数量优势荡然无存。解决办法是加负载均衡损失。在训练损失里加一项惩罚专家使用的不均衡。具体来说计算每个专家被选中的频率然后跟均匀分布的差异做平方乘以一个系数加到总损失里。这个系数需要调太大影响主任务收敛太小起不到均衡作用。另一个技巧是专家容量限制。给每个专家设一个最大处理量超过的输入直接跳过走残差连接。这样能防止某个专家被压垮但也可能丢信息。实际用的时候容量系数一般设1.25到2之间。问题现象解决方案专家坍塌少数专家承担大部分输入负载均衡损失、噪声路由容量溢出专家处理不过来丢token增大容量系数、增加专家数通信瓶颈专家分散在不同卡上专家并行AllToAll优化5.3 MoE与并行策略的组合实践MoE通常跟其他并行策略组合使用。专家可以分布在不同卡上形成专家并行。输入经过路由后需要通过AllToAll通信把token发送到对应的专家所在卡上算完再发回来。这个AllToAll通信是MoE的瓶颈尤其是跨节点的时候。实际部署中我一般把专家并行度控制在单节点内配合张量并行和数据并行。比如一个64专家的MoE模型8卡节点内做专家并行每卡8个专家跨节点做数据并行。这样AllToAll走NVLink速度快很多。训练稳定性方面MoE对学习率很敏感。我试过用跟稠密模型一样的学习率结果路由网络震荡得厉害。后来把路由网络的学习率单独调低一个数量级才稳定下来。另外MoE模型通常需要更长的warmup让路由网络先学会合理分配。注意MoE的显存占用跟专家总数成正比而不是激活的专家数。所以虽然计算量小但显存需求可能比稠密模型还大。部署时要算清楚显存账别被“稀疏”两个字骗了。6. 四种策略的组合选型与实战建议6.1 不同规模模型的并行方案推荐说了这么多实际做项目的时候到底怎么选我按模型规模给个参考模型规模推荐方案理由1B以下数据并行DDP单卡能放下数据并行最简单1B-10BZeRO-2 数据并行优化器状态和梯度切分通信可控10B-100B张量并行 流水线并行 ZeRO-1层内层间都拆优化器状态切分100B以上张量并行 流水线并行 专家并行 ZeRO-1多维度拆分稀疏架构降计算量这个表是经验值具体还要看硬件配置。比如如果只有单节点8卡那张量并行度最多8流水线并行度也受限。如果有多个节点可以跨节点做流水线并行和数据并行但张量并行尽量留在节点内。6.2 通信瓶颈的定位与优化思路分布式训练的性能瓶颈十有八九出在通信上。定位方法很简单用NVIDIA的Nsight Systems或者PyTorch Profiler抓一下时间线看AllReduce、AllToAll、Send/Recv这些通信操作占了多大比例。如果超过30%说明通信是瓶颈。优化手段有几个方向一是重叠通信和计算比如在反向传播算梯度的时候同时做上一层的AllReduce二是压缩通信量用FP16甚至INT8做梯度同步三是换更快的互联NVLink比PCIe快InfiniBand比以太网快。我踩过的一个坑是NCCL版本不匹配。不同节点的NCCL版本不一致导致通信性能忽高忽低。后来统一了NCCL版本问题消失。所以多机训练前一定要检查各节点的软件环境是否一致。6.3 显存优化的几个实用技巧显存不够是分布式训练最常见的报错。除了上面说的并行策略还有几个通用技巧梯度检查点不保存中间激活值反向传播时重新算一遍。显存降一半计算量增30%左右。适合显存极度紧张的场景。混合精度用FP16或BF16做前向反向FP32做参数更新。显存降一半速度还能提升。但要注意loss scaling防止梯度下溢。CPU Offload把优化器状态甚至参数放到CPU内存里用的时候再搬到GPU。显存降很多但速度慢。适合显存实在不够、又不想加卡的场景。激活值重计算跟梯度检查点类似但更细粒度可以选择性地重算某些层的激活值。这几个技巧可以组合使用。我一般优先用混合精度不够再上梯度检查点还不行才考虑Offload。因为Offload对速度的影响太大了能不用就不用。实操心得显存报错的时候别急着加卡。先用torch.cuda.memory_summary()看看显存到底花在哪了。有时候是数据加载的pin memory占多了有时候是日志里存了太多中间变量。定位清楚再对症下药比盲目加卡省钱多了。7. 几个容易被忽略的工程细节7.1 随机种子与可复现性分布式训练下随机种子的设置比单卡复杂得多。数据切分、Dropout、初始化每个环节都涉及随机性。如果种子没设好两次训练结果可能差很多调参的时候根本分不清是参数变了还是随机性导致的。我的做法是给每张卡设不同的种子seed rank但数据切分的种子固定。这样每张卡看到的数据顺序是确定的但模型内部的随机性各卡独立。另外用torch.backends.cudnn.deterministic True可以强制cuDNN用确定性算法代价是速度稍慢。7.2 检查点保存与恢复大模型训练动辄几天几周中间难免出问题。检查点机制必须做好。但分布式下的检查点不是简单存个state_dict就行要考虑各卡的参数切分方式。ZeRO-3下每张卡只存了部分参数保存的时候需要汇总。DeepSpeed提供了save_checkpoint接口能自动处理。但如果自己实现就要小心别存了个残缺的模型。恢复的时候更麻烦。如果并行度变了比如从8卡换成16卡检查点需要重新切分。DeepSpeed支持这种resize但有些框架不支持。所以最好在训练开始前就确定好并行配置别中途改。7.3 监控与日志分布式训练的监控比单卡重要得多。每张卡的loss、梯度范数、学习率、吞吐都要记录。如果某张卡明显慢于其他卡可能是硬件问题或者数据不均衡。我一般用TensorBoard或者Weights Biases做可视化同时用Prometheus Grafana监控GPU利用率、显存、温度、功耗。有一次发现某张卡的温度比其他卡高10度查下来是散热风扇坏了换了风扇就正常了。如果没有监控这种问题很难发现。日志方面建议每张卡单独写日志文件文件名带rank号。这样出问题的时候能快速定位是哪张卡。另外日志级别别设太低不然IO会成为瓶颈。我一般用INFO级别DEBUG只在排查问题时临时开。8. 写在最后的一些个人体会分布式训练这个领域理论看着不难但实操中全是细节。我见过太多人照着论文配了一遍结果跑不起来或者速度远低于预期。问题往往不在算法本身而在环境配置、通信调优、显存管理这些工程细节上。我的建议是先从小的并行配置开始跑通了再逐步扩大。比如先单机8卡数据并行再加张量并行再加流水线并行。每加一种并行都仔细测一下吞吐和显存确认没有性能回退。别一上来就搞64卡全并行出了问题根本不知道从哪查。另外框架的选择很重要。DeepSpeed、Megatron-LM、FairScale这些框架各有优劣但都比自己手写靠谱。手写分布式训练代码光是AllReduce的正确性就够你调一周的。用现成框架把精力放在模型和调参上效率高得多。最后说个小心得分布式训练的性能调优80%的收益来自20%的改动。通常把通信重叠做好、把NCCL参数调对、把micro-batch数量调合适性能就能提升一大截。剩下的边边角角投入产出比不高别过度优化。先把模型训出来再考虑榨干硬件。