Ollama vs vLLM vs llama.cpp：2026 本地大模型部署选型指南

“本地部署大模型”这件事，2026 年已经从极客玩具变成了正经需求——隐私合规、成本控制、离线场景都在推着它走。但很多人一开始就选错了框架，导致要么性能拉胯，要么部署到崩溃。

本文把三个最主流的方案——Ollama、vLLM、llama.cpp——摆上台面，讲清它们各自的哲学和适用边界。

三者本质区别

llama.cpp：底层引擎。 用 C/C++ 写的高效推理库，通过 GGUF 量化格式支持在 CPU、各种 GPU 上跑模型。它是”引擎”，不是”产品”。优点是极致轻量、跨平台、量化方案丰富；缺点是没有原生的服务化、并发调度较弱。

Ollama：面向开发者的封装。 它建立在 llama.cpp 之上，提供了极简的 ollama run 体验、模型管理和 OpenAI 兼容 API。它的目标用户是”想快速跑起来”的开发者。

vLLM：面向生产的推理引擎。 采用 PagedAttention 等显存优化技术，把 GPU 利用率拉到极致，专为高并发和吞吐优化。它的目标用户是”要把模型当服务卖出去”的团队。

四个维度实测对比

假设同样的模型（14B 级别）跑在单张 24GB 显卡上：

并发能力。 这是差距最大的一项。

• vLLM：支持 Continuous Batching，64 并发下吞吐可达单请求的 30 倍以上
• Ollama：默认并发较弱，多请求会排队，适合 1-4 个并发
• llama.cpp：单会话极快，但并发调度需自行实现

显存占用。

• llama.cpp 通过量化最省显存（4-bit 量化能把 14B 压到 8GB 以内）
• vLLM 对显存的管理最精细，但吃 KV cache
• Ollama 介于两者之间，量化选项丰富

部署复杂度。

• Ollama：一行命令，5 分钟
• llama.cpp：需要自己编译、准备 GGUF、写服务层，半天到一天
• vLLM：pip 安装简单，但调优（显存、batch size、TP 配置）需要经验

GPU 利用率。 vLLM 明显领先，在高并发下 GPU 几乎不空转；Ollama 和 llama.cpp 在低并发时利用率都偏低。

决策树：你该选哪个

如果你是个人开发者 / 想快速验证想法 → Ollama。 理由：5 分钟能跑起来，API 兼容 OpenAI，切换模型一行命令。性能对个人使用完全够。

如果你要在消费级硬件 / Mac / 无独显环境跑 → llama.cpp。 理由：量化方案最全，CPU 推理也能接受，苹果 Metal 支持成熟。别指望高并发，但单机单用体验极好。

如果你要对外提供 API 服务 / 高并发 → vLLM。 理由：没有替代品。它是唯一能把 GPU 成本摊薄的方案。代价是配置复杂度。

混合方案： 很多团队的实战是”开发用 Ollama，生产上 vLLM”。用 Ollama 快速试模型和 prompt，验证后部署到 vLLM 集群。这两者 API 都兼容 OpenAI，迁移成本很低。

三个容易踩的坑

坑一：用 Ollama 扛生产流量。 Ollama 很好，但它的定位不是高并发服务器。凌晨没事，白天用户一多就排队,延迟飙升。

坑二：迷信量化越低越好。 4-bit 虽然省显存，但对推理任务的准确率影响明显。建议：对话类可以激进量化，代码和数学推理尽量用 8-bit 或以上。

坑三：忽略显存带宽而非显存容量。 大模型的推理瓶颈常常是内存带宽，不是容量。买卡时别只看显存大小，显存带宽同样关键。

结语

选型的核心不是”哪个最好”，而是”你要解决什么问题”。个人玩票选 Ollama，极限压榨选 llama.cpp，对外服务选 vLLM。 搞清这个分工，你就不会在部署框架上反复折腾了。