关键要点
- llama.cpp： 单请求最快（38 tok/s，26ms）。依赖最少。最适合自定义推理引擎。
- Ollama： 安装最简单（5分钟，一条命令）。比llama.cpp慢 5–10%——对处理速度影响可忽略不计。
- vLLM： 批处理吸吐量最高（250+ tok/s）。生产API服务的唯一选择。
- 单用户聊天：llama.cpp或Ollama（速度几乎相同）。
- 多用户API服务：vLLM（批处理内置支持，吸吐量提升 3–5倍）。
- 三者产生相同的模型输出——差异仅在速度和功能。
- 可同时在不同端口运行三者——它们不会冲突。
性能标准——RTX 4090，Llama 3.3 70B Q4_K_M
llama.cpp单请求最快（38 tok/s）；vLLM批处理吞吐量最高（250+ tok/s）。 RTX 4090 24GB、Llama 3.3 70B Q4_K_M、单请求、2026年4月计测：
| 后端 | token/s | ms/token | VRAM用量 | 批处理吞吐量 |
|---|---|---|---|---|
| llama.cpp | 38 | 26 | 39 GB | N/A（无批处理） |
| Ollama | 36 | 28 | 39 GB | N/A（单批处理） |
| vLLM | 34 | 29 | 41 GB | 250+ tok/s（连续） |
RTX 3060 12GB — Llama 3.2 8B Q4_K_M
RTX 3060 12GB、Llama 3.2 8B Q4_K_M、单请求、2026年4月计测：
| 后端 | token/s | ms/token | VRAM用量 | 批处理吞吐量 |
|---|---|---|---|---|
| llama.cpp | 52 | 19 | 5.2 GB | N/A |
| Ollama | 48 | 21 | 5.4 GB | N/A |
| vLLM | 45 | 22 | 6.1 GB | 180 tok/s（batch=8） |
功能对比
| 功能 | llama.cpp | Ollama | vLLM |
|---|---|---|---|
| 安装时间 | 30分钟（编译） | 5分钟（单命令） | 15分钟（pip install） |
| OpenAI兼容API | ✅（llama-server经由） | ✅（原生） | ✅（原生） |
| 模型格式 | GGUF | GGUF | SafeTensors / HF |
| GPU支持 | CUDA、ROCm、Metal | CUDA、ROCm、Metal | 仅CUDA |
| 批处理 | ❌ | ❌ | ✅ 连续 |
| 多GPU | ❌ | ❌ | ✅ 张量并行 |
| Apple Silicon | ✅ Metal | ✅ Metal | ❌ |
| 聊天界面 | ❌（仅服务器） | ❌（需Open WebUI） | ❌（仅API） |
| 许可证 | MIT | MIT | Apache 2.0 |
安装复杂度对比
- Ollama——5分钟： `brew install ollama` → `ollama run llama3.2`。完成。
- vLLM——15分钟： `pip install vllm` → `python -m vllm.entrypoints.openai.api_server --model meta-llama/Llama-3`。
- llama.cpp——30分钟： 需要编译源码（或下载二进制）。需手动管理模型文件。
- 大多数用户的首选：Ollama
API兼容性
- llama.cpp： 通过llama-server提供OpenAI兼容API。支持大多数IDE插件。
- Ollama： 通过 `ollama serve` 提供OpenAI兼容接口。支持VS Code、Cursor插件。
- vLLM： 原生支持OpenAI标准 `/v1/chat/completions`。兼容性最佳。
- 适用IDE插件（VS Code、Cursor）：使用Ollama或vLLM——跳过llama.cpp。
使用场景指南
- llama.cpp： 自定义推理引擎、依赖最少化、单请求最优速度。
- Ollama： 个人聊天、开发试验、最简单的工作流。
- vLLM： 生产API服务器、多用户部署、高吸吐量场景。
- 可同时在不同端口运行三者——它们不会冲突。
vLLM批处理详解
- llama.cpp： 无原生批处理。请求排队处理。吸吐量：38 tok/s。
- Ollama： 仅支持单批次。无法并行处理多个请求。吸吐量：36 tok/s。
- vLLM： 原生批处理（连续批处理）。可同时处理 32 个请求。吸吐量：250+ tok/s。
- 有 10+ 并发用户的API服务器：vLLM是唯一可行选择。
4个常见错误
- 1认为llama.cpp总是最快。 单 token 处确实最快。但 vLLM 在 10+ 并发请求时快 7 倍。
- 2认为Ollama太慢。 它比llama.cpp慢 5–10%——对 34 tok/s来说影响可忽略不计。
- 3认为必须只选一个。 在不同端口运行三者。聊天用Ollama，API用vLLM。
- 4单用户聊天也用vLLM。 它的优势在于批处理。单用户场景 Ollama 更简单、足够用。
常见问题
初学者应该用哪个？
Ollama。一条命令安装，模型自动下载，界面清晰。与llama.cpp的性能差异在 5% 以内。
llama.cpp、Ollama和vLLM哪个最快？
单请求：llama.cpp（比Ollama快约3%）。刐10个并发请求：vLLM（因原生批处理快约7倍）。
可以用llama.cpp替代Ollama吗？
可以。但需要编译源码。速度提升 3–5%——对大多数用户可忽略不计。Ollama是更好的默认选择。
vLLM是否适合生产环境？
是的。已经在真实生产环境中部署。学习曲线较降，但对于 10+ 并发用户的高吸吐量 API 服务值得。
切换后端需要重新训练模型吗？
不需要。llama.cpp和Ollama使用GGUF；vLLM使用SafeTensors格式。模型可在后端间迁移。输出完全相同。
哪个后端最稳定？
Ollama（架构简单，依赖少）。llama.cpp也很稳定。vLLM更新频繁、出现破嚄性变更的频率较高。
哪个后端支持最多模型格式？
llama.cpp——支持最多 GGUF 量化类型（Q3、Q4、Q5、Q6、Q8）。Ollama封装了llama.cpp，具有相同格式支持。vLLM主要支持 HuggingFace 模型。
中国及亚太地区应用场景
- 中国（数据安全法）： 根据2021年《数据安全法》，重要数据必须在境内存储。本地LLM推理（llama.cpp、Ollama、vLLM）可让数据完全留在本地，满足合规要求。Qwen2.5等国产模型尤适合国内企业部署。
- 亚太地区（数据跨境）： 新加坡、日本、韩国、澳大利亚等地均有跥境传输限制。本地推理可根据 PDPA、APPI、K-ISMS等地区性法规满足合规要求。
- 企业部署： 金融、医疗、法律行业将敏感数据处理在本地。单内部工具用Ollama，多用户企业服务用vLLM。