朋友之间不应该推荐Ollama

Ollama 最初凭借其作为首个简易的 llama.cpp 封装库而获得成功，随后却花了数年时间规避署名、误导用户，并转向云端，而这一切都建立在利用他人引擎赚取的风险投资之上。

以下是完整的历史，以及为什么其他替代方案更胜一筹。

Ollama 是运行本地 LLM 最流行的工具，但它不应该如此。它之所以能占据这个位置，是因为它开创了先河，成为第一个让 llama.cpp 不想编译 C++ 或编写服务器配置的用户也能轻松使用 LLM 的工具。这在当时确实是一项贡献。

但此后，该项目多年来一直在系统性地掩盖其技术来源，误导用户对其运行的程序存在误解，并逐渐偏离了最初赢得用户信任的“本地优先”理念。与此同时，它还在接受风险投资。这不是一篇“正反两方都适用”的文章。我曾经用过 Ollama，现在已经不用了。以下是你也应该不用的原因。

一个带有失忆症的 llama.cpp 包装器

Ollama 的所有推理能力都源自 llama.cpp，这是一个由 Georgi Gerganov 于 2023 年 3 月创建的 C++ 推理引擎。Gerganov 的项目使得在消费级笔记本电脑上运行 LLaMA 模型成为可能。他仅用一个晚上就完成了第一个版本，并由此开启了整个本地 LLM 运动。如今，llama.cpp 在 GitHub 上拥有超过 10 万颗星，450 多位贡献者，并且是几乎所有基于 GGUF 的工具所依赖的基础。

Ollama 由 Jeffrey Morgan 和 Michael Chiang 于 2021 年创立，他们此前都曾参与开发 Kitematic（后被 Docker 公司收购）。他们参加了 Y Combinator 2021 年冬季创业营，获得了种子轮融资，并于 2023 年正式上线。从一开始，他们的理念就是“面向机器学习模型的 Docker”，一个便捷的封装工具，只需一条命令即可下载并运行模型。其底层代码是 llama.cpp，它负责完成所有工作。

许可与署名的缺失
一年多以来，Ollama 的 README 文件中完全没有提及 llama.cpp。README 文件中没有，网站上也没有，他们的宣传材料中也没有。该项目的二进制发行版也没有包含其所分发的 llama.cpp 代码所需的 MIT 许可声明。MIT 许可只有一个主要要求：包含版权声明。Ollama 没有做到这一点。

社区注意到了这个问题。GitHub 上的 #3185 号 issue 于 2024 年初提交，要求解决许可合规性问题。但维护者 400 多天都没有回应。直到 2024 年 4 月，#3697 号 issue 专门要求对 llama.cpp 进行致谢，几个小时后，社区 PR #3700 便随之而来。Ollama 的联合创始人 Michael Chiang 最终在 README 文件末尾添加了一行文字：“llama.cpp 项目由 Georgi Gerganov 创建。”

对公关稿的回应颇具启发性。Ollama 团队写道：“我们花费大量时间修复和修补漏洞……随着时间的推移，我们将过渡到更系统化构建的引擎。” 言下之意：我们不会给 llama.cpp 署名，而且我们计划与之保持距离。

让事情变得更糟的那把叉子

自定义后端的性能倒退
2025 年年中，Ollama 兑现了这一承诺。他们不再使用 llama.cpp 作为推理后端，而是直接基于 ggml 构建了一个自定义实现。他们给出的理由是稳定性，而 Ollama 的企业合作伙伴需要的是可靠性。

结果却恰恰相反。Ollama 的自定义后端重新引入了 llama.cpp 多年前已经修复的 bug。社区成员在多个版本中都发现了结构化输出支持失效、视觉模型运行失败以及 GGML 断言崩溃等问题。在上游 llama.cpp 中运行良好的模型在 Ollama 中却无法正常工作，因为 Ollama 的实现缺少对模型所需张量类型的支持。Georgi Gerganov 本人也指出，Ollama 对 GGML 进行了分支并做出了错误的修改。

基准测试结果说明了一切
多项社区测试表明，在相同硬件和相同型号的处理器上：

运行速度：llama.cpp 的运行速度比 Ollama 快 1.8 倍（161 tokens/s vs 89 tokens/s）。
CPU 端差距：两者的差距高达 30% 至 50%。
吞吐量：在 Qwen-3 Coder 32B 上，llama.cpp 的吞吐量比 Ollama 高出约 70%。

性能上的不足源于 Ollama 的守护进程层、糟糕的 GPU 卸载启发式算法以及落后于上游的第三方后端。

误导性的模型命名

DeepSeek 于 2025 年 1 月发布了 R1 模型系列，而 Ollama 在其库和命令行界面中仅将其列为“DeepSeek-R1”，即较小的精简版本（如 DeepSeek-R1-Distill-Qwen-32B）。运行 ollama run deepseek-r1 会拉取一个 80 亿参数的 Qwen 衍生精简版，其行为与真实模型截然不同。

这并非疏忽。DeepSeek 自己给这些型号起了“R1-Distill”前缀，Hugging Face 也正确地列出了它们。Ollama 却去掉了这个前缀，导致社交媒体上涌现出大量关于性能不佳的误导性讨论，这无疑损害了 DeepSeek 的声誉。

GitHub 问题 #8557 和 #8698 请求将模型分离，但均被标记为重复并关闭。Ollama 知道其中的区别，但选择将其隐藏，大概是因为“DeepSeek-R1”的下载量比完整名称更高。

闭源应用程序

2025 年 7 月，Ollama 发布了一款适用于 macOS 和 Windows 的图形用户界面桌面应用程序。该程序在一个私有代码库中开发（github.com/ollama/app），没有提供许可证，源代码也不公开。对于一个以开源著称的项目来说，这无疑是一个令人震惊的举动。

网站将下载按钮放在 GitHub 链接旁边，使用户误以为下载的是 MIT 许可的开源工具，而实际上下载的是一个未授权的闭源应用程序。正如 XDA 所说：“如果你的项目以开源为卖点，那么在发布时你就不能含糊其辞地说明哪些内容是开源的，哪些内容不是开源的。”

模型文件：重新发明一个已解决的问题

GGUF 的设计核心原则是单文件部署。所有聊天模板、停止令牌、模型元数据都嵌入在文件中，只需将 llama.cpp 指向它即可工作。

Ollama 在此基础上添加了 Modelfile（灵感来自 Dockerfile），这反而增加了复杂性：

模板匹配问题：Ollama 只能从硬编码列表中检测已知模板。如果 GGUF 嵌入了有效的 Jinja 模板但不在 Ollama 的列表内，它会回退到裸模板，破坏指令格式。用户必须手动转换语法，而 llama.cpp 直接读取即可。
修改参数的噩梦：更改温度或系统提示时，用户必须执行 ollama show $\rightarrow$ 编辑 $\rightarrow$ ollama create。这个过程会复制整个模型（30 到 60 GB），仅仅是为了更改一个参数。相比之下，llama.cpp 只需命令行标志（如 --temp 0.7）。

注册瓶颈与量化限制

等待时间
使用 llama.cpp，你可以通过一条命令直接从 Hugging Face 运行新模型。而使用 Ollama，你需要等待工作人员将模型打包、选择量化方式、转换模板并提交到注册表。这导致新模型发布后，用户往往会因为 Ollama 的环境问题（如模板错误）误以为是模型本身的问题。

量化限制
Ollama 仅支持特定的量化格式（Q4_K_S, Q4_K_M, Q8_0 等）。如果你需要 Q5_K_M、Q6_K 或任何 IQ 量化格式，除非自行量化，否则无法实现。对于一个标榜“最简便”的工具来说，让用户去别处寻找基本选项是极其矛盾的。

云枢纽与安全性

2025 年末，Ollama 推出了云托管模型。原本以本地私有推理著称的工具开始将请求路由到第三方云服务（如 MiniMax），但并未明确告知用户数据会被发送到外部服务器。

安全隐患

隐私担忧：对于托管在阿里云等平台上的模型，用户无法获得零数据保留保证。
令牌泄露漏洞 (CVE-2025-51471)：该漏洞允许恶意注册表服务器诱骗 Ollama 发送身份验证令牌。对于一款以本地隐私保护为卖点的工具，这种架构层面的设计缺陷是致命的。

VC 模式：商业逻辑的必然

Ollama 的行为完全遵循了典型的初创公司增长模式：

在开源平台上发布，基于 llama.cpp 构建，赢得社区信任。
尽量减少归因，让产品在投资者眼中显得自给自足。
创建锁定、专有且不兼容的格式（如哈希文件名存储模型）。
启动闭源组件（GUI 应用）和云服务（货币化途径）。

这种“厂商锁定”使得用户即便导入了模型，也难以直接在其他工具中使用这些文件。

可以用什么代替

Ollama 包装盒内的工具可以直接使用，且设置并不难：

核心引擎与命令行

llama.cpp：真正的引擎。拥有兼容 OpenAI 的 API 服务器、内置 Web UI，性能始终优于 Ollama，且完全由社区驱动（MIT 许可证）。
Mozilla llamafile：将模型和运行时打包成单个可执行文件，实现“下载即用”。
llama-swap + LiteLLM：通过单一接口处理多模型编排、加载与热替换。

桌面图形用户界面 (GUI)

Jan (AGPLv3)：本地优先的聊天应用，界面简洁，源代码完整且开源。
koboldcpp (AGPL)：llama.cpp 的分支，内置 Web UI 和丰富配置，完全开源可审计。
LM Studio (闭源)：虽然是闭源软件，但它提供了极佳的一键式操作和透明的参数控制，且对 llama.cpp 保持了良好的致谢精神，并非“寄生”。
Msty：支持多模型并内置 RAG 功能的闭源 GUI。
ramalama (Red Hat)：容器原生的模型运行器，明确标注上游依赖。

大局观

2023 年 3 月的一个晚上，Georgi Gerganov 编写了 llama.cpp，开启了本地 AI 革命。这项工作是本地推理技术保持开放性和可访问性的基础。

Ollama 将这项工作封装成一个漂亮的 CLI 并以此获得风险投资，随后却在署名、项目 fork、闭源应用和云服务等每一个关键决策点上，选择了让自己在投资者眼中显得更加“自给自足”的道路。

本地 LLM 生态系统不需要 Ollama，它只需要 llama.cpp。其余部分都是打包问题，而更好的打包方案已经存在。

本文转载