Ollama把一切藏在一条命令后面，llama.cpp把每个旋钮都交给你。同一份GGUF文件，两种用法，选错了会浪费几天时间。

📜 目录

• 一句话结论
• 上手成本：两分钟 vs 二十分钟
• 功能对比
• 性能：单用户差距没想象中大
• 什么时候该选 Ollama
• 什么时候该选 llama.cpp
• 实际建议：两个都装
• 生态分工：两条路线的历史
• 常见问题
• 相关文章

Ollama vs llama.cpp 2026：本地大模型运行时到底选哪个

这两个项目经常被放在一起比较，但它们并不是同一类东西。Ollama 是一个完整的本地 LLM 产品：模型仓库、命令行、REST API、桌面应用，装完就能对话。llama.cpp 是一个 C/C++ 推理引擎，一个库，负责把 GGUF 权重高效地跑在各种硬件上。搞清这层区别，选择就变得很简单。

一句话结论

上手成本：两分钟 vs 二十分钟

Ollama 的路径是三条命令：

# macOS / Linux 安装脚本，Windows 用官方安装包
curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen3:8b
ollama run qwen3:8b

模型下载、量化档位、GPU 层卸载、上下文长度，Ollama 都替你决定好了。默认值在多数机器上是合理的，这也是它最大的价值。

llama.cpp 的路径是自己编译、自己找权重：

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release -j
./build/bin/llama-cli -m ./models/qwen3-8b-Q4_K_M.gguf -p "你好" -n 128

第一次编译要装 cmake 和编译器，Windows 上还要处理 MSVC 或 MinGW 工具链，折腾二十分钟很正常。换来的是每个候选参数你都能自己设。

功能对比

性能：单用户差距没想象中大

Ollama 的推理后端长期基于 llama.cpp 系实现（具体版本和实现方式以官方仓库说明为准），所以同一份 GGUF、同一台机器、单用户对话，两者的生成速度往往在同一量级，差个百分之几到百分之十几都算正常，更多取决于谁把参数调对了。

差别出现在两个地方。一是高并发：llama.cpp 的 server 面向单路低延迟，Ollama 提供了并行请求相关的环境变量和调度，但真要几十路并发，vLLM 这类带连续批处理的引擎才是对的选择。二是细粒度调优：llama.cpp 能设 -ngl（卸载到 GPU 的层数）、-t（线程数）、-c（上下文长度）、-ctk/-ctv（KV 缓存量化类型），显存刚好卡在边上时，这些参数能决定你跑得起来还是跑不起来。

什么时候该选 Ollama

• 你要做产品原型，需要立刻有 HTTP 接口，不想管编译。
• 团队里有非工程背景的同事也要用，桌面应用比命令行友好。
• 你不想维护模型目录和版本，希望一条命令升级。
• 你在笔记本上日常用，默认配置已经够。

什么时候该选 llama.cpp

• 显存或内存卡得很紧，需要精确控制卸载层数和 KV 缓存。
• 你要跑在非主流硬件上，或者把推理嵌进自己的 C++/Python 程序。
• 你想第一时间试新特性，比如新的量化类型、新的采样器实现。
• 你需要做基准测试，要固定每一个变量。

实际建议：两个都装

最省事的组合是 Ollama 当日常主力，同时编译一份 llama.cpp 留着。理由很实在：两者共用 GGUF 格式，同一个模型文件两边都能直接读，切换零成本。遇到 Ollama 跑不动、或者怀疑速度不对的时候，用 llama.cpp 跑同一个文件做对照，能立刻判断问题出在模型、硬件还是封装层。

# 同一个文件，两边跑，比较 tok/s
ollama run qwen3:8b --verbose
./build/bin/llama-cli -m qwen3-8b-Q4_K_M.gguf -t 8 -c 8192 -n 128

llama.cpp 输出里会分别给出 prompt 处理和生成阶段的耗时，除以 token 数就是每秒 token 数，这是最干净的对比方式。

生态分工：两条路线的历史

理解这两个项目的关系，有助于判断未来该跟谁走。llama.cpp 起步于"让大模型能在普通电脑上跑"这个目标，把 GGUF 格式、量化工具链、多硬件后端这几件事做成了事实标准。今天很多工具能离线跑模型，底层都是它这一套。

Ollama 则是在这套地基上盖房子：把模型仓库、版本管理、服务化接口、桌面体验补齐，让不关心底层细节的人也能用上。所以它们的定位是互补而不是竞争，Ollama 的演进方向是更好用，llama.cpp 的演进方向是更快、支持更多硬件。

这个分工带来的实际影响是：新硬件、新量化格式、新采样算法通常先在 llama.cpp 出现，过一段时间才被上层产品吸收。如果你的需求是"用上最新能力"，跟 llama.cpp；如果需求是"稳定省心"，跟 Ollama。

常见问题

Q：Ollama 能不能用自己下载的 GGUF？ A：可以。写一个 Modelfile，FROM /path/to/model.gguf，然后 ollama create 名字 -f Modelfile。这样私有微调模型也能纳入 Ollama 管理。

Q：llama.cpp 编译报错找不到编译器怎么办？ A：Windows 装 Visual Studio Build Tools 的 C++ 组件，Linux 装 build-essential 和 cmake。这一步没有捷径，卡住的人九成是缺编译器。

Q：为什么不直接用 vLLM？ A：vLLM 面向多用户服务，需要 NVIDIA GPU，对单机个人使用来说部署重量级。个人本地跑模型，Ollama 或 llama.cpp 更合适。

Q：星数能代表质量吗？ A：只能代表关注度。两个项目都在十几万星量级（以 GitHub 实时数据为准），一个偏产品一个偏引擎，星数高低和你的场景无关。

注：安装命令、环境变量与模型名称随版本迭代会变，具体以各项目官方文档为准。

相关文章

• llama.cpp优化技巧：在CPU和GPU上加速本地LLM推理
• 2026年本地运行Llama：llama.cpp（12.3万星）完整指南，从下载GGUF到任意硬件上聊天
• Web LLM（1.9万星）浏览器端推理2026：直接在浏览器里跑Llama和Qwen