进阶 10 分钟工具

Ollama vs llama.cpp：2026年该如何选择 ?

比较 llama.cpp 与 Ollama，就像比较引擎与围绕它打造的汽车。Ollama 内置 llama.cpp 作为推理核心：两者都使用相同的代码计算 token。真正的差异在别处——Ollama 为您自动处理了什么，以及它隐藏了哪些精细控制选项。本指南将给出明确判断：Ollama 实际增加了什么、两者使用同一 GGUF 文件的基准测试、仅在直接使用 llama.cpp 时才能调整的设置，以及针对初学者、开发者或家庭实验室管理者的明确结论。

作者： Mohamed Meguedmi·更新于 2026-09-07·已在 Windows、macOS 和 Linux 上测试

#Ollama 与 llama.cpp 之间的实际关联

llama.cpp 是 Georgi Gerganov 开发的 C/C++ 项目，可在 CPU 和 GPU 上运行 GGUF 格式的语言模型，无需依赖 Python 或 PyTorch。它是整个本地生态广泛采用的核心推理组件：LM Studio、KoboldCpp、Jan 和 Ollama 都直接基于它，或基于它的 fork 版本。

Ollama 因此并非严格意义上的 llama.cpp 竞品：它是一种封装层。它内置了基于 llama.cpp 的自研引擎，增加了模型管理器、后台守护进程和 API 接口。当你运行 `ollama run qwen3` 时，实际生成 token 的是来自 llama.cpp 的代码。问题不在于「哪个更快」——在量化和硬件条件相同的情况下，性能非常接近——而在于「你更需要哪种抽象层级」。

i
同一个引擎，两种设计理念
Ollama 追求零配置：它会替您决定放到 GPU 上的层数、缓存格式和上下文长度。llama.cpp 则通过命令行让您调节其中每一项。前者着重缩短获得第一个 token 前所需的时间，后者着重提升可控性。

#Ollama 相比 llama.cpp 真正增加的功能

本地 AI 套件

只需 1 小时，即可在您的电脑上拥有专属的免费 ChatGPT — LM Studio、Ollama、Open WebUI、您的文档，无需云端。

  • 在线空间，终身可用
  • PDF + 文件
  • 30 天内退款
本地 AI 套件 →或 所有套件终身使用权 — 49 € →

手动编译并运行 llama.cpp，就意味着要自行管理 GGUF 文件的下载、文件路径以及一长串命令行参数。Ollama 会接管这些工作。相比单独使用引擎，它具体增加了以下功能：

模型仓库与拉取
`ollama pull qwen3:8b` 从 ollama.com 下载模型，采用默认量化（通常为 Q4_K_M），并将其存入 blob 仓库。无需在 Hugging Face 上手动查找正确文件。
常驻守护进程
一个服务在后台运行，并监听 http://localhost:11434。模型在两次请求之间保持加载在内存中（keep-alive），并在一段时间没有活动后自动卸载。
自动将计算任务分配到 GPU
Ollama 会估算可用显存，并自动在 GPU 和 CPU 之间分配网络层，无需手动调整 `-ngl`。便捷，但有时过于保守。
Modelfile
一个声明性文件（类似 Dockerfile）用于固定基础模型、系统提示、温度参数和聊天模板，并赋予一个可复用的名称。
兼容 OpenAI 的 API
除了原生的 /api/generate API，还提供一个开箱即用的 /v1/chat/completions 端点。任何 OpenAI 客户端只需更改基础 URL 即可接入。

相比之下，llama.cpp 让您可以掌控一切——但一切也都需要您自己完成。您要自行获取 GGUF 文件、编写命令行，并管理进程的生命周期。这就是完全掌控的代价，接下来的 llama.cpp 与 Ollama 对比会详细说明。

#先决条件

真正决定您能运行哪些模型的唯一因素是内存（RAM，或独立 GPU 上的显存 VRAM）。以下 Q4_K_M 量化下的参考值适用于这两款工具，因为它们使用的是同一个引擎：

3B ≈ 2 GB
几乎任何硬件都能容纳它，包括配备 12 GB 显存的 RTX 3060，而且还有很大的余量。
7B ≈ 5 GB
8 GB VRAM 即可舒适使用（RTX 3060、4060）
14B ≈ 9 GB
完全运行在RTX 3060 12 GB或4070 12 GB显卡上。
32B ≈ 19 GB
需要 RTX 4090 24 GB，或在 16 GB 显存的配置上，将模型部分卸载到 CPU，与 GPU 配合运行。
70B ≈ 40 GB
需要使用多 GPU、配备统一内存的 Mac（M4 Pro 48 GB），或将大部分模型卸载（offload）。
→
一个GGUF文件，两个工具
您无需下载模型两次。从 Hugging Face 获取的同一个 .gguf 文件，可直接使用 llama.cpp 运行，也可通过包含 `FROM ./modele.gguf` 的 Modelfile 导入 Ollama。这正是下文基准测试能够进行完全可比的比较的原因。

#安装并运行这两款工具

  1. 01
    安装 Ollama
    官方脚本在 Linux 上通过一条命令即可安装守护进程和命令行工具；在 macOS 和 Windows 上，可在 ollama.com 下载图形化安装程序。安装完成后，服务将监听 http://localhost:11434.
  2. 02
    使用 Ollama 启动模型
    `ollama run qwen3:8b` 会在首次调用时下载模型，然后开启聊天会话。无需配置其他内容：向 GPU 分配计算任务、上下文和模板均由系统自动管理。
  3. 03
    编译 llama.cpp
    克隆 ggml-org/llama.cpp 仓库，并使用 CMake 编译。GPU 后端选项取决于您的硬件：NVIDIA 使用 CUDA，Mac 使用 Metal（默认启用），AMD 使用 ROCm 或 Vulkan。
  4. 04
    使用 llama.cpp 启动一个 GGUF 模型
    `llama-cli` 加载您明确指定的 .gguf 文件，所有设置都在命令行中指定：GPU 层数（`-ngl`）、上下文大小（`-c`）、CPU 线程数（`-t`）。它不会替您自动推断任何设置。
Ollama — 立即启动
# Installer (Linux) puis lancer un modèle
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:8b

# Vérifier le daemon et lister les modèles
curl http://localhost:11434/api/tags
ollama list
llama.cpp — 编译与启动
# Cloner et compiler avec le backend CUDA (NVIDIA)
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

# Lancer un GGUF avec 35 couches sur le GPU et 8192 de contexte
./build/bin/llama-cli -m ./qwen3-8b-Q4_K_M.gguf -ngl 35 -c 8192 -p "Bonjour"
!
GPU编译的陷阱
编译时未指定正确的后端标志（`-DGGML_CUDA=ON`、用于 ROCm 的 `-DGGML_HIPBLAS=ON`、`-DGGML_VULKAN=ON`），会生成仅支持 CPU 的二进制文件，且不会给出任何提示。如果 llama.cpp 的运行速度看起来比 Ollama 慢十倍，几乎总是这个原因：您编译出的程序没有使用 GPU。请在加载时检查是否出现“offloaded 35/35 layers to GPU”这条消息。

#使用同一个 GGUF 模型对两者进行简单基准测试

结束争论的最佳办法：使用同一个文件，在同一台机器上分别测试两者。llama.cpp 提供了 `llama-bench`，这是一个专用工具，可以分别测量生成吞吐量（tokens/秒）和提示处理（prompt processing）的性能。

测量 llama.cpp 的性能
# Débit brut du moteur sur le GGUF, tout GPU
./build/bin/llama-bench -m ./qwen3-8b-Q4_K_M.gguf -ngl 99
# Sortie : colonnes pp (prompt) et tg (génération) en tok/s
使用同一个文件测试 Ollama
# Importer le GGUF dans Ollama sans le re-télécharger
printf 'FROM ./qwen3-8b-Q4_K_M.gguf\n' > Modelfile
ollama create qwen3-local -f Modelfile

# Chronométrer une génération (--verbose affiche les tok/s)
ollama run qwen3-local --verbose "Explique la photosynthèse en 200 mots"

2026年典型结果，GGUF模型相同且所有层均在GPU上运行：生成速度几乎完全一致，仅相差几个百分点。这是合理的，因为使用的是相同的计算内核。所观察到的差异几乎总是源于隐式设置的不同，而非模型引擎本身：

卸载的模型层
Ollama 可能出于对显存使用的谨慎考虑，将部分层留在 CPU 上，而 `llama-bench -ngl 99` 会将所有层放到 GPU 上。结果是 Ollama 看起来更慢，实际原因却是层的分配方式不同。
上下文长度
更大的上下文会为 KV 缓存预留更多 VRAM，从而减少可用于存放权重的空间。比较时请使用相同的上下文长度。
Flash Attention 与 KV 缓存
无论是否启用、是否量化，这些设置都会影响吞吐量。在llama.cpp中由用户手动设置；在Ollama中则取决于版本及环境变量。
i
基准测试的真实结论
在完全相同的配置下，Ollama 和 llama.cpp 每秒输出的 token 数量相同。因此，两者之间的选择并非单纯速度问题，而是控制与使用体验的问题。

#精细设置仅在 llama.cpp 中可用

正是在这里，llama.cpp 与 ollama 的对比明显偏向一方。llama.cpp 通过直接暴露引擎参数，提供了 Ollama 隐藏或仅部分暴露的调节选项。对于高级使用场景，这些设置将产生根本性影响：

精细控制卸载（-ngl）
您可以精确到每一层，决定有多少层放到 GPU 上。在显存刚够用的情况下，相比 Ollama 多将 2 或 3 层放到 GPU 上，就可能让模型从“缓慢”变为“流畅”。
量化 KV 缓存（-ctk/-ctv）
将 KV 缓存量化为 q8_0，几乎可以将上下文所占内存减半，从而在显存容量不变的情况下支持长得多的上下文窗口——这项调节手段在 Ollama 中不太容易使用。
Flash attention (--flash-attn)
显式启用优化注意力机制，对长上下文的处理速度和内存占用有直接影响。
推测解码 (--model-draft)
接入一个小型“草稿”模型来加速大模型。生成代码时，加速效果可能相当显著，而且 llama.cpp 原生支持这一功能。
GBNF 语法（--grammar）
约束输出，使其符合形式语法（严格 JSON、枚举、自定义格式）。这是实现可靠结构化输出的必要条件，而且比 Ollama 的 JSON 模式提供更细粒度的控制。
RoPE 与上下文扩展
调整`--rope-freq-base`和`--rope-freq-scale`，将上下文长度扩展到超出原始训练时的长度，同时控制性能下降的程度。

Ollama 通过 Modelfile 参数或环境变量提供其中一部分设置，但很少能做到同样精细的控制，而且对 llama.cpp 新功能的支持往往有所滞后。如果您需要的是“在我的显存容量内实现尽可能长的上下文”或“保证格式有效的 JSON”，直接使用底层引擎就能调整一些被封装层锁死的设置。

#API 服务器：Ollama 与 llama-server 对比

这两个工具都能通过 HTTP 提供模型服务。Ollama 的守护进程通过 http://localhost:11434 对外提供服务，带有原生 API（/api/generate、/api/chat）和兼容 OpenAI 的端点（/v1/chat/completions）。llama.cpp 则提供 `llama-server`，这是一个二进制可执行文件，可启动兼容 OpenAI 的 API，并附带一个小型网页界面。

使用 llama-server 提供服务
# API OpenAI-compatible sur le port 8080, tout GPU
./build/bin/llama-server -m ./qwen3-8b-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080
# Interface web : http://localhost:8080  ·  API : /v1/chat/completions
按需使用多个模型
Ollama 根据请求自动加载或卸载多个模型。`llama-server` 的每个进程只提供一个模型的服务——运行逻辑更容易理解，隐式自动处理也更少。
启动参数控制
使用llama-server时，每个引擎设置（上下文长度、KV缓存、Flash Attention）都通过显式启动参数指定。非常适合固定可复现的生产配置。
生态系统
Ollama 在端口 11434 上提供的 API 已成为事实上的标准：Open WebUI、代码编辑器和各类集成都直接对接这一 API。这确实让使用更加方便。
→
可以混合使用
不必永久选定其中一方。许多人保留 Ollama，用于日常使用和连接 Open WebUI；遇到需要更长上下文或量化 KV 缓存的特定工作负载时，再使用 llama-server。同一个 GGUF 文件，两种使用入口。

#按用户类型给出选择建议：初学者、开发者、家庭实验室用户

由于两者使用同一个引擎，选择的依据不是性能，而是您的使用习惯和对命令行的接受程度。

初学者 → Ollama
一条命令安装，一条命令启动，模型无需任何设置就能“用起来”。为了与 LLM 聊天，完全没有必要编译 C++ 代码。继续使用 Ollama 即可，也可以搭配 Open WebUI。
开发者 → 两款
Ollama 适合快速制作原型，并可立即提供兼容 OpenAI 的 API；需要 GBNF 语法、推测解码或精确控制 KV 缓存时，则使用 llama.cpp。两者之间切换很轻松，可以共用 GGUF 文件。
家庭实验室/自托管 → llama.cpp（llama-server）
如果要充分利用有限的显存、固定一套可复现的配置并扩展上下文，直接使用底层引擎更有优势。相应的代价——编译、编写命令行参数、管理进程——恰好也是您希望掌握的内容。

一句话总结：Ollama 是最佳起点，足以满足绝大多数用途；只有当上下文、KV 缓存、语法规则或精确到每一层的 GPU 卸载等具体设置成为限制因素时，才转向直接使用 llama.cpp。这不是替换工具，而是获得更细致的控制。

#深入了解

这些指南是本篇对比的延伸，涵盖从安装到细致调优的各个环节：

Ollama 入门
「5分钟内安装 Ollama（Windows、macOS、Linux）」涵盖守护进程和首个模型的安装，侧重于简易性。
无需 Ollama 即可提供模型服务
《llama-server：基于 llama.cpp 的本地 OpenAI API》从控制角度详细介绍了模型层卸载的精细控制，以及内置的网页界面。
选择量化方式
「2026年GGUF量化：Q4_K_M对比Q5_K_M对比Q6_K」有助于选择合适的.gguf文件，该文件在两个工具中通用。
这份指南对您有帮助吗？

有反馈、发现了错误，或想补充说明？请告诉我们，让这份指南对每个人都更有帮助。