04 - 分布式大模型推理实战：TP/PP/EP并行策略深度解析
本文是《大模型推理框架深度解析》系列的第四篇，详解张量并行、流水线并行与专家并行的原理与配置。
写在前面
当你的模型从7B扩展到70B、405B，单卡显存已经无法满足需求时，分布式推理成为必然选择。但面对TP、PP、EP等各种并行策略，很多开发者感到困惑：
- 这些并行策略有什么区别？
- 我的场景该用哪种？
- 需要什么样的网络环境？
本文将从原理到实践，帮你彻底理解分布式大模型推理。
一、为什么需要分布式推理
1.1 显存墙问题
以Llama-3.1-405B为例：
FP16权重：405B × 2字节 = 810 GB
KV Cache (batch=1, seq=4096)：约50 GB
激活值：约20 GB
总计：> 880 GB即使使用INT4量化，也需要220GB+显存------远超单卡容量。
1.2 分布式推理的收益
除了突破显存限制，分布式还能带来：
- 更高的计算吞吐量：多GPU并行计算
- 更低的延迟：通过张量并行加速单层计算
- 更大的batch size：分散到多卡处理
二、llama.cpp的分布式能力边界
2.1 现状：有限的多GPU支持
llama.cpp的分布式能力相对有限：
bash
# 单节点多GPU层分割
./llama-cli \
-m model.gguf \
--split-mode layer \ # 按层分割（默认）
-ngl 99 # 尽可能多卸载到GPU
# 实验性的行分割（需要高带宽互联）
./llama-cli \
-m model.gguf \
--split-mode row关键限制：
- 不支持跨节点分布式
- 不支持Megatron风格的张量并行
- 不支持流水线并行
- MoE模型仅支持层分割，专家间无并行
适用场景：单节点多GPU的模型分片加载，而非并行加速。
三、vLLM的并行策略矩阵
3.1 张量并行（Tensor Parallelism, TP）
核心思想：将每一层的计算分割到多个GPU上。
以Attention层为例（8头注意力，TP=4）：
输入: [batch, seq, hidden=4096]
↓
┌─────────┬─────────┬─────────┬─────────┐
│ GPU0 │ GPU1 │ GPU2 │ GPU3 │
│ Heads │ Heads │ Heads │ Heads │
│ 0-1 │ 2-3 │ 4-5 │ 6-7 │
└─────────┴─────────┴─────────┴─────────┘
↓
All-Reduce
↓
输出: [batch, seq, hidden=4096]通信模式：每层的forward和backward各需要一次All-Reduce。
适用场景：
- 单节点多GPU（NVLink互联）
- 70B+ dense模型
- 对延迟敏感的场景
配置示例：
python
from vllm import LLM
llm = LLM(
model="meta-llama/Llama-3.1-70B",
tensor_parallel_size=4, # 4x A100
)3.2 流水线并行（Pipeline Parallelism, PP）
核心思想：将模型按层分割到多个节点，每个节点负责一部分层。
Llama-3.1-70B共80层，PP=4：
Node 0 (Stage 0): Layers 0-19 ──→ Node 1 (Stage 1): Layers 20-39
↓
Node 3 (Stage 3): Layers 60-79 ←── Node 2 (Stage 2): Layers 40-59
数据流：
Input → [Stage 0] → [Stage 1] → [Stage 2] → [Stage 3] → Output通信模式：Stage间传递激活值（activation）。
气泡问题：
时间轴 →
朴素PP（大bubble）：
[Stage 0] ████░░░░░░░░░░
[Stage 1] ░░░░████░░░░░░
[Stage 2] ░░░░░░░░████░░
[Stage 3] ░░░░░░░░░░░░████
Micro-batching（减少bubble）：
[Stage 0] ████████░░░░░░
[Stage 1] ░░░░████████░░
[Stage 2] ░░░░░░░░██████
[Stage 3] ░░░░░░░░░░░░████适用场景：
- 跨节点大模型（405B+）
- 网络带宽有限的场景
配置示例：
python
llm = LLM(
model="meta-llama/Llama-3.1-405B",
tensor_parallel_size=4, # 每节点4卡
pipeline_parallel_size=4, # 共4个节点
)
# 总计：4 × 4 = 16张GPU3.3 专家并行（Expert Parallelism, EP）- MoE专用
核心思想：将不同的专家（Expert）分配到不同的GPU上。
以DeepSeek-V3为例（256专家，每token激活8专家）：
传统TP方案的问题：
每个GPU处理所有token，但只用到8/256专家
→ 大量无效计算
EP方案：
┌─────────────────────────────────────────────────────────────┐
│ Attention Layers │
│ (Data Parallel - 所有GPU处理所有token) │
│ [GPU0] [GPU1] [GPU2] [GPU3] ... [GPU63] │
└─────────────────────────────────────────────────────────────┘
↓ All-to-All Dispatch
┌─────────────────────────────────────────────────────────────┐
│ MoE Layer (Expert Parallel) │
│ [GPU0: E0-E3] [GPU1: E4-E7] ... [GPU63: E252-E255] │
│ 每个GPU只处理分配给它的专家的token │
└─────────────────────────────────────────────────────────────┘
↓ All-to-All Combine
┌─────────────────────────────────────────────────────────────┐
│ Attention Layers │
│ (Data Parallel) │
└─────────────────────────────────────────────────────────────┘通信模式：
- All-to-All Dispatch：将token路由到对应的专家GPU
- All-to-All Combine：收集各专家的输出
适用场景：
- MoE模型（DeepSeek-R1、Qwen3-MoE）
- 专家数量多的场景
配置示例：
python
llm = LLM(
model="deepseek-ai/DeepSeek-V3",
tensor_parallel_size=1,
pipeline_parallel_size=1,
# EP通过data_parallel_size隐式实现
data_parallel_size=8,
)3.4 混合并行策略
实际部署中，通常需要组合多种并行策略：
405B模型部署示例（32张H100）：
配置：TP=8, PP=4
Node 0: [GPU0-GPU7] TP Group → Stage 0 (Layers 0-19)
Node 1: [GPU8-GPU15] TP Group → Stage 1 (Layers 20-39)
Node 2: [GPU16-GPU23] TP Group → Stage 2 (Layers 40-59)
Node 3: [GPU24-GPU31] TP Group → Stage 3 (Layers 60-80)
通信：
- 节点内：NVLink 600GB/s+（TP All-Reduce）
- 节点间：InfiniBand 400Gbps（PP激活值传递）四、网络要求详解
4.1 不同并行策略的带宽需求
| 并行策略 | 带宽需求 | 延迟要求 | 推荐网络 |
|---|---|---|---|
| TP（单节点） | 600GB/s+ | <5μs | NVLink/NVSwitch |
| TP（跨节点） | 400Gbps+ | <10μs | InfiniBand NDR |
| PP | 50Gbps+ | <50μs | RoCEv2/InfiniBand |
| EP（MoE） | 200Gbps+ | <20μs | InfiniBand HDR/NDR |
4.2 为什么纯TP跨节点不可行
以Llama-3.1-70B为例，TP=8时：
每层通信量：2 × hidden_size × batch_size × seq_len
= 2 × 8192 × 1 × 4096 × 2字节
= 128 MB
All-Reduce需要传输：2 × (N-1)/N × 128MB ≈ 224 MB
如果跨节点使用以太网（25Gbps）：
传输时间 = 224MB / 25Gbps = 71ms
而单层计算时间仅约2ms → 通信成为瓶颈结论：TP必须限制在单节点内，跨节点使用PP。
4.3 RDMA与InfiniBand的必要性
什么是RDMA ：
Remote Direct Memory Access，允许网卡直接读写远程内存，无需CPU介入。
为什么需要RDMA：
- 降低CPU开销
- 减少延迟（<10μs vs 50μs+ for TCP）
- 提高有效带宽
配置检查：
bash
# 检查RDMA设备
ibstat
# 检查NCCL是否使用RDMA
NCCL_DEBUG=INFO python -c "import torch; torch.distributed.init_process_group(...)"
# 查看日志中的transport类型五、MoE模型的分布式优化
5.1 DeepSeek开源方案
DeepSeek团队开源了DeepEP通信库，专门优化MoE的dispatch/combine：
优化效果：
- 3x训练吞吐提升
- <200μs解码延迟
- 40%部署成本降低核心优化：
- 细粒度通信调度
- 与GPU计算流水线重叠
- 动态负载均衡
5.2 EP+DP Attention协同
DeepSeek-V3的并行策略：
Attention部分：Data Parallel
- 所有GPU都有完整的Attention参数
- 每个GPU处理一部分batch
MoE部分：Expert Parallel
- 专家分散到不同GPU
- 通过All-to-All路由token
优势：
- Attention计算高效（无通信）
- MoE计算高效（仅激活专家参与）六、实战配置示例
6.1 70B模型单节点部署
python
# 4x A100 40GB
llm = LLM(
model="meta-llama/Llama-3.1-70B",
tensor_parallel_size=4,
quantization="awq", # 进一步节省显存
)6.2 405B模型多节点部署
bash
# 启动Ray集群
ray start --head --port=6379
ray start --address="head-node-ip:6379" # 在其他节点执行
# vLLM多节点部署
vllm serve meta-llama/Llama-3.1-405B \
--tensor-parallel-size 8 \
--pipeline-parallel-size 4 \
--quantization fp8 \
--gpu-memory-utilization 0.906.3 DeepSeek-V3 MoE部署
python
# 需要DeepSeek优化的vLLM分支
llm = LLM(
model="deepseek-ai/DeepSeek-V3",
tensor_parallel_size=1, # Attention用DP
pipeline_parallel_size=1,
data_parallel_size=8, # EP=8
distributed_executor_backend="ray",
)七、常见问题排查
问题1：NCCL超时
错误：NCCL operation failed: unhandled system error解决方案：
bash
# 增加超时时间
export NCCL_TIMEOUT=3600
# 检查网络连接
nccl-tests/build/all_reduce_perf -b 8M -e 128M -f 2 -g 8问题2：TP组内GPU通信失败
错误：CUDA error: invalid device ordinal解决方案：
bash
# 确保GPU可见性
export CUDA_VISIBLE_DEVICES=0,1,2,3
# 检查NVLink状态
nvidia-smi topo -m问题3：PP气泡过大
解决方案：
python
# 增加micro-batch数量
llm = LLM(
pipeline_parallel_size=4,
num_scheduler_steps=10, # 增加流水线深度
)参考资源
文章标签
分布式推理 张量并行 流水线并行 专家并行 MoE NCCL RDMA 多机部署