一、省流，直接看结论 一）参数：两个4090，1000 token的输入，128 token的输出（vllm benchmark默认值） 1. benchmark最高并发请求：60+ 参数：两个4090，1000 token的输入，128 token的输出（vllm benchmark默认值） 2.启用FlashInfer前后对比 启用FlashInfer比默认的PyTorch-native模式的性能提升差不多。 client端统计对比 server端统计对比 用pyplot针对这3次测试跑的3个日志文件生成了一个图。 3.结论 测试1000个请求, 三轮跑下来, 不启用flashinfer总耗时稍长一点点(差10来秒, 459 vs 449).启用flashinfer: 并发请求可达到60左右,但是受限于硬件/GPU, 首字出字速度, 单位输出token时延等数据都会延长。每秒输出的总token数1=125604/448.73=27.99 tps每秒输出的总token数2=125600/449.52=27.32 tps不启用flashinfer: 并发请求在40左右, 但首字出字速度, 单位输出 token时延都会较短.每秒输出的总token数=125604/459.73=27.32 tps 关于flashinfer：从测试结果来看，启用后并没有将这1000个请求的总耗时降下来多少，因此最终还是会受限于硬件/GPU？ 二）参数：两个4090，1000 token的输入，1000 token的输出（会议摘要常规输出） 1.benchmark最高并发请求：约40~50左右 2.启用FlashInfer后数据 合并到上面的表格,具体看FlashInfer3一列数据 3.结论 指定输出token数量从128到1000，对最大并发有影响，全影响不是非常大。每秒输出的总token数=967760/1423.79=67.9 tps。这一段测试是在5点后，快下班时间跑的 二、测试硬件环境 •软件环境：PyTorch 2.6.0、Python 3.12(ubuntu22.04)、Cuda 12.4•硬件环境：￮GPU：RTX 4090(24GB) * […]
vllm
一开始报没安装FlashInfer 启动vllm过程中有一个warning。 那就安装一下FlashInfer 从这个代码上看，应该只要不是0.2.3就可以了。 卸载flashinfer-python 安装一个老一点的0.2.2 重新启动server 终于启用了flashinfer! 但是依旧报警告：TORCH_CUDA_ARCH_LIST is not set 指定TORCH_CUDA_ARCH_LIST为8.9 我用的是4090，所以TORCH_CUDA_ARCH_LIST应该是8.9 重新启动server 成功！
相比于ollama, llama.cpp等框架, vllm是一个可以产品化部署的方案，适用于需要大规模部署和高并发推理的场景，采用 PagedAttention 技术，能够有效减少内存碎片，提高内存利用率，从而显著提升推理速度。在处理长序列输入时，性能优势更为明显。因此，今天先用vllm来验证一下QWQ32B 的情况。 硬件环境 租的AutoDL的GPU服务器做的测试 •软件环境 PyTorch 2.5.1、Python 3.12(ubuntu22.04)、Cuda 12.1 •硬件环境 ￮GPU：RTX 4090(24GB) * 2 ￮CPU：64 vCPU Intel(R) Xeon(R) Gold 6430 ￮内存：480G（至少需要382G） ￮硬盘：1.8T（实际使用需要380G左右） 一、虚拟环境 conda create –prefix=/root/autodl-tmp/jacky/env/vllm python==3.12.3 conda activate /root/autodl-tmp/jacky/envs/vllm/ pip install vllm 二、安装 vLLM export VLLM_VERSION=0.6.1.post1 export PYTHON_VERSION=310 pip install https://github.com/vllm-project/vllm/releases/download/v${VLLM_VERSION}/vllm-${VLLM_VERSION}+cu118-cp${PYTHON_VERSION}-cp${PYTHON_VERSION}-manylinux1_x86_64.whl –extra-index-url https://download.pytorch.org/whl/cu118 三、从huggingface下载模型 计划测试 […]