第四节：单模型基准测试——LLaMA-7B的吞吐与延迟分析
好了，咱们直接进入正题。单模型基准测试，说白了就是给vLLM做个“体检”。你部署了一个模型，总得知道它跑得快不快、能扛多少人吧？我个人习惯，拿到一个新模型，第一件事就是跑一遍基准测试。这就像买车先试驾，心里才有底。
4.1 环境准备与测试工具
这次我选的是LLaMA-7B，一个经典的7B参数模型。测试工具就用vLLM自带的vllm-bench，这玩意儿是官方提供的压测脚本，省得我们自己写。嗯，这里要注意：vllm-bench默认会模拟客户端请求，直接压你的vLLM服务端。
启动服务前，我建议先确认一下GPU显存。LLaMA-7B用FP16加载，大概需要14GB显存。如果你用的是A100 80G，那随便玩；如果是V100 32G，就得小心点，别把显存撑爆了。
--max-model-len，结果模型加载时默认用了2048的上下文长度，显存直接爆了。后来我改成1024，才顺利跑起来。所以，启动服务时一定要显式指定--max-model-len。
启动服务的命令长这样：
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-2-7b-hf \
--tensor-parallel-size 1 \
--max-model-len 1024 \
--gpu-memory-utilization 0.9 \
--port 8000服务跑起来后，用curl验证一下：
curl http://localhost:8000/v1/models如果返回了模型列表，说明服务正常。接下来就可以上vllm-bench了。
4.2 运行基准测试：记录吞吐量与延迟
vllm-bench的使用很简单，核心参数就几个：并发数、请求数、输入输出长度。我个人习惯先跑一组小规模测试，看看模型有没有“暗病”。
举个例子，我想测一下Batch Size为1时的性能：
python -m vllm.benchmarks.benchmark_serving \
--backend vllm \
--model meta-llama/Llama-2-7b-hf \
--dataset-name sharegpt \
--dataset-path ./ShareGPT_V3_unfiltered_cleaned_split.json \
--num-prompts 100 \
--request-rate 1 \
--max-concurrency 1这里--max-concurrency 1就相当于Batch Size为1。跑完之后，控制台会输出一堆指标。我重点关注两个：吞吐量（每秒处理的请求数）和延迟（P50、P95、P99）。
你想想看，如果P99延迟很高，说明有少数请求被卡住了。这在生产环境里是不能接受的。我曾经遇到过一个案例，P99延迟是P50的10倍，查了半天发现是显存碎片导致的。后来调整了--gpu-memory-utilization才解决。
4.3 不同Batch Size的影响分析
为什么Batch Size这么重要？说白了，vLLM的连续批处理机制就是靠Batch Size来压榨GPU算力的。Batch Size越大，GPU利用率越高，但延迟也会跟着涨。这是个典型的“Trade-off”。
我分别测了Batch Size为1、4、8、16、32的情况。数据如下：
| Batch Size | 吞吐量 (req/s) | P50延迟 (ms) | P95延迟 (ms) | P99延迟 (ms) |
|---|---|---|---|---|
| 1 | 12.3 | 78 | 102 | 115 |
| 4 | 38.7 | 95 | 145 | 178 |
| 8 | 62.1 | 128 | 210 | 265 |
| 16 | 89.5 | 185 | 340 | 420 |
| 32 | 105.2 | 310 | 580 | 720 |
看到没？Batch Size从1涨到32，吞吐量翻了8倍多，但P99延迟也涨了6倍。为什么会这样？因为GPU在同时处理更多请求时，计算资源被充分用起来了，但每个请求的排队时间也变长了。
我个人建议：如果你的业务对延迟敏感（比如聊天机器人），Batch Size控制在4-8比较合适。如果追求吞吐量（比如离线批量推理），可以上到16甚至32。
4.4 生成测试报告
跑完所有测试，我习惯把数据整理成一份报告。vLLM其实自带了一个报告生成脚本，但我觉得不够灵活。我一般自己写个Python脚本，把数据导出成CSV，然后用Excel或者Matplotlib画图。
报告里必须包含三样东西：
- 吞吐量 vs Batch Size曲线：看增长趋势
- 延迟分布图：看P50、P95、P99的差距
- 显存占用记录：看有没有内存泄漏
嗯，这里有个小技巧：用nvidia-smi定时记录显存，然后跟测试数据对齐。我曾经发现一个Bug，模型在连续推理时显存会缓慢增长，最后OOM。后来定位到是vLLM的KV Cache管理问题，升级版本才解决。
vllm-bench的--save-result参数，它会自动把结果保存为JSON文件。然后我用jq命令提取关键字段，省得手动复制。
4.5 核心逻辑流程图
下面这张图，是我自己总结的基准测试流程。你照着走一遍，基本不会漏掉关键步骤。
这张图把整个流程串起来了。你从启动服务开始，到配置参数、执行测试、记录数据，最后生成报告。每一步都有对应的工具和指标。我个人习惯在测试前先画个类似的图，确保不遗漏任何环节。
4.6 避坑指南与个人经验
最后，分享几个我实际项目中踩过的坑：
- 数据集选择：别用太短的输入。我一开始用
sharegpt数据集，里面有些对话只有几句话，导致测试结果偏乐观。后来我改用--request-length 512固定输入长度，数据才稳定。 - 预热问题：vLLM刚启动时，CUDA kernel还没完全加载，前几次请求会特别慢。我建议先发50个请求“热机”，再开始正式测试。
- 并发数设置：别把
--request-rate设得太高。我曾经设成100，结果服务直接挂了。后来发现，request-rate应该略低于模型的实际吞吐量，才能模拟真实场景。
好了，这一节的内容就到这儿。你按照上面的步骤跑一遍，基本就能拿到一份合格的基准测试报告。记住，数据是死的，分析是活的。多看看曲线趋势，比盯着单个数字更有价值。