Ollama替代品实测：封装层比llama.cpp慢多少

本地大模型部署的终极目标几乎完全一致：在 localhost 上跑一个说 OpenAI API 的端点，让编辑器插件、Agent 框架或脚本别再往付费云密钥里烧 token。Ollama 靠一条命令做到了这一点，也因此成为最流行的入口。

但这家公司现在的位置已经变了。它宣布完成 8800 万美元融资，官方称有 890 万开发者使用，定价页上的云套餐从每月 20 美元一路卖到 500 美元。另一边，我们做了一组计时测试：在同一台 M3 Pro MacBook Pro 上运行同一个模型文件，Ollama 的提示词处理速度比 llama.cpp 慢约 7%，生成速度慢约 9%。

Ollama 到底是什么，以及人们为什么离开

Ollama 是一个 CLI、一个模型库、以及跑在 11434 端口上的 HTTP API，它站在自己并未编写的推理引擎之上。macOS 版 v0.40.4 同时打包了 llama.cpp 和 Apple MLX 的许可证文件，在我们的测试中，它的服务日志显示一个库模型正加载在 MLX 引擎上。MIT 协议，GitHub 星标 183,101。

离开的理由通常有三个：

• 静默截断。 Ollama 的 FAQ 写明默认上下文窗口为 4,096 tokens，除非设置 OLLAMA_CONTEXT_LENGTH。超长提示词会被直接截断，且不报错。
• 引擎本身就能独立使用。 Ollama 能跑的东西，你都可以直接跑，跳过封装的额外开销。
• 公司在向云端转移。 Pro 每月 20 美元含 60 美元用量额度，Max 每月 100 美元含 300 美元，Team 每月 500 美元，且已改为按 token 计费。

第一条在迁移任何东西之前就能低成本排除：

OLLAMA_CONTEXT_LENGTH=16384 ollama serve

在同一模型文件上给封装层计时

测试机为 18 GB 内存的 M3 Pro MacBook Pro，运行 Ollama v0.40.4 和 llama.cpp build b11609。两者都服务来自 ggml-org/Qwen3.5-0.8B-GGUF 仓库的 Q8_0 格式 Qwen3.5-0.8B，SHA-256 已和 Hugging Face 校验一致。一段 Python 脚本向每个服务器发送 545 token 的提示词，要求返回 128 token，一次预热加五次计时运行。每次运行都修改提示词第一行，避免任一服务器命中提示缓存。

配置	提示词处理	生成
llama.cpp llama-server，Q8_0 GGUF	2,600.9 tok/s	108.6 tok/s
llama.cpp llama-server，末尾二次运行	2,570.9 tok/s	106.3 tok/s
Ollama，导入同一个 Q8_0 GGUF	2,426.7 tok/s	98.7 tok/s
Ollama 库内 qwen3.5:0.8b（MLX 引擎，mxfp8）	2,264.6 tok/s	95.3 tok/s

第二次 llama.cpp 运行与第一次相差约 2%，说明热降频解释不了这个差距。Ollama 自家库构建跑在 MLX 上也没有更快，而且噪声最大：不同运行间提示词吞吐在 1,729.8 到 2,970.3 tok/s 之间波动。

单个 0.8B 模型在单台 Mac 上是小样本。完整脚本在原文中，跑一遍只需要几分钟，在自己机器和模型上得到的数字才真正有意义。

GGUF、Q8_0 和 mlx 引擎，是同一条推理链上不同层的产物。 GGUF（GPT-Generated Unified Format）是 llama.cpp 社区定义的容器格式，把权重、分词器、聊天模板和量化元数据打包进单个文件，这也是它能在 llama.cpp、Ollama、LM Studio 之间自由导入的原因。文件名里的 Q8_0 表示 8 位整数量化：权重以 8 bit 块存储，每个块带一个缩放因子，相比 FP16 大约减半，精度损失很小但几乎不省内存——真正省内存通常要降到 Q4_K_M 这类方案。Ollama 在 Apple Silicon 上额外引入 MLX 后端，其 mxfp8 是 MLX 自有的 8 位浮点量化，和 Q8_0 数值格式不同，因此库内 qwen3.5:0.8b 与手动导入的 GGUF 并非同一条路径。测出「导入 GGUF 反而比库内模型快」说明封装层选择的后端和量化方式，比封装本身对吞吐影响更大——同样两个数字放在一起，只有控制住引擎和量化格式才谈得上对比。

llama.cpp：去掉封装，保留引擎

llama.cpp 就是 Ollama GGUF 路径背后的 C/C++ 引擎。自己运行它，恰好移除了上面测得的那个层。

一条命令从 Hugging Face 下载模型并启动 OpenAI 兼容服务器：

llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

上下文大小、GPU 层数和其他引擎设置都是普通命令行参数，而不是 Modelfile。你放弃的是模型管理：没有精选库，也没有后台服务。另外注意 llama-server 现在默认端口是 9931，为旧默认值写的配置需要修改。MIT，131,123 星，v0.6.0，nightly b11609。

OpenAI 兼容 API 是本地推理生态事实上的通用协议。 自 2023 年 11 月起，OpenAI 的 /v1/chat/completions 接口成为默认约定：请求体里一个 model 字段、一个 messages 数组，响应里一个 choices[0].message.content。此后几乎每一款本地推理服务器——llama.cpp、Ollama、vLLM、LocalAI、Docker Model Runner、LM Studio、Jan、MLX LM——都实现了路径和 JSON 结构相同的端点，区别只在端口和是否需要 API key。这意味迁移成本主要是一条 baseURL 配置，而非改写客户端：任何使用 OpenAI SDK 的编辑器插件、Agent 框架或脚本，只要把 base URL 指向 http://localhost:<port>/v1 就能切换后端。同一模型换服务器，行为差异来自后端引擎、上下文窗口和采样默认值，而不是接口本身。

LM Studio：先 GUI，后服务器

LM Studio（现品牌名 LM Studio Bionic）是一个桌面应用，在 llama.cpp 和 MLX 上运行模型。它适合想要模型浏览器和聊天窗口、而不是终端的人。本地服务器从 Developer 标签页或 lms server start 启动，同时暴露 OpenAI 兼容和 Anthropic 兼容端点。

应用本身闭源，只有 lms CLI 是 MIT。它也开始卖云推理（Bionic+ 每月 20 美元，Pro 每月 100 美元），本地运行模型仍免费。测试时版本为 Bionic 1.1.8。

vLLM：一整个团队打同一个端点时

vLLM 是本地模型变成共享内部服务时的去处。PagedAttention、连续批处理和前缀缓存让一块 GPU 同时应对许多并发请求，张量、流水线和专家并行把负载摊到多卡。它在 NVIDIA、AMD 和 Intel GPU 上说 OpenAI API 和 Anthropic Messages API。

它不是笔记本工具，目标机房或云上的 Linux GPU 服务器；Apple Silicon 支持是插件而非核心。如果做对比，SGLang（Apache 2.0，v0.5.21）是它最接近的开源同类。vLLM 为 Apache-2.0，93,753 星。

PagedAttention、连续批处理和前缀缓存，共同决定了一块 GPU 能同时服务多少请求。 传统推理把每个序列的 KV 缓存连续分配，显存碎片严重，长会话只能预留大块空间。PagedAttention 借鉴操作系统虚拟内存分页，把 KV 缓存切成固定大小的块，按需映射，浪费降到接近零。连续批处理（continuous batching）则让请求不必等整批生成完再换下一批：任一序列结束就立即插入新请求，GPU 利用率在并发场景下成倍提升。前缀缓存识别多个请求共享的系统提示词或文档前缀，只算一次 KV。三者叠加，是 vLLM 在单卡上支撑数十并发、而单用户脚本毫无收益的原因——它不是让单个请求更快，而是让许多同时进行的请求把硬件填满。

Jan：开源版 LM Studio

Jan 由 Menlo Research 打造，是一个桌面聊天应用，从 Hugging Face 拉取模型并在本机运行。它在 localhost:1337 提供 OpenAI 兼容 API，支持 MCP 接入 Agent 工具，允许把 OpenAI、Anthropic 或 Groq 的云模型混入同一窗口。其官网称下载量超过 700 万。

Jan 为桌面而生。无头服务器场景，llama.cpp 或 vLLM 更合适。Apache-2.0，44,938 星。

LocalAI：一个假装成 OpenAI 的二进制

LocalAI 在多个引擎前放一个 OpenAI 兼容 API，让针对 OpenAI 写的客户端代码继续跑在自己的硬件上。卖点是广度：文本、语音、视觉、图像和视频模型来自同一个二进制，还能在没有 GPU 的小 VM 或旧台式机上纯 CPU 运行。

广度的代价是运维。LocalAI 按服务器方式配置，后端越多，要维护更新的东西就比单引擎多。MIT，49,519 星。

Docker Model Runner：模型像镜像一样分发

Docker Model Runner 增加了 docker model run，从 Docker Hub 或任意 OCI 仓库拉取模型。它运行在 Docker Desktop、Docker Engine 中，或作为独立 dmr 二进制，模型像容器镜像一样被拉取、打标签和推送。

底层用 llama.cpp，在带 NVIDIA GPU 的 Linux 机器上还用 vLLM 和 Diffusers。12434 端口的 API 同时应答 OpenAI、Anthropic 和 Ollama 客户端，现有 Ollama 集成只需改个 base URL。弱点：仓库仅 659 星，相对它封装的引擎社区很小，模型覆盖取决于仓库里有什么。Apache-2.0。

MLX LM：Apple Silicon 上的 Apple 路线

MLX LM 是 Apple 用来在 MLX 上运行和微调语言模型的 Python 包——正是 Ollama 现在在 Mac 上用的框架。它一条命令加载 Hugging Face 模型，量化它们，并在同一台机器上做 LoRA 或全量微调。mlx_lm.server 暴露一个模仿 OpenAI 聊天端点的 API，默认 8080 端口。

它只在 Apple Silicon 上运行，官方文档称该服务器不建议用于生产。MIT，7,297 星。

八款工具一张表

工具	选择理由	本地 API	许可证
Ollama	一条命令启动	OpenAI 兼容，11434 端口	MIT
llama.cpp	速度和全部参数暴露	OpenAI 兼容	MIT
LM Studio	桌面 GUI	OpenAI 和 Anthropic 兼容	专有应用
vLLM	GPU 服务器上多用户（Mac 仅插件）	OpenAI 和 Anthropic 兼容	Apache-2.0
Jan	开源桌面应用	OpenAI 兼容，1337 端口	Apache-2.0
LocalAI	即插即用 API，含纯 CPU 机器	OpenAI 兼容	MIT
Docker Model Runner	已用容器的团队	OpenAI、Anthropic 和 Ollama 兼容，12434 端口	Apache-2.0
MLX LM	在 Mac 上微调	类 OpenAI，8080 端口	MIT

如何避免迁移两次

切换之前，按顺序做这几件事：

1. 先排除上下文窗口问题。 长提示词上质量崩塌，先设 OLLAMA_CONTEXT_LENGTH。4,096 token 默认值可能就是全部原因。
2. 在自己的模型上跑基准。 单台 Mac 上一个 0.8B 模型的个位数差距，说明不了 NVIDIA 卡上 70B 模型的任何确定结论。
3. 数一数有多少人打这个端点。 一个开发者是桌面问题。一个团队共享一个 URL 是 vLLM 问题。
4. 客户端留在 OpenAI API 上。 这里每个工具都能说它或近似它，所以换服务器主要是换 base URL。
5. 决定你更在意文件还是应用。 GGUF 文件在 llama.cpp、LM Studio、Jan 和 Ollama 之间自由流动，导入前可以用 GGUF Viewer 查看量化、上下文长度和聊天模板。MLX 权重留在 Apple Silicon 上。

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen3.5:0.8b", "messages": [{"role": "user", "content": "ping"}]}'

结论

Ollama 仍然是在本地跑起一个模型最简单的方式，对很多人来说这就够了。但它现在也是站在你可以直接运行的引擎之上的一个封装层，而背后的公司正把更多精力投向云套餐。先修上下文长度，在自己的硬件上跑基准，如果差距真的出现，底下的引擎离你只有一条命令。