vLLM 推理引擎性能分析基准测试

vLLM 推理引擎性能分析基准测试

引用

CSDN

1.

https://blog.csdn.net/qq_36221788/article/details/142982659

本文将介绍vLLM推理引擎在不同参数设置下的性能表现，重点关注--enable-chunked-prefill和--max-num-batched-tokens这两个关键参数对系统性能的影响。通过详细的基准测试和数据分析，我们将揭示这些参数如何影响模型的响应时间和吞吐量。

测试环境与方法

在开始测试之前，我们需要设置环境变量VLLM_TORCH_PROFILER_DIR来保存追踪文件。以下是启动vLLM服务的基本命令：

docker run --runtime nvidia --gpus all \
    -v /data1/data_vllm:/data \
    -p 8001:8000 \
    -e VLLM_TORCH_PROFILER_DIR=/data/mnt/traces/ \
    --name qwen_llm_3 \
    --ipc=host \
    swr.cn-east-3.myhuaweicloud.com/kubesre/docker.io/vllm/vllm-openai \
    --model /data/Qwen2.5-72B-Instruct-GPTQ-Int4 \
    --max-model-len 102400

接下来，使用benchmarks/benchmark_serving.py脚本进行性能测试：

/usr/bin/python3 vllm/benchmarks/benchmark_serving.py --backend vllm --model /data/Qwen2.5-72B-Instruct-GPTQ-Int4 --dataset ShareGPT_V3_unfiltered_cleaned_split.json --profile

测试案例描述

本案例主要分析--enable-chunked-prefill的启用/禁用以及--max-num-batched-tokens参数的调整对性能的影响情况。参数描述请参考官方文档：https://docs.vllm.ai/en/stable/models/performance.html#chunked-prefill

测试数据集

测试数据集来自GitHub上的公开数据集：https://github.com/vllm-project/vllm/blob/main/benchmarks/README.md

测试结果分析

启用chunked-prefill的测试

我们进行了多轮测试，每次调整--max-num-batched-tokens的值，从64到8192不等。以下是关键发现：

• 当--max-num-batched-tokens较小时（<512），prefill阶段耗时较长，但decode阶段速度较快。
• 当--max-num-batched-tokens较大时（>=512），prefill阶段耗时缩短，但decode阶段耗时增加。
• 在本测试集中，当--max-num-batched-tokens超过2048时，prefill和decode阶段的耗时几乎无波动。

禁用chunked-prefill的测试

在禁用chunked-prefill的情况下，我们观察到以下现象：

• 当--max-num-batched-tokens设置过小（<=512），部分请求会因上下文长度超出限制而失败。
• 当--max-num-batched-tokens设置较大（>=2048），prefill阶段的耗时几乎一致。

数据可视化分析

以下是关键指标的可视化结果：

总览-耗时&吞吐量

• 除了开启--enable-chunked-prefill且--max-num-batched-tokens设置较小时会影响总耗时，其他情况几乎无差别。
• --max-num-batched-tokens设置越小，触发chunked-prefill情况越多，prefill耗时大于decode阶段带来的耗时收益，导致总耗时变长。

Time To First Token (TTFT)

• 启用--enable-chunked-prefill时，--max-num-batched-tokens<512时，值越大，prefill耗时越长。
• --max-num-batched-tokens>=512之后，prefill耗时相差不大，这可能与测试数据集中的长文本请求较少有关。

Time per Output Token (TPOT)

• 启用--enable-chunked-prefill时，--max-num-batched-tokens越短，就越快将序列送去decode，耗时就越短。

Inter-token Latency (ITL)

• 都是decode阶段，它和TPOT走势是一致的。

结论

1. 测试数据集对测试情况影响较大，该测试集为官方提供的1000例无长文本（上下文基本在512内）的测试集，生产调优需要根据场景进行重新分析。
2. --enable-chunked-prefill如果开启，--max-num-batched-tokens的大小设置会影响总耗时和吞吐量：

• 如果设置的过小（<256），该值越小耗时越长。
• 如果设置>=256时，耗时和吞吐量几乎无影响。

3. 相比总耗时和吞吐量，--enable-chunked-prefill如果开启，--max-num-batched-tokens的大小设置对prefill和decode两阶段耗时影响较大：

• --max-num-batched-tokens设置越大，prefill阶段耗时越短，decode阶段耗时越长；相反值越小，decode阶段耗时越短，prefill阶段耗时越长。
• 但--max-num-batched-tokens超过一定值时（本测试集超过2048时），两者几乎无波动。

4. --enable-chunked-prefill如果未开启，请求上下文长度会受限于--max-num-batched-tokens的设置，如果值设置的较小，则上下文大于该值的请求将会请求失败。
5. 测试过程中其他结论：

• --max-num-batched-tokens设置的值需要大于模型上下文长度--max-model-len。
• --max-num-batched-tokens需要大于batched的序列（请求）数量--max-num-seqs。
• --max-num-batched-tokens的设置还会受到机器可用显存（乘以--gpu-memory-utilization）限制，因为KV-Cache大概需要占用的最大显存大小公式如下：

  KV_cache_size = 2 * n_layers * n_heads * seq_length * d_head * precision * batch_size
  

  这个公式是用来估算Transformer模型中KV缓存大小的。下面是公式中每个参数的详细解释：
• 2：这个系数是因为每个注意力头都有两个张量需要被缓存：键（Key）和值（Value）张量。所以，对于每个头，我们都需要存储两个张量的内存。
• n_layers：模型中注意力层的总数。在Transformer模型中，每个编码器或解码器块通常包含一个自注意力层，所以这个数字通常等于模型的块数。
• n_heads：每个注意力层中注意力头的数量。在多头自注意力（Multi-Head Attention）机制中，模型会将注意力机制分割成多个“头”，每个头学习序列的不同部分。
• seq_length：序列的最大长度。这是模型在单次推理中可以处理的输入序列的最大长度，包括提示（prompt）和生成的补全部分（completion）。
• d_head：每个注意力头的隐藏维度。这是每个头中键和值张量的维度大小。
• precision：数据的精度，它决定了每个参数需要多少字节来存储。常见的精度包括：
• FP32（单精度浮点数）：4字节/参数
• FP16（半精度浮点数）：2字节/参数
• INT8（8位整数）：1字节/参数
• batch_size：批处理大小，即模型一次推理中同时处理的序列数量。