在线 -
搜索
← 返回题目列表

大模型推理中的 Tensor Parallel、Pipeline Parallel 和 Data Parallel 如何选择？

高频 困难 第 8 / 25 题 更新于 2026/09/25
Tensor ParallelPipeline ParallelData Parallel分布式推理
学习 AI 实战项目

简化版

三种并行切分不同的东西：Tensor Parallel（TP） 把单层的矩阵切到多卡，降低每卡权重和计算，但每层都要高频通信，适合节点内 NVLink；Pipeline Parallel（PP） 按层切分模型，通信量小，但有流水线气泡；Data Parallel（DP） 每卡或每组卡放一份完整副本、分担不同请求，适合扩总吞吐。选择时先满足模型与 KV Cache 的容量约束，再在目标拓扑上实测延迟，最后用 DP 扩吞吐；TP 可能缩短计算时间，也可能因通信开销得不偿失，不能把“上 TP”当成固定顺序。

详细版

  • TP：对 Attention 和 MLP 的线性层做列并行/行并行，用 All-Reduce 合并结果。让单个 token 同时用多卡，能降单请求延迟，但通信几乎贯穿每层，依赖 NVLink/NVSwitch，跨慢网络做大 TP 往往得不偿失。
  • PP：把连续的层分给不同设备，激活在阶段间传递。通信少，但单请求逐 token Decode 时流水线利用率低（气泡多），需要 microbatch 或多请求填充。
  • DP：每卡一个完整模型副本，请求路由到不同副本，副本间不在每个 token 上同步。扩容、路由、故障隔离都简单。

选择时先判断模型权重 + KV Cache 能否单卡容纳，再比较互联带宽、延迟目标、并发和故障域。加 GPU 不保证线性加速——通信、气泡、负载倾斜、切分后单卡算子变小都会降低扩展效率。

完整版教学

记忆钩子：TP 拆一层、PP 拆层段、DP 复制实例；先判断放不下还是吞吐不够，再选切法。

一、Tensor Parallel：切一层，通信频繁

TP 在层内部切矩阵。以 Transformer 的两大块为例（Megatron 经典切法）：

  • MLP：第一个线性层按**输出维（列）切，各卡算一部分中间特征；激活后第二个线性层按输入维（行）**切，最后用 All-Reduce 把各卡结果加起来。
  • 注意力：按注意力头分配到各卡，每卡算一部分头，最后拼接。
每层前向/反向都要 All-Reduce 同步 → 通信次数 ∝ 层数
→ 必须靠 NVLink/NVSwitch 这种超高带宽低延迟互联
→ 跨机器（走以太网/IB）做大 TP 会被通信拖死

TP 让单个 token 的计算分摊到多卡，在计算节省大于通信开销时可以降低单请求延迟，但代价是通信贯穿每一层。小模型、小 batch 或低带宽互联下，通信反而可能使延迟升高。因此 TP 度数通常优先限制在单节点高速互联域内，并以目标负载实测选择，而不是默认开满 8 卡。

二、Pipeline Parallel：切多层，承担气泡

PP 把不同的 Transformer 层放在不同设备上，前一阶段算完把激活传给下一阶段：

卡1: 层 1~20  →  卡2: 层 21~40  →  卡3: 层 41~60  →  卡4: 层 61~80

它通信少（只在阶段边界传激活，不像 TP 每层 All-Reduce），每卡权重也少。但有个致命问题——流水线气泡（bubble）：一个请求在阶段间串行流动，当卡1在算时，卡2/3/4 在空等；排空时反过来。

训练可以用大量 microbatch 填满流水线摊薄气泡；但在线 Decode 每步只生成一个 token、延迟敏感，很难攒够 microbatch，PP 的利用率和调度都更困难。所以推理里 PP 主要用于「模型大到必须跨节点」时的容量手段，而非提速手段。

三、Data Parallel：复制模型，分摊请求

DP 最简单：每卡（或每组卡）放一个完整模型副本，不同请求路由到不同副本独立处理。它不减少单副本的显存、也不降单请求延迟，但：

  • 扩容简单：吞吐不够就加副本；
  • 路由/故障隔离简单：一个副本挂了不影响其他；
  • 是模型单卡/单节点放得下时提高总吞吐的首选。

一个易错点：各副本的 Prefix Cache 和 KV Cache 默认不共享，负载均衡要考虑 token 长度而非只看请求数（把几个长请求都路由到同一副本会打爆它）。

四、组合并行：3D 并行 + Expert Parallel

模型大到单节点放不下时，就组合：

节点内：TP（8 卡，靠 NVLink 扛每层通信）
节点间：PP（把模型分成几段，跨节点接力）
最外层：DP（复制多组上述"模型并行组"，扩吞吐）

MoE 模型还有 Expert Parallel：把不同专家分散到不同设备，token 按路由发给对应专家——这带来 All-to-All 通信和专家负载不均的新问题。核心原则：并行拓扑要匹配物理网络拓扑——通信最频繁的 TP 放带宽最高的机内，通信少的 DP 放最外层跨机。

五、如何评估扩展效率

加卡不等于加速，要对比加 GPU 前后：

  • TTFT、TPOT、总吞吐（真的变好了吗）；
  • 每卡显存、通信占比（通信是否吃掉了计算节省）；
  • 单位 token 成本（更多 GPU 是否只是更贵）。

一个常见陷阱：TP 度数开太大，模型切得太碎，每卡的矩阵变得很小、算子效率低下，加上通信时间超过计算节省，结果更多 GPU 只提高了成本、没提高速度。所以 TP 要适度、优先机内。

六、选型决策树

1. 先求满足权重、运行时和目标 KV 预算的最小模型并行度。
   → 单卡放得下：以单卡副本为基线；若严格延迟目标需要多卡加速，再实测 TP 是否值得。
   → 单卡放不下：比较节点内 TP 与按层 PP；单层张量本身放不下时必须用 TP，层能放下但整模放不下时 PP 也是候选。
2. 模型跨节点时怎么切？
   → 高频集合通信尽量留在高速互联域；根据层大小、链路和在线气泡，在“节点内 TP + 节点间 PP”等组合中压测选择。
3. 模型并行组的吞吐仍不够？
   → 在组外增加 DP 副本，并按 token 负载而非请求个数路由。
顺序是先满足容量，再验证延迟与扩展效率，最后按吞吐和故障冗余复制副本；不存在对所有模型都成立的固定 TP→PP 顺序。

七、并行方式的关键判断表

这张表用于缩小候选方案，不用于替代基准测试。尤其是“适用瓶颈”只说明某种切法解决什么约束；实际收益还由矩阵规模、batch、互联带宽、框架实现和负载形态共同决定。

并行方式切分对象适用瓶颈
Tensor Parallel单层权重与计算单卡放不下一层
Pipeline Parallel连续层段模型深度与跨机部署
Data Parallel模型副本与请求吞吐扩展
Expert ParallelMoE 专家稀疏专家容量

假设单卡基线 TPOT 为 40 ms，TP=2 后为 27 ms、TP=4 后为 25 ms，那么从 2 卡扩到 4 卡只改善约 7%，GPU 成本却翻倍。这个示例说明并行度应在真实请求分布下比较 P95 延迟、总吞吐和单位 token 成本，而不是追求最高卡数或理论 FLOPs。

八、常见误区与追问

  • 误区：Tensor Parallel 的卡数越多延迟越低。 每层都要做跨卡通信，消息变小后通信占比会升高，超过节点互联能力时加卡反而更慢。
  • 误区：Pipeline Parallel 很适合单请求低延迟。 流水线需要多个 micro-batch 填充才能降低气泡，单请求往往要依次经过各 stage，延迟不占优。
  • 误区：Data Parallel 会降低单副本模型显存。 每个 DP 副本仍保存完整模型；它提升独立请求吞吐，却不解决单模型装不下一张卡。
  • 追问：如何选择 TP、PP 和 DP 的组合？ 先确定单层张量和整模分别能否放下，再在高速互联域比较最小 TP/PP 组合；满足容量后用延迟、吞吐和成本实测选型，最后用 DP 扩请求吞吐。
  • 追问：怎样验收并行方案？ 在目标拓扑测通信占比、单请求 P95、整机吞吐、显存余量和故障域，而不是只报理论 FLOPs。

九、加强记忆

三种并行记「切什么 + 什么代价」：TP 切层内矩阵（每层集合通信频繁，只有计算节省大于通信开销才可能降延迟）、PP 切层/深度（通信频率较低但有气泡，常用于容量切分）、DP 复制整套模型并行组（分摊请求、扩吞吐最直接，不降低单请求延迟）。选型不是固定流水线：先确认单层张量、整模与 KV 预算能否放置，再让高频通信匹配高速互联，压测候选 TP/PP 组合，最后按吞吐和冗余增加 DP。超大模型还可能组合 Expert Parallel；任何方案都要以 P95 延迟、吞吐、显存和单位 token 成本验收，加卡不保证线性加速。