01 - 大模型推理框架选型入门：Ollama、llama.cpp与vLLM全景对比
01 - 大模型推理框架选型入门：Ollama、llama.cpp与vLLM全景对比
本文是《大模型推理框架深度解析》系列的第一篇，适合刚接触LLM部署的开发者阅读。
写在前面
随着大语言模型（LLM）的广泛应用，如何将模型高效地部署到生产环境成为每个AI工程师必须面对的问题。目前市面上主流的推理框架有Ollama、llama.cpp和vLLM，但它们的技术定位、适用场景差异巨大。
很多开发者在选型时容易陷入误区：
- 用Ollama部署高并发API服务，结果吞吐量上不去
- 用vLLM跑边缘设备，发现资源占用过高
- 混淆llama.cpp和vLLM的定位，不知道何时该用哪个
本文将从架构分层视角出发，帮你建立清晰的选型认知。
一、三大框架的技术定位
1.1 三层架构视角
如果把LLM推理技术栈比作一座大厦，三个框架分别位于不同的楼层：
┌─────────────────────────────────────────────────────────────┐ │ 应用层（第3层） │ │ ┌─────────────┐ │ │ │ Ollama │ ← 一键式模型管理，类似Docker的体验 │ │ └─────────────┘ │ ├─────────────────────────────────────────────────────────────┤ │ 推理引擎层（第2层） │ │ ┌─────────────┐ ┌─────────────────────────────────────┐ │ │ │ llama.cpp │ │ vLLM │ │ │ │ C++引擎 │ │ Python推理服务平台 │ │ │ └─────────────┘ └─────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────┤ │ 硬件加速层（第1层） │ │ CUDA / Metal / ROCm / AVX512 │ └─────────────────────────────────────────────────────────────┘ 核心区别一句话总结：
- Ollama：让开发者"开箱即用"的工具层
- llama.cpp：追求极致轻量的C++推理引擎
- vLLM：面向生产的高吞吐推理服务平台
1.2 各框架的本质定位
| 维度 | Ollama | llama.cpp | vLLM |
|---|---|---|---|
| 本质 | 模型管理工具 | 推理引擎库 | 推理服务框架 |
| 设计目标 | 开发便捷 | 跨平台兼容 | 高吞吐服务化 |
| 核心用户 | 开发者/研究者 | 嵌入式工程师 | SRE/运维工程师 |
| 部署形态 | 单二进制文件 | 静态库/可执行文件 | Python服务+API |
1.3 Ollama的真相：llama.cpp的封装层
很多开发者不知道的是，Ollama底层调用的正是llama.cpp：
Ollama CLI → Modelfile解析 → GGUF模型下载 → llama.cpp推理引擎 这意味着：
- Ollama的"简单"是有代价的——它隐藏了llama.cpp的精细调参能力
- 在高并发场景下，Ollama的HTTP层成为瓶颈
- 生产环境建议绕过Ollama，直接使用底层引擎
二、适用场景速查表
2.1 按使用场景选型
| 场景 | 推荐框架 | 理由 |
|---|---|---|
| 本地开发测试 | Ollama | 一键安装，Modelfile灵活配置 |
| MacBook Pro本地跑70B | llama.cpp | Metal后端优化，统一内存优势 |
| 边缘设备/嵌入式 | llama.cpp | ARM NEON优化，低资源占用 |
| 高并发API服务 | vLLM | 连续批处理，PagedAttention |
| 70B+大模型生产部署 | vLLM | TP/PP分布式支持完善 |
| MoE模型(DeepSeek) | vLLM | EP专家并行原生支持 |
| CPU兜底/降级链路 | llama.cpp | 跨平台稳定，GGUF生态成熟 |
2.2 按硬件环境选型
无GPU环境：
# 唯一选择：llama.cpp ./llama-cli -m model.gguf --threads 32单卡消费级GPU（RTX 4090 24GB）：
# 7B-13B模型：vLLM或llama.cpp均可# 70B模型：必须用量化版 + vLLM vllm serve --model llama-70b-awq --quantization awq 多卡数据中心GPU（A100/H100）：
# vLLM是最佳选择 vllm serve --model llama-405b --tensor-parallel-size 8Apple Silicon（M1/M2/M3）：
# llama.cpp Metal后端最优 ./llama-cli -m model.gguf -ngl 99# 全部层卸载到GPU三、快速上手示例
3.1 Ollama：5分钟跑起来
# 安装curl -fsSL https://ollama.com/install.sh |sh# 拉取并运行模型 ollama run llama3.1:70b # 自定义Modelfilecat> Modelfile <<'EOF' FROM llama3.1:70b PARAMETER temperature 0.7 PARAMETER top_p 0.9 SYSTEM "你是一个专业的编程助手" EOF ollama create my-model -f Modelfile 3.2 llama.cpp：从源码构建
# 克隆并编译git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp make -j LLAMA_CUDA=1# NVIDIA GPU# 下载GGUF模型并运行 ./llama-cli \ -m models/llama-3.1-70b-Q4_K_M.gguf \ --ctx-size 32768\ --threads 32\ -ngl 99# GPU层数，99表示全部3.3 vLLM：生产级部署
# pip安装 pip install vllm # 启动服务 vllm serve meta-llama/Llama-3.1-70B \ --tensor-parallel-size 4\ --gpu-memory-utilization 0.85\ --max-model-len 32768\ --enable-prefix-caching # 调用APIcurl http://localhost:8000/v1/completions \ -H "Content-Type: application/json"\ -d '{ "model": "meta-llama/Llama-3.1-70B", "prompt": "Hello,", "max_tokens": 100 }'四、常见误区澄清
误区1：Ollama可以替代vLLM用于生产
真相：Ollama的HTTP层和调度逻辑在高并发下会成为瓶颈。实测数据显示，相同硬件下vLLM的吞吐量是Ollama的3-5倍。
误区2：llama.cpp比vLLM慢，应该被淘汰
真相：llama.cpp在CPU推理和边缘设备场景下是最佳选择。它的跨平台能力和GGUF生态是vLLM无法替代的。
误区3：vLLM支持所有模型格式
真相：vLLM主要支持HuggingFace格式（safetensors/bin），而llama.cpp专注于GGUF。选型前需要确认模型格式支持。
五、系列文章预告
本文是系列的开篇，后续将深入各个技术细节：
- 02 - 量化与性能：GGUF、AWQ、GPTQ的原理差异与性能基准
- 03 - KV Cache与批处理：PagedAttention如何让内存利用率从60%提升到95%
- 04 - 分布式推理：TP/PP/EP并行策略的原理与配置
- 05 - 生产架构：Kubernetes部署与混合链路设计
- 06 - 故障排查：监控指标、性能调优与故障演练
参考资源
文章标签
大模型推理LLM部署vLLMllama.cppOllamaAI工程化模型量化
