本篇目标：理解 llama.cpp 为什么值得认真对待，以及什么时候该用它替换掉 Ollama 或 vLLM
前言：为什么写这篇番外？
本来本栏目的定位着重于不需要太多专业知识，鼠标点点就能实现本地部署和使用大模型，但在粉丝晓东同志提醒后感觉有必要再补上两篇关于 llama.cpp 和 FastLLM 的文章；
这两个实在太香了，llama.cpp 对工具调用的支持比ollama完善很多，而 FastLLM 让"不够格"的硬件，也能跑大模型。
一个不是秘密的「秘密」
Ollama 的官方 GitHub 仓库在「Supported backends」一栏明确写着： llama.cpp
Ollama 本质上是在 llama.cpp 外面包了一层「模型管理 + 一键安装 + 命令简化」的壳。它负责帮你下载模型、切换版本、组织目录，但真正干活的那个引擎，就是 llama.cpp。
这不是秘密，但知道这个事实会改变你用这些工具的方式------就像知道自己的车用的是哪款发动机一样。
所以问题来了：既然底层是同一个引擎，为什么不直接用它？
llama.cpp 是什么？
一句话：用 C/C++ 写的、社区最成熟、性能最极致的大模型推理引擎。
2019年前后，独立开发者 Georgi Gerganov 在折腾语音识别时写了这个项目，后来因为社区需求不断扩展，逐渐成长为 LLM 推理的事实标准底层引擎。如今它已经是 GitHub 上 70K+ 星标、被无数项目（包括 Ollama）依赖的核心基础设施。
三个关键事实
1. GGUF 格式是社区事实标准
你从 Hugging Face 下载的大部分开源模型，都有 GGUF 版本。Ollama 拉到本地后，模型文件也是 GGUF 格式------存在 ~/.ollama/models/blobs/ 下，只是改了个名字。
2. C/C++ 原生，极致轻量
llama.cpp 没有 Python 依赖、没有 Docker、没有复杂的 pip 包管理。编译出来就是一个单文件二进制。资源占用极低，ARM Mac、树莓派、甚至手机都能跑。相比之下，vLLM 需要 Python 3.9+、torch、CUDA 工具链一套，Ollama 虽然安装简单但后台进程偏重。
3. GPU 加速的开箱即用体验远超预期
实测 qwen3.5:9b，llama-server 的 Prompt 处理平均速度可达 768 tok/s ，生成平均速度 187 tok/s（Q4_K_M 量化，空上下文）。这个数字跟 Ollama 预热后的表现相当（没有数量级上的优势），但启动速度和冷启动延迟明显优于 Ollama。
💡 关于这点，附在本篇之后的实操教程里有简单的测试日志，可以对比自己的机器环境。
Ollama 很好，但它也有边界
先说结论：Ollama 是优秀的入门工具，但不一定是长期方案。
Ollama 的成功在于大幅降低了本地部署的认知门槛------ollama pull + ollama run 两步走，没有比这更简单的了。但也正因为「简单」，它隐藏了一些对高级用户很重要的东西：
Ollama 的几个局限
| 局限 | 表现 | 影响 |
|---|---|---|
| GPU 利用率受限 | Ollama 的 GPU offload 策略比较保守，不充分压榨显存 | 同等硬件下，llama.cpp 直调用通常比 Ollama 快 10-20% |
| Tool/Function Calling 支持滞后 | Qwen3/Qwen3.5 的 tool_call 在 Ollama 上容易出 bug | Agent 开发者苦不堪言，llama.cpp 就没有这个问题 |
| 模型管理不透明 | 模型文件改头换面存在 blobs/ 目录，QQFM 格式也被硬改 |
想用 GGUF 原生工具排查问题很麻烦 |
| 社区更新节奏不受控 | Ollama 锁定 llama.cpp 版本，新硬件/新架构支持需等 Ollama 发版 | 比如最新的 MLA 注意力优化、FlashAttention 支持往往落后 llama.cpp 主线 |
<,e>我自己的实测体验 ：在 Qwen3.5 的 tool_call 场景下，Ollama 出现了多轮对话中函数描述丢失的问题，切换到 llama-server 直调后问题消失。这在 Agent 开发中是很致命的------你不想排查半天发现是推理引擎的 bug。
什么时候该选 llama.cpp？
基于上面的分析，可以画出一条清晰的使用边界：
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 纯新手，不想碰命令行 | LM Studio / Ollama | 图形界面或一句话命令，零门槛 |
| 日常聊天、快速测试模型 | Ollama | 模型切换方便，社区模型多 |
| 开发 Agent 项目（需要 tool_call） | llama.cpp | tool_call 兼容性好，不出幺蛾子 |
| 追求极致性能/想榨干显卡 | llama.cpp | 直接编译，GPU offload 完全可控 |
| 长期后台服务（7×24 运行） | llama.cpp | systemd --user 原生支持自启+自动恢复 |
| 高并发生产环境（多人调用） | vLLM | PageAttention + PagedKV 管理，高吞吐首选 |
| 端侧/移动端部署 | LiteRT-LM / llama.cpp | llama.cpp 有安卓编译指南，ARM 优化好 |
简单说就是一条经验法则：
LM Studio 是尝鲜，Ollama 是入门，vLLM 是生产，而 llama.cpp 是做 Agent 和跑服务的「硬核选择」。
而我们已经有了一份完整的实操记录
今天随本篇番外一同推送的，是 《llama.cpp 在 Linux 上安装使用教程》。
这份教程是Linux中完全用户态 ，即无sudo权限的普通用户，通过 Conda 完整安装并配置 llama.cpp 的实战记录。它包含：
- ✅ Conda 环境安装编译工具链------无 root 权限也能搞定，前面ollama的安装记录中已有详细步骤。
- ✅ 从源码编译 llama.cpp------理解每步在做什么（这里会涉及远程资源下载的问题，具体见教程）
- ✅ 下载 GGUF 模型 + 测试运行------llama-cli 对话 + llama-server API 服务
- ✅ 服务常驻后台------tmux 和 systemd --user 两种方案，各有优劣
- ✅ 路由模式管理多模型------一个端口提供多个模型服务
- ✅ 实测性能数据------Prompt 768 tok/s、生成 187 tok/s
先读本篇番外建立认知，再翻开那份实操教程动手。 两份一起看，效果翻倍。
番外补充：三个工具的「一句话定位」
考虑到有些读者可能在手机上阅读，不想来回翻前面的文章，这里用一个最简单的句子总结三个工具：
| 工具 | 一句话定位 |
|---|---|
| Ollama | 开箱即用的模型管理器，适合跑单个模型、日常聊天，但对 Agent 开发者的 tool_call 支持不够好 |
| vLLM | 生产级高吞吐推理引擎，适合多人并发调用，但不适合单卡/低显存场景，Windows 原生也不支持 |
| llama.cpp | 底层引擎级方案，性能极致、tool_call 兼容好、支持路由模式管理多模型，是做 Agent 和跑服务的硬核之选 |
写在最后
本地部署这件事，工具只是手段，目的是稳定可靠地跑起你需要的模型。
Ollama 把门槛降到最低，vLLM 把吞吐推到最高，而 llama.cpp 站在两者之间------比 Ollama 灵活，比 vLLM 轻量。对于 Agent 开发者来说，它可能是最舒服的那个中间点。
如果你已经在用一个方案跑得很顺，不必换。但如果你在 Ollama 上遇到 tool_call 的坑、或者觉得 vLLM 太重了------试试 llama.cpp，也许这就是你一直在找的那个方案。
📎 配套阅读 ：llama.cpp 在 Linux 上安装使用指南
🔗 参考资料：