Ollama vs llama.cpp：本地大模型部署，怎么选才合适？

Ollama vs llama.cpp：本地大模型部署怎么选？

如果你负责开发者工作站，或规模不大的内部模型服务，选 Ollama。 它提供模型管理命令、可命名的配置，以及面向应用的 API，让模型从下载到真正可用少走一些步骤。内存规划和访问控制仍然要做，但不必把那么多推理服务的配置细节写进每个人的环境搭建说明。

如果推理配置由你负责，选 llama.cpp。 需要指定确切的 GGUF 文件、检查新的量化版本、调整 GPU 分配，或调优并发请求与上下文容量时，它更合适。好处是部署的每个细节都能说清楚；代价是这些配置也要由你自己维护。

如果现有运行时已经满足响应和质量要求，就继续用。 仅仅因为别人晒出一组更快的笔记本测试结果，就从 Ollama 迁到 llama.cpp，理由并不充分。先明确自己缺少哪项控制能力，或者要解决哪个已经测量过的问题，再决定是否迁移。

本文于 2026 年 10 月 16 日对照两个项目当时的在线文档完成核实，比较维度包括安装、模型文件控制、API 行为、并发和硬件支持。本文不包含亲自上机进行的性能测试。

上述能力见 Ollama CLI 指南、GGUF 导入指南和 llama.cpp 服务端参考文档。两个项目的本地软件都免费，Ollama 的托管服务另当别论；模型本身的许可证也需要单独考虑。参见 Ollama 仓库、llama.cpp 仓库。

同源的推理技术，不同的运维职责

Ollama 在推理能力之上增加了模型管理和服务层；llama.cpp 则直接提供推理工具。 推理就是用模型权重处理输入，再生成输出 token。要把这项工作管理起来，还得找到模型、为配置命名、加载模型、接收请求，以及淘汰旧的模型文件。

Ollama 在仓库中致谢了 llama.cpp。但说它“只是一个套壳”过于绝对：当前源码还包含其他后端相关实现，包括 MLX 组件。技术上有渊源，不代表每个模型都使用相同的后端、代码版本或执行路径。参见 Ollama 源码与致谢。

可以把这道选择题理解为：你打算把多少底层细节写进部署说明？如果开发者只需要一个明确的模型名称和接口地址，Ollama 的封装很有帮助。如果基础设施负责人需要同时掌握文件校验和、后端构建方式与内存设置，直接配置 llama.cpp 更容易把这些细节交代清楚。

安装与模型管理：日常使用，Ollama 更省心

Ollama：把反复搭建的环境封装好

Ollama 是本地模型运行工具，提供模型库管理和服务 API。 它提供 macOS、Windows 和 Linux 下载版本，CLI 包含 IT 负责人日常需要的操作：pull、run、ls、rm、ps 和 stop。Modelfile 是描述模型配置的文本文件，可以把基础模型和指令打包，并赋予一个名称。参见 Ollama 快速入门、CLI 参考文档。

做团队共用的编程助手试点时，把批准使用的模型、配置和接口地址统一记录下来即可。开发者不应该只是为了接入应用，就必须先学会分配 GPU 资源。这正是选择 Ollama 而非 llama.cpp 最有说服力的理由。

当封装好的工作流无法表达你需要的推理服务行为时，限制就出现了。不要默认上游 llama.cpp 的参数能原样传给 Ollama。准备围绕某项设置设计部署方案前，先确认已安装版本是否真的提供它。

llama.cpp：直接掌控，不等于必须自行编译

llama.cpp 是一套推理工具，包含命令行、HTTP 服务端和 Web 界面。 当前 README 提供安装器、预编译发行包、Docker 和源码构建等选项，也介绍了通过 llama cli -hf 和 llama serve -hf 从模型托管平台 Hugging Face 直接加载模型的方法。源码编译是一种选择，不是入门的前提。参见 llama.cpp 安装与快速入门。

直接使用 llama.cpp，也不意味着以后每个模型都得手动启动一个独立、互不关联的进程。服务端文档介绍了支持模型目录和配置预设的路由器。区别在于，这套运维方式中有多少内容需要你自行选择和维护。参见服务端路由文档。

这一项，Ollama 更适合日常安装和模型管理。 只有显式配置确实能为你的工作流带来价值时，才值得在这里选择 llama.cpp。如果真正需要的是桌面模型工作台，更应该比较的是 Ollama 与 LM Studio。

GGUF 与量化：llama.cpp 更便于精确控制模型文件

两者都能运行 GGUF 模型；llama.cpp 提供的模型准备和选择流程更直接。 GGUF 是存储模型权重与元数据的文件格式。量化通过降低权重的存储精度来缩小占用，但质量上的取舍取决于模型和任务。

llama.cpp 的量化工具文档列出了 Q4_K_M、Q5_K_M 和 Q8_0 等格式，还提供重要性矩阵和逐张量控制。重要性矩阵有助于判断模型哪些部分需要更高精度；逐张量控制则允许对不同的权重数组采用不同处理方式。当现成下载的模型无法满足内存或质量要求时，这些能力就有了价值。参见 llama.cpp 量化指南。

Ollama 可以通过 Modelfile 中的 FROM 行导入准备好的 GGUF。当前文档明确说明，导入 GGUF 不会对模型进行量化，需要先用 llama-quantize 等工具处理。这是一种实用的分工：用 llama.cpp 准备模型文件，再通过 Ollama 分发命名配置。参见 Ollama 导入文档。

例如，将兼容的单文件文本模型放在 ./team-model.gguf 后，以下命令会创建一个 Ollama 配置，并指定上下文容量：

cat > Modelfile <<'MODEL'
FROM ./team-model.gguf
PARAMETER num_ctx 8192
MODEL
ollama create team-local -f Modelfile
ollama run team-local

文件名和模型名都可以自行选择，上下文设置也只是示例，并非适用于所有负载的推荐值。语法来自 Modelfile 参考文档。

不要把 .gguf 扩展名当成兼容性保证。运行时仍然需要支持模型架构，以及把消息转换为模型预期输入的对话模板。多模态模型还可能需要独立的视觉或音频组件，llama.cpp 量化指南说明了额外的投影器文件。仅仅成功得到一条文本回复，并不能证明图像输入或工具调用也可用。

这一项，需要自定义量化和精确选择模型文件时，llama.cpp 更合适。 如果准备好的模型已经可用，而你更喜欢 Ollama 的运维方式，继续用 Ollama 也没问题。模型权重和运行时可以分开选，模型选择可参考《2026 年最佳本地 LLM》。

服务端与 API 兼容性：常规集成，Ollama 更顺手

应用只需要接入一个文档清楚的本地模型 API 时，Ollama 更适合作为默认选择；需要调优服务端配置时，llama.cpp 更有优势。 Ollama 提供原生 API 和兼容 OpenAI 的接口。llama.cpp 也提供兼容 OpenAI 的 chat completions、responses 和 embeddings 接口。这里的“兼容”意味着请求接口熟悉，并不保证所有功能的行为完全一致。参见 Ollama API 文档、llama.cpp 服务端参考文档。

某项具体限制可能直接决定迁移是否可行：Ollama 的 Responses API 是无状态的，不支持 previous_response_id 或 conversation。如果应用依赖这些字段让服务端记住对话，只修改基础 URL 并不够。需要核对目标服务端文档中的行为，再决定由哪里保存对话历史。

上下文配置也是一道边界。Ollama 的 OpenAI 兼容性指南要求通过 Modelfile 修改本地模型的上下文大小。这个设置与输出 token 上限不同：允许回答更长，并不会自动让模型容纳更长的输入。

直接部署 llama.cpp 时，服务端提供模型别名、聊天模板设置、API 密钥和可选的指标功能。内部助手需要保持 API 中的模型名称不变、同时替换底层模型文件时，这些选项很有用。不过，升级时也会多出一批需要审查并保留的配置。

并发调优：llama.cpp 的推理服务控制更直接

Ollama 能处理同时到来的请求；llama.cpp 则把更多调度和内存配置直接开放出来。 同时加载多个模型，与同时处理多个请求，是两回事。加载一个编程模型和一个嵌入模型，与多段对话共用一个已加载模型，内存消耗方式并不相同。

Ollama 文档介绍了 OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS 和 OLLAMA_MAX_QUEUE。每个模型的默认并行请求数为 1，能否并行处理取决于可用内存。调大队列上限只能让更多任务排队，并不会增加推理能力。参见 Ollama 并发文档。

llama.cpp 文档介绍了并行解码、连续批处理和服务端槽位。连续批处理允许服务端在正在执行的请求完成后接纳新任务；槽位则是处理请求的位置。相关控制项包括 --parallel 和 --kv-unified-per-slot，此外还有 GPU 分配与缓存设置。参见 llama.cpp 服务端控制选项。

提高并发之前，先算上下文容量

以一个试点配置为例，4 个同时执行的请求 × 8,192 token 上下文 = 32,768 个 token 位置。这表示上下文容量，不是 RAM 用量。KV 缓存保存模型的注意力状态，它和权重及其他运行时分配一起占用内存。具体占多少字节，取决于模型架构和缓存精度。

使用前文示例中兼容的 team-model.gguf，当前版本的 llama.cpp 可以直接表达这组配置：

llama serve -m ./team-model.gguf \
  --alias team-local \
  --host 127.0.0.1 --port 8080 \
  --parallel 4 \
  --kv-unified-per-slot 8192

这些是为试点选定的设置，并非测试结果或项目默认值。服务端文档说明，未显式指定 --ctx-size 时，共享 KV 缓存池的容量由槽位数乘以每个槽位的上限确定。访问控制准备好之前，试点服务应继续只监听回环地址。

使用 Ollama 时，在服务环境中配置并行度和上下文，再通过 ollama ps 检查实际生效的上下文，以及模型在 CPU/GPU 上的分配情况。它的上下文专门文档说明了默认值如何随硬件变化，因此应记录实际使用的容量。参见 Ollama 上下文配置。

Ollama 与 llama.cpp 性能对比：先明确负载

没有哪个项目能仅凭名字，就在所有延迟或吞吐量测试中胜出。 比较前，要对齐权重、量化、模板、上下文、后端和硬件。然后分别考察排队等待时间、首 token 延迟、生成速度，以及负载下完成的请求数。

对于内部支持助手，单次回复很快，并不能证明员工可以流畅地同时使用。应回放具有代表性的短问题和长文档请求，单独统计冷启动，并记录运行时版本和测试日期。一份速度差异报告，只有交代了测试者、日期、硬件、模型和负载，才值得参考。

这一项，有明确的并发调优需求时，llama.cpp 更合适。 如果 Ollama 的设置已经满足服务目标，而且简化运维比增加控制项更重要，就继续用 Ollama。

Apple Silicon 与 GPU 支持：让后端适配硬件

常规工作站部署，Ollama 更方便；需要专门控制后端时，llama.cpp 更有优势。 两者都支持 Apple GPU 加速。Ollama 文档说明了 Metal 支持；llama.cpp 则把 Apple Silicon 作为重点支持的平台，使用 Metal、Accelerate 和 ARM 优化。参见 Ollama 硬件支持、llama.cpp 支持的硬件。

在 Mac 上，先从原生应用或原生二进制程序开始。Ollama 文档说明，macOS 上的 Docker Desktop 不提供 GPU 加速。因此，把一个正常工作的原生环境搬进容器，可能会改变执行路径，让原本以为条件一致的对比失去基础。参见 Ollama 关于 Docker GPU 的说明。

对于其他工作站，Ollama 文档列出了 NVIDIA 支持、通过 ROCm 支持 AMD，以及安装相应后端后的 Vulkan 支持。llama.cpp 则提供面向 NVIDIA 的 CUDA、面向 AMD 的 HIP，以及 Vulkan 和 SYCL 路径，并在构建说明中介绍如何选择后端。需要核对具体的操作系统、GPU 和驱动组合，不能仅凭显卡厂商名称就认定可用。参见 Ollama GPU 指南、llama.cpp 构建指南。

实际排查时，先看模型放在哪里：权重是在 GPU、CPU，还是分布在两者之间？如果模型加上下文所需的内存超过了分配额度，再多配置项也解决不了。先选一个装得下的配置，再判断回答质量是否可以接受。

Muse Spark Open 给这道选择题带来了什么？

Meta 点名支持 llama.cpp，意味着多了一条有官方依据、值得验证的推理引擎路径，并不意味着应该立即替换 Ollama。 在 2026 年 10 月 15 日的 Muse Spark Open 公告中，Meta 将 llama.cpp 列入支持的推理引擎。如果想评估这款新发布的模型，又不愿假设其他运行时已经封装了同等支持，直接使用 llama.cpp 就值得考虑。参见 Meta 公告。

硬件背景不能忽略。Meta 给出的模型规模为总参数量 816B、激活参数量 42B，桌面示例使用的是两台 Apple M5 Ultra Mac Studio，搭配 MLX。这个示例不是 llama.cpp 的性能测试，激活参数量也不能代替对完整模型内存需求的核算。参见 Meta 的硬件与模型说明。

落到自己的部署上，需要一起核对具体构建版本、模型文件、量化、模板，以及所需的输入类型。发布公告中列出某个引擎，不代表你安装的 Ollama 版本已经支持该模型，也不代表普通开发者笔记本就能装得下。它给基础设施负责人增加了一条评估路径；要推广到工作站，仍需单独验证。

从 Ollama 迁移到 llama.cpp：配置也要一起搬

迁移的重点是保留原有行为，而不只是复制权重。 应用的历史记录、检索索引和请求处理逻辑，可能都位于这两个运行时之外。替换模型服务时，要把这些边界分清楚。

如果现有服务运行良好，也没有人需要额外的控制能力，就不要迁移。 也可以用 llama.cpp 准备 GGUF，再继续通过 Ollama 提供服务。两个项目完全可以负责同一工作流中的不同环节。

Ollama vs llama.cpp vs vLLM：什么时候该走出工作站？

当持续的多人访问或分布式推理成为核心需求时，可以评估 vLLM。 vLLM 是推理服务引擎，其文档重点介绍了连续批处理、缓存管理和分布式执行选项。当你围绕专用加速硬件资源运营服务时，这些能力值得评估。参见 vLLM 文档。

连续批处理本身并不是分界线，因为 llama.cpp 也支持它。也不存在一个通用的员工人数门槛，一达到就必须迁移。偶尔收到短请求的服务，与人数更少、却持续提交长编程任务的团队，负载完全不同。

决策标准应当可测量：如果当前方案在有代表性的峰值需求下达不到响应目标，而 vLLM 恰好提供所缺的控制项或部署能力，就开展评估。如果当前方案已经达标，继续用即可。另一篇 Ollama 与 vLLM 对比会深入讨论这类服务部署决策。

下周一就可以动手：选定一项本地工作流，固定模型和上下文，设定预期并发需求，在扩大访问范围前进行回放。让结果告诉你，究竟需要换运行时，还是只需要把配置做好。

常见问题

用 AI 业务工作流审计清单选出第一项值得在本地提供服务的私有工作流，并订阅通讯，跟进后续工具变化。