为什么本地大模型生态不需要 Ollama

Ollama 是运行本地大模型最受欢迎的方式。但它不应该是。它获得这一地位是因为首发优势——首个让不想编译 C++ 或写自己服务器配置的人能够使用 llama.cpp 的工具。那曾是一个真实的贡献，虽然很短暂。但这个项目随后花费多年系统地隐瞒其实际技术来源，误导用户关于他们运行的内容，并偏离了使其赢得信任的"本地优先"使命。同时还在融资风险投资。

这不是一篇"两方论述"文章。我用过 Ollama。我已经转向其他方案了。以下是你也应该这样做的原因。

A llama.cpp 包装器，患有失忆症

Ollama 的全部推理能力来自 llama.cpp，这是 Georgi Gerganov 在 2023 年 3 月创建的 C++ 推理引擎。Gerganov 的项目使在消费级笔记本电脑上运行 LLaMA 模型成为可能，他在一个晚上就拼凑出了第一个版本，并启动了整个本地大模型运动。今天 llama.cpp 在 GitHub 上拥有超过 10 万星标、450+ 贡献者，是几乎每个基于 GGUF 的工具都依赖的基础。

Ollama 由 Jeffrey Morgan 和 Michael Chiang 于 2021 年创立，两人都曾参与 Kitematic（一个被 Docker Inc. 收购的 Docker GUI）。他们通过了 Y Combinator 的 2021 冬季批次，募集了种子前融资，并在 2023 年公开推出。从第一天起，宣传语就是"大模型的 Docker"——一个方便的包装器，可以用一条命令下载和运行模型。在幕后，是 llama.cpp 在做所有工作。

超过一年的时间里，Ollama 的 README 中没有提及 llama.cpp。不在 README 中，不在网站上，也不在他们的营销材料中。项目的二进制分发中没有包含他们所发布的 llama.cpp 代码所需的 MIT 许可证通知。这不是开源礼仪问题——MIT 许可证只有一个主要要求：包含版权通知。Ollama 没有这样做。

社区注意到了。GitHub issue #3185 在 2024 年初被提出，请求许可证合规。超过 400 天没有获得维护者的回应。当 issue #3697 在 2024 年 4 月被提出，明确要求对 llama.cpp 的致敬时，社区 PR #3700 在数小时内随之提出。Ollama 的联合创始人 Michael Chiang 最终在 README 的底部添加了一行："llama.cpp project founded by Georgi Gerganov"。

对 PR 的回应很有启示。Ollama 团队写道："我们花费大量时间对其进行修复和补丁，以确保 Ollama 用户的顺利体验……随着时间推移，我们将过渡到更系统地构建的引擎。"翻译过来就是：我们不会给 llama.cpp 突出的致敬，我们打算无论如何都要与之保持距离。

正如一位 Hacker News 评论者所说："我对他们的做法感到困惑，这是自己制造的负面公关。基于 llama 完全是有效的，他们在易用性方面确实在增加价值。只需给 llama 团队适当的致敬。"另一位评论："Ollama 一直在淡化其对 llama.cpp 的依赖这一事实在本地大模型社区中已经为人所知很久了。"

使事情变得更糟的分叉

在 2025 年中期，Ollama 落实了这一距离。他们放弃了使用 llama.cpp 作为推理后端，而是在 ggml 之上构建了自定义实现——ggml 是 llama.cpp 本身使用的低级张量库。他们声称的原因是稳定性：llama.cpp 发展迅速且经常破坏兼容性，而 Ollama 的企业合作伙伴需要可靠性。

结果相反。Ollama 的自定义后端重新引入了 llama.cpp 多年前已解决的错误。社区成员指出了结构化输出支持的破损、视觉模型故障以及多个版本中的 GGML 断言崩溃。在上游 llama.cpp 中运行良好的模型在 Ollama 中失败，包括新发布的 GPT-OSS 20B 等，Ollama 的实现缺乏对模型所需的张量类型的支持。Georgi Gerganov 本人发现 Ollama 曾分叉并对 GGML 进行了不当修改。

讽刺之处显而易见。多年来他们淡化了对 llama.cpp 的依赖，然后当他们最终尝试独立时，他们制造出了他们拒绝致敬的东西的一个劣质版本。

基准测试说明了一切。多个社区测试显示 llama.cpp 在相同硬件上使用相同模型时运行速度比 Ollama 快 1.8 倍，每秒 161 个令牌对比 89 个。在 CPU 上，差距为 30-50%。最近对 Qwen-3 Coder 32B 的比较显示 llama.cpp 的吞吐量高约 70%。性能开销来自 Ollama 的守护进程层、不佳的 GPU 卸载启发式算法以及落后于上游的供应商后端。

误导性的模型命名

当 DeepSeek 在 2025 年 1 月发布其 R1 模型家族时，Ollama 列出了较小的蒸馏版本，比如 DeepSeek-R1-Distill-Qwen-32B（这些是经过微调的 Qwen 和 Llama 模型，而不是实际的 671 亿参数 R1），却在他们的库和 CLI 中简单地标记为"DeepSeek-R1"。运行 ollama run deepseek-r1 会拉取一个 8B 的 Qwen 衍生蒸馏，其行为与真实模型完全不同。

这不是一个疏忽。DeepSeek 本身用"R1-Distill"前缀命名这些模型。Hugging Face 正确列出了它们。Ollama 删除了这一区分。结果是社交媒体上充满了人们声称在消费级硬件上运行"DeepSeek-R1"的帖子，随后是对其表现不佳原因的困惑，在这个过程中对 DeepSeek 造成了声誉伤害。

GitHub issues #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 所言："如果你的项目是靠开源来做交易的，你就没有权利在发布时对什么是开源、什么不是开源含糊其辞。"

Modelfile：重新发明已解决的问题

GGUF 是由 Georgi Gerganov 创建的模型格式，其设计遵循一个核心原则：单文件部署。GGUF 规范的第 1 点写道："完整信息：加载模型所需的所有信息都包含在模型文件中，用户无需提供任何额外信息。"聊天模板、停止令牌、模型元数据，一切都嵌入在文件中。你把 llama.cpp 指向一个 GGUF 文件，它就能工作。

Ollama 在此基础上添加了 Modelfile。它是一个独立的配置文件，自然地受 Dockerfile 启发，指定基本模型、聊天模板、系统提示、采样参数和停止令牌。大部分信息已经存在于 GGUF 文件内部。正如一位 Hacker News 评论者所言："我们刚刚摆脱了那种多文件混乱，结果 Ollama 又把它加了回来。"

这种方法的问题会快速复合。Ollama 只能自动检测来自硬编码列表中已知的聊天模板。如果一个 GGUF 文件在其元数据中嵌入了有效的 Jinja 聊天模板，但它与 Ollama 的任何已知模板都不匹配，Ollama 会回退到一个裸露的 {{ .Prompt }} 模板，无声地破坏模型的指令格式。用户必须手动从 GGUF 中提取聊天模板，将其翻译为 Go 模板语法（与 Jinja 不同），并将其写入 Modelfile。同时，llama.cpp 读取嵌入的模板并直接使用它。

修改参数更糟。如果你想改变从 Ollama 的注册表中拉取的模型上的温度或系统提示，工作流是：用 ollama show --modelfile 导出 Modelfile，编辑它，然后运行 ollama create 来构建一个新的模型条目。用户报告说这个过程为了改变一个参数而复制整个模型，30 到 60 GB。正如一个用户所描述的："'modelfile'工作流是个麻烦。这是一个很糟糕的模式，我讨厌它。其中一些模型有 30 到 60GB，为了改变一个参数而复制整个东西真是太愚蠢了。"

相比之下，在 llama.cpp 中，参数就是命令行标志。想使用不同的 temperature？传入 --temp 0.7。想换一个系统提示词？在 API 请求中传入即可。无需创建文件，无需复制数 GB 的数据，也无需学习专有格式。

Modelfile 还将用户锁定在 Ollama 的 Go 模板语法中，而模型创建者实际发布的是另一套语言——Jinja 模板。LM Studio 可以直接接受 Jinja 模板。llama.cpp 会从 GGUF 中读取模板。只有 Ollama 要求你在两种模板语言之间进行转换，而且它出错的频率高到 GitHub 上甚至出现了专门讨论 Ollama 模型库模板与上游 GGUF 元数据不匹配问题的完整 issue。

模型注册中心瓶颈

当一个新模型发布时，比如新的 Qwen、Gemma 或 DeepSeek 变体，社区成员（如 Unsloth 或 Bartowski）通常会在数小时内完成量化，并将 GGUF 上传至 Hugging Face。使用 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 进行尝试，结果模型无法正常工作、速度缓慢或聊天模板被搞砸，最后被责怪的却是模型，而不是运行时。最近一篇题为“If you want to test new models, use llama.cpp/transformers/vLLM/SGLang”的 PSA 帖子记录了 Qwen 模型在工具调用方面出现问题并生成垃圾回复的情况；由于 Ollama 内置的后端和有问题的模板处理，这些问题“只会在 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 后来增加了对 ollama run hf.co/{repo}:{quant} 的支持，其方式是即时生成一个 Docker 风格的 manifest，这在一定程度上缓解了模型可用性问题。但即便如此，文件仍然会被复制到 Ollama 使用哈希命名的 blob 存储中，你依然无法与其他工具共享该 GGUF，模板检测问题也仍然存在。其基础架构没有改变：Ollama 将自己插入你与模型之间，充当中间商，而这个中间商比它所封装的工具更慢、能力更弱、兼容性也更差。

2025 年末，Ollama 在其本地模型库之外引入了云托管模型。这个曾经与本地、私密推理画等号的工具，开始将提示词转发给第三方云服务商。MiniMax 等专有模型出现在模型列表中，却没有明确说明选择这些模型会把你的数据发送到本机之外。

用户对数据转发提出了担忧：当你通过“Ollama Cloud”运行 MiniMax-m2.7 这样的闭源模型时，你的提示词可能会被转发给实际托管该模型的外部服务商。Ollama 自己的文档称：“我们会处理你的提示词和响应以提供服务，但不会存储或记录这些内容”，却完全没有说明第三方服务商会如何处理这些数据。对于由 Alibaba Cloud 托管的模型，用户指出其并未提供零数据保留保证。

CVE-2025-51471 又进一步加剧了这一问题。这是一个影响所有 Ollama 版本的令牌窃取漏洞。恶意模型注册中心服务器可以在正常拉取模型的过程中，诱骗 Ollama 将身份验证令牌发送到攻击者控制的端点。修复方案已经以 PR 的形式存在，却花了数月时间才得以合入。对于一个以本地隐私建立品牌形象的工具来说，能够将凭据泄露给任意服务器的漏洞绝非小事，而是架构理念层面的问题。

审视其激励结构之后，这一切就更容易理解了。Ollama 是一家由 Y Combinator 支持的（W21）初创公司，创始人此前曾构建过一款 Docker GUI，后来被 Docker Inc. 收购。这套剧本并不陌生：为现有开源项目套上一层用户友好的界面，积累用户群，融资，然后再考虑如何变现。

其发展轨迹清晰地遵循了这一模式：

基于开源项目发布，构建于 llama.cpp 之上，赢得社区信任

弱化署名，让投资者觉得产品能够自给自足

制造锁定效应：专有的模型注册中心格式、其他工具无法使用的哈希文件名

推出闭源组件：GUI 应用

增加云服务：变现渠道

这个模型注册中心值得仔细审视。Ollama 使用哈希文件名，以自己的格式存储下载的模型。如果你已经通过 Ollama 拉取了几个月的模型，就无法在不做额外处理的情况下，直接让 llama.cpp 或 LM Studio 使用这些文件。你可以通过 Modelfile 将自己的 GGUF 导入 Ollama，但想把它们再取出来却被刻意设置了重重阻力。这是一种大多数用户在尝试离开之前都不会注意到的供应商锁定。

Ollama 所封装的工具都可以直接使用，而且配置起来并没有困难多少。

llama.cpp 才是真正的引擎。它提供与 OpenAI 兼容的 API 服务器（llama-server）、内置 Web UI、对上下文窗口和采样参数的完整控制，而且吞吐量始终优于 Ollama。2026 年 2 月，Gerganov 的 ggml.ai 加入 Hugging Face，以确保该项目的长期可持续发展。它真正由社区驱动，采用 MIT 许可证，拥有 450 多名贡献者，并且仍在积极开发中。

Mozilla 的 llamafile 将单文件理念更进一步：它把模型和运行时打包成一个可执行文件，无需安装即可在六种操作系统上运行。下载、双击，完成。

llama-swap 负责多模型编排，可以在单个 API 端点后按需加载、卸载和热切换模型。将它与 LiteLLM 搭配使用，你就能获得一个统一的 OpenAI 兼容代理，通过恰当的模型别名在多个后端之间进行路由。

如果你想要桌面 GUI，也有真正的开源选择。Jan（AGPLv3）是一款本地优先的聊天应用，拥有简洁的界面和完整的源代码。koboldcpp（AGPL）是 llama.cpp 的一个分支，内置 Web UI 并提供丰富的配置能力，完全开放、完全可审计。两者都是真正的自由开源软件项目，而不是在开源引擎之外隐藏专有代码的封装器。

此外还有闭源封装器。LM Studio 是构建于 llama.cpp 之上的专有软件，它能成为最受欢迎的 Ollama 替代方案是有充分理由的：它提供同样的一键式便利体验，拥有完善的 GUI，接受任意 GGUF，并开放所有可调参数。至关重要的是，LM Studio 的开发者一直以善意对待整个生态系统。他们维护了正规的致谢页面，明确标注 llama.cpp 及其许可证，也从未试图掩盖底层使用的技术。它是一款闭源产品，但并不寄生。Msty 是另一个构建在开源推理技术之上的闭源 GUI，支持多模型并内置 RAG。

我并不反对有人通过提高自由开源软件的易用性来开展商业活动。这是合理的。但我们有必要诚实地看待这些工具的本质：它们是因 llama.cpp 而存在的商业产品，而不是 Ollama 的开源替代品。善意封装器与恶意封装器之间的区别，不在于它们是否收费或是否发布专有代码，而在于它们是否尊重自己所依赖的工作。LM Studio 做到了。Ollama 没有。

Red Hat 的 ramalama 也值得一看。这是一款容器原生的模型运行器，在最显眼的位置明确标注了对上游依赖项目的致谢。这正是 Ollama 从一开始就应该做的事情。

这些工具的安装配置都不需要超过几分钟。认为 Ollama 是唯一易用选择的说法，早已不再成立。

2023 年 3 月，Georgi Gerganov 在一个晚上匆忙写出了 llama.cpp，由此掀起了一场本地 AI 革命。他和数百名贡献者组成的社区多年来一直努力让越来越强大的模型能够在消费级硬件上运行。这项工作确实非常重要，它是保持本地推理开放且易于使用的基石。

Ollama 将这项工作包装成了一个漂亮的 CLI，基于此融了 VC 资金，花了一年多时间拒绝给予应有的信用，进行了不当的 fork，发布了闭源应用作为补充，然后将整个项目转向云服务。在每个可能成为优秀开源公民的决策点上，他们选择了能让自己在投资者面前看起来更自给自足的路线。

本地 LLM 生态不需要 Ollama。它需要 llama.cpp。其他的都是包装，而更好的包装方案已经存在了。