llama cpp 和 ollama 的 区别

很多人第一次装本地模型时会被这两个名字绕住：明明装的是 Ollama，日志里却一直出现 llama.cpp；想自己编译一份又发现没有现成的模型管理。这篇不比较谁更强，只把两者的分工讲开——一个偏底层推理引擎，一个偏开箱即用的运行时，然后给出按场景挑的判断顺序和不适用的情况。

很多人第一次装本地模型时会被这两个名字绕住：明明装的是 Ollama，日志里却一直出现 llama.cpp；想自己编译一份又发现没有现成的模型管理。这其实不是巧合，而是两者本来就是上下层关系，一个在跑推理，一个在管服务。

这篇不比较谁更强，只把两者的分工讲开——一个偏底层推理引擎，一个偏开箱即用的运行时，然后给出按场景挑的判断顺序，以及哪些情况下这两条路都不太合适。

定位差别：引擎和运行时不是同一层东西

llama.cpp

推理引擎本身，负责加载权重、量化、跑 token 生成，通常以库或命令行可执行文件的形式存在

Ollama

在引擎之上包的一层运行时，附带模型仓库、后台常驻服务和 HTTP 接口

所以「装了 Ollama 就等于装了 llama.cpp」在多数情况下成立，反过来不成立：自己编 llama.cpp 不会顺带得到模型拉取和常驻服务。这一层差别决定后面所有差异，选型时先问自己：我要的是能跑，还是能调。

• 想改推理参数、换量化方式、把推理嵌进自己的程序，往下走，看引擎
• 想尽快跑起来、有统一接口给别的应用调，往上走，看运行时
• 想两者都占，通常做法是用运行时日常跑，遇到具体瓶颈再针对单个模型换引擎

安装与日常运维：一个管编译，一个管服务

判断你是否需要碰底层，有个简单办法：如果只是给聊天前端或知识库工具提供一个本地接口，运行时的抽象正好省事；如果要做批量离线推理、嵌进已有程序、或压榨特定硬件，自己控制引擎更顺手。

两边都不是「一次装完就不用管」：模型文件和缓存目录会越滚越大，机器换盘、多人共用、离线环境部署这几类情况都要提前想好路径和权限。查目录和路径类问题可以先到 /ai-dict/category/infra 对照术语。

1. 先定运行环境确认目标机器是纯 CPU、还是有可用的 GPU 后端，两者在编译选项和默认参数上差别不小
2. 再定谁常驻如果是长期给别的应用调，运行时省掉自己写守护进程的活；如果是一次性批量任务，命令行跑完就退更干净
3. 最后验证可维护性在目标机器上完整走一遍安装和升级流程，别只看能不能跑起来——升级会不会把已有配置冲掉，这一步最容易被忽略

运行时路线一般用「按名字拉」的方式获取模型，配套的量化版本和清单由它自己维护，省去你找权重、转格式的步骤；代价是依赖它的模型清单，冷门模型或自己微调出来的权重未必能直接按名字拉。

引擎路线默认你自己准备权重文件，格式转换和量化往往要额外做一步；好处是任何合规来源的权重都能用，私有微调的产物也能直接跑。

选型判断可以简化为：团队里都是调接口的应用开发，选运行时；要在同一台机器上跑多种模型做压测、或者模型来源受内网管控，选引擎或用引擎自己封装。

并发和吞吐这类指标别凭感觉，先到 /models/deploy 按你的模型和量化档位算一遍，再决定要不要换框架。

按场景挑：四类人各自的默认答案

• 只想在本机跑一个对话模型、接个现成前端：先用运行时，够用就别折腾引擎，等遇到具体瓶颈再说
• 要把本地模型嵌进自己的程序、或者对生成参数有精细要求：直接用引擎，省掉中间一层带来的不确定性
• 多模型横向对比、做离线批量任务：引擎更容易脚本化和批处理，运行时的服务模型反而多一层管理成本
• 内网、离线、合规受限环境：优先看谁能离线导入权重和离线安装，这一步常常直接决定选谁，跟性能无关

不适用的情况也说清楚：如果只是想知道某个开源模型效果好不好，跑本地这一步本身就未必必要，先到 /models 看模型资料、到 /rankings 看可信度排行，比装环境快得多。

如果并发量上来了、要服务多人，这两个可能都不是终局方案，可以参照站内 /inference 的开源模型比价再判断，把自建和调用服务的总成本放在一起算。

先分清楚你要的是「能跑」还是「能调」，再决定站在引擎那一侧还是运行时那一侧。