一、为什么大模型训练离不开并行

单张加速卡的显存是有限的，权重、梯度、优化器状态加上激活值都要占地方。模型参数到千亿级别时，光是把参数存起来就超出单卡显存，训练自然没法在一张卡上完成。并行训练的核心思路，就是把放不下的东西拆开，分给多张卡共同承担。拆的对象不同，就形成了不同的并行方式：按数据拆叫数据并行，按层内的权重矩阵拆叫张量并行，按模型的层拆叫流水线并行。三种方式各有擅长的场景，也各有代价，代价主要体现在卡之间的通信上。选策略的过程，本质上是在显存、通信和扩展性三者之间做取舍，没有哪一种方式在所有情形下都占优。

并行度也不是越高越好。卡数增加后，同步和调度的开销跟着上涨，超过某个规模，再加卡的收益就越来越薄。所以谈并行策略时，还要同时看扩展效率，也就是每加一倍卡，速度能提升几成。理想的方案是在目标规模内保持扩展效率可用，而不是纸面上把卡数堆到顶。

二、数据并行的工作方式

数据并行是最容易理解的一种。每张卡上都放一份完整的模型，各自领取不同的数据分片，前向和反向各自独立计算，算完再把各自的梯度汇总合并，保证所有卡的模型始终一致。它适合模型本身能放进单卡显存的情形，实现简单、扩展性也好。当模型大到单卡放不下时，可以配合分片技术，把参数、梯度和优化器状态分散到各卡上，用到哪部分再临时取回，用计算时间换显存空间。数据并行的通信量与参数量相关，机器之间的网络带宽往往成为扩展的制约因素。工程上还会用梯度累积，把多个小批次攒成一个大批次再同步，以此减少通信次数，也适配显存紧张的情形。

选同步时机也有讲究。每一步都同步最稳妥，但通信频繁；隔几步再同步能省流量，却要接受轻微的偏差。多数训练框架把同步细节封装好了，使用者只需要在提交任务时选好参数，具体节奏交给系统去执行，出问题时再回头调整也不迟。

三、张量并行的适用场景

张量并行解决的是另一个问题：单层的权重矩阵太大，一张卡算不动。它把大矩阵切成若干块，分给多张卡协作完成同一次运算，各卡算完各自的部分，再交换少量中间结果拼出最终答案。由于交换发生在每一层运算的内部，通信非常频繁，对卡间带宽要求很高，因此张量并行通常只在同一台机器内部的卡之间使用，借助机器内的高速互联来支撑这些频繁的数据往来。模型越大，单层运算量越大，张量并行的收益越明显；模型不大时用它反而会让通信开销盖过计算收益，得不偿失。注意力模块和前馈层是常见的切分位置，这两处也是大模型里参数集中的地方。

还有一个细节值得注意：张量并行对访存同样敏感。切分得当，各卡的显存带宽一起出力；切分不当，某一张卡先忙完干等，其余卡的算力白白闲置。经验上先按二的幂次试起，再结合实测微调，是省力的办法。

四、流水线并行的作用

流水线并行按层切分模型，前面若干层放在一组卡上，中间若干层放在另一组，数据像在流水线上一样依次经过各段。它的通信量小，只传递段与段之间的中间结果，适合在机器之间使用。但流水线有个先天缺点：同一时刻总有一些卡在等数据到来，处于空转状态，这些空转被称为气泡。工程上用微批次技术缓解，把一个批次拆成多个小块连续送入流水线，让各段尽量同时有事做；更精细的交织调度还能进一步压缩气泡占比。流水线的段数取多少，需要在气泡损失和通信节省之间取一个折中，一般不会切得太碎。

流水线还带来一个好处：它让显存需求按段分摊，每张卡只需要装下自己那一段的参数和激活，这对超深模型尤其友好。与张量并行相比，它牺牲了一些并行度，换来了通信上的清净，两者经常在同一个任务里分别负责不同层级的工作。

五、三种方式的搭配思路

实际的大模型训练很少只用一种并行方式，常见做法是把三者叠起来：机器内部用张量并行吃满高速互联，机器之间用流水线并行摊薄显存压力，再在最外层套数据并行来扩大总批次。理解了这个分层结构，搭配的思路就清晰了：先保证模型放得下，再保证通信扛得住，最后才追求批次规模。判断顺序也建议照此来，先定张量并行的度数，让单机显存够用；再定流水线的段数，让总显存够用；剩下不够的扩展需求交给数据并行去满足。三个度数确定后，还要回头核验总批次大小和学习率的匹配关系，防止训练效果受影响。

度数之外还有一个容易被忽略的变量：任务的副本数。同一份训练起多个副本各自吃数据，本质上也是数据并行的延伸，适合用来快速消化海量语料。副本之间定期交换参数的频率，同样要依据网络条件来定，频率高则收敛稳，频率低则通信省。

六、依据模型规模定策略

模型规模不同，合理的组合差别很大。十亿到百亿参数的模型，单卡或者数据并行加分片通常就能应付，没必要引入复杂的切分。几百亿参数级别，一般需要机器内张量并行加机器间数据并行的组合。到千亿以上，三种方式往往同时上场，还要叠加分片技术才能把状态放下。对多数团队而言，从小规模配置起步验证流程，再逐步加大并行度，是稳妥的路径。一次到位的大配置一旦跑不通，排查成本很高；而小配置虽然慢一些，却更容易定位显存或者通信方面的具体问题，把隐患消灭在放大规模之前。

另有一个实用技巧：先用小模型把链路验证一遍。流程通了、脚本对了，再换成真实模型上量级。许多看似复杂的并行问题，在小模型上就能提前暴露，修起来也快得多。这种先小后大的节奏，能省下大量反复等待的时间。

七、依据集群拓扑定策略

集群的物理拓扑对策略选择影响很大。机器内部卡与卡之间通常是高速互联，带宽充裕、延迟低，适合频繁通信的张量并行；机器之间走网络，带宽相对有限，适合通信量小的数据并行和流水线并行。调度系统如果能感知拓扑，把同一任务的卡尽量放在互联关系紧密的位置，通信效率会明显提升。此外还要留意节点间的网络是否对等，若有部分链路带宽偏低，这些位置就应该少承担通信密集的角色。拿到一批新设备时，先用小任务实测一下机器内和机器间的通信速率，比凭经验猜测可靠得多。

软硬件版本也影响策略效果。驱动、通信库和训练框架的版本要配套，版本错位时，高速互联可能落到普通链路上，性能大幅下降却不容易察觉。上线新集群时做一轮基准测试，把各档配置的实测速度记录在案，日后选策略就有参照。

八、实践建议与常见误区

几条经验值得参考。第一，先在小规模上把流程跑通，确认损失能正常下降，再放大规模，出问题时更容易定位。第二，盯住每一步的耗时构成，看计算和通信各占多少，通信占比过高说明并行度配置不合理，值得重新调配。第三，不要盲目堆卡，超过某个点之后加卡的收益会迅速衰减，先弄清楚瓶颈在哪里再扩。常见误区包括：张量并行度开得过大导致通信淹没计算；批次大小随手改动却没联动学习率；只看总耗时却不看单步耗时和步数的关系。把这些细节管住，同一套硬件往往能挤出可观的速度提升。

此外，记录每次配置的改动和对应表现，形成自己团队的配置档案。下次遇到相似规模的模型，直接从档案里挑一个起点，比从零摸索快得多。并行策略没有一劳永逸的答案，随模型和硬件的变化定期复盘调整，档案越厚，起步越顺，这才是长久之道。