停止使用 Ollama

# 朋友不该让朋友用 Ollama | 沉睡机器人 来源：https://sleepingrobots.com/dreams/stop-using-ollama/ Ollama 是目前最流行的本地大语言模型运行工具，但它不应占据这个地位。它之所以能拿下这个位置，只是因为来得早——第一个让不懂编译 C++ 或自己写服务器配置的人也能用上 `llama.cpp` 的工具。这曾是一份实打实的贡献，但也就短暂那么一阵子。此后，该项目多年里系统性地掩盖其实际技术的来源，误导用户了解他们究竟在跑什么，并且逐渐背离了当初赢得信任的“本地优先”使命。而这一切，还是在拿了风投资金的情况下发生的。 这不是一篇“各打五十大板”的文章。我一度用过 Ollama。但现在已经改用其他工具了。以下就是你该和它说再见的原因。 ## 一个患有“失忆症”的 llama.cpp 封装器 Ollama 全部的推理能力都来源于 [llama.cpp](https://github.com/ggml-org/llama.cpp)，这是 Georgi Gerganov 在 2023 年 3 月创建的 C++ 推理引擎。正是 Gerganov 的项目让 LLaMA 模型能够在普通消费级笔记本上运行——他[用一个晚上](https://github.com/ggml-org/llama.cpp/blob/775328064e69db1eb/README.md)拼凑出了初版，由此引爆了整个本地大语言模型运动。如今 llama.cpp 在 GitHub 上拥有超过 10 万颗星、450 多位贡献者，几乎所有基于 GGUF 的工具都离不开它。 Ollama 由 Jeffrey Morgan 和 Michael Chiang 于 2021 年创立，两人之前曾参与过 [Kitematic](https://github.com/docker/kitematic)（一个被 Docker Inc. 收购的 Docker GUI）。他们通过了 Y Combinator 2021 年冬季批次，获得了种子轮前融资，并于 2023 年公开发布。从第一天起，他们的口号就是“LLM 界的 Docker”——一个通过单条命令下载并运行模型的便捷封装器。而底层，所有工作都是 llama.cpp 完成的。 在长达一年多的时间里，Ollama 的 README [丝毫没有提及 llama.cpp](https://github.com/ollama/ollama/issues/3697)。README 里没提，官网上没提，宣传材料里也没提。该项目的二进制发行版[没有附带 llama.cpp 代码所需的 MIT 许可证声明](https://github.com/ollama/ollama/issues/3185)。这并非开源礼仪的小节：MIT 许可证只有一个主要要求——包含版权声明。Ollama 没有这样做。 社区注意到了这个问题。2024 年初，有人提了 [GitHub Issue #3185](https://github.com/ollama/ollama/issues/3185) 要求遵守许可证规定。这个 issue **超过 400 天没有得到维护者的任何回应**。当 [Issue #3697](https://github.com/ollama/ollama/issues/3697) 在 2024 年 4 月被创建，专门要求标明 llama.cpp 致谢信息时，社区用户几小时后就提交了 [PR #3700](https://github.com/ollama/ollama/pull/3700)。最终，Ollama 联合创始人 Michael Chiang [在 README 底部加了一行](https://github.com/ollama/ollama/commit/9755cf9173152047030b6d080c29c829bb050a15)：“llama.cpp 项目由 Georgi Gerganov 创立。” 他们对这个 PR 的回复暴露了真实态度。Ollama 团队写道：“我们花了大量时间修复和打补丁，以确保 Ollama 用户获得顺畅体验……随着时间的推移，我们将过渡到更系统地构建的引擎。”言下之意：我们不会给 llama.cpp 显眼的鸣谢位置，而且我们反正计划与其拉开距离。 正如 [一位 Hacker News 评论者](https://news.ycombinator.com/item?id=44003741) 所言：“我始终对他们的做法感到困惑，这完全是自找的负面公关。基于 llama 构建完全合理，他们也在易用性上增加了价值。只需给 llama 团队应有的致谢就行了。”另一位则说：“Ollama 一直刻意淡化对 llama.cpp 的依赖，这在本地大模型社区里早就不是秘密了。” ## 让事情变得更糟的分支 2025 年中，Ollama 兑现了“拉开距离”的承诺。他们放弃了将 llama.cpp 作为推理后端，而是直接在 [ggml](https://github.com/ggml-org/ggml)（llama.cpp 本身使用的底层张量库）之上构建了一个自定义实现。他们官方的理由是稳定性：llama.cpp 迭代快、容易破坏旧功能，而 Ollama 的企业合作伙伴需要可靠性。 结果却适得其反。Ollama 的自定义后端[重新引入了 llama.cpp 多年前就已解决的 bug](https://www.xda-developers.com/ollama-easiest-way-start-local-llms-worst-keep-running/)。社区成员反馈，多个版本中出现了结构化输出支持崩溃、视觉模型失败以及 GGML 断言崩溃等问题。在上游 llama.cpp 中运行良好的模型，[在 Ollama 中无法运行](https://finance.biggo.com/news/202508120115_Ollama_llama.cpp_compatibility_issues)，包括新发布的 GPT-OSS 20B——Ollama 的实现缺乏模型所需的张量类型支持。Georgi Gerganov 本人[指出](https://x.com/ggerganov/status/1953088008816619637) Ollama 进行了分叉并对 GGML 做了糟糕的改动。 讽刺意味十足：多年淡化对 llama.cpp 的依赖，最终单飞时，却造出了一个比它们不承认的那个东西更差劲的版本。 基准测试说明了情况。多项社区测试表明，在相同硬件和模型下，llama.cpp [速度是 Ollama 的 1.8 倍](https://www.arsturn.com/blog/comparing-ollama-and-llamacpp)——每秒 161 个 token 对比 89 个。在 CPU 上，差距达到 [30-50%](https://deploybase.ai/articles/llama-cpp-vs-ollama)。最近一项 [Qwen-3 Coder 32B 的对比](https://www.reddit.com/r/LocalLLaMA/comments/1q64f26/llamacpp_vs_ollama_70_higher_code_generation/) 显示，llama.cpp 的吞吐量高出 ~70%。性能开销来自 Ollama 的守护进程层、糟糕的 GPU 卸载启发式算法，以及一个落后于上游的自研后端。 ## 误导性的模型命名 当 DeepSeek 在 2025 年 1 月发布 R1 模型系列时，Ollama 将较小的蒸馏版本（如 DeepSeek-R1-Distill-Qwen-32B，这是微调后的 Qwen 和 Llama 模型，并非真正的 6710 亿参数 R1）在其库和 CLI 中[直接标记为“DeepSeek-R1”](https://www.reddit.com/r/LocalLLaMA/comments/1i8ifxd/ollama_is_confusing_people_by_pretending_that_the/)。运行 `ollama run deepseek-r1` 拉取的是一个 8B Qwen 衍生的蒸馏模型，其行为与真正的模型截然不同。 这绝非疏忽。DeepSeek 自己就为这些模型加了“R1-Distill”前缀。Hugging Face 上也正确标注。Ollama 却抹掉了这一区别。结果导致大量社交媒体帖子声称自己在消费级硬件上运行“DeepSeek-R1”，随后又因模型表现不佳而困惑不已，[进而损害了 DeepSeek 的声誉](https://www.reddit.com/r/LocalLLaMA/comments/1i8ifxd/ollama_is_confusing_people_by_pretending_that_the/)。 GitHub Issue [#8557](https://github.com/ollama/ollama/issues/8557) 和 [#8698](https://github.com/ollama/ollama/issues/8698) 请求将模型分开命名。两者都被标记为重复且没有修复。时至今日，`ollama run deepseek-r1` 仍然启动一个微小的蒸馏模型。Ollama 明知区别却选择模糊处理，很可能因为“DeepSeek-R1”比“DeepSeek-R1-Distill-Qwen-32B”能带来更多下载量。 ## 闭源应用 2025 年 7 月，Ollama [发布了一款 macOS 和 Windows 的 GUI 桌面应用](https://ollama.com/blog/new-app)。该应用是在私有仓库（`github.com/ollama/app`）中开发的，发布时未附带许可证，源代码也未公开。对于一个以开源为招牌的项目而言，这一举动令人震惊。 社区成员[立刻提出了担忧](https://github.com/ollama/ollama/issues/11634)。许可证问题获得了 40 个赞。开发者发现二进制文件中包含[潜在的 AGPL-3.0 依赖项](https://github.com/ollama/ollama/issues/11634)。该网站将下载按钮紧挨着 GitHub 链接放置，让用户误以为下载的是 MIT 许可的开源工具，而实际得到的却是一个未授权闭源应用。维护者数月保持沉默。最终代码在 2025 年 11 月被[合并到主仓库](https://github.com/ollama/ollama/pull/12933)，但最初的发布方式已经暴露了该项目的真实倾向。 正如 [XDA 所言](https://www.xda-developers.com/ollama-easiest-way-start-local-llms-worst-keep-running/)：“如果你的项目靠着开源的名声发展，你就不能在发布时对哪些部分开源、哪些闭源含糊其辞。” ## Modelfile：重新发明一个已有的轮子 GGUF 是 Georgi Gerganov 创建的模型格式，其设计[核心原则](https://github.com/ggml-org/ggml/blob/master/docs/gguf.md)是单文件部署。GGUF 规范的第一条就是：“完整信息：加载模型所需的所有信息都包含在模型文件中，用户无需提供额外信息。”聊天模板、停止符、模型元数据……全都嵌入文件内。你只需将 llama.cpp 指向一个 GGUF 文件，一切就能正常工作。 Ollama 在此基础上又增加了 Modelfile。它是一个独立的配置文件（自然受到了 Dockerfile 的启发），用于指定基础模型、聊天模板、系统提示、采样参数和停止符。而这些信息的大部分原本就已经存在于 GGUF 文件中。正如[一位 Hacker News 评论者](https://news.ycombinator.com/item?id=43845842)所言：“我们好不容易才摆脱了那种多文件混乱，Ollama 却把它们又请了回来。” 这种方式的问题迅速累积。Ollama [只能自动识别它已知的聊天模板](https://github.com/ollama/ollama/issues/6371)——即一份硬编码列表中的模板。如果某个 GGUF 文件的元数据中嵌入了有效的 Jinja 聊天模板，但该模板不在 Ollama 的已知列表里，Ollama 就会回退到一个裸 `{{ .Prompt }}` 模板，从而静默破坏模型的指令格式。用户必须手动从 GGUF 中提取聊天模板，将其翻译成 Go 模板语法（与 Jinja 不同），再写入 Modelfile。而与此同时，llama.cpp 直接读取嵌入的模板，开箱即用。 修改参数就更糟糕了。如果你想更改从 Ollama 注册表拉取的模型的 temperature 或系统提示，工作流是：用 `ollama show --modelfile` 导出 Modelfile，编辑它，然后运行 `ollama create` 构建一个新的模型条目。用户[反馈](https://news.ycombinator.com/item?id=43845842)，这个过程会复制整个模型（30 到 60 GB）——仅仅是为了修改一个参数。正如一位用户描述的：“Modelfile 的工作流简直折磨人。这是个糟糕透顶的模式，我恨透了它。有些模型有 30 到 60 GB，为了改一个参数就复制整个文件，简直愚蠢。” 相比之下，在 llama.cpp 中，参数就是命令行选项。想要不同的 temperature？传入 `--temp 0.7`。不同的系统提示？在 API 请求中传入即可。无需创建文件，无需复制千兆字节，无需学习专有格式。 Modelfile 还将用户锁定在 Ollama 的 Go 模板语法中，而这是一种[与模型创作者实际使用的 Jinja 模板不同的语言](https://github.com/ollama/ollama/issues/8982)。LM Studio 直接接受 Jinja 模板。llama.cpp 从 GGUF 中读取它们。只有 Ollama 要求你在模板语言之间做翻译，并且常常出错，以至于[有整整一个 GitHub issue](https://github.com/ollama/ollama/issues/8982) 都在讨论 Ollama 库与上游 GGUF 元数据之间的模板不匹配问题。 ## 注册表瓶颈 当新模型发布时（比如新版本的 Qwen、Gemma 或 DeepSeek），GGUF 文件通常几小时内就会出现在 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](https://github.com/ollama/ollama/issues/8752)，没有 Q5、Q6 或 IQ 量化），将聊天模板转换为 Go 格式，然后推送。在那之前，这个模型在 Ollama 的世界里就不存在——除非你自己手动执行 Modelfile 那套流程。 这就导致 r/LocalLLaMA 上[反复出现一种模式](https://www.reddit.com/r/LocalLLaMA/comments/1rjb7yk/psa_if_you_want_to_test_new_models_use/)：新模型发布后，人们通过 Ollama 尝试，结果模型崩溃、运行缓慢或聊天模板混乱，然后模型被指责，而不是运行时环境。最近一篇名为“如果你要测试新模型，请用 llama.cpp/transformers/vLLM/SGLang”的 PSA 帖子提到，Qwen 模型在工具调用和垃圾回复上表现出的问题“只会在 Ollama 上出现”，原因是它们自研的后端和糟糕的模板处理。正如一位评论者所说：“朋友不该让朋友用 Ollama。” 量化限制尤其令人沮丧。Ollama [仅支持创建 Q4_K_S、Q4_K_M、Q8_0、F16 和 F32 量化](https://github.com/ollama/ollama/issues/10749)。如果你需要 Q5_K_M、Q6_K 或任何 IQ 量化——这些格式 llama.cpp 已经支持多年——那你只能在自己动手在 Ollama 之外进行量化。当有用户[问及 Q2_K 支持时](https://github.com/ollama/ollama/issues/10749)，得到的回复实际上是“请使用其他工具”。对于一个标榜自己为“运行模型最简单方式”的项目来说，告诉用户去其他地方寻找基本的量化选项，已经说明了很多问题。 Hugging Face 最终通过动态生成 Docker 风格的 manifest 增加了对 `ollama run hf.co/{repo}:{quant}` 的支持，这在一定程度上解决了可用性问题。但即便如此，文件仍会被复制到 Ollama 的哈希 blob 存储中，你不能与其他工具共享这个 GGUF 文件，而且模板检测问题依然存在。根本架构没有变：Ollama 把自己插在你和模型之间当中间人，而这个中间人比你依赖的下层工具更慢、能力更差、兼容性也更低。 ## 向云端转向 2025 年末，Ollama 在本地库旁边引入了云端托管的模型。这个本应与本地、私有推理划等号的工具，[开始将提示路由到第三方云提供商](https://www.banandre.com/blog/ollamas-shift-to-cloud-and-proprietary-models-sparks-privacy-and-openness-backlash)。像 MiniMax 这样的专有模型出现在模型列表中，却没有明确说明选择它们会将你的数据发送到机器之外。 用户[对数据路由提出了担忧](https://www.reddit.com/r/ollama/comments/1s18cdf/ollama_cloud_ai_no_public_privacy_policy/)：当你通过“Ollama Cloud”运行像 MiniMax-m2.7 这样的闭源模型时，你的提示词可能会被转发到实际托管该模型的外部提供商。Ollama 自己的文档说“我们处理你的提示词和响应以提供服务，但不会存储或记录这些内容”，但只字未提第三方提供商如何处理这些数据。对于由阿里云托管的模型，用户[指出没有任何零数据保留保证](https://github.com/ollama/o