张量并行与流水并行有哪些区别？适用场景怎么选？

张量并行与流水并行是目前大模型训练中两种最核心的并行策略，其适用场景区分本质上就一句话：张量并行适合单机内高速互联环境下对单层算子进行拆分，流水并行适合多机环境下按层切分模型并隐藏通信延迟。

两种并行策略都致力于解决单卡显存放不下大模型的困境,但它们的切分逻辑、通信开销、工程复杂度以及生效场景截然不同，选错并行策略，轻则训练效率低下，重则导致集群吞吐量断崖式下跌，理解两者的真实边界，比了解它们各自怎么做更重要。

为什么说两者解决的问题根本不同

模型训练遇上显存瓶颈时,我们面对的其实有两种不同性质的障碍。

第一个障碍是单卡显存容量的物理上限。 一个拥有几千亿参数的模型，光参数和优化器状态就能轻松填满数张A100的显存，此时需要的是把模型拆开，分别放进不同显卡里。

第二个障碍是计算设备利用率上不去。 设备明明有空闲，但由于数据搬运或等待前序结果，计算单元只能空转，此时需要的是让数据像流水线一样在不同设备间有序流动。

张量并行解决的是第一个问题中“单个算子如何拆开算”的维度，流水并行解决的则是第二个问题中“整体流程如何排班”的维度，行业共识认为，这两者本身不属于同一层级的设计决策，但在实际工程里又必须放在一起联调，很多团队把提速失败归咎于并行策略本身，实际上是用错了场景。

张量并行：适合单机内高速互联的场景

张量并行的核心思路是把一个层的参数矩阵切分成几块,分别放在不同GPU上，让这几块GPU协作完成同一个层的计算，这种方式能有效降低单卡显存占用，但代价是极其频繁的数据交互。

张量并行的典型适用环境

• 单机内多卡环境（如单台8卡或更多卡的服务器）
• 节点间使用NVLink或NVSwitch这类超高带宽、低延迟的互联技术
• 模型层内计算量极大,单层参数已经大到无法塞进一张卡
• 需要精细地平衡各卡计算负载,避免某个计算单元闲置

业内专家指出,张量并行在单机场景下表现可以非常好，因为NVLink的带宽通常是PCIe的数倍以上，能有效消化每次矩阵乘法后的All-Reduce通信开销，但如果把张量并行强行扩展到跨多机的环境，通信就会经过网卡和交换机，延迟会比NVLink高出一个数量级，此时每次算子级同步都会放大为一场灾难。

什么时候应该避开张量并行

• 机器间跨节点网络只是普通万兆或IB网络,带宽有限
• 模型层数远多于单层宽度,适合按层切分而不是按算子切分
• 团队对通信库和集合通信调优经验不足
• 推理场景多于训练场景,因为推理时张量并行的通信效率往往低于更简单的模型分片策略

实际部署中,一个常见的误区是：工程师看到显存不够，第一反应就是把张量并行度从4加到8，但如果你的8卡横跨了两个机箱，跨机箱的通信开销会瞬间吞噬掉并行带来的算力增益，宁可降低单卡利用率，也不要让关键路径上的通信跨过PCIe交换机。

张量并行适用场景速查表

流水并行：适合多机多卡的顺序切分场景

流水并行不拆分某个具体的层,而是把整个模型按层切成多个阶段，每个阶段放在不同的设备上，数据像流水线一样依次经过各个阶段完成前向和反向计算。

这种架构的优势在于设备间通信频率远低于张量并行,只需要在相邻阶段边界处传递激活值和梯度，通信数据量小得多，对网络带宽的容忍度更强。

流水并行的具体适用场合

• 模型有数十层乃至上百层,天然适合按层切分
• 训练集群由多台服务器构成,节点间通信链路是主要瓶颈
• 希望以较少的代码改动实现大规模多卡扩展
• 模型结构较规整（如标准Transformer decoder堆叠），每个stage计算量接近

流水并行最典型的应用场景是超大规模语言模型的多机训练,这类模型通常由几百个结构相同的Transformer层堆叠而成，把它们切成若干段放入不同机器，每台机器内部再配合张量并行和数据并行使用，整体通信占用会明显降低。

流水并行的明显短板是空转率

切分后每个设备只负责部分层的计算,而样本必须依次流经所有阶段，当阶段A在计算时，阶段B可能正在等待数据，为了缓解这种空闲等待，业界普遍引入micro-batch机制，将一个大的batch切分为若干小份依次泵入流水线，让不同阶段同时处理不同样本的不同层。

不过就算用了micro-batch，流水线本身依然存在预热和排空阶段带来的空转，阶段数越多，空转比例越高，所以流水并行并不适合层数特别少或计算量极端不均衡的模型，假如一个模型只有6层，非要切成5个流水阶段，那么大部分时间设备都在等待而不是计算，效率会很难看。

流水并行适用场景速查表

实践中怎么选：按硬件和模型规模来确定

大多数情况下,你需要组合运用多种并行策略，而不是单一押注某一种方式，一个大模型训练任务通常采用3D并行方案：数据并行做样本维度扩展，张量并行做层内算子拆分，流水并行做层间阶段拆分。

决策路径分三步走

第一步,确认单卡是否能装下单个Transformer层及其优化器状态，如果能装下，优先不用张量并行，直接用数据并行加流水并行，如果单层已经OOM，那就必须启用张量并行，把单层参数拆到多卡上。

第二步,判断节点数量和节点间带宽，当总卡数超过单机8卡范围，或者需要扩展到几十台节点时，流水并行是节点间通信的优先方案，节点之间的通信量相对于张量并行要小很多，对IB网络或RoCE网络的依赖也低一些，如果你使用的是多机多卡环境且网络是千兆级别，张量并行的跨节点通信会被卡到怀疑人生。

第三步,评估显存墙在哪一层，显存不够分为两种情况：模型整体太大，或者某个特定层太大，整体太大用流水并行按层切；特定层太大用张量并行把层内参数瓜分掉，如果两者都大，那就先张量并行把单层拆小，再流水并行把不同层分配到不同机器。

实际参数配置的参考建议

• 单机8卡：一般先用张量并行度4，加上数据并行度2，避免使用流水并行。
• 两机16卡：较优配置是张量并行度4加流水并行度2加数据并行度2，节点间只有一对通信边界。
• 四机以上：流水并行度至少4，张量并行度控制在2到4之间，数据并行作为吞吐量放大的手段。
• 超大模型（万亿参数级别）：必须在上述基础上叠加显存卸载和激活重计算，单纯并行不够。

这些配置建议不需要当作教条,因为模型结构、算子实现、梯度累积步数等因素都会影响最优组合，但方向是确定的：先解决通信瓶颈，再解决显存瓶颈，最后解决利用率瓶颈。

核心区别：通信模式与颗粒度

从根源上理解两个并行策略的区别,有助于你遇到新问题时自行判断。

张量并行是计算图的横向切分，它把二维矩阵乘按行或按列切开，让每个GPU只计算一部分结果，再通过All-Reduce等集合通信合并完整结果，每次矩阵乘法都要触发一次全通信，通信频率极高，通信数据量也大。

流水并行是计算图的纵向切分，它把整个网络切割成若干连续子图，每个GPU负责一段完整的前向和反向计算，设备间只在边界处传递结果数据，通信频率低，单次通信的数据量取决于隐藏层维度和batch大小。

一句话总结：张量并行用高频通信换显存下降，流水并行用低频通信加流水空转换显存下降，前者适合带宽极高的单机环境，后者适合通信受限的多机环境。

张量并行与流水并行怎么选涉及的实际训练场景

国内某大型互联网公司的训练集群通常采用单机8卡A100配置,在这种环境下，实际使用张量并行是性价比相当高的选择，工程师只需在框架中设置tensor_parallel_size=8，模型就能成功加载并训练，代码改动量极小，但一旦涉及到多台机器，比如32卡乃至64卡训练时，不引入流水并行只靠张量并行硬扛，网络传输的数据量会大得惊人。

反过来看,推理场景中不少团队会刻意避开张量并行，因为推理存在严重的存算不平衡，频繁的通信会让GPU空转等待数据，相比而言，把模型按层拆到多张卡上做顺序推理，在延迟不敏感的离线批处理任务中反而更稳定。

就具体操作而言,目前主流大模型训练框架对两种并行都做了抽象封装，你在Megatron-LM或vLLM中看到的并行配置，无非就是在参数里声明张量并行度和流水并行度，关键是训练或推理之前，先想清楚你的瓶颈在通信还是显存，这个判断决定了你后续所有调优工作的方向。

对于拿不准的情况，最简洁的选型建议是：单机内优先调大张量并行度，跨节点一定引入流水并行。 这套组合在绝大多数大模型训练场景中都能稳健运行，也是当前行业内验证过的最稳妥路径。

常见问题简答

问题1：大模型训练中张量并行度和流水并行度一样吗？

不完全一样,张量并行度受限于单层能被切分的维度数量，通常受注意力头数或隐藏层维度的约数限制，流水并行度受限于模型总层数，理想情况下两者相乘再乘数据并行度，应等于总GPU数量，若张量并行度过大，通信开销会呈指数级上升；若流水并行度过大，设备空转比例升高。

问题2：张量并行与流水并行能只用其中一种吗？

可以,如果模型相对较小但单层超大，只用张量并行即可，如果模型层数极多但单层参数不多，只用流水并行即可，但在前沿超大模型里，两种策略往往需要混用，模型参数达到数千亿级别时，单靠张量并行会把通信压垮，单靠流水并行又会遇到单层显存超限的问题，所以行业普遍采用两者结合的方式。

问题3：百度搜索上说的张量并行和流水并行区别到底指什么？

核心区别在于切分的维度不同,张量并行按参数矩阵的维度切开，每个设备负责一部分计算，设备间需要频繁同步中间结果，流水并行按网络层顺序切开，每个设备负责一整段完整子网络，设备间只需要在层边界处传递少量数据，前者看重带宽，后者更务实，更关心把多机算力组织成一个高效的整体。