大模型推理的分布式部署张量并行、流水线并行与数据并行的组合策略当模型参数量突破千亿单张 H100 的 80GB 显存放不下一个 Layer 的权重时分布式推理就不是可选项而是必选项。但并行策略的选择从来不是非此即彼——张量并行切割了模型流水线并行切割了层数据并行切割了请求。三者如何组合直接决定推理吞吐和延迟的上限。一、三种并行范式的数学本质1.1 张量并行Tensor Parallelism, TP张量并行的核心思想是将单个 Transformer 层内的权重矩阵切分到多个 GPU 上并行计算。对于一个[hidden_size, intermediate_size]的前馈网络权重矩阵 WTP 沿列方向切分为 W₁ 和 W₂Y GeLU(X · W) GeLU(X · [W₁ || W₂]) [GeLU(X·W₁) || GeLU(X·W₂)]TP 的通信发生在每次前向传播中——每个 GPU 计算的结果需要 All-Reduce 汇总。对于 N 张 GPU 的 TP每次前向传播的通信量约为4 × hidden_size² × N。这决定了 TP 只能在高带宽的 NVLink 域内使用跨节点 TP 的 PCIe/NVSwitch 延迟会导致通信开销吃掉所有并行收益。1.2 流水线并行Pipeline Parallelism, PPPP 将模型的层序列切分成多个 Stage每个 Stage 部署在一组 GPU 上。Micro-batch 流水线执行不同 Stage 同时处理不同的 Micro-batch。PP 的通信只发生在 Stage 边界通信量是batch_size × hidden_size远小于 TP。但 PP 引入了气泡Bubble——流水线填充和排空阶段部分 GPU 处于空闲状态。气泡占比近似为(P-1) / M其中 P 是 Stage 数M 是 Micro-batch 数。1.3 数据并行Data Parallelism, DPDP 最简单每个 GPU 有一份完整的模型副本处理不同的输入数据。反向传播后通过 All-Reduce 同步梯度。推理场景下 DP 没有梯度同步开销只需在负载均衡层分发请求。1.4 通信开销对比并行策略通信量量级通信频率适宜拓扑TPO(hidden² × N)每层NVLink 域内PPO(batch × hidden)每Stage边界跨节点DPO(参数总量)每Step训/0推任意在推理场景的具体架构中用户请求首先经过负载均衡器分发至不同的 GPU 组每个组维护一份完整的模型副本以实现请求级并行。而在单个 GPU 组内部则进一步采用 TP 与 PP 的组合策略TP 负责层内切分利用 NVLink 互联进行高速通信PP 则负责跨 Stage 的边界通信例如将模型分为 Layer 0-15 和 Layer 16-31 两个阶段。这种分层架构确保了在负载均衡层分发请求的同时组内能高效利用 NVLink 带宽处理张量并行并通过流水线并行管理内存与计算负载。二、TPPP 组合配置GPU 拓扑感知的决策2.1 八卡节点的最佳实践典型的 8×H100 节点NVLink 全互联推荐配置70B 以下模型TP4, PP2。TP 在 4 张卡内通过 NVLink 高速通信PP 的 2 个 Stage 各占 4 张卡70B~130B 模型TP8, PP1。全节点作为一个 TP 组利用全部 NVLink 带宽130B 模型TP8, PP2跨节点。引入跨节点通信需要 InfiniBand 或 RoCE 网络关键配置原则TP 优先填满 NVLink 域。跨 NVSwitch 的 TP 通信延迟是域内的 3-5 倍收益急剧下降。2.2 多机多卡的调度策略多节点部署时调度器需要同时考虑亲和性同一 TP 组的 GPU 尽量在同一节点碎片整理避免 GPU 资源碎片化——大模型推理任务应优先调度到空闲度高的节点故障域同一模型的不同 DP 副本应分布在不同节点避免单节点故障导致全部副本不可用# GPU拓扑感知调度伪代码 class TopologyAwareScheduler: def schedule(self, model_config, available_gpus): 根据模型配置和可用GPU列表计算最优并行策略。 Args: model_config: 含model_size_gb, num_layers, hidden_size字段 available_gpus: 可用GPU列表含node_id, nvlink_group字段 Returns: ParallelConfig: TP?, PP?, 每GPU分配的层范围 # Step 1: 确定最小TP——单GPU能否装下一个Layer layer_memory model_config.hidden_size * model_config.hidden_size * 4 * 4 / (1024**3) min_tp max(1, int(layer_memory / 70)) # 假设单GPU 70GB可用显存 # Step 2: 在NVLink域内尽量使用更大的TP nvlink_groups self._group_by_nvlink(available_gpus) best_config None best_throughput 0 for tp in [1, 2, 4, 8]: if tp min_tp: continue pp (model_config.num_layers * tp) // (tp * 4) # 每GPU 4层的经验值 pp max(1, pp) # 评估通信开销和吞吐量 comm_cost self._estimate_communication(tp, pp, nvlink_groups) throughput self._estimate_throughput(tp, pp, model_config) if throughput - comm_cost best_throughput: best_throughput throughput - comm_cost best_config ParallelConfig(tptp, pppp) return best_config三、推理延迟的理论下界分析理解延迟的理论下界是判断是否还有优化空间的基础。对于一次 Prefill-Decode 两阶段的推理请求Prefill 阶段延迟下界 模型总FLOPs / (GPU数 × 单GPU理论TFLOPS × 利用率)。H100 的 BF16 理论峰值约 989 TFLOPS大模型推理的实际利用率通常在 45-60%Decode 阶段延迟下界 num_tokens × (2 × 参数量 × 带宽) / 显存带宽。Decode 是显存带宽受限的Memory-Bound而非计算受限这意味着优化 Prefill 延迟靠加 GPU 和 TP优化 Decode 延迟靠提高显存带宽和 KV Cache 管理。关键洞察对于交互式对话场景Decode 为主TP 超过 NVLink 域后几乎无收益。因为 Decode 每步的计算量很小一次矩阵-向量乘法通信延迟完全支配了总延迟。四、生产环境的关键实践4.1 KV Cache 的分布式管理多 GPU 推理时KV Cache 的分布直接决定了 Decode 阶段的通信模式。vLLM 的 PagedAttention 机制在 TP 场景下需要额外考虑每个 KV Block 在 TP 组内是分片存储的Attention 计算时需要 All-Reduce。4.2 连续批处理与并行策略的交互Continuous Batching 在预填充阶段可以混合处理不同长度的请求但 PP 场景下会因为 Micro-batch 的填充/排空引入额外的调度复杂度。需要在吞吐量和延迟之间做权衡——更多 Micro-batch 减少气泡但增加端到端延迟。4.3 监控指标体系分布式推理需要建立三个维度的监控GPU 维度SM 利用率、显存带宽利用率、NVLink 带宽利用率模型维度每 Token 延迟TTFT/TPOT、Token 吞吐量、批处理效率请求维度队列等待时间、端到端延迟、首 Token 延迟报警规则以用户体验为锚点首 Token 延迟超过 2 秒报警端到端延迟超过 30 秒报警批处理效率低于 60% 报警。五、总结分布式推理的并行策略选择是一个非凸优化问题——不存在全局最优解只有给定硬件拓扑和模型规模下的局部最优。核心决策框架是三句话TP 解决单层放不下PP 解决全部层放不下DP 解决请求太多处理不过来。实际部署中先用 TP 填满 NVLink 域再用 PP 跨节点扩展容量最后用 DP 扩展吞吐——这是一个由内向外的扩展路径。未来随着 NVLink 带宽的持续增长Blackwell 的 NVLink 6 已达 1800GB/sTP 的应用范围将进一步扩大。但跨节点 PP 的气泡问题短期内没有根本性突破——气泡占比的控制仍然依赖于 Micro-batch 数量的增加而这与延迟优化天然矛盾。本文的延迟分析基于 Transformer Decoder-Only 架构Encoder-Decoder 模型的通信模式有所不同。