llama.cpp 还是 Ollama:2026 年该跑哪一个?

要最高的 tokens/秒和完全的控制权,跑裸 llama.cpp;要一条命令装好、开箱即用的 API 服务,用 Ollama。 Ollama 并不是竞争引擎——它是一个 Go 服务,把 llama.cpp 打包成自己的推理后端,再加上模型管理(ollama pull llama3.1),并在 11434 端口提供 REST API。所以真正的问题不是”哪个引擎更快”,而是”你想对这个引擎的旋钮掌控多少”。Ollama 出厂默认偏保守(Q4_K_M 量化、较小的上下文、直到不久前都没有 flash attention),同样的硬件能跑出肉眼可见的差距。下面:到底差在哪、速度差距从哪来、同一个模型在两边跑,以及一张决策表。

llama.cpp 和 Ollama 到底有什么区别?

llama.cpp 是推理引擎:GGUF 之父 Georgi Gerganov 的单个 C/C++ 项目,能在 CPU、GPU 或两者混合上跑量化模型。它给你 llama-cli 做一次性提问、llama-server——一个 OpenAI 兼容的 HTTP 服务器——外加引擎支持的每一个调优参数:GPU 层卸载、KV cache 量化、投机解码、自定义采样器。

Ollama 是架在这个引擎之上的产品。它 fork 并内嵌 llama.cpp,然后包上:

• 一个模型注册表(ollama pull、ollama list),自动切分 GGUF 权重;
• Modelfile 系统(一种类 Dockerfile 的提示词模板与参数规格);
• 一个后台守护进程,把模型焐在 VRAM 里,并暴露自己的 REST API;
• 自动硬件检测加安全默认值。

实际后果:用 Ollama,你管理的是模型;用 llama.cpp,你管理的是推理。只要你曾经想改量化格式、量化 KV cache、把上下文调过默认值、或者把特定层钉在 GPU 上,那就是 llama.cpp 的地盘。Ollama 把大部分旋钮藏了起来——故意的。

	llama.cpp	Ollama
本质	推理引擎(C/C++)	封装 llama.cpp 的服务
安装	源码编译或包管理器	一行命令安装,单个二进制
跑一个模型	llama-cli -m model.gguf + 参数	ollama run llama3.1
API	OpenAI 兼容(llama-server)	自有 REST + OpenAI 兼容端点
模型管理	自己去下 GGUF 文件	注册表:pull/list/rm
默认值	一切自己定	保守:Q4_K_M、较小上下文
引擎更新	第一时间(上游)	慢上游一拍
可调深度	全量(KV 量化、投机解码、采样器)	有限透传
适合	性能调优、服务器、边缘设备	快速上手、开发笔记本

llama.cpp 比 Ollama 快吗?

同一个 GGUF 文件、同一档量化、同样上下文、同一个 llama.cpp 版本——不,两者在误差范围之内,因为做算术的 Ollama 就是 llama.cpp。你看到的每一个”Ollama 慢 30%“的基准,实际都是在比默认配置。差距来自三个地方:

1. 量化选择。 Ollama 注册表默认 Q4_K_M。用 llama.cpp 跑同一个模型的 Q5_K_M 或 Q6_K,速度相近但每个 token 的质量更好——或者选 Q4_0/IQ4 换原始速度。
2. Flash attention 与 KV cache 量化。 --flash-attn 加 -ctk q8_0 -ctv q8_0 大幅缩小 KV cache,长上下文下 tokens/秒上升,同样的 VRAM 装得下更大的上下文。Ollama 只开放了其中一部分。
3. 版本滞后。 llama.cpp 每周都在合入 kernel 优化;Ollama 按自己的节奏合并上游。在同一台机器上,新编译的 llama.cpp 可能实测快过几个月前的 Ollama 二进制——直到 Ollama 追上来。

一条与引擎无关的快速基准命令——报告 prompt 评估和生成速度:

./build/bin/llama-bench -m Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99 -fa 1

拿它去跑 Ollama 自己的模型文件(~/.ollama/models/blobs/...,改名为 .gguf),你通常会和 Ollama 的数字完全一致——然后在 16k 上下文加 -ctk q8_0,反超它。

怎么在两边跑同一个模型?

两边都吃 GGUF。各自的最小端到端流程:

# --- Ollama 路线:安装、拉取、起服务 ---
curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b        # 下载 Q4_K_M,装进 VRAM,开一个聊天

# 它的 API,OpenAI 兼容风格:
curl -s http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3.1:8b",
  "messages": [{"role": "user", "content": "Say hi in 5 words"}]
}'

# --- llama.cpp 路线:编译、下载 GGUF、起服务 ---
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON    # 或者 -DGGML_VULKAN=ON / -DGGML_HIP=ON
cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf --local-dir models

./build/bin/llama-server -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf 
  -ngl 99 --ctx-size 16384 --flash-attn -ctk q8_0 -ctv q8_0 --port 8080

llama-server 暴露的是 OpenAI Chat Completions schema,所以同一段 curl 打向 http://localhost:8080/v1/chat/completions 原样可用。任何为 OpenAI API 写的工具——脚本、编辑器、RAG 管线——都能指向任意一边。真正干活的是参数:-ngl 99 把所有层卸到 GPU,--flash-attn 加 -ctk/-ctv 这一对让 16k 上下文塞进一张按 Ollama 默认配置会被拒绝的 8 GB 卡。

至于怎么挑 GGUF 文件本身、那些量化标签是什么意思,见 本地运行 GGUF 模型。

什么时候 Ollama 更合理?

大多数人应该从 Ollama 开始,这不是安慰奖:

• 你想今晚就跑起来。 一条命令,模型拉好,API 就绪。llama.cpp 意味着选后端(CUDA/Vulkan/HIP/Metal)、编译、手动下权重。
• 你同时玩很多模型。 注册表、自动卸载和 Modelfile 比手动管理一堆 GGUF 目录省心。
• 你的机器一般般。 Ollama 的默认值保守得有道理——几乎总能装下、跑起来。
• 你要一个稳定的 API 面。 Ollama 的守护进程替你管模型生命周期,常驻服务不用自己操心。

以下场景选裸 llama.cpp:做基准测试、任何规模的对外服务、跑在手机或树莓派上、小显存要长上下文、或者想在上游合并当天就用上新特性。重度用户往往两个都跑:Ollama 当日用机,一个钉住版本的 llama.cpp 留给那个需要最后 20% 性能的工作负载。

如果你的对比其实是桌面 GUI 应用,那是另一条轴——见 Ollama 对比 LM Studio;按任务挑引擎和模型,最适合写代码的本地 LLM 负责模型那一侧。

该用哪个?

按控制权决定,不是按速度。 引擎是同一个,默认值不是。目标只是”能跑、有 API”就装 Ollama——损失的几个旋钮你本来也不会去拧。要 tokens/秒、上下文长度或量化控制就编译 llama.cpp——每个旋钮都给你,代价是自己管模型。无论哪条路,跑的都是同一批 GGUF 文件,以后切换花的是一个下午,不是一次重写。