为什么你应该停止使用Ollama大语言模型

📝

当地的 LLM 生态系统不需要 Ollama；它需要的是 llama.cpp。

原文链接：https://mp.weixin.qq.com/s/shTViuzx6HXTSzmLRu9e5w

当地的 LLM 生态系统不需要 Ollama；它需要的是 llama.cpp。

Ollama 是目前运行本地大型语言模型的最流行方式。但实际上它本不该如此。它之所以能占据这一地位，是因为它是第一个让那些不想编译 C++或编写服务器配置的人也能使用 llama.cpp 的工具。从某种程度上说，这确实是一项有价值的贡献。但此后，该项目多年来一直刻意隐瞒其技术的真正来源，误导用户对其运行机制的认识，也背离了最初赢得用户信任的“以本地运行为主”的理念。而这一切，都是在使用风险投资资金的情况下发生的。

这不是那种试图平衡双方观点的文章。我曾经使用过 Ollama，但现在不再用了。以下是你也应该放弃它的原因。

带有 Amnesia 的 llama.cpp 封装层

Ollama 的所有推理功能都源自 lama.cpp，这是 Georgi Gerganov 于 2023 年 3 月开发的 C++推理引擎。正是 Gerganov 的项目使得在普通笔记本电脑上运行 LLaMA 模型成为可能。他在一个晚上就完成了该引擎的第一个版本，这一成果也引发了整个本地大语言模型领域的快速发展。如今，lama.cpp 在 GitHub 上获得了超过 100,000 个星标，拥有 450 多名贡献者，是几乎所有基于 GGUF 的工具所依赖的基础框架。

Ollama 由 Jeffrey Morgan 和 Michael Chiang 于 2021 年创立。两人此前都参与过 Kitematic 的开发，那是一款 Docker 图形用户界面工具，后来被 Docker Inc.收购。Ollama 团队参加了 Y Combinator 2021 年的冬季培训项目，获得了种子轮融资，并于 2023 年正式对外发布。从一开始，该产品的定位就是“面向大语言模型的 Docker”——即通过一个命令即可下载并运行模型。实际上，所有核心功能都是由 llama.cpp 实现的。

社区注意到了这一情况。2024 年初，GitHub 上开启了编号为#3185 的议题，要求确保符合许可协议要求。该议题在 400 多天内都没有得到维护者的回复。2024 年 4 月，当又开启了编号为#3697 的议题，专门要求对 llama.cpp 项目进行确认时，社区成员很快提交了编号为#3700 的 PR。Ollama 的联合创始人 Michael Chiang 最终在 README 文件的末尾添加了一行文字：“llama.cpp 项目由 Georgi Gerganov 创建。”

对这篇公关稿的回应很能说明问题。Ollama 的团队写道：“我们花费了大量时间进行修复和补丁更新，以确保 Ollama 用户能获得流畅的体验……今后，我们将逐步转向更系统化开发的引擎。”换句话说：我们不会给 lama.cpp 过多的宣传，而且也打算与其保持距离。

正如一位 Hacker News 用户所说：“他们的做法一直让我费解，这完全是在自讨苦吃、损害自身形象。在 Llama 的基础上进行改进是完全合理的，而且他们在用户体验方面也做出了贡献。应该给予 Llama 团队应有的认可。”另一位用户则指出：“Ollama 一直淡化其对 lama.cpp 的依赖，这一事实在本地大语言模型社区早已为人所知。”

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

2025 年年中，Ollama 切实采取了这种分离措施。他们不再使用 llama.cpp 作为推理后端，而是直接在 ggml 之上构建了自己的实现。ggml 是 llama.cpp 本身所使用的底层张量计算库。Ollama 这样做的理由是稳定性：llama.cpp 更新过快，容易出问题，而 Ollama 的企业客户需要的是可靠的系统。

结果却恰恰相反。Ollama 的自定义后端重新引入了 lamma.cpp 多年前已经解决的漏洞。社区成员指出了结构化输出功能的故障、视觉模型的失效问题，以及多个版本中出现的 GGML 相关崩溃现象。那些在上游 lamma.cpp 中运行正常的模型，在 Ollama 中却出现了问题，其中包括 GPT-OSS 20B 这样的新版本。Ollama 的实现缺乏该模型所需的张量类型支持。Georgi Gerganov 本人也指出，Ollama 是对 GGML 进行了恶意修改的分支。

真是具有讽刺意味。多年来他们一直淡化自己对 lama.cpp 的依赖，而当他们终于试图独立开发时，却做出了一个连他们自己都不愿承认的、质量低劣的版本。

各项基准测试结果都很能说明问题。多项社区测试表明，在相同的硬件和模型条件下，llama.cpp 的运行速度比 Ollama 快 1.8 倍：每秒处理 161 个标记，而 Ollama 仅为 89 个。在 CPU 上，这一差距为 30-50%。最近对 Qwen-3 Coder 32B 的测试显示，llama.cpp 的吞吐量高出约 70%。其性能劣势主要源于 Ollama 的守护进程机制、较差的 GPU 卸载机制，以及落后于主流技术的后端系统。

具有误导性的模型命名

2025 年 1 月，当 DeepSeek 发布 R1 系列模型时，Ollama 在其数据库和命令行界面中，将那些经过微调的 Qwen 和 Llama 模型——比如 DeepSeek-R1-Distill-Qwen-32B 这类规模较小的衍生模型——简单地统称为“DeepSeek-R1”，而未将其与拥有 6710 亿参数的原始 R1 模型区分开来。运行 ollama run deepseek-r1 指令会获取一个基于 8B Qwen 模型衍生出的简化版本，其表现与真正的 R1 模型完全不同。

这并非疏忽。DeepSeek 本身给这些模型都加上了“R1-Distill”前缀。Hugging Face 的标注也是正确的。只是 Ollama 去掉了这一区分。结果，社交媒体上充斥着人们声称自己在普通硬件上运行着“DeepSeek-R1”的帖子，随后又出现了关于该模型性能不佳的种种疑问，从而对 DeepSeek 的声誉造成了损害。

GitHub 上的#8557 和#8698 两个问题都要求将这两个模型分开。但这两个问题都被标记为重复提交而未被处理。时至今日， ollama run deepseek-r1 仍然在使用那个经过压缩处理的微型模型。Ollama 其实明白其中的区别，但选择对此加以隐藏，很可能是因为“DeepSeek-R1”的下载量比“DeepSeek-R1-Distill-Qwen-32B”更高。

该闭源应用程序

2025 年 7 月，Ollama 发布了适用于 macOS 和 Windows 的 GUI 桌面应用程序。该应用程序是在一个私有代码库中开发的（ github.com/ollama/app ），在发布时未附带许可协议，源代码也未向公众公开。对于一个以开源著称的项目来说，这一做法显得有些反常。

社区成员立即表达了担忧。该许可证问题获得了 40 个赞成票。开发人员在二进制文件中发现了可能违反 AGPL-3.0 许可证的依赖项。该网站的下载按钮位于 GitHub 链接旁边，给人的印象是用户正在下载遵循 MIT 许可证的开源工具，但实际上他们得到的是未经许可的闭源应用程序。维护者数月来保持沉默。该代码最终于 2025 年 11 月被合并到主代码库中，但从最初的发布情况来看，就能看出该项目的真正意图。

正如 XDA 所说：“如果你的项目是以开源为卖点的，那么在项目发布时，就必须明确说明哪些部分是开源的，哪些部分不是。”

模型文件：重新审视一个已被解决的问题

GGUF 是由 Georgi Gerganov 创建的模型格式，其设计遵循一个核心原则：单文件部署。GGUF 规范的第 1 点明确指出：“完整信息：加载模型所需的所有信息都包含在模型文件中，用户无需提供任何额外信息。”聊天模板、停止标记、模型元数据，所有这些内容都嵌入在文件中。只需将 llama.cpp 指向该 GGUF 文件，模型即可正常运行。

Ollama 在此基础上还添加了 Modelfile。这其实是一个独立的配置文件，其设计灵感自然来源于 Dockerfiles。该文件用于指定基础模型、聊天模板、系统提示词、采样参数以及停止标记等信息。这些信息大部分其实已经包含在 GGUF 文件中了。正如一位 Hacker News 用户所说：“我们好不容易摆脱了多文件带来的混乱，结果 Ollama 又把它们加回来了。”

这种方法的弊端会迅速累积。Ollama 仅能自动检测硬编码列表中已知的聊天模板。如果某个 GGUF 文件的元数据中包含有效的 Jinja 聊天模板，但该模板与 Ollama 已知的模板不匹配，Ollama 会退而使用默认的 {{ .Prompt }} 模板，从而无形中破坏了模型的指令格式。用户必须手动从 GGUF 中提取聊天模板，将其转换为 Go 模板语法（这与 Jinja 的语法不同），然后再将其写入 Modelfile 文件中。而 llama.cpp 则直接读取嵌入的模板并使用它。

修改参数的情况更糟。如果你想更改从 Ollama 注册表中获取的模型的温度或系统提示词，操作流程如下：先导出包含 ollama show –modelfile 的 Modelfile 文件，对其进行编辑，然后再运行 ollama create 以生成新的模型。用户反映，为了更改一个参数，整个 30 到 60GB 大小的模型都被复制了。正如一位用户所说：“‘Modelfile’这种操作流程简直糟糕透顶。这完全是毫无效率的重复劳动，我实在讨厌。有些模型大小高达 30 到 60GB，仅仅为了更改一个参数就复制整个文件，简直太愚蠢了。”

与 llama.cpp 相比，后者的参数是命令行标志。想要不同的温度？传入 –temp 0.7 即可。系统提示符不同？直接在 API 请求中指定即可。无需创建任何文件，无需复制大量数据，也无需学习复杂的专有格式。

该模型文件还迫使用户使用 Ollama 的 Go 模板语法，而这与模型创建者实际发布的 Jinja 模板是不同的语言。LM Studio 可以直接识别 Jinja 模板。lam.cpp 则从 GGUF 中读取这些模板。唯有 Ollama 需要用户在不同的模板语言之间进行转换，而且经常出错，以至于 GitHub 上有很多专门讨论 Ollama 库与上游 GGUF 元数据之间模板不匹配的问题。

注册表瓶颈

每当有新模型发布，比如新的 Qwen、Gemma 或 DeepSeek 版本，GGUFs 通常会在几小时内出现在 Hugging Face 上，这些模型由 Unsloth 或 Bartowski 等社区成员进行量化处理。使用 llama.cpp，你可以立即运行这些模型： llama-server -hf unsloth/Qwen3.5-35B-A3B-GGUF:Q4_K_M 。只需一条命令，直接来自 Hugging Face，无需任何中间环节。

使用 Ollama 时，你需要耐心等待。Ollama 团队中必须有人将模型打包好以便上传到注册表中，选择要提供的量化方式（通常只有 Q4_K_M 和 Q8_0 两种，没有 Q5、Q6 或 IQ 量化方式），将聊天模板转换为 Go 格式，然后再将其上传。在完成这些步骤之前，该模型在 Ollama 系统中实际上是不存在的，除非你自己手动处理 Modelfile 相关操作。

在 r/LocalLLaMA 上，这种情况反复出现：新模型发布后，人们尝试通过 Ollama 来使用它们，结果却发现模型要么运行不正常、速度很慢，要么聊天模板质量糟糕。在这种情况下，人们总是责怪模型本身，而不会去追究运行环境的问题。最近有一篇题为“如果你想测试新模型，请使用 llama.cpp/transformers/vLLM/SGLang”的帖子指出，由于 Qwen 模型使用了特定的后端架构和有问题的模板处理机制，因此在工具调用和响应质量方面存在问题，而这些问题“只有在 Ollama 上才会出现”。正如一位评论者所说：“朋友是不会让朋友去用 Ollama 的。”

量化限制尤其令人沮丧。Ollama 仅支持创建 Q4_K_S、Q4_K_M、Q8_0、F16 和 F32 这几种量化格式。如果你需要 Q5_K_M、Q6_K 或任何 Llama.cpp 多年来一直支持的 IQ 量化格式，那你就没辙了，除非你在 Ollama 之外自行进行量化处理。当有用户询问是否支持 Q2_K 格式时，得到的答复实际上是“请使用其他工具”。对于一个宣称自己是运行模型的简易方式的项目来说，却让用户去别的地方寻找基本的量化功能，这实在说不通。

Hugging Face 最终通过动态生成 Docker 风格的配置文件，实现了对 ollama run hf.co/{repo}:{quant} 的支持，这在一定程度上解决了可用性问题。但即便如此，该文件仍会被复制到 Ollama 的哈希化存储系统中，你仍然无法将 GGUF 与其他工具共享，模板检测问题也依然存在。其根本架构并未改变：Ollama 始终充当着你与模型之间的中介，而这个中介比其上层的工具更慢、功能更弱、兼容性也更差。

Cloud Pivot

2025 年底，Ollama 在本地模型库的基础上推出了云端托管模型。这款原本以本地私有推理著称的工具，开始将用户输入的提示语发送至第三方云服务提供商。MiniMax 等专有模型也出现在了模型列表中，但并未明确说明选择这些模型会导致用户数据被传输到外部服务器。

用户对数据路由问题表示担忧。当通过“Ollama Cloud”运行 MiniMax-m2.7 这类闭源模型时，用户的输入内容可能会被转发给实际托管该模型的外部服务提供商。Ollama 的官方文档称“我们处理用户的输入和输出内容以提供服务，但不会存储或记录这些内容”，却未提及第三方服务提供商会如何处理这些数据。对于由阿里云托管的模型，用户指出该平台并不提供“零数据保留”保障。

CVE-2025-51471 进一步加剧了这一问题。该漏洞属于令牌泄露型缺陷，影响了所有版本的 Ollama。恶意注册表服务器可在正常模型加载过程中，诱使 Ollama 将其认证令牌发送到攻击者控制的端点。虽然该漏洞的修复方案早已提交，但实际应用仍耗费了数月时间。对于一个以保护用户隐私为核心理念的工具而言，允许凭证泄露给任意服务器的漏洞绝非小问题，而是一个关乎整体架构的设计缺陷。

VC 模式

当你了解其激励机制后，这一切就都说得通了。Ollama 是一家由 Y Combinator 投资的初创公司，其创始人曾是开发 Docker 图形用户界面的工程师，该界面后来被 Docker Inc.收购。这种模式很常见：将现有的开源项目包装进用户友好的界面中，建立用户群，筹集资金，然后再考虑如何实现盈利。

其发展过程完全遵循这一规律：

基于开源技术启动，以 llama.cpp 为框架，赢得社区信任
尽量减少归因因素，让投资者觉得该产品具备自我造血能力。
创建一种具有锁定效应的专有模型注册格式，使用哈希处理后的文件名，确保该格式无法与其他工具兼容
启动闭源组件及 GUI 应用程序
添加云服务，作为盈利渠道

模型注册表值得仔细研究。Ollama 使用自己特有的格式，通过哈希处理后的文件名来存储下载的模型。如果你已经使用 Ollama 数月，那么如果不进行额外操作，就无法直接让 llama.cpp 或 LM Studio 识别这些文件。虽然可以通过 Modelfile 将自定义的 GGUF 模型导入 Ollama，但将其导出却相当麻烦。这是一种供应商锁定机制，大多数用户在试图离开该平台时才会意识到这一点。

该用什么来替代

Ollama 所封装的工具可以直接使用，其设置难度也不大。

llama.cpp 是该引擎的核心。它拥有与 OpenAI 兼容的 API 服务器（ llama-server ）、内置的 Web 用户界面，能够完全控制上下文窗口和采样参数。其处理效率也始终优于 Ollama。2026 年 2 月，Gerganov 的 ggml.ai 加入了 Hugging Face，以确保该项目的长期可持续发展。该项目完全由社区驱动，采用 MIT 许可证，目前有 450 多名贡献者正在积极开发中。

Mozilla 的 llamafile 将“单文件”理念进一步发扬光大：它将模型和运行时环境打包为一个可执行文件，无需任何安装即可在六种操作系统上运行。下载后双击即可使用。

Llama-Swap 能够处理多模型协调工作，通过单个 API 端点按需加载、卸载和热替换模型。将其与 LiteLLM 结合使用，即可获得一个兼容 OpenAI 的统一代理，该代理能够通过适当的模型别名在多个后端之间进行路由选择。

如果你需要桌面图形用户界面，其实有很多开源选项可供选择。Jan（AGPLv3）是一款以本地使用为主的聊天应用，拥有简洁的界面和完整的源代码。koboldcpp（AGPL）则是 llama.cpp 的衍生项目，具备内置网页界面和丰富的配置选项，完全开源且可被彻底审计。这两款都是真正的开源项目，而非那种利用开源引擎来掩盖专有代码的封装工具。

还有那些闭源的封装工具。LM Studio 是一款基于 llama.cpp 开发的专有软件，它之所以能成为 Ollama 最受欢迎的替代品，是有充分理由的：它拥有与 Ollama 相同的一键操作便捷性，同时还配备了完善的图形用户界面；它能接受任何格式的 GGUF 输入，并能完整展示所有相关参数。最重要的是，LM Studio 的开发者始终以诚信的态度对待整个生态系统。他们专门设置了致谢页面，明确标注了 llama.cpp 及其许可证信息，也从不试图隐瞒软件的内部实现细节。虽然这是一款闭源产品，但它绝不是那种“寄生于”开源技术的软件。Msty 则是另一款基于开源推理引擎开发的闭源 GUI 工具，它支持多模型处理，还内置了 RAG 功能。

我并不反对有人通过让开源软件更易于使用来开展业务。这完全合情合理。但有必要坦诚地说明这些工具的实质：它们是商业产品，其存在得益于 lama.cpp，而非 Ollama 的开源替代方案。区分善意开发的工具与恶意开发的工具，不在于是否收费或是否使用专有代码，而在于是否尊重了其赖以存在的开源成果。LM Studio 做到了，Ollama 则没有。

Red Hat 的 Ramalama 也值得一试，这是一款基于容器的模型运行工具，它会明确地将所有上游依赖项清晰地展示出来。这正是 Ollama 从一开始就应该做的。

这些工具的安装都只需要几分钟时间。认为 Ollama 是唯一可行的选择，这种观点早已不再正确。

全局视野/整体情况

2023 年 3 月的一个晚上，Georgi Gerganov 编写出了 lama.cpp。这一举动引发了本地人工智能领域的革命。他和数百名贡献者共同付出了多年努力，使得越来越强大的模型能够在普通硬件上运行。这项工作意义重大，它是让本地推理技术得以持续发展、被更多人使用的基石。

Ollama 把那个项目包装成了一个用户友好的命令行界面，借此筹集了风险投资资金。随后一年多时间里，他们一直拒绝承认该项目的开源性质。他们还恶意地分叉了该项目，同时发布了一个闭源应用程序。最后，他们将整个项目转向了云服务领域。在每一个本可以成为优秀开源项目的关键时刻，他们都选择了能让投资者觉得他们更“自给自足”的做法。

当地的 LLM 生态系统不需要 Ollama。它需要的是 llama.cpp。其余的不过是打包工作而已，而且现有的打包方式已经相当不错了。

‘码字派’译自：

https://sleepingrobots.com/dreams/stop-using-ollama/

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。