# Vllm处理长输入性能变差讨论

**URL:** <https://discuss.vllm.ai/t/vllm/1465>\
**Category:** General\
**Created:** [August 27, 2025, 12:11pm UTC](https://discuss.vllm.ai/t/vllm/1465 "2025-08-27T12:11:30Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![wanghua11haiyouma](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/wanghua11haiyouma/32/650_2.png) [@wanghua11haiyouma](https://discuss.vllm.ai/u/wanghua11haiyouma)\
**Post date:** [August 27, 2025, 12:11pm UTC](https://discuss.vllm.ai/t/vllm/1465/1 "2025-08-27T12:11:30Z")

</div>

我使用vllm+Qwen32B+tp2+h800，输入63K（长输入），输出1K，进行性能评估

压测并发100的时候，平均生成速率20token/s（平均生成速率=生成总token/总耗时），吞吐是1000token/卡/s（=100\*20/2）；

压测并发40的时候，平均生成速率是22token/s，吞吐是440token/卡/s（=40\*22/2）；

单独请求的时候平均生成速率是40token/s，为啥40并发的时候并发没有打满（是小于100的），但是平均生成速率变的这么慢

---

<div class="post-metadata">

**Author:** ![RunLLM](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/runllm/32/233_2.png) [@RunLLM](https://discuss.vllm.ai/u/RunLLM)\
**Post date:** [August 27, 2025, 12:12pm UTC](https://discuss.vllm.ai/t/vllm/1465/2 "2025-08-27T12:12:34Z")

</div>

我的理解是，vLLM在长输入（如63K tokens）和高并发（如100并发）场景下，单请求生成速度（如40 token/s）会因并发增加而下降（如降到20~22 token/s），整体吞吐（如1000 token/卡/s）也未线性提升。这种现象在社区报告中较常见，主要原因可能包括KV cache占用、调度瓶颈、tokenization和prefill阶段的资源竞争等，尤其是长prompt下prompt阶段耗时显著，影响后续生成速度。据[Qwen2.5-VL官方性能评测](https://docs.vllm.ai/projects/recipes/en/latest/Qwen/Qwen2.5-VL.html)和相关[社区讨论](https://github.com/vllm-project/vllm/issues/1315)，并发数提升时，单请求速度下降、吞吐未线性增长是预期现象。

如果你发现40并发时并未打满GPU，但生成速度仍远低于单请求，建议关注max-num-seqs、max-num-batched-tokens等参数设置，或检查tokenization是否成为瓶颈。长prompt下，prompt阶段会阻塞后续生成，导致整体吞吐下降，这在[社区issue](https://github.com/vllm-project/vllm/issues/1026)中有详细分析。你需要更详细的调优建议或参数设置说明吗？

Sources:

- [长prompt阻塞分析](https://github.com/vllm-project/vllm/issues/1026)
- [Qwen2.5-VL官方性能评测](https://docs.vllm.ai/projects/recipes/en/latest/Qwen/Qwen2.5-VL.html)
- [社区讨论](https://github.com/vllm-project/vllm/issues/1315)

---

<div class="post-metadata">

**Author:** ![wanghua11haiyouma](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/wanghua11haiyouma/32/650_2.png) [@wanghua11haiyouma](https://discuss.vllm.ai/u/wanghua11haiyouma)\
**Post date:** [August 27, 2025, 12:17pm UTC](https://discuss.vllm.ai/t/vllm/1465/3 "2025-08-27T12:17:38Z")

</div>

如果40并发已经有瓶颈，为啥增加更多的并发，比如100并发，平均生成速率没有什么改变

---

<div class="post-metadata">

**Author:** ![RunLLM](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/runllm/32/233_2.png) [@RunLLM](https://discuss.vllm.ai/u/RunLLM)\
**Post date:** [August 27, 2025, 12:18pm UTC](https://discuss.vllm.ai/t/vllm/1465/4 "2025-08-27T12:18:19Z")

</div>

这是vLLM在高并发下的典型瓶颈现象：当40并发已达到系统瓶颈时，继续提升到100并发，平均生成速度不会明显提升，甚至可能持平或下降。根本原因通常是GPU KV cache、tokenization、prefill阶段或调度能力已饱和，导致新请求只能排队等待，无法并行加速，详见[官方优化文档](https://docs.vllm.ai/en/latest/performance/optimization.html)和[社区相关讨论](https://github.com/vllm-project/vllm/issues/13508)。

此时，提升并发数只会增加排队延迟，不会提升吞吐。建议通过监控GPU利用率、KV cache占用、pending/running请求数等指标，定位瓶颈环节，并尝试调整max-num-seqs、max-num-batched-tokens等参数，或优化输入长度、模型并行度。如需详细调优建议，请告知。

Sources:

- [官方优化文档](https://docs.vllm.ai/en/latest/performance/optimization.html)
- [社区相关讨论](https://github.com/vllm-project/vllm/issues/13508)

---

<div class="post-metadata">

**Author:** ![wanghua11haiyouma](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/wanghua11haiyouma/32/650_2.png) [@wanghua11haiyouma](https://discuss.vllm.ai/u/wanghua11haiyouma)\
**Post date:** [August 27, 2025, 12:19pm UTC](https://discuss.vllm.ai/t/vllm/1465/5 "2025-08-27T12:19:33Z")

</div>

100并发相比40并发生成速率上没有明显降低，如果达到系统瓶颈，100并发生成速率正常会降低吧

---

<div class="post-metadata">

**Author:** ![RunLLM](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/runllm/32/233_2.png) [@RunLLM](https://discuss.vllm.ai/u/RunLLM)\
**Post date:** [August 27, 2025, 12:19pm UTC](https://discuss.vllm.ai/t/vllm/1465/6 "2025-08-27T12:19:57Z")

</div>

是的，理论上如果系统已达瓶颈，继续提升并发（如从40到100）时，单请求生成速度（token/s）会下降，整体吞吐也不会提升，甚至可能略降。这是因为新请求只能排队，资源已被占满，详见[官方优化文档](https://docs.vllm.ai/en/latest/performance/optimization.html)。

但在实际测试中，如果100并发与40并发时单请求生成速度几乎无变化，说明瓶颈主要体现在排队延迟上，而不是每个请求的生成速率。此时，系统已无法并行处理更多请求，增加并发只会让更多请求等待。需要更详细的瓶颈分析方法吗？

Sources:

- [官方优化文档](https://docs.vllm.ai/en/latest/performance/optimization.html)

---

<div class="post-metadata">

**Author:** ![wanghua11haiyouma](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/wanghua11haiyouma/32/650_2.png) [@wanghua11haiyouma](https://discuss.vllm.ai/u/wanghua11haiyouma)\
**Post date:** [August 27, 2025, 12:24pm UTC](https://discuss.vllm.ai/t/vllm/1465/7 "2025-08-27T12:24:01Z")

</div>

希望给出更详细的瓶颈分析思路和方案～～～

---

<div class="post-metadata">

**Author:** ![RunLLM](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/runllm/32/233_2.png) [@RunLLM](https://discuss.vllm.ai/u/RunLLM)\
**Post date:** [August 27, 2025, 12:25pm UTC](https://discuss.vllm.ai/t/vllm/1465/8 "2025-08-27T12:25:00Z")

</div>

详细瓶颈分析思路如下：

1. **监控关键指标** ：通过Prometheus或日志，重点关注GPU利用率、KV cache占用、pending/running请求数、max-num-seqs/max-num-batched-tokens设置、tokenization耗时、prefill与decode阶段耗时等。若GPU利用率未满、KV cache占用低但pending多，说明调度或tokenization是瓶颈；若GPU利用率高、KV cache接近上限，则是显存/并发能力瓶颈。[官方指标文档](https://docs.vllm.ai/en/latest/design/metrics.html)有详细指标说明。

2. **逐步定位与调优** ：

3. **具体操作建议** ：

如需具体参数调优或监控脚本示例，请告知。

Sources:

- [官方指标文档](https://docs.vllm.ai/en/latest/design/metrics.html)
- [优化建议](https://docs.vllm.ai/en/latest/performance/optimization.html#performance-tuning-with-chunked-prefill)
- [tokenization瓶颈讨论](https://github.com/vllm-project/vllm/issues/22048)
- [NUMA相关讨论](https://github.com/vllm-project/vllm/issues/16444)

---

<div class="post-metadata">

**Author:** ![neweyes](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.vllm.ai/neweyes/32/928_2.png) [@neweyes](https://discuss.vllm.ai/u/neweyes)\
**Post date:** [November 19, 2025, 1:02am UTC](https://discuss.vllm.ai/t/vllm/1465/9 "2025-11-19T01:02:37Z")

</div>

不光是vllm，就算是基于cpu的多线程/进程编程也不是线程和进程数量越多越好。达到上限后继续增加压力只会让资源竞争加剧，请求都被阻塞堆积。要不tcp里面怎么会有拥塞控制机制呢
