Ollama、llama.cpp、vLLM：本地推理的三条路线怎么选

先把三个项目摆在一起

截至 2026 年 10 月 23 日：Ollama 184,394 star、v0.40.9，MIT；llama.cpp 132,089 star、v0.7.0，MIT；vLLM 95,195 star、v0.32.0，Apache-2.0。三个都是活跃项目，凑在一起不是因为它们竞争，而是因为它们解决的是三个不同的问题。

Ollama：把模型变成一条命令

它的价值在体验：ollama run qwen3 就能开始对话，模型自动下载、自动套量化模板，还提供一个 OpenAI 兼容的 /v1 端点。写脚本、做原型、本机试模型，没有比它更快的路径。

但它的默认假设是「一台机器、一个用户」。并发请求会排队，多个客户端同时打会明显变慢。拿它当团队内部 API 用，前几天没事，人一多就露馅。

llama.cpp：控制到每一个字节

GGUF 格式、K-quants 量化、CPU 与 GPU 混合推理、--n-gpu-layers 逐层卸载，这些能力让它成为边缘设备、Apple Silicon、低显存显卡上的默认选择。它也是很多上层工具（包括 Ollama）的推理内核。

代价是要自己搭服务层：并发、队列、鉴权、监控，都得另外写。它给你的是引擎，不是产品。

vLLM：为吞吐而生

PagedAttention 把 KV cache 按页管理，continuous batching 让新请求随时插入正在跑的批次。同样一张卡，vLLM 的吞吐通常是单请求串行方式的数倍，这是它在服务端站稳的原因。

它也有明确的代价：以 GPU 为主，启动要预分配显存，模型加载慢，配置项多。为了跑一个 7B 模型给三个人用，上 vLLM 属于杀鸡用牛刀。

怎么选，看一张表

两个最常见的错配

一是用 Ollama 扛十人以上的并发，然后抱怨「本地模型慢」——慢的不是模型，是排队。二是用 vLLM 去跑一张 8GB 显卡上的 7B 模型，显存被预分配吃满，稍微长一点的上下文就 OOM。

还有一点值得说清：同一个模型、同一档量化，三个工具生成的文本质量没有本质差别。差别在延迟、吞吐、显存占用和运维成本上。选型时先量清楚你的并发数和可接受的首 token 延迟，再谈工具。

我的判断

这三个项目不是替代关系，而是分层：llama.cpp 是引擎，Ollama 是引擎加产品壳，vLLM 是为服务端重写的调度器。真正该问的问题不是「哪个更好」，而是「我这一年到头有几个并发」。

参考来源

• Ollama
• llama.cpp
• vLLM

延伸阅读

• 本地 AI 硬件正在集体开花
• 开源模型进入落地竞争
• Q4_K_M、AWQ、FP8 在省什么