朋友之间不应该推荐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 图形用户界面工具，后被 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 团队写道：“我们花费大量时间修复和修补漏洞，以确保 Ollama 用户获得流畅的使用体验……随着时间的推移，我们将过渡到更系统化构建的引擎。” 言下之意：我们不会给 llama.cpp 署名，而且我们计划与之保持距离。 正如一位Hacker News 评论者所说：“我一直对他们的做法感到困惑，这简直是自找麻烦。基于 Llama 进行开发完全合理，而且他们也确实提升了易用性。 只是应该给予 Llama 团队应有的认可。”另一位评论者则表示：“Ollama 一直淡化他们对 llama.cpp 的依赖，这在本地 LLM 社区早已是公开的秘密。” 让事情变得更糟的那把叉子 2025 年年中，Ollama 兑现了这一承诺。他们不再使用 llama.cpp 作为推理后端，而是直接基于ggml（llama.cpp 本身使用的底层张量库）构建了一个自定义实现。 他们给出的理由是稳定性，llama.cpp 更新频繁，容易出现问题，而 Ollama 的企业合作伙伴需要的是可靠性。 结果却恰恰相反。Ollama 的自定义后端重新引入了 llama.cpp 多年前已经修复的 bug。社区成员在多个版本中都发现了结构化输出支持失效、视觉模型运行失败以及 GGML 断言崩溃等问题。 在上游 llama.cpp 中运行良好的模型在 Ollama 中却无法正常工作，包括像 GPT-OSS 20B 这样的新版本，因为 Ollama 的实现缺少对模型所需张量类型的支持。 Georgi Gerganov 本人也指出，Ollama 对 GGML 进行了分支并做出了错误的修改。 真是莫大的讽刺。多年来，他们一直淡化对 llama.cpp 的依赖，结果最终尝试独立开发时，却做出了一个不如原作者的版本，而他们之前却拒绝承认这一点。 基准测试结果说明了一切。多项社区测试表明，在相同硬件和相同型号的处理器上， llama.cpp 的运行速度比 Ollama 快 1.8 倍，每秒处理 161 个令牌，而 Ollama 仅为 89 个。 在 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，这些模型是对 Qwen 和 Llama 模型进行微调后的结果，并非真正的 6710 亿参数 R1 模型。 运行该ollama run deepseek-r1模型会拉取一个 80 亿参数的 Qwen 衍生精简版，其行为与真实模型截然不同。 这并非疏忽。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的图形用户界面桌面应用程序。该应用程序在一个私有代码库中开发github.com/ollama/app，没有提供许可证，源代码也不公开。 对于一个以开源著称的项目来说，这无疑是一个令人震惊的举动。 社区成员立即提出了担忧。许可证问题获得了 40 个赞。开发者在二进制文件中发现了潜在的 AGPL-3.0 依赖项。 网站将下载按钮放在 GitHub 链接旁边，使用户误以为下载的是 MIT 许可的开源工具，而实际上下载的是一个未授权的闭源应用程序。 维护者几个月来一直保持沉默。代码最终于 2025 年 11 月合并到主代码库中，但最初的发布暴露了该项目的真实意图。 正如XDA 所说：“如果你的项目以开源为卖点，那么在发布时你就不能含糊其辞地说明哪些内容是开源的，哪些内容不是开源的。” 模型文件：重新发明一个已解决的问题 GGUF 是由 Georgi Gerganov 创建的模型格式，其设计核心原则是：单文件部署。GGUF 规范的第一条写道：“完整信息： 加载模型所需的所有信息都包含在模型文件中，用户无需提供任何额外信息。”聊天模板、停止令牌、模型元数据，所有这些都嵌入在文件中。 只需将 llama.cpp 指向一个 GGUF 文件，即可正常工作。 Ollama 在此基础上添加了 Modelfile。这是一个独立的配置文件，其灵感显然来自 Dockerfile，它指定了基础模型、聊天模板、系统提示符、采样参数和停止令牌。 这些信息大部分已经存在于 GGUF 文件中。正如一位 Hacker News 评论者所说：“我们好不容易摆脱了多文件混乱的局面，结果 Ollama 又把它加了回来。” 这种方法的弊端会迅速累积。Ollama 只能从硬编码的列表中自动检测已知的聊天模板{{ .Prompt }}。 如果一个 GGUF 文件的元数据中嵌入了一个有效的 Jinja 聊天模板，但它与 Ollama 已知的模板都不匹配，Ollama 就会回退到使用一个裸模板，从而悄无声息地破坏模型的指令格式。 用户必须手动从 GGUF 文件中提取聊天模板，将其转换为 Go 模板语法（与 Jinja 不同），然后写入模型文件。而 llama.cpp 却直接读取嵌入的模板并使用它。 修改参数更糟糕。如果你想更改从 Ollama 注册表中提取的模型的温度或系统提示，工作流程是： 导出模型文件ollama show --modelfile，编辑它，然后运行命令ollama create创建新的模型条目。用户报告称，这个过程会复制整个模型（30 到 60 GB），而仅仅是为了更改一个参数。 正如一位用户所描述的：“‘模型文件’工作流程简直是噩梦。这简直是胡闹，我讨厌它。有些模型有 30 到 60 GB，为了更改一个参数就复制整个模型，这简直愚蠢至极。” 相比之下，llama.cpp 中的参数是命令行标志。想要不同的温度？传递参数即可--temp 0.7。想要不同的系统提示符？在 API 请求中传递。 无需创建文件，无需复制 GB 的数据，也无需学习任何专有格式。 模型文件还将用户限制在 Ollama 的 Go 模板语法中，这与模型创建者实际发布的 Jinja 模板语言不同。LM Studio 直接接受 Jinja 模板。 llama.cpp 从 GGUF 读取这些模板。只有 Ollama 要求用户在模板语言之间进行转换，而且转换错误率很高， 以至于GitHub 上有很多 issue专门讨论 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，不提供 Q5、Q6 或 IQ 量化），将聊天模板转换为 Go 格式，然后提交。 在此之前，除非你自己手动修改模型文件，否则该模型在 Ollama 的系统中并不存在。 这在 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 或任何其他 IQ 量化格式（llama.cpp 多年来一直支持这些格式），除非您在 Ollama 之外自行进行量化，否则将无法实现。 当用户询问 Q2_K 支持时，得到的回复实际上是“使用其他工具”。 对于一个标榜自己是运行模型最简便的工具的项目来说，让用户去别处寻找基本的量化选项，这本身就说明了一些问题。 Hugging Face 最终通过动态生成 Docker 风格的清单文件来支持此功能ollama run hf.co/{repo}:{quant}，这在一定程度上解决了可用性问题。 但即便如此，该文件仍会被复制到 Ollama 的哈希 blob 存储中，你仍然无法与其他工具共享 GGUF，模板检测问题依然存在。 其基本架构依然不变：Ollama 将自身置于你和你的模型之间，而这个中间人比它所依赖的工具速度更慢、功能更弱、兼容性更差。 云枢纽 2025 年末，Ollama 在本地模型库之外推出了云托管模型。这款原本以本地私有推理著称的工具开始将请求路由到第三方云服务提供商。 诸如 MiniMax 之类的专有模型出现在模型列表中，但并未明确告知用户选择这些模型会将数据发送到外部服务器。 用户对数据路由提出了担忧。当通过“Ollama Cloud”运行像MiniMax-m2.7这样的闭源模型时，用户的提示信息可能会被转发给实际托管该模型的外部服务提供商。 Ollama官方文档称“我们会处理您的提示和响应以提供服务，但不会存储或记录这些内容”，但并未说明第三方服务提供商如何处理这些信息。 对于托管在阿里云上的模型，用户指出，阿里云并不提供零数据保留保证。 CVE-2025-51471漏洞加剧了这一问题，该漏洞是一个令牌泄露漏洞，影响所有 Ollama 版本。 恶意注册表服务器可以诱骗 Ollama 在正常拉取模型期间将其身份验证令牌发送到攻击者控制的端点。 该漏洞的修复程序已以 PR 的形式提交，但耗时数月才最终合并。对于一款以本地隐私保护著称的工具而言，一个会将凭据泄露给任意服务器的漏洞绝非小事，而是一个架构理念上的问题。 VC模式 当你了解其激励机制时，这一切就更容易理解了。 Ollama 是一家由 Y Combinator 投资的初创公司（W21），由一群工程师创立，他们之前开发了一个 Docker 图形用户界面，后来被 Docker 公司收购。 他们的模式很常见：将现有的开源项目封装成一个用户友好的界面，建立用户群，筹集资金，然后找到盈利模式。 这一过程完全遵循了这一模式： 在开源平台上发布，基于 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的一个分支，内置Web用户界面和丰富的配置选项，完全开源且可审计。 两者都是真正的自由开源软件项目，而不是将专有代码隐藏在开源引擎背后的封装程序。 此外，还有一些闭源封装软件。LM Studio是一款基于 llama.cpp 构建的专有软件，它之所以成为 Ollama 最受欢迎的替代方案，原因显而易见： 它提供了同样便捷的一键式操作，并拥有完善的图形用户界面 (GUI)，支持所有 GGUF 格式，且所有参数都公开透明。 至关重要的是，LM Studio 的开发者对整个生态系统秉持着良好的合作精神。他们维护了一个完善的致谢页面，注明了 llama.cpp 及其许可证， 并且没有试图掩盖其底层代码。虽然它是闭源产品，但它并非寄生于其他生态系统。Msty是另一个基于开源推理的闭源 GUI，它支持多模型并内置了 RAG（红绿灯）功能。 我并不反对有人通过让开源软件（FOSS）更便捷来建立自己的商业模式。这无可厚非。但我们必须坦诚地指出这些工具的本质： 它们是基于 llama.cpp 而存在的商业产品，而非 Ollama 的开源替代品。善意封装和恶意封装的区别不在于它们是否收费或发布专有代码， 而在于它们是否尊重自己所依赖的成果。LM Studio 做到了这一点，而 Ollama 则没有。 Red Hat 的ramalama也值得一看，它是一个容器原生模型运行器，会明确地将上游依赖项放在最显眼的位置。这正是 Ollama 从一开始就应该做的。 这些工具的设置都只需要几分钟。认为 Ollama 是唯一无障碍选择的观点早已过时。 大局观 2023年3月的一个晚上，Georgi Gerganov 匆匆编写了 llama.cpp，由此开启了本地人工智能领域的革命。 他和数百名贡献者组成的社区多年来致力于让在消费级硬件上运行功能日益强大的模型。这项工作意义非凡，它是本地推理技术保持开放性和可访问性的基础。 Ollama 将这项工作封装成一个漂亮的命令行界面 (CLI)，并以此获得了风险投资，之后却拒绝署名一年多，还糟糕地 fork 了项目，同时发布了一个闭源应用， 最后又将整个项目转向了云服务。在每一个本可以成为优秀开源公民的决策点上，他们都选择了让自己在投资者眼中显得更加自给自足的道路。 本地LLM生态系统不需要Ollama，它只需要llama.cpp。其余部分都是打包问题，而更好的打包方案已经存在。 [本文转载][1] [1]: https://sleepingrobots.com/dreams/stop-using-ollama/