📚 课程目录第3章多GPU部署基础

3. 多GPU部署基础：多GPU环境配置、CUDA与NCCL基础、分布式推理概念

3.1 多GPU环境配置：从单卡到多卡的硬件与驱动准备

在开始vLLM吞吐调优之前，必须先确保多GPU环境是健康且可通信的。很多吞吐问题并非源于推理引擎，而是底层环境配置不当。多GPU部署的第一步是确认硬件拓扑与驱动状态。

使用 nvidia-smi 查看GPU列表，确认所有设备均被正确识别。对于多卡服务器，还需关注NVLink连接与PCIe拓扑。NVLink提供高带宽低延迟的GPU间直连通道，而PCIe Switch则影响跨NUMA节点的通信效率。推荐使用 nvidia-smi topo -m 查看GPU间互连矩阵，判断是否存在NVLink桥接。

# 查看GPU拓扑矩阵
nvidia-smi topo -m

# 输出示例（简化）
        GPU0    GPU1    GPU2    GPU3    CPU Affinity
GPU0     X      NV1     NV2     NV2     0-31
GPU1    NV1      X      NV2     NV2     0-31
GPU2    NV2     NV2      X       NV1    32-63
GPU3    NV2     NV2     NV1      X      32-63

若拓扑显示为 NV1/NV2，说明存在NVLink连接；若显示 PIX 或 PHB，则仅通过PCIe通信，此时跨GPU通信带宽将显著受限。在vLLM中，这直接影响张量并行（Tensor Parallelism）的通信效率。

环境检查清单：

驱动版本 ≥ 525.60.13（CUDA 12.0+），且所有GPU驱动一致。
运行 nvidia-smi -q -d SUPPORTED_CLOCKS 确认GPU时钟未被锁定。
检查 /proc/driver/nvidia/version 确认内核模块与驱动匹配。
使用 nvtop 或 nvidia-smi dmon 监控实时利用率，排除硬件故障。

3.2 CUDA与NCCL基础：通信库的选型与配置

CUDA（Compute Unified Device Architecture）是NVIDIA的并行计算平台，而NCCL（NVIDIA Collective Communications Library）是专为多GPU通信设计的库。vLLM在张量并行和流水线并行中依赖NCCL的 all-reduce、all-gather 等集合通信原语。

NCCL的版本直接影响通信效率。vLLM要求NCCL ≥ 2.18，推荐使用2.20+。可通过 python -c "import torch; print(torch.cuda.nccl.version())" 查看PyTorch内置的NCCL版本。若版本过旧，需通过环境变量 NCCL_ROOT 指定自定义安装路径。

关键NCCL环境变量及其对吞吐的影响如下表所示：

环境变量	作用	推荐值
`NCCL_DEBUG`	输出通信日志，用于排障	INFO（调优时）→ WARN（生产）
`NCCL_IB_DISABLE`	禁用InfiniBand，强制走TCP	0（有IB时）
`NCCL_P2P_DISABLE`	禁用GPU直连（P2P）	0（启用NVLink时）
`NCCL_BUFFSIZE`	设置通信缓冲区大小（字节）	默认即可，过大反而降低吞吐
`NCCL_NET_GDR_LEVEL`	GPUDirect RDMA级别	5（若硬件支持）

常见误区：不要盲目设置 NCCL_P2P_DISABLE=1 来规避通信错误。这会强制数据经过CPU内存中转，导致跨GPU通信带宽下降数倍，vLLM吞吐可能直接减半。应先通过 nvidia-smi topo -m 确认P2P是否可用，再决定是否禁用。

3.3 分布式推理核心概念：张量并行与流水线并行

vLLM支持两种分布式推理策略：张量并行（Tensor Parallelism, TP）和流水线并行（Pipeline Parallelism, PP）。理解二者的差异是调优吞吐的前提。

张量并行将单个Transformer层的权重矩阵按行或列切分到多张GPU上，每张GPU持有部分权重，计算时通过 all-reduce 同步中间结果。TP适合单机多卡且NVLink互联的场景，通信频率高但单次数据量小。

流水线并行则将模型按层切分，每张GPU负责连续的若干层。数据以micro-batch形式在GPU间顺序流动，通信频率低但存在气泡（bubble）问题。PP适合多机多卡或NVLink带宽不足的场景。

vLLM中通过 --tensor-parallel-size 和 --pipeline-parallel-size 参数控制。例如，4卡服务器可配置 TP=4, PP=1（纯张量并行），或 TP=2, PP=2（混合并行）。

# 启动vLLM服务，使用4卡张量并行
python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3-8B-Instruct \
    --tensor-parallel-size 4 \
    --pipeline-parallel-size 1 \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.9

下图展示了TP=2与PP=2混合并行时，模型层与GPU的映射关系，以及数据流方向：

图中可见，GPU0与GPU1之间通过NVLink频繁进行 all-reduce 操作，而GPU0/1与GPU2/3之间则通过较慢的PP通道传递完整hidden states。理解这一数据流后，就能明白为何TP尺寸受限于单机GPU数，而PP则更适合跨机扩展。

3.4 案例：8卡A100环境下的vLLM启动与验证

假设我们有一台8×A100 80GB服务器，NVLink全互联。目标是部署Llama-3-70B-Instruct模型。由于70B模型权重约140GB（FP16），单卡无法容纳，必须使用多卡。

推荐配置为 TP=8, PP=1，因为8卡间NVLink全互联，TP通信效率最高。启动命令如下：

export CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7
export NCCL_DEBUG=WARN
export NCCL_P2P_LEVEL=NVLink

python -m vllm.entrypoints.openai.api_server \
    --model meta-llama/Llama-3-70B-Instruct \
    --tensor-parallel-size 8 \
    --max-model-len 4096 \
    --gpu-memory-utilization 0.92 \
    --enforce-eager

启动后，通过 nvidia-smi 观察显存占用，应看到每张卡约占用18-20GB（权重+KV cache）。若某张卡显存明显偏低，说明并行配置未生效。

验证吞吐是否正常，可使用 vllm bench 工具或简单的并发请求脚本：

# 使用vllm内置benchmark
python benchmarks/benchmark_throughput.py \
    --model meta-llama/Llama-3-70B-Instruct \
    --tensor-parallel-size 8 \
    --input-len 512 \
    --output-len 128 \
    --num-prompts 200 \
    --max-num-seqs 64

正常8卡A100下，Llama-3-70B的吞吐应达到 1500-2500 tokens/s（取决于输入输出长度）。若远低于此，需检查NCCL通信是否正常。

3.5 误区与复盘：多GPU部署中的典型问题

误区1：忽略NUMA亲和性。 在多路CPU服务器上，GPU0-3可能挂在CPU0的PCIe控制器下，GPU4-7挂在CPU1下。若vLLM进程的CPU亲和性未设置，可能导致跨NUMA访问，增加内存延迟。建议使用 numactl --cpunodebind=0 --membind=0 启动进程。

误区2：盲目增大NCCL缓冲区。 设置 NCCL_BUFFSIZE=1073741824（1GB）并不一定能提升吞吐。过大的缓冲区会增加显存占用，且在小batch下反而增加同步开销。默认值通常已是最优。

误区3：将TP与PP混用时不考虑通信拓扑。 例如在4卡机上设置 TP=2, PP=2，若GPU0与GPU2不在同一NUMA域，PP通信将走PCIe而非NVLink，导致流水线气泡时间显著增加。应先查看拓扑矩阵，将同一PP stage的TP rank放在NVLink直连的GPU上。

复盘建议：每次修改环境配置后，使用 NCCL_DEBUG=INFO 启动一次vLLM，观察日志中的 NCCL communicator 初始化信息，确认通信图（communication graph）与预期一致。若出现 NET/IB 或 P2P 相关警告，说明通信路径未按最优方式建立，需调整环境变量或硬件插卡位置。

最后，务必在正式调优前，用 all_reduce_perf（NCCL官方benchmark）测试GPU间实际带宽。若NVLink带宽低于理论值（A100为600GB/s），应检查NVLink线缆连接或驱动版本。只有底层通信健康，vLLM的吞吐调优才有意义。