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

General
1

我使用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的），但是平均生成速率变的这么慢

2

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

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

Sources:

3

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

4

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

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

Sources:

5

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

6

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

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

Sources:

7

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

8

详细瓶颈分析思路如下：

  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接近上限，则是显存/并发能力瓶颈。官方指标文档有详细指标说明。

  2. 逐步定位与调优：

    • tokenization瓶颈：小模型/短输入时常见，可通过增加–api-server-count提升tokenizer并发能力。相关讨论
    • prefill瓶颈：长prompt时，prefill阶段耗时远大于decode，建议缩短输入或提升max-num-batched-tokens，充分利用chunked prefill。优化建议
    • KV cache瓶颈：增大gpu-memory-utilization、减少max-model-len、合理设置max-num-seqs，或提升tensor_parallel_size（但注意多卡同步开销）。
    • 调度/并行瓶颈：尝试调整tensor/pipeline/data parallel参数，或升级vLLM版本，利用V1调度优化。
    • 硬件瓶颈：如NUMA架构、无NVLink等，需优化进程绑定或更换硬件。NUMA相关讨论

  3. 具体操作建议：

    • 逐步提升max-num-batched-tokens，观察吞吐变化。
    • 监控e2e latency、TTFT、decode latency等，分析是排队还是生成慢。
    • 用vLLM自带benchmark脚本或Prometheus监控，定位瓶颈点。
    • 若瓶颈在tokenization，可用–api-server-count提升API并发。
    • 若瓶颈在KV cache，适当缩短max-model-len或提升gpu-memory-utilization。
    • 若瓶颈在prefill，优化输入长度或分批处理。

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

Sources: