大模型推理的分布式部署：张量并行、流水线并行与数据并行的组合策略

Dicky-_-zhang

1536人浏览 · 2026-07-19 15:09:45

Dicky-_-zhang · 2026-07-19 15:09:45 发布

大模型推理的分布式部署：张量并行、流水线并行与数据并行的组合策略

当模型参数量突破千亿，单张 H100 的 80GB 显存放不下一个 Layer 的权重时，分布式推理就不是"可选项"而是"必选项"。但并行策略的选择从来不是非此即彼——张量并行切割了模型，流水线并行切割了层，数据并行切割了请求。三者如何组合，直接决定推理吞吐和延迟的上限。

一、三种并行范式的数学本质

1.1 张量并行（Tensor Parallelism, TP）

张量并行的核心思想是将单个 Transformer 层内的权重矩阵切分到多个 GPU 上并行计算。对于一个 [hidden_size, intermediate_size] 的前馈网络权重矩阵 W，TP 沿列方向切分为 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, PP）

PP 将模型的层序列切分成多个 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, DP）

DP 最简单：每个 GPU 有一份完整的模型副本，处理不同的输入数据。反向传播后通过 All-Reduce 同步梯度。推理场景下 DP 没有梯度同步开销，只需在负载均衡层分发请求。

1.4 通信开销对比

并行策略	通信量量级	通信频率	适宜拓扑
TP	O(hidden² × N)	每层	NVLink 域内
PP	O(batch × hidden)	每Stage边界	跨节点
DP	O(参数总量)	每Step（训）/0（推）	任意

在推理场景的具体架构中，用户请求首先经过负载均衡器分发至不同的 GPU 组，每个组维护一份完整的模型副本以实现请求级并行。而在单个 GPU 组内部，则进一步采用 TP 与 PP 的组合策略：TP 负责层内切分，利用 NVLink 互联进行高速通信；PP 则负责跨 Stage 的边界通信，例如将模型分为 Layer 0-15 和 Layer 16-31 两个阶段。这种分层架构确保了在负载均衡层分发请求的同时，组内能高效利用 NVLink 带宽处理张量并行，并通过流水线并行管理内存与计算负载。

二、TP+PP 组合配置：GPU 拓扑感知的决策

2.1 八卡节点的最佳实践

典型的 8×H100 节点（NVLink 全互联），推荐配置：

70B 以下模型：TP=4, PP=2。TP 在 4 张卡内通过 NVLink 高速通信，PP 的 2 个 Stage 各占 4 张卡
70B~130B 模型：TP=8, PP=1。全节点作为一个 TP 组，利用全部 NVLink 带宽
130B+ 模型：TP=8, PP=2（跨节点）。引入跨节点通信，需要 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(tp=tp, pp=pp)
        
        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 每步的计算量很小（一次矩阵-向量乘法），通信延迟完全支配了总延迟。