vLLM部署大模型的基准测试

官方文档：Benchmark Suites — vLLM

github官网项目：https://github.com/vllm-project/vllm

硬件状况：4张4090的24G的卡

问：如何完成基准测试

答：如下图所示

如下是脚本的部分内容，全部代码过长无法粘贴（后面我选择了拉取整个vllm项目，这里看看即可）

python benchmark_serving.py
--backend vllm \
--tokenizer /root/autodl-tmp/Qwen/Qwen2___5-Coder-32B-Instruct-GPTQ-Int8\
--dataset /root/LLaMA-Factory/ShareGPT_V3_unfiltered_cleaned_split.json\
--num-prompts 500 \
--request-rate
1 \
--host 127.0.0.1 \
--port 8080\

脚本解释：（只做解释，后面优化了这个启动命令）

启动 benchmark_serving.py 这个python文件中的代码

backend 模式为 vllm 这里对应如下

是发送请求的模式，可以有很多不同的模式

tokenizer 加载模型中的tokenizer

dataset 指定对应的测试数据集

num-prompts 发送请求数量 发送500次请求

request-rate 发送请求的频率，一秒一次

host 发送请求的ip地址

port 发送请求的端口

发现有个包未导入

pip install ASYNC-REQUEST-FUNCS 也失败，也就是说这是一个vllm自己写的包

选择下载完整的vllm项目，问题解决

启动命令增加 --modol 指向模型（后来我发现这只是一个模型名称的参数，并不需要完整的路径） --dataset-name 数据集的格式

启动后，出现NOT FOUND

查看vllm API 后台也是 not found，基准测试的not found 应该是 API返回的

后使用openai 进行了一次请求，仔细对照下发现了不同

基准测试的 请求 base_url:127.0.0.1:8080/v1/completions

openai的 请求 base_url:127.0.0.1:8080/v1/chat/completions

基准测试的请求url是一个老版本的格式，是openai 0.28的格式，非常古老了已经

查看python源码，修改url

出现新的错误：Unprocessable Entity

仔细查看启动命令后和查看backend_request-func.py的源码后，应当将 --backend更改为openai-chat，因为咱们的vllm是部署到openai API上的，访问也是openai的格式

修改后的启动命令

python benchmark_serving.py

--backend openai-chat

--model Qwen2___5-Coder-32B-Instruct-GPTQ-Int8

--tokenizer /root/autodl-tmp/Qwen/Qwen2___5-Coder-32B-Instruct-GPTQ-Int8

--dataset-path /root/LLaMA-Fac

tory/ShareGPT_V3_unfiltered_cleaned_split.json

--dataset-name sharegpt

--num-prompts 500

--request-rate 1

--host 127.0.0.1

--po

rt 8080

成功启动

测试结果：82 / 500 * 100% = 16.4%

GPU状况如下：

修改为两秒一次

97 / 500 * 100% = 19.4%

修改为 4秒一次

105 / 500 * 100 % = 21%

设置输出之后发现，在流式过程中，在响应了一部分之后，就被其他打断了

一秒一次 500次请求

50 / 500 * 100% = 10 %

修改为 规模比较小的 Qwen2-7B-Chat模型

一秒一次 500次 请求

374 / 500 * 100 % = 74.8%

从以上基准测试来看，在使用Qwen2___5-Coder-32B-Instruct-GPTQ-Int8和QwQ-32B-Preview模型进行vllm推理时，模型本身就比较大，外加生成的文本质量高就会带来更多的负担，更改为7B级别的chat模型之后，会有比较高的一个正确率，但是相应的文本质量就会降低，综上vllm启动的OpenAI的APi端口，有不错的稳定性，并不会因为大量的请求出现宕机的情况，但是由于本身算力的限制和迫切生成高质量文本的本能，会导致请求的成功率比较低，换言之，即API的并发性不高。