4. 数据并行推理：数据并行在推理中的应用与局限性
数据并行，这个词大家都不陌生。训练的时候用得最多，对吧？但推理场景下，数据并行到底能不能用、怎么用、坑在哪？今天咱们就好好聊聊这个。
我个人习惯把数据并行推理叫做“无脑加速方案”。为什么这么说？因为它实现起来确实简单——把一批请求拆开，分到多个GPU上，各自跑各自的模型副本，最后汇总结果。但简单归简单，里面的门道可不少。
4.1 数据并行推理的核心思想
说白了，就是“人多力量大”。
你想想看，如果只有一个GPU，一次只能处理一个batch的请求。假设你的模型推理一次需要100ms，那QPS（每秒查询数）撑死了也就10。但如果你有4张GPU，每张卡独立处理不同的请求，理论上QPS就能到40。
这里的关键是：每个GPU上都有一份完整的模型参数副本。它们之间不需要通信，各算各的。这就是数据并行和模型并行最本质的区别。
核心公式：
总吞吐 = 单卡吞吐 × GPU数量（理想情况下）
实际吞吐 = 单卡吞吐 × GPU数量 × 效率系数（通常0.8~0.95）
我在项目中遇到过，有些团队把数据并行推理吹得天花乱坠，结果上线后发现效率系数只有0.6。为什么？后面会讲。
4.2 数据并行推理的典型架构
先看一张图，这是我画的数据并行推理的典型流程：
这张图其实已经说得很清楚了。请求进来后，先经过一个负载均衡器，然后分发到不同的GPU上。每个GPU独立推理，最后把结果返回给客户端。
嗯，这里要注意：负载均衡器怎么分？最简单的就是轮询（Round Robin）。但实际生产中，我建议用最小连接数策略，因为不同请求的推理时间可能不一样，轮询会导致某些GPU忙死、某些闲死。
4.3 数据并行推理的优势
为什么数据并行在推理中这么受欢迎？我总结了几个点：
- 实现简单：不需要改模型结构，不需要切分参数。把模型加载到多张卡上，改一下路由逻辑就行。
- 弹性扩展：流量大了？加卡就行。流量小了？减卡。不像模型并行，加减卡还得重新切分模型。
- 故障隔离：一张卡挂了，其他卡还能继续服务。只是容量下降，不会全挂。
- 延迟稳定：每张卡处理自己的请求，没有跨卡通信，延迟基本稳定。
我的经验：数据并行最适合无状态推理场景。比如文本分类、图像识别、向量化等。对于有状态的服务（比如对话历史依赖），需要额外处理状态同步，复杂度就上去了。
4.4 数据并行推理的局限性
好了，前面说了这么多好处，现在该泼冷水了。数据并行不是万能的，它有明显的天花板。
4.4.1 显存浪费问题
这是最直接的痛点。每张卡都要加载完整的模型参数。如果模型有70B参数，用FP16存，那就是140GB。一张A100才80GB显存，根本放不下。你想想看，这种情况下数据并行根本玩不转。
我曾经见过一个团队，硬要用数据并行部署一个130B的模型。结果呢？每张卡都放不下，只能把batch_size设成1，还频繁OOM。最后老老实实换成了模型并行+流水线并行。
| 模型规模 | 单卡显存需求（FP16） | A100-80G可部署 | 数据并行是否可行 |
|---|---|---|---|
| 7B | ~14GB | 5个副本 | ✅ 非常适合 |
| 13B | ~26GB | 3个副本 | ✅ 适合 |
| 70B | ~140GB | 0个副本 | ❌ 不可行 |
| 130B | ~260GB | 0个副本 | ❌ 不可行 |
4.4.2 通信开销被忽视
有人说数据并行不需要通信。这话对，也不对。
推理过程中确实不需要通信。但别忘了，模型更新呢？如果你的推理服务需要热更新模型参数（比如AB测试不同版本），那所有GPU都得同步更新。这时候通信开销就来了。
我遇到过最坑的一次：一个团队用数据并行部署了8张卡，每次模型更新时，8张卡同时从共享存储加载参数，结果存储带宽被打满，更新耗时从预期的10秒变成了2分钟。期间所有请求都超时了。
避坑指南：我曾经在更新策略上吃过亏。建议使用滚动更新：先更新一半的GPU，等它们稳定后再更新另一半。这样服务不会中断。或者用预热加载，提前把新参数加载到显存中，再原子切换。
4.4.3 负载不均问题
这个其实挺隐蔽的。你以为请求是均匀分配的，但实际呢？
举个例子：你的模型做文本生成。有些请求只生成10个token，有些要生成1024个token。生成10个token的请求10ms就结束了，生成1024个的可能要500ms。如果负载均衡器只是简单轮询，那处理长请求的GPU就会一直被占用，其他GPU却闲着。
说白了，请求的推理时间方差越大，负载不均越严重。
4.4.4 扩展效率递减
加卡一定能线性提升吞吐吗？不一定。
当GPU数量增加时，负载均衡器的压力会变大。如果负载均衡器成了瓶颈，加再多GPU也没用。我见过一个极端案例：32张卡的数据并行集群，负载均衡器用的是单线程的Nginx，结果Nginx先扛不住了，CPU跑到100%，请求排队。
另外，共享资源（比如存储、网络）也会成为瓶颈。所有GPU同时读同一个模型文件，存储带宽够吗？所有GPU同时写日志，日志系统扛得住吗？
4.5 数据并行推理的最佳实践
说了这么多问题，那到底该怎么用数据并行？我分享几个经验：
- 模型规模要匹配：单卡能放下完整模型，这是前提。放不下就别硬上数据并行。
- 使用动态batch：把多个请求拼成一个batch，充分利用GPU的并行计算能力。我习惯设置最大等待时间（比如5ms），超过这个时间不管batch满没满都送进去算。
- 负载均衡要智能：别用简单的轮询。用最小连接数或者加权最小连接数，根据每张卡的实时负载来分配。
- 预热机制：新启动的GPU，先发几个小请求让它"热起来"，再正式接入流量。否则第一次推理会很慢（因为缓存没建立）。
- 监控每张卡的利用率：如果某张卡利用率明显低于其他卡，说明负载均衡有问题，或者请求分布不均匀。
代码示例：动态batch + 数据并行
class DataParallelInference:
def __init__(self, model_path, num_gpus=4):
self.models = []
for i in range(num_gpus):
model = load_model(model_path, device=f'cuda:{i}')
self.models.append(model)
self.request_queue = asyncio.Queue()
self.batch_size = 8
self.max_wait_ms = 5
async def inference(self, request):
# 把请求放入队列
future = asyncio.Future()
await self.request_queue.put((request, future))
return await future
async def batch_processor(self):
while True:
batch = []
# 收集请求，最多等5ms
deadline = time.time() + self.max_wait_ms / 1000
while len(batch) < self.batch_size:
remaining = deadline - time.time()
if remaining <= 0:
break
try:
req, fut = await asyncio.wait_for(
self.request_queue.get(), timeout=remaining)
batch.append((req, fut))
except asyncio.TimeoutError:
break
if not batch:
continue
# 分配到不同的GPU
gpu_id = hash(batch[0][0].id) % len(self.models)
model = self.models[gpu_id]
# 执行推理
inputs = [req for req, _ in batch]
outputs = model(inputs)
# 返回结果
for (_, fut), output in zip(batch, outputs):
fut.set_result(output)4.6 什么时候不该用数据并行
最后，我想说说哪些场景下数据并行不是好选择：
- 超大模型（单卡放不下）：这个不用多说了，物理限制摆在那。
- 请求延迟要求极高：数据并行本身不会降低延迟，但负载均衡和排队会增加额外延迟。如果要求P99延迟<10ms，数据并行可能不是最优解。
- 模型频繁更新：每次更新都要同步所有GPU，如果更新频率很高（比如每分钟一次），同步开销会吃掉大部分收益。
- 单卡吞吐已经足够：如果一张卡就能扛住所有流量，加卡反而增加了系统复杂度。别为了用并行而用并行。
好了，关于数据并行推理，今天就聊到这。记住一句话：数据并行是推理加速的"第一板斧"，但不是万能药。用得好，事半功倍；用不好，事倍功半。