ollama llama.cpp 关系

很多人装了 Ollama 之后才发现它底层跑的其实是 llama.cpp，于是困惑：那我到底装了两个东西还是一个？该学哪个、命令为什么长得不一样、出问题该看谁的日志。这篇不重复「两者有啥区别」的结论，而是把依赖链条拆开：谁在编译、谁在推理、谁在管模型文件，再给出几条你能在自己机器上验证的方法。

很多人装完 Ollama 才发现，底层推理那一步并不是它自己从零写的，而是走了一套成熟的推理引擎。于是问题就来了：我到底装了两个东西还是一个？该学哪个命令？出问题了该翻谁的日志？

这篇不跟你重复「两者有啥区别」的结论，而是把依赖链条拆开看：谁在编译、谁在真正算、谁在管模型文件。看完你至少能在自己机器上验证一遍，而不是靠听别人说。

先分清：谁调用谁，谁在真正算

llama.cpp

推理引擎，负责加载权重、做矩阵计算、吐出一个个 token，本质是一套库加几个命令行程序

Ollama

上层封装，管模型拉取、版本标签、常驻服务、HTTP 接口，真正算的时候交给内置的推理后端

所以这两者不是竞品，是「壳与芯」的关系。你卸载 Ollama，不会动到自己单独编译的 llama.cpp；反过来你把 llama.cpp 删了，Ollama 只要用的是自带的那份后端，照样能跑。判断依据很简单：看进程名、看是谁在吃 CPU/GPU，别只盯着命令行里敲了哪个词。

• 打开任务管理器或 top，观察跑模型时被拉起来的是哪个可执行文件
• 看 Ollama 的安装目录里有没有一份独立的后端二进制，还是静态链进主程序
• 把 Ollama 停掉，再手工跑一次 llama.cpp 命令行，确认两者互不影响
• 记住：命令长得不一样，是因为一个在包服务、一个在包推理，不是两套不同技术

那为什么还各自独立存在

如果你只是想改造采样参数、直接加载某个量化文件、跑一些结构比较冷门的模型，llama.cpp 更直接，中间没有一层在替你决定参数。反过来，你想要一行命令起服务、让别的程序通过接口调用、模型目录自动管理，Ollama 省事得多，代价是可调范围被收窄。

什么情况下不适用：要跑高并发、要张量并行上多卡，这两条路都不该硬扛，该换面向吞吐的推理服务方案。判断动作就一句话——先写下你是「只想本地对话」还是「要嵌进自己的程序」，前者偏 Ollama，后者先评估再定。

三步自查：确认你机器上的真实依赖

1. 看安装目录与运行时依赖翻一遍 Ollama 的安装路径，确认推理后端是随包内置，还是外挂了一个独立可执行文件；两种情况的升级和排错方式不一样。
2. 同一模型跑两遍做对照把同一个量化模型分别用两种方式跑一次，对比启动日志里打印的后端名、线程数、显存卸载信息是否一致。不一致，说明你其实在用两个不同的后端。
3. 按层排除，而不是重装结果异常或速度不对时，按「模型文件—推理后端—上层服务」的顺序逐层排除。先确认模型文件本身能加载，再看后端参数，最后才怀疑上层服务。

给你的落地清单

• 只在单机做对话和知识库：装 Ollama 就够，别为了「摸底层」再去编译一遍 llama.cpp
• 要精细控参或跑小众模型：直接上 llama.cpp，先跑通命令行，再考虑包一层服务
• 要对外提供稳定接口、多用户并发：这两个都更适合做验证，正式环境按 /models/deploy 的测算流程走一遍
• 迁移前先确认模型格式与许可证，量化格式不通用时换工具意味着重新下载
• 拿不准就跑同一模型做一次对照，用自己机器上的日志说话，而不是听结论

最后提醒一句：具体的内存占用、速度差异这类数字，别信任何一张流传的截图。到 /tools/speed-test 用你手上的机器和模型实测一遍，再看当时的数字，才有参考意义。