LLaMA-Factory 集成 vLLM 的安装与推理速度实测

💡 小技巧：如果你在 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 内部的调度器。

性能实测：数字不会说谎

我们设计了三组对比方案，均在同一硬件环境下执行：

测试数据集包含 100 条真实用户指令，平均输入约 120 tokens，输出限制为最多 512 tokens。

结果如下：

注：吞吐量 = 总生成 token 数 / 总耗时（不含模型加载）

vLLM 方案总耗时仅 24 秒，相较原生 Transformers 提速 3.4 倍，WebUI 单条模式提速近 3 倍。虽然未达'10 倍'宣传峰值，但考虑到这是中小批量离线推理，已属非常亮眼的表现。

更关键的是 吞吐量指标：vLLM 达到 2150 tokens/s，是原生方案的 3.5 倍。这意味着同样的硬件，可以支撑更多并发请求，显著降低单位推理成本。

显存效率：少用 1.5GB 是怎么做到的？

通过 nvidia-smi 观察显存占用：

令人惊讶的是，尽管 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 在以下几个维度表现出色：

它不仅是'更快的推理器'，更是一种面向生产的架构升级。特别是当你面临以下需求时，vLLM 几乎是必选项：

• 高并发在线服务；
• 低成本私有化部署；
• 快速迁移 OpenAI 应用；
• 单卡跑大模型。

结合 LLaMA-Factory 的完整微调生态，这套技术栈已经具备成为企业级大模型底座的能力。未来我们还将探索多卡并行、监控集成等方向，推动开源模型真正走向工业级可用。

技术演进的本质，不是追求理论极限，而是让先进能力落地于平凡场景。vLLM 正在做的，就是这件事。