3.2 多GPU并行优化

3.2 多GPU并行优化

本节导读：单卡装不下、或者单卡吞吐不够时，就需要多GPU并行。本节讲清vLLM三种并行方式（TP/PP/DP）的原理与适用场景，给出选型决策树，并覆盖从单机多卡到多机集群的完整部署与排障。

学习目标

• 理解张量并行、流水线并行、数据并行的原理与开销来源
• 掌握并行方式的选型决策方法
• 能独立完成单机多卡与多机多卡的vLLM部署
• 掌握NCCL通信问题的排查思路

核心概念

三种并行方式对比

张量并行的本质

TP把每个注意力头和FFN矩阵切到多卡上，各卡算完自己的分片后用NCCL all-reduce汇总。关键约束与开销：

• 整除约束：tensor_parallel_size 必须整除 num_attention_heads（7B级模型通常16/32头，TP=4没问题；但如64头的模型不能设TP=6）
• 通信密集：每个transformer层要做2次all-reduce，所以TP只在NVLink域内高效——同一台机器内用NVLink互联的卡，跨机TP会被网络拖垮
• 收益递减：TP=2→4吞吐提升明显，TP=8以上通信占比急剧上升

流水线并行的定位

PP按层切分：GPU0放前1/4层，GPU1放第二个1/4层。通信量极小（只传层间激活），适合跨机；代价是存在"气泡"（流水线空转）且单请求延迟反而增加。vLLM用interleaved调度（micro-batch交错）压低气泡比例。

数据并行：最便宜的扩展

DP不切模型，每卡跑一个完整副本，前面用负载均衡分发请求。没有通信开销，扩展近乎线性，前提是单卡装得下整个模型。生产高吞吐场景"TP=2/4 + 多副本DP"往往优于"纯TP=8"。

选型决策树

单卡能放下模型？
├─ 是 → 吞吐不够？→ 多副本数据并行（每卡独立实例，前置LB分流）
└─ 否 → 模型多大？
    ├─ 单机多卡放得下 → 张量并行（TP=2/4/8，保持NVLink域内）
    └─ 需跨机 → TP(机内) + PP(机间)，或直接用Ray集群
​

分步实战

步骤 1：单机张量并行部署

vllm serve Qwen/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.9
​

启动日志中确认每张卡各自加载了分片权重，显存占用约为全量的1/4加激活与KV Cache。

步骤 2：TP + PP混合并行（跨机场景）

# 两台机器各4卡跑70B：机内TP=4，机间PP=2
vllm serve Qwen/Qwen2.5-72B-Instruct \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2
​

步骤 3：多机Ray后端

多机部署用Ray管理进程。先在所有节点启动Ray集群：

# 主节点
ray start --head --port=6379
# 工作节点
ray start --address=<主节点IP>:6379
​

然后只在主节点启动vLLM，指定GPU总数：

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2 \
  --distributed-executor-backend ray
​

步骤 4：多副本数据并行（吞吐扩展）

两块卡各跑一个TP=1实例，用nginx做least_conn分流：

upstream vllm_pool {
    least_conn;
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;
}
server {
    listen 8000;
    location / { proxy_pass http://vllm_pool; }
}
​

注意：多副本间不共享KV Cache，带prefix缓存的流量按会话哈希路由可提升命中率。

步骤 5：验证并行正确性

# 对比单卡与并行的输出是否一致（temperature=0）
curl -s http://localhost:8000/v1/completions -d '{
  "model": "...", "prompt": "北京是中国的", "temperature": 0, "max_tokens": 8
}'
​

TP/PP只是切分方式不同，数值上可能有极微小的浮点差异，但语义必须一致；若输出明显混乱，优先怀疑通信或权重切分配置。

完整示例：8×A100集群跑72B的方案对比

结论：机内优先TP=4，剩下的卡做副本扩展，吞吐比纯TP=8高40%；只有当显存实在不够时才上PP。

常见问题 FAQ

Q1：启动报错 "tensor parallel size is not divisible by num_attention_heads"？
TP必须整除注意力头数。检查模型config.json中的 num_attention_heads，调整 tensor_parallel_size 为其因子（如32头可选1/2/4/8/16/32）。

Q2：多机Ray启动后卡在等待worker？
依次排查：①各节点CUDA版本与vLLM版本完全一致；②RAY_ADDRESS/防火墙放行6379及10001端口；③共享存储挂载路径相同（模型文件各节点都能读到同一路径）；④ray status 确认节点与GPU都已被识别。

**Q3：TP=2比TP=1慢，正常吗？**
小模型上完全可能。TP的all-reduce开销是固定的，7B以下模型单卡算力过剩，切分后通信占比反而超过计算节省。经验：7B以下不切，14B以上才考虑TP。

Q4：NCCL超时报错怎么排查？
NCCL timeout 通常源于网络或P2P问题：①同机卡间确认nvidia-smi topo -m显示NVLink而非PCIe；②容器内需要 --gpus all --ipc=host --shm-size=16g；③跨机网卡带宽不足时调大超时 export NCCL_TIMEOUT=1800 只能缓解，根治要升级IB/RoCE。

Q5：DP多副本怎么做灰度发布？
LB层按权重分流（如新版本实例先接5%流量），对比两版本的错误率与P99延迟，逐步放量。副本间天然隔离，是成本最低的灰度方案。

最佳实践与避坑

• 避坑一：跨机TP。张量并行每层都要all-reduce，普通以太网下跨机TP吞吐可能掉到单机的一半以下，跨机扩展请用PP或副本式DP；
• 避坑二：所有节点手动 pip install 导致版本漂移。用统一的Docker镜像保证各节点CUDA/torch/vLLM严格一致；
• 实践：先确定"单副本最小TP数"（能放下即可），剩余GPU全部用于副本扩展，这是吞吐性价比最高的路径；
• 实践：多机部署为Ray head与vLLM分别配置日志目录，排障时按"Ray集群→NCCL通信→vLLM引擎"三层逐层定位。

本节小结

本节讲清了三种并行的取舍：TP用通信换显存、适合机内；PP用延迟换扩展、适合跨机；DP零通信、是吞吐扩展首选。核心方法论是"最小TP + 多副本"。下一节转向另一个免费午餐——缓存策略优化。

延伸阅读

• 相关章节：3.1 批处理参数调优、5.3 企业级部署方案、5.4 性能深度调优
• Ray文档、NCCL用户指南