流水线并行的工程实现从张量切分到通信隐藏的并行策略选型一、当模型大到单卡装不下——三种并行范式的分工边界大型 Transformer70B 参数的推理不仅需要多 GPU还需要在如何将模型分片的问题上做出工程决策。Data ParallelismDP复制模型副本每个副本处理不同的输入样本适用于批量离线推理。Tensor ParallelismTP将单层 Attention 的 Head 沿维度切分到多 GPU通过 All-Reduce 同步输出——这是 70B 模型在单节点 8 卡内部的标准策略。Pipeline ParallelismPP将模型按层切分为连续 Stage每个 Stage 由不同的 GPU 组负责——这是跨节点扩展时的必然选择。三种并行范式的关系不是选哪个更好而是在哪些维度上需要并行TP 解决单层过大问题PP 解决层数过多问题DP 解决吞吐量需求问题。在 8 卡 H100 节点上部署 70B 模型时TP8 是默认解扩展到 405B 时需要 TP8 PP216 卡2 个 Pipeline Stage因为单卡权重 KV Cache 在 8 卡配置下仍超出显存。二、Pipeline Parallelism 的通信模式与 Bubble 问题flowchart TD subgraph Pipeline_Parallel[Pipeline Parallelism 2 Stages] A1[Stage 0: GPU 0-3br/Layers 0-39] --|Send hidden statesbr/NCCL P2P| A2[Stage 1: GPU 4-7br/Layers 40-79] A2 -.-|Backward: Send gradients| A1 end subgraph Bubble_Problem[Pipeline Bubble——GPU 空闲等待] B1[GPU 0-3: █████░░░░░] B2[GPU 4-7: ░░░░██████] B1_desc[前向: 计算 60%等待 40%br/后向: 梯度计算 60%等待 40%] end subgraph Solutions[Bubble 的缓解方案] C1[Micro-Batch: 将大 batch 切分为小 micro-batchbr/缩小空闲窗口] C2[1F1B 调度: 交替执行 forward/backwardbr/填充 idle 间隙] C3[Interleaved PP: Layer 0→GPU0, Layer 1→GPU1, Layer 2→GPU0br/减少梯度同步边界] endPipeline Bubble 是 PP 的核心性能瓶颈。在朴素实现中Forward Pass 按 Stage 顺序执行GPU 0-3 计算完毕后将 Hidden States 发送给 GPU 4-7。这期间 GPU 4-7 处于空闲状态——这就是 Bubble。Bubble 的大小取决于 Stage 数量Stage 越多Bubble 总时长越大总体 GPU 利用率越低。Micro-Batch 切分是缓解 Bubble 的标准方案。将一个大 BatchB64切分为 4 个 Micro-Batch各 B16前向 Micro-Batch 1 从 Stage 0 → Stage 1 后Stage 0 立即开始 Micro-Batch 2 的计算而非等待 Micro-Batch 1 走完后向。这样 GPU 0-3 和 GPU 4-7 的忙碌时间重叠增多Bubble 减小。三、TP vs PP vs DP 的选型决策表维度Tensor ParallelismPipeline ParallelismData Parallelism切分维度层内Head 维度层间连续层分组数据Batch 维度通信量每个 Forward 两次 All-Reduce每层 2 × hidden_size × batch一次 P2P 发送 Hidden StatesStage 间 1 × hidden_size × batch一次 All-Reduce 梯度每 Step 1 × 参数量通信频率高每层低Stage 间低每 StepGPU 利用率高无 Bubble中天然 Bubble中梯度同步等待跨节点友好否All-Reduce 跨 IB 带宽敏感是P2P 通信量小是梯度聚合通过 RDMA最佳场景单节点内8 卡 NVLink跨节点扩展16~64 卡大批量离线推理实际部署组合在 8 卡 H100NVLink 900 GB/s的节点上TP8 是 70B 模型的标准配置——单节点内 NVLink 带宽远高于 InfiniBandAll-Reduce 开销可隐藏于 GPU 计算。扩展到 16 卡2 节点时节点间使用 InfiniBand400 GB/s通信成为瓶颈——此时适合 TP4 每节点 PP2 跨节点节点内部用 TP 高效通信节点间用 PP 的 P2P 降低跨节点流量。四、Pipeline Parallelism 在推理场景的适用性分析PP 对延迟的放大效应推理场景中每个请求的 Forward Pass 需要经过所有 Stage。如果 TPOT25ms单 StagePP2 将 Hidden States 的 P2P 传输引入 ~0.5ms 的额外延迟总体延迟 25.5ms——看起来微小但在 50 Token 的序列中累积至 25ms在延迟敏感的交互场景中感知显著。Prefill 阶段的 Bubble 更严重Prompt 在 Pre-fill 阶段一次性处理此时 GPU 计算量远大于 Decode 阶段。PP 的 Stage 0 完成 Pre-fill 后发送 Hidden States 给 Stage 1期间 Stage 1 必须等待完整接收后才能开始计算——Bubble 时间 Stage 0 的计算时间。在 Micro-Batch 切分不可行的 Pre-fill 阶段PP 的 Bubble 成本最高。与 TP 的协同使用生产中最常见的方案是 TP 内部 PP 跨节点。例如 LLaMA-3.1-405B 在 32 卡上使用 TP8 PP4——4 个 Pipeline Stage每个 Stage 内部使用 TP8 处理单层的 Attention。这既利用了 TP 的层内高效通信NVLink又通过 PP 将巨大的总参数量切分为可管理的显存占用。五、总结流水线并行是模型规模超越单节点显存上限时的必然选择。其核心优势在于层间 P2P 通信量远小于 TP 的 All-Reduce天然适合跨节点扩展。但 Pipeline Bubble 是固有的性能代价——1F1B 调度和 Micro-Batch 切分是缓解 Bubble 的标准工程手段。选型决策规则70B 以下单节点→ TP8 仅使用 Tensor ParallelismNVLink 最优路径70B~200B 跨节点→ TP(节点内) PP2(节点间)400B 多节点→ TP8 PP4~8配合 1F1B 调度降低 Bubble。在推理场景中应尽量减少 PP Stage 数量每增加 Stage 都放大延迟和 Bubble优先使用 TP 扩展至单节点的 NVLink 极限。