LLaMA-Factory中vLLM安装与推理速度实测
LLaMA-Factory中vLLM安装与推理速度实测
在大模型落地的工程实践中，一个常被低估却至关重要的问题浮出水面：为什么训练好的模型一上线就“卡成幻灯片”？
我们见过太多这样的场景——本地测试时响应流畅，可一旦接入真实用户请求，系统立刻陷入高延迟、频繁OOM（显存溢出）的窘境。究其根源，并非模型本身的问题，而是推理后端扛不住压力。
HuggingFace Transformers 固然强大，但它的默认推理模式为每个请求分配固定长度的 KV Cache，批处理也依赖静态 batching，面对变长输入和突发流量时显得力不从心。尤其在单卡部署、资源受限的边缘环境中，这种低效尤为致命。
有没有一种方式，能让7B级别的模型在消费级显卡上跑出“类服务级”的吞吐表现？答案是：vLLM + LLaMA-Factory 的组合拳。
为什么 vLLM 能破局？
传统推理引擎的瓶颈，本质上是显存管理和计算调度的双重失效。而 vLLM 的设计思路很像现代操作系统的内存管理——它把 KV Cache 当作虚拟内存页来处理。
这就是 PagedAttention 的核心思想：不再为每个序列一次性预分配完整的 attention 缓存，而是将其切分为多个“页面”，按需加载、动态拼接。这样一来，即使两个请求的上下文长度相差十倍，它们也能共享同一块物理显存空间，极大提升了利用率。
更进一步，vLLM 实现了真正的 连续批处理（Continuous Batching）。想象一下，传统批处理就像公交车发车——必须等满员才启动；而 vLLM 则像是地铁，乘客随时上下，列车持续运行。哪怕某个长文本还在逐字生成，新来的短请求也能立即插入并开始推理，GPU 几乎没有空转时间。
官方宣称“5~10倍吞吐提升”听起来夸张，但在合适场景下完全可期。我们的目标很明确：用真实微调模型，在 RTX 4090 上验证这一性能跃迁是否成立。
环境配置：别让依赖毁了你的实验
实验平台如下：
| 组件 | 版本 |
|---|---|
| GPU | NVIDIA RTX 4090 (24GB) |
| CUDA | 12.6 |
| Python | 3.10 |
| PyTorch | 2.3.1+cu126 |
| LLaMA-Factory | main 分支（2024Q4版） |
安装 vLLM：避开版本陷阱
vLLM 对环境极其敏感，尤其是 CUDA 和 Python 的匹配。直接 pip install vllm 往往会触发源码编译，失败率极高。建议走“预编译 wheel 包”路线。
前往 vLLM Releases 页面，选择对应版本：
wget https://github.com/vllm-project/vllm/releases/download/v0.4.3/vllm-0.4.3+cu126-cp310-cp310-manylinux1_x86_64.whl 使用国内镜像加速安装：
pip install ./vllm-0.4.3+cu126-cp310-cp310-manylinux1_x86_64.whl \ -i https://pypi.tuna.tsinghua.edu.cn/simple \ --trusted-host pypi.tuna.tsinghua.edu.cn 如果遇到：
RuntimeError: Failed to find C compiler. Please specify via CC environment variable. 说明缺少构建工具链。补上即可：
sudo apt-get update && sudo apt-get install --no-upgrade -y build-essential 💡 小技巧：如果你在 WSL 或远程服务器中工作，确保 .whl 文件位于 Linux 子系统内，不要挂在 Windows 挂载路径下，否则可能出现文件读取异常。启动推理：让 Qwen-7B 跑起来
我们以 LLaMA-Factory 微调后的 DeepSeek-R1-Distill-Qwen-7B 模型为例进行测试，模型路径为：
/mnt/e/model/DeepSeek-R1-Distill-Qwen-7B 该模型基于 deepseek prompt 模板训练，因此推理时必须指定相同模板，否则逻辑混乱。
LLaMA-Factory 提供了便捷脚本 vllm_infer.py，一键启动：
python ./scripts/vllm_infer.py \ --model_name_or_path /mnt/e/model/DeepSeek-R1-Distill-Qwen-7B \ --template deepseek \ --dataset data_sample \ --cutoff_len 512 \ --max_samples 100 \ --batch_size 32 \ --enable_thinking False \ --max_new_tokens 512 参数说明：
--model_name_or_path：模型路径，支持 HuggingFace 格式或本地保存的 checkpoint。--template：prompt 模板，务必与训练一致，否则指令理解将出错。--dataset：输入数据集，JSONL 格式，每行一个样本。--cutoff_len：最大上下文长度，影响 KV Cache 占用。--batch_size：逻辑批大小，vLLM 会在此基础上做动态连续批处理。--max_new_tokens：控制生成长度，避免无限输出拖慢整体进度。
值得注意的是，这里的 batch_size 并非传统意义的静态批处理，而是用于控制并发请求数上限。真正实现高效调度的是 vLLM 内部的调度器。
性能实测：数字不会说谎
我们设计了三组对比方案，均在同一硬件环境下执行：
| 方案 | 框架 | 是否启用量化 | 批处理方式 |
|---|---|---|---|
| A | HuggingFace Transformers | FP16 | 静态 batch=8 |
| B | LLaMA-Factory + WebUI | FP16 | 无批处理（逐条） |
| C | LLaMA-Factory + vLLM | FP16 | 动态连续批处理 |
测试数据集包含 100 条真实用户指令，平均输入约 120 tokens，输出限制为最多 512 tokens。
结果如下：
| 方案 | 总耗时（秒） | 平均每条耗时（ms） | 吞吐量（tokens/s） |
|---|---|---|---|
| A | 82s | ~820ms | ~620 |
| B | 70s | ~700ms | ~540 |
| C | 24s | ~240ms | ~2150 |
注：吞吐量 = 总生成 token 数 / 总耗时（不含模型加载）
vLLM 方案总耗时仅 24秒，相较原生 Transformers 提速 3.4倍，WebUI 单条模式提速近 3倍。虽然未达“10倍”宣传峰值，但考虑到这是中小批量离线推理，已属非常亮眼的表现。
更关键的是 吞吐量指标：vLLM 达到 2150 tokens/s，是原生方案的 3.5倍。这意味着同样的硬件，可以支撑更多并发请求，显著降低单位推理成本。
显存效率：少用 1.5GB 是怎么做到的？
通过 nvidia-smi 观察显存占用：
| 方案 | 峰值显存占用 |
|---|---|
| Transformers | ~18GB |
| vLLM | ~16.5GB |
令人惊讶的是，尽管 vLLM 处理了更高并发，显存反而更低。这正是 PagedAttention 的魔力所在——它避免了大量因 padding 和预留缓存造成的浪费。
在实际业务中，这种精细的内存控制意味着：
- 可部署更大规模模型（如13B）于单卡；
- 支持更长上下文对话而不崩溃；
- 更稳定应对流量高峰，减少 OOM 报错。
进阶玩法：OpenAI 兼容 API 一键对接
除了命令行批量推理，vLLM 最实用的功能之一是提供 OpenAI-style API 接口，便于快速集成到现有系统。
LLaMA-Factory 的 api_server.py 支持无缝切换后端：
python ./scripts/api_server.py \ --model_name_or_path /mnt/e/model/DeepSeek-R1-Distill-Qwen-7B \ --template deepseek \ --infer_backend vllm \ --vllm_max_batch_size 32 \ --vllm_gpu_memory_utilization 0.95 服务启动后监听 http://localhost:8000，发送请求如同调用 GPT：
curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "prompt": "请写一首关于春天的诗", "max_tokens": 128, "temperature": 0.7 }' 返回格式完全兼容 OpenAI Schema，前端无需修改即可完成模型替换。这对于想用开源模型替代闭源 API 的团队来说，简直是降本利器。
常见坑点与优化建议
❌ 安装时报错 No module named 'pydantic'
vLLM 强依赖 pydantic v2，而许多旧环境仍为 v1。解决方案：
pip install "pydantic>=2.0" -i https://pypi.tuna.tsinghua.edu.cn/simple ❌ CUDA out of memory 怎么办？
即便 vLLM 显存效率高，激进的配置仍可能翻车。建议：
- 设置
--vllm_gpu_memory_utilization 0.9，留出 10% 安全余量； - 控制
--vllm_max_batch_size，避免瞬时请求堆积； - 启用量化进一步压缩显存。
✅ 推荐开启：GPTQ/AWQ 量化推理
vLLM 原生支持加载 GPTQ 和 AWQ 量化模型。例如加载一个 INT4 量化的 Qwen-7B：
python ./scripts/vllm_infer.py \ --model_name_or_path /path/to/qwen-7b-gptq-int4 \ --quantization gptq \ --dtype half 实测显示，INT4 模型显存占用降至 9GB 左右，推理速度再提升 20%~30%，且质量损失极小。对于资源紧张的生产环境，这是性价比极高的选择。
结语：vLLM 值得引入吗？
综合来看，vLLM 在以下几个维度表现出色：
| 维度 | 表现 |
|---|---|
| 推理速度 | 提升 3x+ |
| 吞吐能力 | 提升 3.5x |
| 显存效率 | 更优，节省约 1.5GB |
| 易用性 | 脚本完善，API 兼容性强 |
| 生产适用性 | 支持批处理、量化、服务化部署 |
它不仅是“更快的推理器”，更是一种面向生产的架构升级。特别是当你面临以下需求时，vLLM 几乎是必选项：
- 高并发在线服务；
- 低成本私有化部署；
- 快速迁移 OpenAI 应用；
- 单卡跑大模型。
结合 LLaMA-Factory 的完整微调生态，这套技术栈已经具备成为企业级大模型底座的能力。未来我们还将探索多卡并行、监控集成等方向，推动开源模型真正走向工业级可用。
技术演进的本质，不是追求理论极限，而是让先进能力落地于平凡场景。vLLM 正在做的，就是这件事。
