ollama llama.cpp 区别

很多人第一次在本地跑模型，是先看到 Ollama 的一行命令，后来又在教程里碰到 llama.cpp，两边都能跑同一个模型文件，于是卡在「我到底该装哪个」。这篇不讲参数细节，只按你的使用形态（命令行还是写代码、单机还是塞进 App、要不要手动调量化）给一套对照和判断顺序，顺带说清什么时候两个都装、什么时候谁都不用。

很多人第一次在本地跑模型，是先看到 Ollama 的一行命令，后来又在教程里碰到 llama.cpp，两边都能跑同一个模型文件，于是卡在「我到底该装哪个」。这篇不讲参数细节，只按你的使用形态（命令行还是写代码、单机还是塞进 App、要不要手动调量化）给一套对照和判断顺序，顺带说清什么时候两个都装、什么时候谁都不用。

先记住一句话：它们不是同一层的东西。你在 Ollama 里选的量化档位，本质还是 llama.cpp 那一套的产物，所以拿「哪个更好」去比，往往会比错对象。真正要问的是：你需要一个能调的服务，还是要一套能嵌进自己代码的推理实现。

先把两者是什么说清：一个是工具链，一个是包装好的服务

llama.cpp 是偏底层的推理实现，围绕 GGUF 量化格式做 CPU/GPU 混合推理。你得自己拿权重、转格式、敲参数，好处是每一步都在你手里。Ollama 把模型下载、格式管理、常驻服务和 HTTP 接口打包好，一条命令就能拉起，代价是中间多了一层约定。

llama.cpp

一套推理工具链，权重和参数都由你准备，适合嵌进程序或压榨老硬件。

Ollama

一个常驻本地服务，把模型管理、接口和运行参数都封装好，先跑起来优先。

GGUF

一种量化后的模型文件格式，两边基本都围绕它工作，换工具通常不用换文件。

量化档位

同一模型按不同精度压出来的多个文件，档位越低越省内存，质量损失越明显。

判断要点就一句：你要的是「自己控每一步」还是「先跑起来再说」。前者往 llama.cpp 走，后者留在 Ollama。拿不准的话，去 /ai-dict/category/tech 把推理、量化、上下文这些词先过一遍，再回来看这篇会顺很多。

什么情况直接用 Ollama：要快、要接口、要少折腾

• 本机快速试模型效果，今天想跑三个不同模型比一比；
• 给内部小工具提供一个本地 HTTP 接口，前端或脚本直接调；
• 接桌面客户端做本地知识库，不关心底层线程怎么排；
• 教学演示或者给不太懂命令行的同事用，需要少踩坑。

好处是模型名称、路径、端口这些都有约定，改环境变量就行；默认行为也替你选好了，开箱能用的概率高。坏处是默认行为不一定贴合你的机器，显存吃紧或想用非标量化时，能拧的旋钮比直接上 llama.cpp 少。

接口地址、端口这类基础项先在 /ai-dict 里对齐术语，具体到参数再去 /models/deploy 做一遍显存和量化测算。别凭感觉选档位，跑不起来多数时候是模型文件跟机器对不上，不是工具的问题。

什么情况上 llama.cpp：要控、要嵌、要压榨老硬件

• CPU-only 的小主机，没有独显也想跑得动；
• Mac 上靠统一内存跑量化模型，想把内存用满；
• 把模型塞进自研程序或插件，作为其中一个模块；
• 需要按自己节奏调线程数、上下文长度和 KV 缓存。

它更像一个库而不是一个产品：你拿到的是权重和推理程序，失去的是开箱可用的服务层，模型下载、会话管理、并发这些得自己补。这不是缺点，是定位。

两者都装也很常见：用 Ollama 做日常快速验证，用 llama.cpp 做最终集成和边缘设备落地。前提是你清楚哪些模型文件能共用，别一边下了一份权重、一边又转了一份格式，磁盘先扛不住。

一张对照清单：三分钟定下来，再看要不要迁

先答四个问题：只自己用还是要给别人调接口？机器有没有独显、显存多大？能不能接受手动转权重和编译？模型以后会不会换得频繁？把答案填进下面这张表，基本就能定。

1. 准备同一个量化文件挑一个两边都能读的 GGUF 文件，别用两套权重，否则比较结果没有意义。
2. 各跑一次最小验证同样的提示词、同样的上下文设置，各跑一遍，记录显存占用、首字延迟和输出速度。
3. 核对数字再决定具体数值到 /tools/speed-test 看当时的记录，别用别人的截图当依据，机器差异很大。
4. 核一遍许可证和来源权重能不能商用和工具本身的开源协议是两回事，容易被混在一起，落地前单独确认。

迁移动作用最小验证就好：先拿同一个量化文件在两边各跑一次，再决定主用哪边。不要一上来就大改目录结构，万一发现两边都不合适，改回去的成本比你想的高。