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 上验证这一性能跃迁是否成立。

环境配置：别让依赖毁了你的实验

实验平台如下：

安装 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 内部的调度器。

性能实测：数字不会说谎

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

测试数据集包含 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 正在做的，就是这件事。