很多人用 ollama 跑本地模型，遇到上下文长度、显存占用、模板不对、输出慢这些问题时想调底层，才发现 ollama 其实是把 llama.cpp 封了一层。这篇不重复「两者区别」那类结论，而是给你两条可落地的路径：走 ollama 的服务接口做参数覆盖，或者直接拿 GGUF 走 llama.cpp 原生可执行文件，以及什么时候该换回去。
用 ollama 跑本地模型挺省心，但跑着跑着总会撞上几堵墙：上下文拉不满、显存爆了、模板对不上、输出慢得离谱。这时候你想往下调，翻文档才发现 ollama 底下压着的其实是 llama.cpp。于是问题就变成了——我到底该在 ollama 里改，还是干脆绕出去直接跑 llama.cpp。
这篇不重复「两者有什么区别」那类结论，只给你两条能落地的路径：A 是留在 ollama 里用它已经放出来的口子去影响底层行为，B 是拿 GGUF 文件直接走 llama.cpp 原生可执行文件。外加一条判断标准，帮你决定什么时候该原路退回。
先确认它们到底是什么关系
把 ollama 想成一个产品层：它管模型拉取、对话模板、HTTP 服务、缓存和版本管理，让你一句命令就能跑起来。真正加载 GGUF 权重、一个 token 一个 token 往外吐的，是它下面那层 llama.cpp 推理执行体。所以「用 ollama 使用 llama.cpp」在实践里通常指两种情况：借 ollama 暴露的底层参数间接控制它，或者彻底绕过 ollama 自己调 llama.cpp。
- 产品层（ollama）
- 负责把模型拉下来、套模板、开接口、管缓存，你日常打交道的都是这一层
- 执行层（llama.cpp）
- 真正读 GGUF、算注意力、生成 token 的地方，显存和速度主要取决于它
- 判断分叉
- 你要改的开关 ollama 放出来了就走 A，没放出来或要换量化文件就走 B
判断走哪条路其实只看一件事：你要动的东西，是不是 ollama 已经开放给你的参数。放出来的，走 A 路线最省事；没放出来，或者你手里有一份要指定加载的 GGUF，那就走 B。想先把概念边界对一遍，可以到 /stacks 和 /ai-dict/category/tech 看看这些名词是怎么归类的。
A 路线：留在 ollama 里，用它的口子调底层行为
这条路的核心思路是：不改执行体，只改传给它的参数。ollama 在模型层、运行层、调用层各开了一些口子，改对了效果和直接调 llama.cpp 差不多，但省掉了自己管模板和缓存的麻烦。
| 层面 | 能动的项 | 生效方式 |
|---|---|---|
| 模型层 | 系统提示、对话模板、上下文长度、采样参数、GPU 卸载层数 | 写进 Modelfile 后重建该模型 |
| 运行层 | 并发请求数、显存驻留时长、可见显卡、模型存储路径 | 改环境变量并重启服务 |
| 调用层 | 单次请求里覆盖部分采样或长度参数 | 只对当次请求生效，适合临时压测 |
- 先只改一个参数比如先把上下文长度调大，其余不动，用同一条提示词跑一遍，看输出是否变长、显存是否顶上去
- 确认生效如果表现和改之前一模一样，多半是没重建模型或没重启服务，先排除这个再怀疑参数本身
- 再加第二个一次只加一个变量，方便回滚。一次改五个参数，出问题你根本不知道是谁的锅
- 记下基线把改之前的显存占用、首 token 延迟、每秒出词数记在一个小本子上，后面所有对比都跟它比
调用层覆盖适合压测，不适合长期配置。你要是看到某次请求参数变了就以为全局改了，下次重启会发现全打回原形。判断自己该不该用 A 路线很简单：如果你要的效果 ollama 官方文档里有对应参数，就别绕出去，留在这一层维护成本最低。
B 路线：拿 GGUF 直接跑 llama.cpp
当你需要用到 ollama 未公开的量化格式、想自己控制层卸载策略、要把推理嵌进自己的进程，或者想拿逐 token 的日志做分析，就该绕出去直接跑 llama.cpp 了。代价是你得自己管模板、缓存和版本升级。
- 适用场景：自定义量化档位、逐层卸载调优、进程内嵌、需要原始生成日志
- 准备工作：把权重下载成 GGUF 放到本地目录，确认你编译的版本支持手里的量化档位
- 模板对齐：同一份权重在两边表现可能不同，迁移时固定同一条提示词做对照
- 资源估算：显存和并发怎么定，按 /models/deploy 与 /compute/sizing 的口径先算一遍再动手
- 验证方式：跑通后先看首 token 延迟和稳定输出长度，别急着上并发
# 思路示意，实际参数名以你本地版本的 help 输出为准
llama-cli -m /path/to/model.gguf -c 4096 -ngl 99 -p "你的提示词"
# 先把上下文和卸载层数固定，再逐个调，方便对比迁移到原生 llama.cpp 之后，最容易翻车的是模板不一致：ollama 帮你套好的对话格式，原生这边要你自己给。同一份权重，两边输出风格差一截是常事，所以对照实验一定要固定提示词和采样参数，不然你会把模板差异误判成模型能力差异。
什么时候该换回去，什么时候别折腾
绕出去不等于更高级。如果你要的只是一个稳定的本地对话服务、需要自动拉模型和统一接口，留在 ollama 里更省事，绕出去的收益很低，多出来的维护全是自己的。
| 你的目标 | 建议路线 | 原因 |
|---|---|---|
| 稳定对话服务、自动拉模型 | 留在 ollama | 封装已经帮你处理了模板和缓存 |
| 吞吐对比、协议适配、自定义采样 | 原生 llama.cpp | 可见度更高，控制粒度更细 |
| 换特定量化文件或嵌入自有进程 | 原生 llama.cpp | ollama 不保证支持你要的格式 |
| 只想调上下文或采样 | 留在 ollama | 这些参数它已经放出来了 |
两边的量化档位选择逻辑是共通的：显存够不够、能跑多长上下文、速度和质量的取舍，按 /models/deploy 里的口径先定档，再决定跑在哪一层。具体到某个档位在你机器上的实际占用，去 /compute/sizing 按当时的数字核对，别照搬别人的配置。
- 第一步：确认权重没换排错先看 GGUF 文件和量化档位是不是还是原来的那个，换过文件就别急着怪框架
- 第二步：确认上下文长度一致两边上下文设置不同，输出长度和显存表现自然对不上，先把这栏拉平
- 第三步：确认模板一致提示词套的模板不同，模型看到的东西就不同，输出差异可能全来自这里
- 第四步：才怀疑框架差异前三步都排除了，再考虑实现细节带来的真实差异，这时候的对比才有意义
决定走 A 还是 B 的，从来不是谁更底层，而是你要改的开关有没有被放出来。下一步想先确认手上的设备和量化档位能跑到什么程度，再去动手改参数，先到部署与算力页面按当时的数字核对一遍，能省掉一轮瞎试。→
常见问题
ollama 能不能直接指定用哪个 llama.cpp 版本或自定义编译参数？
通常不行，ollama 发布的是打包好的运行时，你改不了里面的推理引擎版本。真要控制到这一层，就得自己编译 llama.cpp 跑 GGUF，代价是模板、缓存、服务接口都得自己接。判断标准很简单：你需要改的是模型参数还是引擎本身，前者留在 ollama 就够。
同一份模型权重，为什么 ollama 和原生 llama.cpp 输出效果不一样？
常见三个原因：对话模板不同、默认采样参数不同、上下文长度上限不同。权重本身一般是一样的。排查方法是固定同一条提示词、同一温度，先对齐模板和上下文长度，再看差异是否还在。如果还差，再比量化档位是否一致。
跑起来就爆显存或速度特别慢，先查哪里？
按这个顺序：一看量化档位是不是选高了，二看 GPU 卸载层数有没有超出显存，三看上下文长度是不是开太大，四看是不是同时有别的进程占着卡。参数在哪里改、显存怎么算，到 /models/deploy 和 /compute/sizing 按当口径核对一遍再调。
