ollama llama.cpp 对比

很多人本地跑模型时卡在同一个问题上：明明两个工具都能加载 gguf，到底该装哪个、什么时候该换。这篇不堆参数，只按「你是单人试玩、还是要嵌进产品」这条线，把两者的定位差别、性能取向、适用人群和切换成本摆出来，最后给一份可以照着走的选型与排查顺序。涉及具体版本与数字，一律到站内对应页面核对当时的数值。

本地跑模型的人迟早会撞上这个问题：两个工具都能加载 gguf，到底装哪个。多数纠结不是因为功能不够，而是没分清它们其实不在同一层——一个是你直接面对的服务，另一个是别人可以调用的引擎。先把这条线划清，后面的性能对比和迁移成本才有意义。

这篇按「你是单人试玩，还是要嵌进产品」这条主线走。先讲两者是什么关系，再给四类人对号入座，然后说性能差异到底从哪来、怎么自己量，最后讲从一边换到另一边要动哪些东西。涉及具体版本与数值，一律到站内对应页面核对当时的数字。

先分清两者是什么关系

最容易错位的地方，是把它们当成同层竞品来比。Ollama 更像一个装好就能用的服务：模型拉取、常驻进程、HTTP 接口、显存分配都替你做了，你面对的是一个地址而不是一个程序。llama.cpp 是推理引擎本体，给你的是可执行文件和库，模型文件、量化方式、线程数、卸载层数全要你自己指定。严格说不是同一层的东西，真正要比的是「你要不要那层封装」。

封装层

帮你做默认决策、暴露简单接口，省心但可调项少。

引擎层

只提供推理能力，参数全开放，调对了更快、调错了更慢。

复用关系

封装层往往在底层复用了同一个引擎，所以模型文件常常可以直接搬。

• 先问自己：要的是一个命令行聊天窗口，还是要一段能被别的程序调用的推理能力。
• 如果是前者，封装层的默认值就够用；如果是后者，接口贴近底层的那个更合适。
• 分不清术语时，先到 /ai-dict 把推理框架、量化这类词过一遍，再回来看具体工具。
• 别拿「谁功能多」当标准，两者功能交集很大，差别在默认值与可控粒度。

什么情况下选谁：四类人对号入座

把使用者粗分四类，基本能覆盖日常决策。注意这里的分类只看场景，不看机器配置高低，配置问题属于下一节要量的东西。

最后一行要单独说：如果诉求是稳定并发和吞吐，那这条路线本身就不对，站内 /vllm-vs-ollama-inference 讲的就是这条分界线。不适用的情况也要讲清——如果你的权重格式只有服务化框架才跑得起来，那本文的结论对你没用，直接跳框架选型那条线。

• 先按上表对号，落在前三行的，再往下看性能那节。
• 落在第四行的，别在本文纠结，去看并发与吞吐导向的方案。
• 不确定自己属于哪类，就按「未来三个月会不会被别人调用」来判。

性能差异从哪来、怎么自己量

性能差距通常不在「谁算法更快」，而在三处：默认参数、量化档位、显存与内存的调度策略。同一份权重换工具，先把这三项对齐，对比才有意义。封装层帮你做了一些默认选择，省心但未必是你机器上的最优解；引擎层把旋钮全交给你，调对了更快，调错了更慢。

1. 固定变量同一模型文件、同一量化档位、同一提示词长度，三项不一致就别比。
2. 分开记录分别记首字延迟和持续生成速度，只记一个数会误判体感。
3. 换档位再测量化档位换一档重测一次，看瓶颈在算力还是在带宽。
4. 交叉验证用 /tools/speed-test 量延迟基线，用 /models/deploy 粗算显存与并发余量。

任何「谁快多少」的绝对数字都不该照抄，你的卡、量化档、上下文长度都会改变结论。想参考横向数值，到站内速度测试页看当时的记录，并留意测试条件是否和你一致。

先把可比条件对齐，再谈快慢，否则你测的是配置差异不是工具差异。

从 Ollama 换到 llama.cpp 要动哪些东西

迁移的坑往往不在推理本身，而在调用方式和参数映射。动之前先估工作量，别把它当成换个命令的事。

• 先在旁路环境跑通，别直接替换正在用的那一份。
• 报错先查量化格式与参数，不要一上来怀疑文件损坏。
• 参数逐个对照设置，改完立刻复测延迟，确认是变好还是变差。
• 留一条回退路径，切换后观察一两天再决定是否清理旧环境。

更细的迁移清单和字段对照，可以按站内模型迁移类文章的顺序走，逐项打勾比凭记忆改参数稳得多。判断类内容都有边界：如果你本来就只需要一个本地聊天入口，那这次迁移大概率不值得做。