📚 课程目录第3章多GPU推理概述

3、多GPU推理概述：多GPU并行策略及适用场景

3.1 为什么单卡无法满足大模型推理需求

当模型参数量达到数十亿甚至数千亿级别时，单张GPU的显存容量与算力都会成为瓶颈。以LLaMA-70B为例，仅权重就需要约140GB显存（FP16），而主流数据中心GPU如A100/H100的显存为80GB，单卡根本无法装载完整模型。即便模型勉强放入显存，推理时的KV Cache、中间激活值也会进一步挤压显存空间。更关键的是，单卡算力限制了生成吞吐——大模型推理是访存密集型任务，单卡的内存带宽决定了token生成速度的上限。

多GPU并行推理的核心思想是：将模型或数据拆分到多张GPU上，协同完成一次推理请求。根据拆分维度的不同，形成了三种基础并行策略：数据并行（Data Parallelism）、张量并行（Tensor Parallelism）和流水线并行（Pipeline Parallelism）。理解三者的本质区别与适用边界，是设计多GPU推理架构的第一步。

核心判断标准：先问“瓶颈在显存容量还是吞吐量”。若单卡放不下模型，必须用张量并行或流水线并行；若单卡能放下但吞吐不足，优先考虑数据并行或增加batch size。

3.2 三种并行策略的深入剖析

3.2.1 数据并行（Data Parallelism）

数据并行是最直观的策略：每张GPU都保存一份完整的模型权重，将不同的输入请求（batch）分发到不同GPU上并行处理。推理阶段各GPU完全独立，无需任何通信，因此扩展性极好。但在训练阶段，每轮前向/反向传播后需要执行梯度AllReduce同步，确保各副本权重一致。

在TensorRT-LLM中，数据并行通常通过运行时多实例实现——即启动多个独立的引擎实例，每个实例绑定一张GPU，由前端负载均衡器将请求分发到不同实例。这种方式实现简单，吞吐量随GPU数量近似线性增长。

# TensorRT-LLM 数据并行启动示意（伪代码）
# 每个GPU启动一个独立进程，加载相同engine
for gpu_id in range(num_gpus):
    runtime = Runtime(engine_path, worker_id=gpu_id)
    # 每个worker独立处理分配给自己的请求
    start_inference_server(runtime, port=8000 + gpu_id)

适用判断：当模型能完整放入单卡显存（如7B/13B模型在A100上），且业务并发请求量大时，数据并行是最优选择。它不引入任何通信延迟，吞吐扩展最平滑。

3.2.2 张量并行（Tensor Parallelism）

张量并行解决的是单卡显存放不下模型的问题。它将每一层的权重矩阵按行或列切分到多张GPU上，每张GPU只负责计算自己分片对应的部分。以Transformer的线性层为例，假设权重矩阵为 \(W\)，将其按列切分为 \([W_1, W_2]\) 分别放在GPU0和GPU1上，输入 \(X\) 同时广播给两张卡，各自计算 \(X \cdot W_i\)，最后通过AllReduce将部分结果相加得到完整输出。

张量并行的核心特征是每层计算都需要一次跨卡通信，因此通信量极大，对GPU间互联带宽（NVLink/NVSwitch）要求极高。在TensorRT-LLM中，张量并行通过引擎配置参数 tensor_parallel_size 指定，引擎构建时会自动将权重分片并插入通信原语。

# TensorRT-LLM 构建张量并行引擎
trtllm-build --model_dir ./llama-70b \
             --tensor_parallel_size 4 \
             --output_dir ./engine_tp4

关键限制：张量并行规模受限于GPU拓扑。跨节点（非NVLink互联）使用张量并行会导致通信延迟急剧上升，通常建议TP规模不超过单节点内GPU数量（如8卡DGX节点内使用TP=8）。

3.2.3 流水线并行（Pipeline Parallelism）

流水线并行将模型按层切分为多个阶段（stage），每个阶段分配一张或多张GPU。数据依次流过各阶段，前一个阶段的输出作为后一个阶段的输入。与张量并行不同，流水线并行只在阶段边界发生通信，通信量小，对互联带宽要求较低。

但流水线并行存在气泡（bubble）问题：在流水线启动和排空阶段，部分GPU处于空闲状态。为减少气泡，通常采用微批次（micro-batch）技术——将一个大batch拆分为多个小batch依次送入流水线，让各阶段尽量保持忙碌。TensorRT-LLM通过 pipeline_parallel_size 参数启用流水线并行，并支持与张量并行组合使用。

策略	显存占用	通信开销	扩展瓶颈	典型规模
数据并行 (DP)	每卡完整权重	推理无通信	显存容量	1~32卡
张量并行 (TP)	权重分片	每层AllReduce	互联带宽	2~8卡
流水线并行 (PP)	层分片	阶段边界传输	气泡率	2~16卡

3.3 混合并行与真实场景选择

实际部署中，三种策略往往组合使用。以LLaMA-70B在8卡A100（单节点）上推理为例：模型权重FP16约140GB，单卡80GB无法容纳，因此必须使用张量并行。若使用TP=8，则每卡仅需存储17.5GB权重，但每层计算都需要跨8卡AllReduce，对NVLink带宽压力较大。另一种方案是TP=4 + PP=2：先按张量并行将模型切为4份，再将层分为2个阶段，每阶段4卡。这样每卡存储约35GB权重，通信压力较TP=8有所缓解，但引入了流水线气泡。

工程经验法则：
单节点内优先使用TP，充分利用NVLink高带宽（900GB/s）；
跨节点必须使用PP或DP，避免TP跨节点通信；
DP作为最外层扩展手段，叠加在TP/PP之上，提升整体吞吐；
TensorRT-LLM支持 tp_size × pp_size × dp_size 三维组合，但需保证总GPU数 = 三者乘积。

# 混合并行示例：TP=4, PP=2, DP=2，共16卡
trtllm-build --model_dir ./llama-70b \
             --tensor_parallel_size 4 \
             --pipeline_parallel_size 2 \
             --output_dir ./engine_tp4_pp2

# 推理时启动2个数据并行实例（DP=2）
# 每个实例使用engine_tp4_pp2，绑定8张GPU

3.4 常见误区与选型复盘

误区一：盲目追求最大TP规模。TP=8在单节点内可行，但若模型较小（如7B），TP=8反而因通信开销导致延迟劣于TP=1。TP的目的是解决显存容量，而非提升速度。当模型能放入单卡时，TP只会增加延迟。

误区二：忽略KV Cache的显存占用。长序列推理时，KV Cache可能占据与权重相当的显存。例如LLaMA-70B在TP=8下每卡权重17.5GB，但若batch=32、序列长度4096，每卡KV Cache可能超过20GB。选型时必须预留KV Cache空间，否则需降低batch或增加TP规模。

误区三：将训练经验直接迁移到推理。训练时PP常用于跨节点降低通信，但推理场景下PP的气泡问题在低batch时尤为严重。若单请求延迟敏感（如对话场景），PP可能导致GPU利用率不足30%。推理优先考虑TP+DP组合，仅在模型超大（如万亿参数）时才引入PP。

复盘案例：某团队部署LLaMA-70B，最初选择TP=8单节点方案，A100×8，batch=64，序列长度2048。实测每卡显存占用：权重17.5GB + KV Cache 24GB + 激活值约6GB = 47.5GB，仍有富余。但AllReduce通信占比达18%，GPU利用率仅72%。后改为TP=4 + DP=2：每卡权重35GB + KV Cache 24GB + 激活值6GB = 65GB，接近80GB上限，但通信占比降至9%，整体吞吐提升22%。该案例说明：在显存允许的前提下，适度降低TP规模、增加DP维度，往往能获得更好的综合吞吐。

总结而言，三种并行策略各有明确的适用边界：数据并行解决吞吐扩展，张量并行解决单层权重超显存，流水线并行解决极深模型的跨节点部署。实际选型需结合模型大小、GPU拓扑、显存余量、延迟要求和并发模式综合判断，并通过TensorRT-LLM的profile工具实测验证，而非机械套用固定模板。