推理服务的吞吐量不会随着并发数线性增长，而是存在一个明确的拐点：在拐点之前，提升并发能近乎线性地压榨算力；一旦越过拐点，排队延迟与显存争抢会迅速吞噬收益，吞吐曲线掉头向下，甚至引发雪崩。
这个拐点并不神秘,它由三个变量共同决定：算力利用率、显存带宽、请求的显存占用形态，下面直接拆解拐点出现的底层逻辑，以及你在实际部署时该怎么找到它。
推理吞吐为什么会先升后降
你可能遇到过这种情况：把并发从 8 调到 16，吞吐量涨了将近一倍；再调到 32，涨了 30%；继续调到 64，反而跌了 20%，这不是玄学，而是推理引擎在告诉你你已经跨过了拐点。
拐点前的“甜蜜区”：连续批处理带来的红利
推理引擎（vLLM、TensorRT-LLM、SGLang）都用连续批处理（Continuous Batching）来提升吞吐，早期并发低的时候，GPU 每轮调度都能塞满更多的请求，降低了空闲气泡比例，此时每增加一个并发请求，相当于在不额外增加太多延迟的情况下，把空闲的算力卖了出去，所以这一段曲线的斜率很陡，几乎接近线性。
拐点后的“泥潭”：预填充与解码的互相拉扯
一旦并发超过某个阈值,新进入的请求会强制打断正在进行的解码阶段，去执行新请求的预填充（prefill），预填充是密集矩阵乘法，显存带宽消耗极大；而解码阶段是访存密集型，两者混跑时，显存带宽成为唯一的瓶颈，此时你加再多的请求，GPU 也没办法同时服务所有人，反而因为频繁切换，把已有请求的解码效率拖垮了。
影响拐点位置的三个核心参数
同样是 A100，跑 7B 模型的拐点在并发 32，跑 70B 模型的拐点可能在并发 8，原因在于以下三点：
KV Cache 的显存吞噬效应
每个并发请求都要占用一部分显存来存储 KV Cache，并发越高，KV Cache 占用越大，留给计算资源的可用空间就越小，当剩余显存不足以支持一次较大的预填充 batch 时，调度器只能被迫减小 batch size吞吐自然下滑，业内专家指出，KV Cache 与并发数近似线性增长，而算力的增长是片状的，两者一旦相交，拐点就来了。
预填充与解码的算力配比
不同业务的请求平均 tokens 长度差异很大，比如聊天场景，用户输入短、输出长，预填充压力小，拐点会往后移；而文档摘要场景，输入极长，预填充成为主战场，拐点会大幅前移，你可以通过调整
max_num_batched_tokens 和 max_num_seqs 这两个参数，人为改变拐点的位置。
并发压力下的调度策略
贪心调度和高优先级抢占策略会在高并发时造成明显的“头部效应”先来的大请求占住资源，后续的小请求全部排队，这时吞吐量数字可能仍然平稳，但 TTFT（首 token 延迟）会突然飙升，你的外部体验已经挂掉了。
找拐点：一套直接可用的压测路径
与其背理论,不如动手打一次压，以下方法适用于绝大多数自建推理服务，也能用于云厂商的 GPU 服务器（比如简米云 PAI、酷番云 TI 平台）。
第一步：固定输入输出 token 长度
用镜像请求或者自定义数据集,把输入长度固定在 512 tokens，输出长度固定在 256 tokens，不要用真实流量的混合长度做首次定位，否则你区分不了是长度导致的下滑，还是并发导致的拐点。
第二步：逐档加并发，记录三组数据
从并发 1 开始，按 1、2、4、8、12、16、20、24、32、40、48、64 逐档增加，每个档位运行 5 分钟，等吞吐稳定后再记录，你需要盯住三组指标：
- 吞吐量（tokens/s，包括预填充和解码两部分）
- TTFT 的平均值与 P99（首 token 延迟）
- GPU 显存利用率与 SM 占用率
第三步：找“吞吐拐点”和“延迟拐点”
把数据画成折线图,你会看到两个拐点：
- 吞吐拐点：吞吐曲线从上升转为平缓或下降的那个点，这就是你系统的最大有效并发。
- 延迟拐点：P99 TTFT 开始急剧变大的那个点，它通常比吞吐拐点来得更早，所以你的实际并发上限，要取这两个拐点中的较小值。
并发 吞吐(tokens/s) P99 TTFT(ms)
1 1200 50
8 8500 72
16 14800 110
24 19100 260
32 18500 980 // 拐点明显
40 16800 2100上表就是一个典型的测试结果：并发 24 到 32 之间，吞吐只涨了不到 5%，而 TTFT 涨了近 4 倍，那你的生产环境就应该把并发控制在 24 左右，而不是 32。
拐点之后怎么抢救：三个实操方向
如果你已经测出了拐点,但业务流量又要求你必须扛住，怎么办？别硬扛，下面三条路可以选。
扩容 + 分片，而不是只堆并发
单卡有物理上限,但你可以把推理请求按模型分片或者按业务优先级分流，比如一个 7B 模型在单卡上拐点是 32，那你就用两张卡各跑 32，总吞吐直接翻倍，同时用负载均衡把新请求轮询到压力较小的卡上，避免某张卡先撞墙。
打开请求级抢占和队列优先级
vLLM 支持在 API Server 层配置请求的 priority 字段，你可以把交互式请求的优先级调高，把离线批处理请求的优先级调低，这样即使在并发过冲的时候，用户的对话响应也不会被慢任务拖死，吞吐数字不好看，但业务感知正常。
减少单请求的 KV Cache，采用 PagedAttention
PagedAttention 在 vLLM 中是默认开启的，但你需要检查是否禁用了 enable_prefix_caching，打开前缀缓存后，相同前缀的请求可以共享 KV Cache，相当于把每个请求的显存占用砍半，拐点自然右移，对于多轮对话场景，这个优化尤其明显。
不同硬件上的拐点差异
你在采购服务器或者租 GPU 的时候，经常会听人问：“A100 能撑多少并发？”这个问题本身就不严谨，拐点受制于显存带宽和显存容量，而这两者在不同卡上差异巨大。
| 硬件型号 | 显存带宽 | 7B 模型典型拐点范围 | 备注 |
|---|---|---|---|
| RTX 4090 | ~1TB/s | 并发 8-16 | 适合低负载原型验证 |
| A100 80G | ~2TB/s | 并发 24-40 | 生产环境最常见 |
| H100 80G | ~3.3TB/s | 并发 40-64 | 高吞吐场景首选 |
| 华为昇腾910B | ~1.2TB/s | 并发 16-24 | 国产卡优化需要额外调参 |
注意,上表只是经验范围，实际拐点取决于你的 input/output 长度，如果你的请求输出特别长（比如生成 2000 tokens 的代码），H100 的拐点也可能降到 20 以下。
什么时候你真的需要关注拐点
不是所有团队都需要懂这套东西,如果你只是跑了几个 demo，或者 QPS 常年低于 1，那拐点离你很遥远，但以下三种情况，建议你认真做一次压测：
- 你的推理服务在高峰时段出现大量 503 或超时，但 GPU 利用率显示才 40%
- 你要买新机器，但预算有限，需要在“买 3 张中端卡”和“买 1 张高端卡”之间做选择
- 你的产品出海到东南亚或欧洲等地域，这些区域用热门型号 GPU 的计费方式差别较大，通过压测确定拐点，能精确计算单 token 的成本
如果你用的 GPU 服务器是按量付费（比如按小时计费），那么把并发控制在拐点附近，能最大化单位时间的有效产出，亏本还是赚钱，看的就是你有没有在拐点上运行。
推理服务在高并发下还要盯住另一个隐藏指标
除了吞吐曲线本身,GPU 功耗墙也会在高并发时干扰你的判断，很多云厂商的实例会限制整机功耗，当并发超过拐点后，GPU 核心频率可能主动下降 15%-20%，导致吞吐进一步下跌，这时候你观察到的拐点，其实是“算力降频”和“显存争抢”的叠加效果，解决的办法比较直接：在压测时记录 nvidia-smi 里面的温度与功耗曲线，如果发现 30 秒内有效功耗持续接近上限，那就说明你已经撞到了功耗墙，需要重新评估机型的散热能力或者降低并发目标。
关于推理吞吐的常见疑问
以下两个问题经常出现在技术社区和搜索词里,这里直接给出结论。
推理吞吐和并发是不是越高越好？
不是,并发过高会导致预填充过度抢占资源，反而让整体吞吐下降，真正健康的指标是 单位时间完成的 request 数量，而不是同时挂起的 request 数量，当你的吞吐曲线开始走平，就说明并发已经饱和，再往上加只是徒增排队延迟。
为什么我换了更大的显存卡，拐点还是没变？
因为大显存卡通常只是提升了 KV Cache 的容量上限，并没有同比例提升显存带宽，如果你的模型参数量不变，但请求的上下文长度很长，那么限制你吞吐的实际上是带宽，容量再大也只是把崩溃点推迟了一小段，这时候更应该关注显存带宽接近满载的百分比，而不是可用显存的剩余值。
从长期实践看,推理服务的吞吐优化永远在“算力利用率”和“显存带宽消耗”之间找平衡，更直白地说，你不需要把并发调到最大，你只需要找到那个吞吐不再上涨、延迟还不算离谱的临界点，然后稳在那里，把这个值写进你的配置模板，再配合自动扩缩容，你的推理服务就不会在流量洪峰中翻车。