本地大模型推理引擎横评：Ollama、vLLM、llama.cpp 到底该选谁？

部署本地大模型的第一步不是选模型——是选推理引擎。引擎选错了，显存占满、吞吐上不去、甚至跑都跑不起来，再好的模型也白搭。

大叔分别用 Ollama、vLLM、llama.cpp 三款引擎跑了大半个月，从部署、吞吐、显存占用到生产可用性逐一实测。今天直接给结论，不整虚的。

---

一、三款引擎一句话定性

引擎 一句话 适合谁 Ollama 开箱即用的个人级推理工具 个人尝鲜、日常聊天、快速验证 vLLM 高性能生产级推理服务器 API服务、多用户并发、高吞吐场景 llama.cpp CPU/异构设备最优解 无独显、显存小、边缘设备

---

二、部署难度：Ollama >> vLLM > llama.cpp

Ollama 最简单，一条命令搞定：

curl -fsSL https://ollama.com/install.sh | sh

ollama pull qwen2.5:7b
ollama run qwen2.5:7b

从零到跑起来，不超过 5 分钟。模型自动下载、自动量化、自动加载，适合第一次接触本地 AI 的人。

vLLM 需要手动搭环境：

# 建议 venv 隔离

python3 -m venv vllm-env
source vllm-env/bin/activate
pip install vllm
vllm serve Qwen/Qwen2.5-7B-Instruct --max-model-len 8192

vLLM 强在批处理（continuous batching），多用户并发时吞吐碾压 Ollama，但配置项多，新手容易调崩。

llama.cpp 提供编译选项最灵活：

git clone https://github.com/ggml-org/llama.cpp

cd llama.cpp && cmake -B build && cmake --build build --config Release
./build/bin/llama-server -m Qwen2.5-7B-Q4_K_M.gguf --port 8080

跨平台兼容最好，ARM Mac、Intel 旧机器、树莓派都能跑，但要自己编译，门槛稍高。

---

三、性能实测：吞吐量对比

测试条件：RTX 4090 24GB + Qwen2.5-7B-Q4_K_M，单用户连续 100 次请求，output 平均 512 tokens。

指标 Ollama vLLM llama.cpp 首token延迟 ~120ms ~80ms ~150ms 吞吐量（单用户） ~45 t/s ~55 t/s ~38 t/s 吞吐量（4并发） ~68 t/s ~185 t/s ~55 t/s 显存占用（空闲） ~5.2GB ~5.8GB ~4.6GB 显存占用（满载） ~6.8GB ~8.2GB ~5.9GB

结论：

• 单用户聊天，三款差距不大，Ollama 胜在省心
• 如果做 API 服务给多人用，vLLM 的 continuous batching 优势巨大，4 并发吞吐接近 Ollama 的 3 倍
• 显存寸土寸金的场景（比如跟 ComfyUI 共享显卡），llama.cpp 最省

---

四、生产环境怎么选

大叔的建议非常直白：

• 个人用、实验、写博客 → 闭眼选 Ollama，别折腾
• 做 API 服务、跑 RAG 系统、对接 Web 应用 → 上 vLLM，吞吐碾压
• 没有独显、用 Mac / 树莓派、显存小于 8G → llama.cpp 或它的封装版 LM Studio

一个小技巧：Ollama 底层调用的其实是 llama.cpp，所以如果你只是个人用，不需要纠结——Ollama 拿来即用，底层性能一点都不差。

---

五、避坑提醒

1. 量化不是万能药：Q4 模型推理速度比 FP16 快约 2 倍，但复杂推理任务（数学、代码）质量会下降，重要场景请先用 FP16 测效果再降级

2. vLLM 的内存分配：默认会吃掉所有空闲显存，记得设 --gpu-memory-utilization 0.8 留余量给其他服务

3. llama.cpp 的 GGUF 模型：Hugging Face 上非 GGUF 格式没法直接用，需要先转格式或用 llama-convert 脚本

---

写在最后

三款引擎没有绝对的好坏，只有适不适合你当前的场景。如果你还在纠结，先用 Ollama 跑一个星期，觉得性能瓶颈了再换引擎，模型文件是通用的，不需要重头再来。

*本文由 IT大叔的工具箱（www.vpnt.top）原创，转载请注明出处。*