很多人本地跑模型时卡在同一个问题上：看到 llama.cpp 和 Ollama 两个名字，不知道该装哪个，也说不清它们是不是竞品。其实一个是底层推理引擎，一个是把引擎包起来的易用外壳。这篇按「先搞清关系、再对照差异、最后按场景选」的顺序讲，并给出几个能直接照着做的判断动作。
很多人第一次本地跑模型时，卡在一个很基础的问题上：看到 llama.cpp 和 Ollama 两个名字，不知道该装哪个，也说不清它们到底是不是竞品。这里先把结论摆出来，省得绕弯子：这两个不是同一层的东西，一个是底层推理引擎，一个是把引擎包起来、让你少操心参数的外壳。
搞清这层关系之后，选择就简单多了。你要决定的其实是：要不要自己管模型文件、量化档位和运行参数。想省事就挑外壳，想自己掌控就选引擎。下面按「先理关系、再对照差异、然后按场景选、最后踩坑排查」的顺序讲，每一步都给出能照着做的动作。
先搞清关系：不是竞品，是上下层
把 Ollama 想象成一个带自动挡的车，llama.cpp 是发动机。Ollama 底层调用推理引擎把模型跑起来，llama.cpp 是其中被广泛采用的一类引擎，两者是调用和被调用的关系，不是互相替代的选项。所以「装哪个」这个问题本身，问的其实是「我要不要自己管参数和文件格式」。
- llama.cpp
- 偏底层的推理引擎，模型文件、量化、线程、显存卸载这些参数基本都摆在你面前，自己拿 GGUF 文件按路径加载。
- Ollama
- 在引擎之上加了一层易用外壳，有固定的模型拉取命令和存放位置，默认起一个常驻服务并暴露接口。
- 上下层关系
- Ollama 在运行时用到推理引擎，llama.cpp 属于可被调用的那类引擎，不存在谁取代谁。
换个说法：llama.cpp 面向的是想自己控制量化档位、线程数、显存卸载比例的那批人；Ollama 面向的是想一行命令把对话跑起来、不关心底层细节的人。选哪个的实质，是你愿不愿意把参数管起来。如果你的需求只是「能用就行」，那这个问题几乎不用纠结；如果你要抠显存、试不同量化，那上层外壳的默认值反而会挡住你。
底层差异对照：控制权、格式与运行方式
两者的差异集中在三块：模型怎么管理、参数暴露到什么程度、程序怎么被调用。下面这张表可以不背，但建议对着自己的场景看一遍，很快就能定位到该往哪个方向走。
| 对比项 | llama.cpp 侧 | Ollama 侧 |
|---|---|---|
| 模型管理 | 自己拿 GGUF 文件按路径加载，命名和存放自己定 | 有自带的模型仓库与拉取命令，存放位置由它接管 |
| 参数暴露 | 上下文长度、线程数、GPU 卸载层数等直接做成启动参数 | 通过配置或接口透传，部分细节被默认值盖住 |
| 调用方式 | 自带轻量服务端和命令行，接应用要自己配 | 默认起常驻服务并暴露兼容接口，接应用更省事 |
| 默认取向 | 控制权优先，参数越全越好 | 开箱优先，默认值替你做了不少决定 |
还要提醒一句：并发和吞吐这块，别指望靠换这两个工具来解决。两人同时用问题不大，真到多人共享、要稳定吞吐的时候就该考虑别的方案了。至于某个引擎在你这张卡上实际能跑到什么速度，跟显卡型号、量化档位、上下文长度都有关，没有一个放之四海皆准的数字，最好自己测一遍，或到 /tools/speed-test 看当时的对照。
按场景选：三步判断加一份对照
- 第一步：看你要不要调参只想跑通对话、不打算动参数，选 Ollama，把精力留给用起来这件事；要卡显存、试不同量化档位、控制 GPU 卸载层数，选 llama.cpp，它的启动参数更直观。
- 第二步：看硬件余量显存紧张时，先算清模型加量化的大致占用，再决定要不要手动设 GPU 卸载层数，这一步 llama.cpp 的操作更直接。算不准就先小档位跑一次，看有没有真的用到 GPU，再往上加。
- 第三步：看接入方式只是本地自己用，命令行够；要被别的程序调用、要常驻服务，优先挑带常驻服务和兼容接口的那一侧，省去自己搭服务端的工夫。
什么情况下这个判断不适用？当你的需求是多人共享、要求稳定高并发或者严格计费口径时，这两个都不该是你的最终选择，应该去看专门的推理服务方案，并按当时的资源占用去评估，而不是硬扛。
新手最容易踩的坑与排查顺序
本地推理出事，通常不是工具选错了，而是问题定位混在一起。先把「装不上」和「跑不动」分开：装不上多半是安装源、依赖或权限的问题；跑不动多半是显存或量化档位的问题。这两类现象不同，排查路径也完全不同，混着查只会浪费时间。
- 模型文件格式对不对：确认你加载的是引擎认的格式，别把不兼容的文件硬塞进去
- 量化档位是否超出显存：先降一档跑通，再逐步往上加，加不动就停
- 上下文长度是不是设得太大：上下文占的显存常被忽略，先调小试一次
- 是否真的用上了 GPU：跑起来时确认一下卸载层数和设备占用，别让它在 CPU 上硬扛
- 换工具前先记下当前配置：避免换完发现是参数问题，而不是工具问题
速度慢的时候，先量出基线再调参，别凭感觉改。先测一次延迟和生成速度，记下来，然后每次只改一个参数再测，这样才知道是哪个改动起了作用。这种量化的调参方式，比反复换工具有效得多。想知道同类方案当前的横向表现，可以到 /rankings 看当时的数字。
下一步如果你还在纠结该装哪个，先去 /sites 把本地推理相关的方案过一遍，重点看它们的接入方式和模型管理方式，再对照上面三步判断，基本就能定下来。→常见问题
Ollama 是不是就是 llama.cpp 套了个壳？
不完全是。它确实在底层调用推理引擎来加载和运行模型，但自己还加了模型仓库管理、常驻服务、接口层和配置体系。可以理解成把引擎、模型分发和调用入口打包成一个开箱即用的工具，代价是部分底层参数被默认值盖住，想细调需要绕一下。
我只想本地聊天，有必要折腾 llama.cpp 吗？
多数情况下没必要。如果目标就是跑通对话、偶尔换换模型，用带模型仓库和命令行的那一侧更省时间。真正值得切到底层引擎的场景是：显存刚好卡在边缘需要手动调卸载层数、想对比不同量化档位的效果差异，或者要自己控制模型文件来源。
这两个能同时装在一台机器上吗？会不会冲突？
一般可以共存，模型文件和运行目录各管各的，注意别让两边同时占满显存就行。实际用的时候建议先确认哪边在跑、显存被谁占着，再启动另一边。遇到启动失败先看是不是端口或显存被占，而不是直接怀疑装坏了。
