很多人装了 Ollama 跑模型，看到日志、GGUF、量化这些词又对不上号，遇到显存、参数、性能问题就不知道是改 Ollama 还是动 llama.cpp。这篇把两层的分工、调用链和各自的调参入口摊开讲，再给几条按场景选层的判断标准，让你出问题时知道该敲哪一层的命令。
很多人第一次跑本地模型，是从 Ollama 的命令行开始的：装好、pull 一个模型、敲一句 prompt 就出结果。转头看日志或报错，又冒出 GGUF、量化、GPU 卸载层数这些词，越看越像另一套东西。其实这两者不是竞品关系，而是上下叠在一起的两层，弄清楚谁包着谁，出问题才知道该敲哪一层的命令。
这篇不讲安装教程，只把两层的分工、调用链和各自的调参入口摊开，再给几条按场景选层的判断标准。看完你应该能做到：看到一个报错或一个性能数字，先判断它属于哪一层，再决定动手改哪里，而不是把两边的参数都乱调一遍。
两层怎么叠：谁是引擎谁是壳
llama.cpp 是底层推理引擎，核心工作是加载权重、管理 KV 缓存、做采样、调度 CPU 与 GPU 后端。Ollama 是上层的外壳，把引擎能力包装成一个常驻服务加一套命令行，顺带管模型清单、参数模板和多模型切换。理解了「引擎负责算、外壳负责管」，后面很多困惑就自动消失了。
两者关系最直接的证据在日志里：Ollama 启动一个模型时，实际动作是让引擎去加载对应的 GGUF 文件，你能在输出里看到引擎侧的加载、卸载和设备分配信息。也就是说，Ollama 不自己实现推理，它只是把引擎拉起来并接管输入输出。中间还有一层属于 Ollama 自己维护的东西——模型清单、模组配置、参数模板，这些是直接跑引擎命令行时没有的。
| 看到的行为 | 属于哪一层 | 判断口径 |
|---|---|---|
| 直接在命令行喂 prompt，没有服务概念 | 引擎层 | 引擎只负责一次推理，不常驻 |
| 要 pull、要 serve、要开端口 | 封装层 | 有模型仓库管理和服务进程 |
| 日志里出现 GGUF 加载、设备卸载 | 引擎侧输出 | 是引擎在干活，被外壳调用 |
| 能切换多个模型、自动卸载释放显存 | 封装层 | 引擎原生命令行不提供这套管理 |
各自管什么，别找错入口
调参之前先定位归属，改错层往往既不生效也不报错，白白浪费时间。一个简单的划分：凡是和「算出结果」相关的参数，基本归引擎层；凡是和「拿到模型、对外提供接口」相关的设置，基本归封装层。
- 引擎层负责
- 量化格式支持、CPU/GPU 卸载比例、线程数、批大小、上下文长度、采样参数
- 封装层负责
- 模型下载与命名、服务端口与并发、环境变量、API 兼容层、多模型常驻与切换
- 典型错配一
- 把「模型拉不到」当引擎问题查，其实多半是封装层的仓库配置或网络设置
- 典型错配二
- 把「输出变慢」怪到封装层，其实更多是引擎的卸载层数与上下文长度设得不对
还有个常被忽略的点：封装层往往会设一套默认参数，这些默认值会直接传给引擎。你觉得「没改过任何东西」的时候，其实是封装层替你决定了上下文长度、卸载策略和批处理方式。所以排查性能问题，第一步是把这些默认值显式地找出来看，而不是凭空猜。
什么时候停在 Ollama，什么时候往下探
不是所有人都需要碰引擎层。判断标准很朴素：你现在的痛点，封装层能不能通过它自己的配置解决。能解决就待在上面，解决不了再往下。往下探不是升级，而是拿便利换控制权。
- 留在封装层的场景：单机对话、接本地知识库、做接口联调、给团队里非工程同学用
- 值得往下探的信号一：要指定精细的量化档位，封装层没暴露对应开关
- 值得往下探的信号二：要跑封装层还没收录的模型结构或权重格式
- 值得往下探的信号三：要针对特定硬件后端做压榨式调优，比如手动控制卸载层数
- 往下探的代价：得自己管权重文件、自己拼启动参数，失去模型管理和自动卸载这类便利
不适用的情形要说清楚：如果团队里没人愿意长期维护脚本、跟进引擎版本变动，往下探只会让部署变得更脆。这种情况下宁可在封装层接受一点性能损失，也不要为了几个百分点的提升引入一堆手工步骤。
一张对照清单：按需求选层
下面这张表按「我要做什么」来组织，先看需求落在哪一行，再看优先层和对应的动作，避免一上来就两头调参。
| 需求场景 | 优先层 | 先做什么 |
|---|---|---|
| 快速试一个新模型 | 封装层 | 直接用默认参数跑通，先看效果再谈优化 |
| 长期常驻对外服务 | 封装层 | 先把服务、并发和模型切换配好，稳定优先 |
| 极致显存控制 | 引擎层 | 显式设置卸载层数、上下文与批大小，逐项对比 |
| 跑封装层未收录的结构 | 引擎层 | 自行准备权重，用引擎原生命令行加载验证 |
| 多人共用一台机器 | 两层结合 | 封装层管调度，引擎层管资源上限 |
除了需求，还有两条约束会直接影响要不要提前规划分层：一是是否要对外提供多路并发，二是是否需要可视化管理面板。前者更依赖封装层的服务能力，后者基本只能靠封装层的生态工具解决。把这两条先想清楚，能省掉后面很多返工。
落地建议就一句：先在封装层跑通整条链路，再按具体瓶颈逐项下探，一次只动一个变量。别一开始就全手写命令，那样连基线都没有，出了变化也说不清是谁造成的。想横向对比不同本地运行方式的实测表现，可以到 /tools/speed-test 看当时的数字，别拿别人环境里的结论直接套自己的机器。
出问题的排查顺序
本地部署出问题，最容易犯的错是同时改好几个参数，然后看结果变好了就以为找到了原因。正确的做法是固定顺序、单变量推进，下面这套顺序可以直接照做。
- 第一步：看封装层日志确认模型是否加载成功、是否走了预期设备、服务端口是否正常监听。这一步排除的是「模型根本没起来」这类问题。
- 第二步：看引擎层信息在日志里找上下文长度、卸载层数、线程与批大小，判断是不是被默认值限住了。这一步排除的是「起来了但没跑满」这类问题。
- 第三步：单变量改参数一次只改一项，记下改动前后的差异。多变量同时动，结论基本不可用，等于白测。
- 第四步：回归基线如果改动后更差，先退回到能跑通的那组配置，再换一个方向试，不要在前一组上继续叠加。
排查时还有一个判断口径：报错信息里出现仓库、拉取、服务端口这类词，往封装层找；出现 GGUF、加载层数、后端、上下文这类词，往引擎层找。按关键词分流，比凭感觉乱试快得多。想了解各类本地运行方式的定位差别，可以在 /guides 里按主题翻对应的指南。
下一步如果你正在选本地运行方案，或者想看看不同方式在实际机器上的差别，可以先到站内的工具目录和评测页翻一翻，那里的对比维度比单看日志更完整。→常见问题
Ollama 是不是就是 llama.cpp 换个名字？
不是换名字，是加了外壳。引擎负责真正的推理计算，Ollama 负责把模型下载、服务常驻、参数模板和接口这一整套包起来。所以你能在 Ollama 里看到引擎的加载日志，但用的是它的命令和管理方式。想确认当下用的哪套，去 技术栈图谱 顺着条目往上看一层。
直接用 llama.cpp 会不会比 Ollama 快很多？
不一定，快慢取决于卸载策略、上下文长度、批大小和硬件后端，而不是用哪层壳。很多场景下两者跑同一个 GGUF 差异很小，只有在你要手动压显存或跑封装层不支持的结构时，下探才有明显收益。先测出你的延迟基线，再决定动不动。
换模型或换量化档位时，该在哪一层操作？
日常换模型在封装层操作就行，拉取和切换都由它管。只有当你需要指定封装层还没收录的量化档位或特殊结构时，才去引擎层手动加载权重。换算显存和档位的关系可以去 部署测算 按参数量和量化过一遍，再回来选层。
