企业官网建设流程全解析

这一篇是部署服务化篇的收官，主题是大多数工程师在 70B+ 模型部署时都会被问到的问题：

并行怎么切？

这是一个看似简单实则复杂的问题。前面几篇我们已经多次提到 TP、PP、EP、CP，但都是浅尝辄止。今天我们把它们一次性讲透。

如果你做过相关工作，下面这些问题应该不陌生：

• 8 卡 H100 部署 Llama-3-70B，用 TP=8 还是 TP=4+PP=2？

• 跨机部署一定要 PP 吗？跨机能不能用 TP？

• DeepSeek-V3 671B 怎么切？专家并行（EP）是什么？

• 1M 上下文场景下，CP（Context Parallel）怎么和 TP 配合？

• 集群用 InfiniBand 200Gbps 够不够？

• 同样是 8 卡，为什么 TP=8 比 TP=4 慢？

读完本文你将能：

1. 区分 5 大并行策略的本质差异和适用场景

2. 设计混合并行配置（3D / 4D 并行）

3. 根据硬件 + 模型规模选对最优策略

4. 在 vLLM / SGLang 上实战配置各种并行

5. 排查通信瓶颈

我们开始。

一、为什么需要分布式

1.1 单卡装不下的硬上限

回顾前面我们算过的数字：

单卡 H100/H200 上限是 80-141GB。所以：

• 8B / 14B：单卡跑得动

• 32B：单卡极限（INT4）

• 70B：必须多卡

• 405B / 671B：必须跨机

1.2 不仅是「装下」

分布式推理不只解决"装下"问题，还要解决：

1. 吞吐：多卡分担同一请求 → 单请求快

2. 并发：多副本独立处理 → 总吞吐高

3. 长上下文：单卡 KV Cache 不够 → 跨卡分担

4. MoE 专家：稀疏激活 → 专家分布

5. 跨机网络：高带宽互联 vs 低带宽 → 不同策略

不同需求对应不同的并行策略。

1.3 五大并行策略速览

DP - Data Parallel ── 数据并行 ── 切请求 TP - Tensor Parallel ── 张量并行 ── 切层内算子 PP - Pipeline Parallel ── 流水并行 ── 切层 EP - Expert Parallel ── 专家并行 ── 切 MoE 专家 CP - Context Parallel ── 上下文并行 ── 切序列

下面逐个深入。

二、五大并行策略深度拆解

2.1 Data Parallel (DP)：最朴素的并行

做法：把同一个完整模型在多张卡上各放一份，每张卡处理不同的请求。

卡 0：完整模型 + 请求 A 卡 1：完整模型 + 请求 B 卡 2：完整模型 + 请求 C 卡 3：完整模型 + 请求 D

优点：

• 实现极简

• 无跨卡通信

• 线性扩展吞吐

缺点：

• 不省显存——每张卡都要装完整模型

• 70B 模型每张卡都要 140GB（FP16） → 单卡 H100 装不下，根本不能用 DP

适用场景：

• 模型小（< 单卡显存）

• 业务高并发

• 多副本部署（业务层路由）

与训练 DP 的区别：训练 DP 需要梯度同步（AllReduce），推理 DP 完全独立。

2.2 Tensor Parallel (TP)：层内切分

核心思想：把每一层的算子（attention、MLP）切到多张卡上并行计算。

2.2.1 Attention 切分

Multi-Head Attention 天然适合切：

原始：64 个 attention head 在 1 张卡 TP=8：8 个 head / 卡，共 8 张卡

每张卡算自己那 8 个 head，结果通过 AllReduce 合并。

2.2.2 MLP 切分

FFN 的W1: [d, 4d]和W2: [4d, d]用行列分割：

W1 切列：每张卡持有 [d, 4d/N] W2 切行：每张卡持有 [4d/N, d]

计算流程：

x → W1 (列切) → activation → W2 (行切) → AllReduce → output

中间结果不需要同步，只在最后做一次 AllReduce。

2.2.3 TP 的通信代价

每层 Transformer Block 通信约2 次 AllReduce：

• attention 后的 AllReduce

• FFN 后的 AllReduce

对 Llama-3-70B（80 层）：

• 每次 forward：160 次 AllReduce

• 每次 AllReduce 通信量：~ d × batch × seq × 2 bytes

这就是为什么 TP 要求高速互联——通信跑不快，TP 直接变成性能杀手。

2.2.4 通信带宽要求

核心规则：

TP 必须用 NVLink 级别的互联，跨机做 TP 是灾难。

2.2.5 TP 的实际收益

理想：TP=8 → 8× 加速
现实：TP=8 → 5-6× 加速（通信开销吃掉一部分）

随着 TP 数增大，通信开销不成比例上升：

生产建议：TP 通常 ≤ 8（单节点内 NVLink），跨机要换 PP。

2.3 Pipeline Parallel (PP)：层间切分

核心思想：把模型的不同层放到不同卡上。

卡 0：layers [0-19] 卡 1：layers [20-39] 卡 2：layers [40-59] 卡 3：layers [60-79]

请求像在流水线上"流过":

时刻 1：请求 A 在卡 0 时刻 2：请求 A 在卡 1，请求 B 在卡 0 时刻 3：A 在卡 2，B 在卡 1，C 在卡 0 ...

2.3.1 PP 的 bubble 问题

最朴素的 PP 有起始 + 结束的 bubble——前几个 step 后面的卡闲着，最后几个 step 前面的卡闲着：

时刻： 1 2 3 4 5 6 7 8 卡 0: A B C D - - - - ← 后期闲 卡 1: - A B C D - - - 卡 2: - - A B C D - - 卡 3: - - - A B C D - ← 前期闲 ^^^^^^^^^^^^ 只有这里满载

Bubble 占比：约(PP - 1) / 总 step 数。如果总 step 数远大于 PP，bubble 影响小。

优化：1F1B、Interleaved 1F1B

通过更精细的调度，把不同 micro-batch 交错执行，bubble 显著降低：

传统 PP： bubble ~ 40% 1F1B： bubble ~ 20% Interleaved：bubble ~ 5% DualPipe（DeepSeek V3）：bubble ~ 0%

2.3.2 PP 的通信代价

PP 通信量比 TP 小得多——只在「层边界」传递激活值：

• 每层间一次 send/recv

• 通信量：batch × seq × d × 2 bytes

适合跨机部署——InfiniBand 完全够用。

2.3.3 TP vs PP 决策

推理首选 TP——除非跨机或单层太大。

2.4 Expert Parallel (EP)：MoE 专属

背景：DeepSeek-V3 / Mixtral 等 MoE 模型有大量专家（256+），如果按 TP 切，每张卡都要装所有专家——显存爆。

EP 的做法：

256 个专家 → 切到 8 张卡，每张卡 32 个专家 每个 token 选 8 个专家 → 通过 All-to-All 路由到对应卡

通信特点：

• All-to-All：每张卡都要和其他卡互发数据

• 通信量 = batch × seq × d × 2 bytes（不大，但全连通）

2.4.1 EP 的工程挑战

1. 专家负载不均

某些专家被频繁激活，某些几乎不用。

对策：

• 训练时引入 auxiliary loss-free 负载均衡（DeepSeek V3 创新）

• 推理时实时监控，动态调整

2. 跨卡 All-to-All 慢

跨节点 All-to-All 是分布式系统中最慢的通信模式。

对策：

• 同节点内尽量做完通信（节点内 EP）

• DeepEP 等专用 All-to-All 库

2.4.2 EP 的实际效果

DeepSeek V3（671B / 37B 激活）部署：

2.5 Context Parallel (CP)：序列切分

场景：1M 上下文，单卡 KV Cache 几百 GB 装不下。

做法：把序列切到多卡，每张卡持有一部分 K/V，用 Ring Attention 累积。

1M 序列 / 8 卡 = 每卡 125K 卡 0: token [0, 125K) 卡 1: token [125K, 250K) ... 卡 7: token [875K, 1M)

通信特点：Ring 通信（环形传递 K/V），通信和计算 overlap。

第 15 篇我们详细讲过，这里不再展开。

CP 的适用场景

• 上下文 > 100K

• 模型不大（< 100B）—— 否则 TP 已经把卡用完了

• 高速互联（NVLink + IB）

三、混合策略：3D 并行 / 4D 并行

3.1 单一并行不够用

实际生产中，单一并行策略往往不够：

• 仅 TP：跨机变慢

• 仅 PP：单卡装不下大层

• 仅 EP：MoE 才有效

所以工业部署都是混合：

小模型 (8B-32B)： TP 即可 大模型 (70B-405B)： TP + PP 超大 MoE： TP + PP + EP 长上下文： TP + PP + CP 全场景： TP + PP + EP + CP (4D)

3.2 3D 并行（最常见）

Llama-3-405B 跨机部署（16 卡 H100，2 节点）：

节点 1（8 × H100） 节点 2（8 × H100） TP=8 in node TP=8 in node ↘ ↙ PP=2 across nodes

总并行度：TP=8 × PP=2 = 16 GPU

为什么这么切：

• TP=8 在单节点内 NVLink 通信

• PP=2 跨节点（IB 通信量小）

• 模型权重均匀分布

3.3 4D 并行（MoE 超大规模）

DeepSeek-V3 671B 部署（32 卡 H100，4 节点）：

TP=4 × EP=4 × PP=2 = 32 GPU ↓ 节点内：TP=4 节点间：PP=2 + EP=4

配置思路：

• TP=4：单节点 4 卡切层内（每卡装 1/4 共享权重）

• EP=4：跨节点 4 路切专家（每节点 64 个专家）

• PP=2：横跨多组节点

3.4 计算公式

总卡数 =TP × PP × EP × CP × DP

举例：

8 卡部署 70B 模型： TP=8, PP=1, EP=1, CP=1, DP=1 → 1 个副本 16 卡部署 70B 模型： TP=8, PP=1, EP=1, CP=1, DP=2 → 2 个副本（高并发） 16 卡部署 70B 模型 + 长上下文： TP=8, PP=1, EP=1, CP=2, DP=1 → 单副本 1M 上下文 32 卡部署 405B 模型： TP=8, PP=4, EP=1, CP=1, DP=1 → 1 个副本 32 卡部署 671B MoE： TP=4, PP=2, EP=4, CP=1, DP=1 → 1 个副本

四、实战配置

4.1 vLLM 单机 TP（最常用）

# 8 卡 H100 部署 Llama-3-70B vllm serve meta-llama/Llama-3-70B-Instruct \ --tensor-parallel-size 8 \ --dtype bfloat16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.92 \ --port 8000

注意事项：

• TP 数必须是num_attention_heads的因子（Llama-3-70B 是 64 → TP 可以是 1/2/4/8/16/32/64）

• 单节点 NVLink 才合理 TP

4.2 vLLM 多机 TP + PP

# 2 节点 × 8 卡，部署 405B # Master 节点 ray start --head --port=6379 # Worker 节点 ray start --address=<master_ip>:6379 # 在 Master 上启动 vLLM vllm serve meta-llama/Llama-3-405B-Instruct \ --tensor-parallel-size 8 \ --pipeline-parallel-size 2 \ --distributed-executor-backend ray \ --dtype bfloat16 \ --max-model-len 16384 \ --port 8000

关键点：

• 必须用 Ray 作为分布式执行器

• 所有节点同样的 vLLM 版本

• 同样的模型权重路径（NFS / 分布式存储）

4.3 vLLM 长上下文 + CP

# 16 卡部署 70B + 1M 上下文 vllm serve meta-llama/Llama-3-70B-Instruct \ --tensor-parallel-size 4 \ --context-parallel-size 4 \ --max-model-len 1048576 \ --kv-cache-dtype fp8 \ --rope-scaling '{"type":"yarn","factor":8.0}' \ --enable-chunked-prefill \ --port 8000

TP=4 + CP=4 = 16 卡：

• TP 切模型权重

• CP 切序列长度

4.4 SGLang EP 部署 MoE

# 32 卡部署 DeepSeek-V3 python -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-V3 \ --tp 4 \ --ep 4 \ --pp 2 \ --dist-init-addr master:50000 \ --nnodes 4 \ --node-rank 0 \ --enable-flashinfer \ --port 30000

注意：SGLang 对 MoE 优化做得更好，EP 部署推荐用它。

4.5 配置选择决策树

模型规模？ │ ├─ < 30B → 单卡 (DP 多副本) │ ├─ 30-70B → TP 单机 │ └─ 上下文 > 128K → + CP │ ├─ 70-200B (Dense) → TP 单机 / TP+PP 双机 │ ├─ 200B-1T (MoE) → TP + EP + PP 多机 │ └─ > 1T → 4D 并行 + 大型集群

五、网络拓扑与硬件要求

5.1 通信带宽对应表

5.2 推荐架构

单机 8 卡训练 / 推理：

• 8 × H100 SXM5（NVLink + NVSwitch）

• 1.8 TB/s 二分带宽

• 完美做 TP=8

8 卡服务器 + 集群：

• 节点内：H100 SXM + NVLink

• 节点间：InfiniBand NDR 400G × 8 网卡

• 适合 TP=8 in node + PP/EP across nodes

经济型方案：

• 8 × RTX 4090（PCIe 互联）

• 适合 DP 多副本（不适合 TP）

• 不能跨机

5.3 通信瓶颈识别

部署后看 GPU 利用率：

nvidia-smi dmon -s u # 实时 utilization nvtop # 多卡可视化

异常模式：

• GPU 利用率 50-60% 周期波动 →TP 通信瓶颈

• GPU 利用率梯子状（前面满后面空）→PP bubble

• 整体利用率 < 30% → 通信完全卡死

排查工具：

# NVIDIA Insight / Nsight Systems 跑 trace nsys profile --output=trace python my_inference.py # 看 NCCL 日志 NCCL_DEBUG=INFO vllm serve ...

六、生产常见问题

6.1 TP 反而变慢

症状：TP=8 比 TP=4 还慢。

原因：通信开销超过算力收益。

对策：

• 检查 NVLink 是否启用：nvidia-smi nvlink -s

• 降 TP 数（往往 TP=4 已经够）

• 提高 batch size（增大 compute / communication 比例）

6.2 PP bubble 严重

症状：GPU 利用率呈梯子状。

对策：

• 启用 1F1B 调度（vLLM 默认）

• 增加 micro-batch 数量

• 减少 PP 数（PP=2 通常足够）

6.3 MoE 专家不均衡

症状：某些卡显存满，某些卡空。

对策：

• 监控专家激活分布

• 训练阶段加 load balance loss

• 推理时启用 Expert Affinity（部分框架支持）

6.4 跨机延迟超预期

症状：跨机 PP 比预期慢 2-3 倍。

对策：

• 检查 InfiniBand 拓扑：ibstat

• 确认 NCCL 用了 IB：NCCL_IB_DISABLE=0 NCCL_NET=IB

• 测试通信带宽：nccl-tests/all_reduce_perf

6.5 显存不均衡

症状：某些卡 OOM，某些卡空闲。

对策：

• TP 数选择不当（不是 head 数的因子）

• PP 切分不均（用--pipeline-parallel-balance）

• KV Cache 量化 + offloading

七、扩展话题与下一篇预告

7.1 Disaggregated Prefill/Decode（新趋势）

2025 年的新方向——把 prefill 和 decode 部署到不同集群：

Prefill 集群（compute-bound）：高算力 GPU、少量 KV 存储 Decode 集群（memory-bound）：大显存 GPU、强带宽 请求流： 用户 → Prefill 集群（生成 KV） → 传到 Decode 集群（生成 token）

优势：

• 两类负载用不同硬件优化

• 资源利用率从 60% 提升到 90%+

• DeepSeek V3 / Llama 4 已经在用

7.2 异构硬件混部

未来推理集群可能不是同质化的：

• 高端 GPU 跑 prefill

• 低端 GPU 跑 decode

• CPU 处理 embedding

• NPU / TPU 跑特定任务

7.3 下一篇预告

部署服务化篇 5 篇圆满收官！下一阶段进入工程实践篇（第 21-25 篇）：

• 第 21 篇：GPU 选型指南 - A100/H100/4090/910B 性价比分析—— 从硬件视角看大模型部署：什么场景买什么卡？租 vs 买？国产卡现状？

• 之后是集群运维（22 篇）、权重管理（23 篇）、显存优化（24 篇）、成本测算（25 篇）。

工程实践篇 5 篇收官后，我们就接近系列后半段——RAG / Agent / 前沿话题。

八、结语：分布式推理是大模型工程的"内功"

读完本文你应该明白：

• 5 大并行策略：DP / TP / PP / EP / CP 各有适用场景

• TP 用 NVLink，PP 用 IB——通信带宽决定策略

• 混合并行：实际生产 70B+ 模型都是 TP+PP，超大 MoE 是 4D 并行

• 通信开销随并行度非线性增长——TP=16 不一定比 TP=8 快

• Disaggregated Prefill/Decode是下一代架构趋势

参考文献：

分布式推理：TP / PP / EP / CP 并行策略详解