Ollama 还是 vLLM，先数你有几个用户
选推理引擎，别先比速度，先数用户数。
摘要
本地跑大模型，Ollama、llama.cpp、vLLM 三选一，关键不是谁更快，而是同时有几个人在用。一个人用，三者差距不大，看顺手程度；多人并发，vLLM 的优势会被放大。本文按个人电脑、单卡服务器、生产服务三种场景给出取舍，并顺带梳理 LocalAI、MLC LLM、oMLX。
先说结论：三个引擎，其实是三种分工
- llama.cpp：底层引擎。C/C++ 写成，GitHub 约 13.3 万 star，MIT 协议，几乎什么硬件都能跑（Metal、CUDA、AMD 的 HIP、Vulkan、纯 CPU 等），自带 OpenAI 兼容的服务端和网页界面。
- Ollama：把 llama.cpp 这一类能力包装成“一条命令就能跑”的产品。约 18.6 万 star，MIT 协议，有模型库、有官方 Docker 镜像，macOS、Windows、Linux 都能装。
- vLLM：面向多用户服务的推理引擎。约 9.6 万 star，Apache-2.0，核心是 PagedAttention 和连续批处理，同样提供 OpenAI 兼容接口。
所以别把它们当成“同一个赛道的三个选手”。前两个解决“我怎么在自己的机器上把模型跑起来”，第三个解决“怎么让很多人同时用得起”。
一个人用：差距没你想的大
社区流传的一组单请求数据（Llama 3.1 8B，RTX 4090，来源是社区基准，口径不统一，只看趋势）：
| 引擎 | 格式 | 生成速度 |
|---|---|---|
| Ollama | Q4_K_M | 约 62 token/s |
| llama.cpp | Q4_K_M | 约 65 token/s |
| vLLM | FP16 | 约 71 token/s |
注意最后一行跑的是 FP16，前两行是 4 比特量化，格式不同，没法直接比引擎。原作者自己的判断也是：差距主要来自量化，不是运行时。另有来源提到 Ollama 比直接用 llama.cpp 多 5% 到 15% 的包装开销，个别配置报告到 30% 左右；还有一组 L40S 上的测试里，两者差得更大，原因没查清。数字互相矛盾，结论只能是：单人使用，别为这点速度差折腾。
这个场景该比的是别的东西：
- 想要省事：Ollama。一条命令装好，模型库里拉模型，空闲 5 分钟自动卸载，还能在多个模型之间热切换。
- 想要控制权：直接用 llama.cpp。量化档位、上下文长度、各种启动参数自己定，新特性出得也比包装层快。
- vLLM：这个场景用它基本是杀鸡用牛刀。
多人并发：差距开始拉开
同一份社区汇总里，并发聚合吞吐是这样的（来源没标模型和显卡，只能看趋势）：
| 并发请求数 | Ollama | vLLM |
|---|---|---|
| 1 | 约 62 | 约 71 |
| 8 | 约 82 | 约 187 |
| 50 | 约 155 | 约 920 |
单人时差 1.1 倍，8 路时 2.3 倍，50 路时接近 6 倍；100 路以上，Ollama 开始排队，vLLM 还在往上走。另一项同卡同模型的测试（Qwen2.5-7B，并发 1 到 64）里，64 路时 vLLM 的聚合吞吐是 llama.cpp 的 2.8 到 4.4 倍。两组数字不一样，方向一致。
原因在两个设计上：PagedAttention 让 KV 缓存几乎不浪费，连续批处理让新请求不用等前面的请求跑完。想看原理，可以翻本号之前的《PagedAttention 原理》。
Ollama 也能开并发，但要自己动手：官方 FAQ 里 OLLAMA_NUM_PARALLEL 默认是 1，调大之后，所需内存按“并行数 × 上下文长度”放大，官方举的例子是 2K 上下文开 4 路并行，实际按 8K 上下文分配内存。排队上限 OLLAMA_MAX_QUEUE 默认 512，超出就返回 503。
三种场景怎么选
| 场景 | 首选 | 理由 |
|---|---|---|
| 个人电脑，自己用 | Ollama，想折腾换 llama.cpp | 装得快、换模型方便，速度差距可以忽略 |
| 单卡服务器，几个人共用 | 先 Ollama 调并行数，请求开始排队再换 vLLM | 并发低时差距小；并发上去后差距明显拉开 |
| 生产服务，对外提供接口 | vLLM（或同类的 SGLang） | 连续批处理，高并发下吞吐明显高 |
两个容易踩的坑，换 vLLM 前要知道：
- vLLM 一启动就占显存。
gpu_memory_utilization默认约九成（早期版本是 0.90，近期稳定版是 0.92），启动时就按这个比例把显存划给自己，权重放进去之后，剩下的几乎全部预留成 KV 池。社区的例子是 24GB 的 3090 跑 7B 的 AWQ 4 比特模型，权重约 5GB，KV 池却占了 17 到 18GB，别的程序基本没位置了。要和别的任务共用显卡，得把这个参数调低。Ollama 和 llama.cpp 则是按权重加设定的上下文长度分配缓存，不会预先吃满显存。 - vLLM 一个服务只服务一个模型。想换模型要重启；Ollama 则可以按需加载，默认最多同时驻留“3 × GPU 数”个模型（纯 CPU 时为 3 个），前提是内存放得下。
另外，Mac 用户别急着装 vLLM：它的硬件插件列表里有 Apple Silicon，但社区评价是 Mac 上并不成熟。Windows 上则通常要走 WSL2。
还有三个名字，各管一块
这次的候选里还有三个高 star 项目，定位和上面不重叠：
- LocalAI（约 5 万 star）：不是一个新引擎，而是一层统一接口。后面接 llama.cpp、vLLM、whisper.cpp、stable-diffusion 等多种后端，对外兼容 OpenAI 和 Anthropic 的接口。适合一个入口同时管文本、语音、图像的场景。
- MLC LLM（约 2.3 万 star）：走机器学习编译路线，目标是“一份模型到处部署”，覆盖 iOS、Android、浏览器的 WebGPU 以及主流显卡。要把模型塞进手机或网页，才轮到它。
- oMLX（约 2.3 万 star）：专给 Apple Silicon 的服务端，基于 MLX，带连续批处理，KV 缓存分内存和固态硬盘两层，重启后还能恢复。要求 macOS 15 以上、M1 及更新的 Apple 芯片。Mac 上想让几个人共用，它比 Ollama 更对路。
再往极端走一步是 ds4。上一篇写过它：只专门优化 DeepSeek、GLM、Qwen 的少数几个模型，在 128GB 的 M5 Max 上跑 2 比特量化的 DeepSeek V4 Flash，2K 上下文生成约 39 token/s。它的做法是“通用性换极致”，也明确说明部分量化格式和内核沿用了 llama.cpp 和 GGML 的代码。所以这几个项目不是简单的替代关系：Ollama 把 llama.cpp 作为后端之一，LocalAI 把它当成可接入的后端，ds4 也沿用了它的部分代码，都是站在 llama.cpp 肩膀上。
我的看法
先回答三个问题再装软件：
- 同时会有几个人用？一个人，Ollama 或 llama.cpp；请求开始排队，就该看 vLLM。
- 机器是什么？Mac 优先 Ollama、llama.cpp、oMLX；NVIDIA 显卡才是 vLLM 的主场。
- 愿不愿意自己调参数？不愿意选 Ollama，愿意选 llama.cpp 或 vLLM。
引擎之间的单人速度差，多半比量化档位带来的差距还小。与其在这里纠结，不如先把模型和量化选对。想继续往下挖的读者，可以看本号推理系列里的《TensorRT 与 ONNX Runtime》和《SGLang 上手》。
收藏这三行
- 一个人用：Ollama 省事，llama.cpp 可控，别为 10% 的速度折腾。
- 多人并发：先看
OLLAMA_NUM_PARALLEL，撑不住就上 vLLM，并记得调gpu_memory_utilization。 - Mac 专用：Ollama、llama.cpp、oMLX；NVIDIA 服务器：vLLM 或 SGLang。
你现在本地跑的是哪一个？是一个人用，还是已经有人在排队了？