> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 为什么我不再使用Ollama - URL: https://www.hubwiz.com/blog/why-i-stopped-using-ollama/ - Published: 2026-06-01T01:06:32.000Z - Updated: 2026-10-13T14:49:36.000Z - Description: 在2026年继续使用Ollama正在让你的性能、灵活性和对开源生态系统的信任付出代价。 - Author: admin - Tags: TOOL, OLLAMA, #Import 2026-10-14 14:41 正在发生这样的情况：每当新用户想开始使用本地AI时，Ollama就成为默认推荐。YouTube教程指向它。博客文章默认使用它。文档将其视为标准。这是一个问题——因为你有更好的选择，而在2026年继续使用Ollama正在让你的性能、灵活性和对开源生态系统的信任付出代价。 我写这篇文章是为了节省我自己花了很多时间才弄清楚这一切的代价。读一读。考虑切换。你的未来自己——以及开源社区——会感谢你的。 ## 1、Ollama比llama.cpp慢得多 多个社区基准测试和开发者报告显示，通过Ollama运行同一个模型比直接通过llama.cpp运行产生的每秒token数少30-70%。这不是边际差异——这是你在等待输出时能感觉到的差距。 在一台运行Qwen3 Coder 32B的RTX 5090上，一位用户记录了llama.cpp为52 token/秒，而Ollama为30 token/秒——70%的性能差距。这不是个别案例。nullmirror团队记录了他们从Ollama切换到llama.cpp的过程，发现他们测试的每个模型的吞吐量都有一致的提升，没有任何质量折衷。 ## 2、他们fork了llama.cpp，走向闭源，把你锁定了 在2024-2025年期间，Ollama fork了ggml（llama.cpp构建在其上的底层张量库），并构建了自己的自定义推理引擎。他们完全停止使用llama.cpp。随之而来的是一个专有的模型存储格式。 你下载的模型以哈希文件名存储在Ollama自己的注册表格式中。你不能直接让llama.cpp、LM Studio或任何其他推理框架指向这些文件。你"拥有"的模型被困在Ollama的生态系统中。 这就是伪装成开源便利性的供应商锁定。你不被允许再导出"开源的"LLM模型权重了。这种讽刺令人瞠目。 更糟糕的是，在此期间，Ollama的推理性能一直比llama.cpp差——所以你被锁定了，还得到了更慢的性能。双重损失。 ## 3、他们停止署名，然后又改回来了。为什么？ Ollama开始将自己定位为一个独立平台，而不仅仅是llama.cpp的包装器。随之而来的是一个令人担忧的模式：他们停止给上游依赖提供适当的署名。 多年来，Ollama的README没有提及llama.cpp。归属信息被埋没、模糊或缺失。如果你的项目以开源为卖点，你不允许在发布时模糊什么是开源的、什么不是。 2026年5月，Ollama宣布了v0.30.0-rc15，切换回直接使用llama.cpp。GGUF模型现在又是一等公民了。三个原因推动了这一逆转： 1. 社区对锁定和缺乏署名的压力。 2. 性能压力——他们的自定义后端无法跟上llama.cpp的进步。 3. 模型兼容性——他们的fork无法足够快地支持新架构。 这一逆转是受欢迎的，但它不能抹去他们主动破坏所依赖的项目的那个时期。问题是：如果社区压力没有增大，他们还会切换回来吗？ ## 4、Ollama背叛了本地优先的承诺 Ollama最初是作为一个本地AI推理工具开始的。这是承诺。在你自己的硬件上运行模型。保持数据私密。没有云、没有跟踪、没有中间人。 然后Ollama开始引入风险投资资金，并将自己重新定位为平台——不是工具，而是平台。随之而来的是Ollama Cloud。 云服务一直是一场灾难： - Qwen3.5模型的29.7%失败率，有记录且持续发生 - Ollama Cloud Pro所有模型95%的失败率 - 推理时60多秒的超时，破坏了代理工作流 - 工具调用故障（在云模型上启用工具时出现500错误） - 恶意的速率限制：每月100美元的用户仅5天后就遭遇4天限流 - 支持失踪：工单被忽视超过2周，没有事件沟通 付费使用云服务的用户正在切换到本地模型、vLLM和替代方案。服务不可靠，支持不存在，定价充满敌意。 当Ollama推动云推理时，隐私影响是什么？你的提示、你的对话、你的数据——去了哪里？曾经倡导本地优先AI的公司现在正在构建云业务。激励机制已经转移，而且并没有向有利于你的方向转变。 ## 5、信任和透明度问题 除了性能和云可靠性之外，Ollama还有一系列信任问题： 当DeepSeek发布其R1模型系列时，Ollama将较小的蒸馏版本——如`DeepSeek-R1-Distill-Qwen-32B`——在库中简单地列为"DeepSeek-R1"。这造成了巨大的混乱。社交媒体上充斥着人们声称他们在消费级硬件上运行"真正的"DeepSeek-R1，而实际上他们运行的是远小于6710亿参数完整模型的蒸馏变体。 Ollama被指控没有适当署名其项目所依赖的llama.cpp作者。他们的二进制发行版对依赖关系的说明很模糊。他们的GUI应用程序在没有源代码和许可不明确的情况下发布。应用程序代码现在已在仓库中，但这只让早期的发布看起来更糟，而不是更好。 Ollama的桌面应用程序在发布时不是主GitHub仓库的一部分。许可证不明确。源代码未公开。如果你的项目以开源为卖点，你不允许在发布时模糊什么是开源的、什么不是。 ## 6、Ollama正在快速落后 - MTP（多token预测）：llama.cpp已合并。Ollama的自定义后端无法正确支持。 - 结构化输出：在Ollama的自定义后端中损坏，在llama.cpp中正常工作。 - 新模型架构：llama.cpp在几天内添加支持。Ollama的fork落后了几个月。 - SEED OSS 36B：Ollama因为拒绝更新其llama.cpp fork，在这个模型的支持上落后了几个月。 - 路由器模式：llama.cpp现在有原生的模型切换和Web UI。Ollama在便利性方面的优势已经消失。 llama.cpp正在更快速地发展、更好地进行推理、并提供更多功能。Ollama的自定义后端重新引入了llama.cpp多年前就解决的bug。社区正在用脚投票。 ## 7、那你应该用什么替代？ 你不再需要Ollama了。它所构建的工具现在可以直接访问，而且在大多数情况下，设置起来并不困难： - 原始性能 → llama.cpp —— 更快、更多控制、没有开销。现在有路由器模式和Web UI。 - GUI + 简单性 → LM Studio —— 精致的界面，适当的GGUF支持，模型切换，定期更新的llama.cpp后端 - 多用户/生产环境 → vLLM或SGLang —— 适当的并发性，生产就绪，行业标准 - Mac / Apple Silicon → oMLX或MLX —— 原生Apple Silicon优化，连续批处理，MTP支持 便利性差距已经关闭。llama.cpp现在有了模型切换的路由器模式和内置的Web聊天界面。你不再需要Ollama的抽象层了。 Ollama刚起步时很棒。它降低了本地AI的入门门槛。让不想从源码编译C++的人也能运行LLM。为此，它值得赞赏。 但在2026年，Ollama不再是那个工具了。它是一家风投支持的平台公司： - 比它所基于的技术慢30-70% - 将你的模型锁定在专有格式中超过一年 - 停止为它所构建的开源项目署名 - 用一个不可靠的云服务背叛了本地优先的承诺 - 用令人困惑的模型命名误导用户 - 在功能方面落后于llama.cpp的持续进步 你不再必须使用Ollama了。替代方案更好、更快、更透明，也更尊重让这一切成为可能的开源社区。 今天就切换吧。你的性能、你的灵活性以及你对开源的信任都会因此变得更好。 --- 原文链接: [Why You Should Completely Avoid Ollama in 2026](https://blog.gopenai.com/why-you-should-completely-avoid-ollama-in-2026-6135d9e8591e?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「本地 & 自托管 LLM」专题的一部分。**完整地图见：[本地 & 自托管 LLM 完全指南](https://www.hubwiz.com/blog/local-llm-stack/)