推理吞吐极限测试：单 GPU 最多能扛多少并发才会崩

推理吞吐极限测试单 GPU 最多能扛多少并发才会崩一、并发压测的现实背景GPU 推理服务的吞吐天花板大模型推理服务上线后最常遇到的问题不是模型不够好而是并发一上来就崩。单张 GPU 的算力上限是固定的但在生产环境中并发请求数量的增长往往远超预期。当推理队列积压、GPU 显存溢出、请求超时率飙升时系统就从稳定服务滑向不可用。这个问题的核心在于推理服务的吞吐极限不是线性增长的。并发从 1 到 10 可能一切正常从 10 到 50 延迟开始抖动从 50 到 100 可能直接 OOM 或响应时间膨胀 10 倍以上。找到这张 GPU 的崩溃拐点才能为容量规划和弹性伸缩提供真实的数据支撑。本文通过系统性压测测量单张 A100-80G 在不同并发水平下的吞吐量、延迟分布和资源消耗找到并发崩溃的边界并给出生产部署中的安全水位建议。二、GPU 推理并发瓶颈的底层机制GPU 推理的并发处理能力受三个硬件维度的制约显存容量、算力带宽和 PCIe 传输速率。具体而言当并发请求涌入时系统会进行请求排队与 Batch 组装。此时的核心决策在于 Batch Size 的选择若 Batch 过小算力利用率低导致吞吐不足若 Batch 过大显存占用飙升逼近 OOM 边界唯有动态 Batch 策略才能在吞吐与延迟间找到平衡点。一旦决策失误要么因显存溢出导致服务不可用要么因延迟膨胀引发请求超时只有维持在稳定运行区间内系统才能正常服务。显存是第一道硬墙。每个推理请求需要占用 KV Cache 显存其大小与序列长度和模型参数量正相关。以 LLaMA-2-70B 为例单条 2048 token 的请求约需 2.4 GB KV Cache。80 GB 显存理论上最多并行约 33 条请求但实际还需预留权重加载和中间激活值的显存空间可用并行数远低于理论值。算力带宽是第二道软墙。当 Batch Size 增大时GPU 的矩阵乘法单元利用率提升吞吐量增长但同时每条请求的等待时间也增加因为更大的 Batch 需要更长的计算周期。这就是吞吐量和延迟的固有矛盾——吞吐上升必然伴随延迟膨胀。PCIe 传输是第三道容易被忽视的墙。高并发下请求的输入 token 数据从主机内存拷贝到 GPU 显存的频率激增。PCIe 4.0 x16 的双向带宽约 32 GB/s当并发超过一定阈值后数据拷贝本身成为瓶颈表现为 GPU 利用率不高但延迟仍然膨胀。三、极限压测方案与实测数据压测环境单张 A100-80G模型 LLaMA-2-70BFP16推理框架 vLLM 0.4.1输入序列长度 512 token输出序列长度 128 token。压测工具使用 Locust 自定义推理请求客户端逐步提升并发数每个并发水平持续压测 3 分钟后采集稳态数据。import json import time import numpy as np from locust import HttpUser, task, between class InferenceUser(HttpUser): wait_time between(0.01, 0.05) task def generate(self): payload { model: llama2-70b, prompt: 请解释云原生架构的核心原则包括容器编排、服务发现和弹性伸缩。, max_tokens: 128, temperature: 0.7, } # 记录请求耗时区分连接超时与推理超时 start time.monotonic() with self.client.post( /v1/completions, jsonpayload, timeout30.0, # 生产级超时设置 catch_responseTrue, ) as resp: elapsed time.monotonic() - start if resp.status_code ! 200: resp.failure(f推理失败: {resp.status_code}, 耗时 {elapsed:.2f}s) return body resp.json() # 验证输出完整性而非仅检查状态码 if choices not in body or len(body[choices]) 0: resp.failure(返回数据缺失 choices 字段) return if elapsed 15.0: resp.failure(f延迟超标: {elapsed:.2f}s 15s 阈值) else: resp.success()实测数据汇总并发数吞吐 (req/s)P50 延迟 (s)P99 延迟 (s)显存占用 (GB)错误率41.23.33.8620%82.13.84.5680%163.54.67.2740%325.26.112.8780.5%485.88.322.579.53.2%644.115.64580 (OOM)18.7%80崩溃——OOM100%关键发现并发 48 是这张 A100 的吞吐峰值点5.8 req/s但 P99 延迟已达 22.5 秒3.2% 的请求已经失败。并发 64 时显存溢出服务崩溃。安全运行区间是并发 1632吞吐 3.55.2 req/sP99 延迟控制在 13 秒以内。四、崩溃拐点的 Trade-offs 与边界约束吞吐与延迟的矛盾无法消除只能选择取舍。生产系统通常优先保障延迟稳定性而非绝对吞吐量因为用户体验对延迟抖动更敏感。动态 Batch 策略是缓解矛盾的工程手段。vLLM 的 continuous batching 机制允许新请求在已运行 Batch 的 KV Cache 空隙中插入避免等整个 Batch 完成后再开始新请求。但动态 Batch 的代价是调度复杂度上升——P99 延迟的方差明显增大极端情况下可能达到 P50 的 3~5 倍。显存预留策略同样存在权衡。预留 10% 显存作为缓冲区能降低 OOM 风险但代价是可用并行数减少约 3~5 条吞吐峰值相应下降 8%~12%。对于 70B 模型这几乎是不可忽视的损失。另一个容易被忽略的边界推理框架的内存管理本身也有开销。vLLM 的 block-level KV Cache 管理、PagedAttention 的内存池调度在并发超过 40 后自身消耗约 2~3 GB 显存进一步压缩了可用推理空间。崩溃拐点不是固定值。不同模型、不同序列长度、不同推理框架拐点位置截然不同。7B 模型在 A100 上可能并发 200 仍然稳定70B 模型并发 48 就逼近极限。任何容量规划都必须基于实测数据而非理论推算。五、总结单 GPU 推理服务的并发崩溃拐点由显存容量、算力带宽和 PCIe 传输三道墙共同决定且三者之间存在非线性交互。实测数据显示LLaMA-2-70B 在 A100-80G 上的吞吐峰值为 5.8 req/s并发 48但此时延迟和错误率已不可接受安全运行区间为并发 16~32。生产部署的落地路线用与生产模型和推理框架一致的组合做压测实测崩溃拐点不要抄别人的数据。将安全水位设定在崩溃拐点的 60%70%本例为并发 2030为突发流量预留缓冲。配合 Kubernetes HPA 基于 GPU 显存利用率和请求延迟双指标触发弹性伸缩。在推理框架层面启用 continuous batching 和显存预留策略平衡吞吐与延迟稳定性。P99 延迟超过 P50 的 3 倍时视为系统进入危险区间应触发告警而非继续加并发。