llama.cpp 与 ollama比较

想在自己机器上跑模型，翻了一圈发现 ollama 装起来就能用，llama.cpp 又总跟量化、GGUF 绑在一起，到底该选哪个？这篇不比较跑分，只按你的使用方式和硬件条件拆开讲：什么情况装 ollama 更省事，什么情况非得上 llama.cpp，以及两边互相迁移时容易踩的坑。

想在自己机器上跑模型，翻了一圈发现 ollama 装起来就能用，llama.cpp 又总跟量化、GGUF 绑在一起，到底该选哪个。这篇不比较跑分，也不比谁更强，只按你的使用方式和硬件条件拆开讲：什么情况装 ollama 更省事，什么情况非得上 llama.cpp，以及两边互相迁移时容易踩的坑。

先给个大概印象：一个是「引擎加工具链」，一个是「开箱即用的运行与管理外壳」。名字听着像竞品，其实定位不在一个层面。先把这层关系理清，后面的选型判断就顺了。

先分清两者的定位差在哪

llama.cpp 本质上是一套推理引擎和量化工具链，核心工作是把模型权重转成自己的量化格式，然后在 CPU 或 GPU 上把它高效跑起来。它的命令行参数多、可控性强，你几乎能碰到每一层细节：线程怎么分、上下文开多大、多少层权重卸载到内存。代价就是这些东西得你自己调。

ollama 则是打包好的本地模型运行与管理工具。它把「拉模型、跑服务、开接口」这几步做成一条命令，底层同样依赖推理引擎。它的价值不在引擎本身，而在把运维动作标准化了：模型放哪、怎么删、怎么常驻、怎么被别的软件调用，都有现成约定。

不适用的情况也说清楚：如果你根本不需要本地跑，只想用官方网页版或云 API，那这两者都不用碰，直接去站内官方 API 价格页面对比当时的数字就行。

这些场景直接用 ollama 更省事

• 个人笔记本、桌面机，想快速验证一个模型能不能跑、效果够不够用，装完拉下来就能对话，不用先折腾编译。
• 需要给第三方工具（聊天界面、知识库、编辑器插件）提供本地接口时，它默认起服务、暴露本地端口这件事做得更顺，省掉自己写一层封装的功夫。
• 多模型来回切换、想统一管理模型文件的存放位置和删除，用它的模型管理命令比手动翻目录省心。
• 只是偶尔用一下，不想长期维护一套环境，装一个能跑就行的方案性价比更高。

不适用的情况：需要自定义量化档位、线程数、上下文长度、显存卸载比例的极限调参，ollama 能调的东西比引擎本身少一截；或者你的机器资源刚好卡在边缘，需要压榨每一分显存，这时候它的默认策略未必是最优解。

这些场景 llama.cpp 更合适

• 硬件比较吃亏：只有 CPU、核显，或显存刚好卡在模型边缘，需要按层数手动把部分权重卸载到内存里才跑得动。
• 要自己挑量化格式与档位，在输出质量和内存占用之间做取舍，这类精细控制是它的强项。
• 要把推理接进自己写的程序或服务里，需要底层库级别的调用，而不是只调一个 HTTP 接口。
• 对响应延迟有明确要求，需要针对自己的机器反复压参数找那个平衡点。

# 先确认本机能被引擎识别的加速后端与可用内存量\n# 再决定是整模型放进显存，还是按层卸载\n# 具体命令与参数名以你所用引擎版本的帮助输出为准，别照抄旧教程

不适用的情况：对命令行不熟、也不想研究参数，硬上 llama.cpp 只会让搭建时间远超实际使用时间。真要走这条路，先去站内 AI 术语词典把量化、上下文、显存卸载这几个词过一遍，再来配参数会顺很多。

两边互相迁移时的排查顺序

1. 第一步：看权重格式引擎原生吃的是自己的量化格式，ollama 管的模型文件有自己的存放结构。直接复制文件通常不通用，要按各自文档做导入或转换。先确认你手上的文件是哪一种，再决定要不要转。
2. 第二步：对参数上下文长度、并发数、线程数在两边默认值不一样。迁移后如果感觉变慢、或者答到一半就断，先怀疑这里，而不是先怀疑模型本身。
3. 第三步：查环境变量模型存储路径、绑定地址、是否常驻显存这类设置，两边命名不同，搬配置不能照抄。逐项对照两边文档里的变量名，确认生效了再往下走。
4. 第四步：同题对照跑一遍用同一段提示词各跑一遍，只比「能不能稳定出结果、响应快慢是否可以接受」。别拿跑分当唯一依据，自己的机器和实际用法才是标准。

想横向看不同机器和不同配置下的本地推理表现，可以去站内工具目录的速度测试条目，用统一的测试方法自己跑一遍，比看别人的结论靠谱。要对照模型规模和硬件要求，站内模型资料库里也有按硬件条件分类的整理，数字以页面当时显示的为准。