本地部署大模型实战：Ollama、llama.cpp 与 vLLM 深度对比

本地运行大语言模型已经不再是极客的玩具。如今在消费级硬件上跑 7B 到 70B 参数模型，性能已经逼近云端 API，而且无需 API Key、不依赖云服务、数据完全留在本地。这篇指南聚焦三个主流推理引擎——Ollama、llama.cpp 和 vLLM，从易用性到吞吐量做一次系统拆解。

三款引擎的定位差异

三者虽然都能跑同一个模型，但设计哲学完全不同。Ollama 追求开箱即用，一条命令拉模型、起服务，适合开发者日常聊天和快速验证。llama.cpp 追求底层控制，从量化类型到 GPU 层数全都能手动调，是嵌入式和边缘部署的首选。vLLM 则瞄准生产级吞吐，靠 PagedAttention 和连续批处理把并发能力拉满，适合要同时服务大量用户的场景。

一个常被忽略的细节：三者都暴露 OpenAI 兼容 API。这意味着前端代码不用改，就能在它们之间切换后端，迁移成本几乎为零。

维度	Ollama	llama.cpp	vLLM
易用性	极高	中等	较低
模型格式	GGUF	GGUF	HF/Safetensors
批处理	不支持	不支持	PagedAttention
量化	自动	手动	AWQ/GPTQ
最佳场景	本地聊天	边缘/嵌入	生产服务

PagedAttention 是 vLLM 的核心技术，思路借鉴了操作系统的虚拟内存分页。传统推理中，每个请求的 KV Cache（键值缓存）必须在显存里占用一整块连续空间，长度按最大可能序列预留，导致大量碎片和浪费。PagedAttention 把 KV Cache 切成固定大小的块（block），按需分配、非连续存放，再用一张块表把它们逻辑上串起来。这样一来显存利用率可以从传统的 20%～40% 提升到 90% 以上，同一张卡能同时容纳的请求数大幅增加。它还是连续批处理（Continuous Batching）的基础——新请求可以在任意时刻插入正在运行的批次，而不必等整批结束，这正是 vLLM 吞吐量领先的数量级来源。

硬件门槛与显存估算

决定能不能跑起来的关键是显存。业界经验公式是：显存 ≈ 参数量 × 0.5（Q4 量化）到 ×1.0（Q8 量化），单位为 GB。

模型	量化	显存/内存	纯 CPU
7B	Q4_K_M	6 GB	可跑但慢
7B	Q8_0	8 GB	可用
13B	Q4_K_M	10 GB	可跑但慢
33B	Q4_K_M	20 GB	不可行
70B	Q4_K_M	40 GB	不可行

33B 以上基本告别纯 CPU。一张 24GB 显存的 RTX 3090 二手约 800 美元，能覆盖 7B 到 33B 的 Q4 模型，月电费大约 15 美元。这是很多个人开发者和小团队的甜蜜点。

Ollama：最省心的起点

Ollama 的价值在于把复杂度全藏起来。安装只需一行：

# Linux
curl -fsSL https://ollama.com/install.sh | sh
# macOS
brew install ollama
# Windows
winget install Ollama.Ollama

拉取并运行模型同样是单条命令，模型会自动下载成 GGUF 格式：

ollama run mistral:7b-instruct-q4_K_M
ollama list
ollama show mistral:7b-instruct-q4_K_M

服务默认监听 11434 端口，OpenAI 兼容接口可直接用 curl 或 Python requests 调用。对于需要自定义系统提示词和参数的场景，可以用 Modelfile 定义。例如把温度、top_p、上下文长度和系统角色固化下来，再用 ollama create 打包成本地模型，避免每次调用都重复传参。

Ollama 的短板也同样明确：不支持批处理。单请求场景它很舒服，但并发一上来就会成为瓶颈。

llama.cpp：控制力拉满

llama.cpp 需要自己编译，但也换来了最大的自由度：

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make LLAMA_CUBLAS=1   # NVIDIA GPU

**GGUF 与 k-quant 量化**：GGUF 是 llama.cpp 主推的模型文件格式，专为 CPU/混合推理设计，把权重、词表、超参数打包进单个文件，支持内存映射（mmap）从而加快加载并降低内存压力。表格里的 Q4_K_M 中的 K 指 k-quant，是一套分块量化方案：把权重按块分组，每组用不同的位宽和缩放/最小值参数表示，对敏感层保留更高精度。后缀 M 表示 medium，在 S（small）、M、L（large）三档中质量与体积折中。相比早期的 Q4_0，Q4_K_M 用更少的比特换来更好的困惑度表现，因此成为社区事实标准。选量化档位本质上是在显存、速度和输出质量之间做取舍。

**投机解码（Speculative Decoding）** 的原理是“小模型起草、大模型把关”。推理时先用一个参数量小得多的草稿模型，一次前向并行生成若干候选 token（比如 4～8 个），再让主模型一次性验证这一整段。如果候选被主模型接受，就省下了逐个生成的开销；被拒绝的部分则回退重来。由于验证是并行的，而生成是串行的，只要草稿模型的接受率足够高，整体就能获得 2～3 倍加速，且输出分布与只用主模型完全一致，不损失质量。草稿模型通常选用同系列的小尺寸版本或专门训练的蒸馏模型。代价是额外占用一份显存，因此在显存吃紧的边缘设备上要权衡是否启用。
# 或 make LLAMA_METAL=1  # Apple Silicon

它支持把 Hugging Face 上的 Safetensors 模型转换成 GGUF，并手动选择量化类型。量化档位直接决定体积与质量的天平，下面以 7B 模型为例：

类型	体积 (7B)	质量	速度
Q2_K	~2.8 GB	低	最快
Q3_K_M	~3.3 GB	中	快
Q4_K_M	~3.8 GB	良好	均衡
Q5_K_M	~4.7 GB	更好	较慢
Q8_0	~7.2 GB	接近 fp16	最慢

Q4_K_M 是绝大多数场景的默认答案——体积、质量、速度取得了最好的平衡。启动服务时可以指定 GPU 卸载层数、上下文长度，并开启 Flash Attention 加速：

./llama-server -m ./model.Q4_K_M.gguf -c 8192 --port 8080 -ngl 99 -fa

它还有一个进阶特性值得关注：投机解码（Speculative Decoding）。用一个小的草稿模型配合大模型，能显著加速生成。配置方式是同时指定主模型和 -md 草稿模型。这个机制在 llama.cpp 中已经相对成熟，是边缘场景提效的实用手段。

vLLM：生产级吞吐

vLLM 的定位很清楚——为并发而生。安装需要 CUDA 12.1+ 和 Python 3.10+，也支持 ROCm（AMD 显卡）：

pip install vllm

启动服务时，--gpu-memory-utilization 控制显存占用比例，--max-model-len 限制上下文长度。多卡场景用 --tensor-parallel-size 做张量并行，70B 模型可以拆到两张卡上跑。量化方面原生支持 AWQ 和 GPTQ，直接指定 --quantization awq 即可。

性能差距是数量级的。在同一模型（Llama-3.1-8B）、批大小 32、上下文 2048 的条件下：

• vLLM（PagedAttention）：约 450 tok/s
• llama.cpp（批大小 32）：约 280 tok/s
• Ollama（无批处理）：约 120 tok/s

需要说明的是，这组数据来自单一来源的测试环境，实际表现会随硬件和负载变化。但趋势是稳定的：vLLM 在高并发下优势明显，Ollama 的定位本就不是吞吐。

性能调优要点

三个引擎各有调优抓手。llama.cpp 建议把线程数设为物理核心数，用 -b 和 -ub 控制批大小，Flash Attention 需要 Hopper/Ada 架构或 Apple Silicon 支持。vLLM 通过 --max-num-batched-tokens 和 --max-num-seqs 提升批处理能力，--enable-chunked-prefill 适合长上下文，--enable-prefix-caching 则能复用共享前缀，对固定系统提示词的场景收益明显。Ollama 主要通过环境变量控制，比如 OLLAMA_NUM_PARALLEL 设并发数、OLLAMA_MAX_LOADED_MODELS 控制驻留显存的模型数量、OLLAMA_FLASH_ATTENTION=1 开启加速。

批大小（batch size）与并发 是区分三个引擎性能曲线的关键变量。llama.cpp 的 -b（逻辑批大小）和 -ub（物理微批大小）决定一次前向处理多少 token，调大能提高 GPU 利用率，但显存占用也随之上升；vLLM 的 --max-num-seqs 限制同时在跑的序列数，--max-num-batched-tokens 限制单批的 token 总量，两者共同约束显存与吞吐的平衡。需要区分两个概念：静态批处理一次处理固定的一组请求，必须等最慢的那个结束；连续批处理则动态补充新请求，让 GPU 几乎不空转。Ollama 默认没有真正的批处理，只能靠 OLLAMA_NUM_PARALLEL 开多个并行槽位来缓解，但每个槽位仍各自独立推理，因此在高并发下与 vLLM 的差距会进一步拉大。

常见故障排查

显存溢出是最常见的问题，解决路径是降低 GPU 层数、换更小的量化，或把部分层卸载到 CPU。CPU 推理慢时优先确认是否用了 Q4_K_M 并启用了 BLAS。模型加载失败通常与 GGUF 兼容性有关，可尝试用 llama.cpp 的转换脚本重新生成。API 连接被拒则检查端口、防火墙，Ollama 需要设置 OLLAMA_HOST=0.0.0.0 才能被外部访问。输出质量差时，可以调高温度、换更大模型或提升量化精度。

成本账与决策路径

本地部署的经济性需要放在时间维度上看。一套 Ollama + RTX 3090 的二手硬件成本约 800 美元，月电费约 15 美元；llama.cpp + RTX 4090 约 1600 美元，月电费 25 美元；vLLM + 双 A100 80GB 约 3 万美元，托管费约 500 美元/月。对照云 API 每月 50 到 500 美元的用量，本地 GPU 的回本周期大约在 6 到 18 个月之间。数据隐私要求高、调用量稳定的团队，本地部署的性价比更明显；调用量波动大的场景，云 API 更灵活。

选择逻辑可以归纳成一句话：只想聊天和快速测试选 Ollama；要嵌入应用、做边缘设备或自定义量化选 llama.cpp；要服务大量用户、追求高吞吐选 vLLM；用 Apple Silicon Mac 的话，Ollama 或 llama.cpp 的 Metal 后端都是合适选择。

结语

本地大模型已经具备生产可用性。三款引擎的边界清晰：Ollama 赢在开发者体验，llama.cpp 赢在控制力和边缘适配，vLLM 赢在服务规模。它们共享 OpenAI 兼容接口这一事实，意味着你可以先从 Ollama 起步验证想法，等并发压力上来了再平滑迁移到 vLLM，而不必重写业务代码。下一步可以在此基础上接入 RAG、函数调用，或用 LoRA 微调自己的专属模型。