Ollama被200万开发者捧上神坛，有人实测后选择连夜卸载

本地跑大模型的人里，每3个就有1个装过Ollama。这个数字来自项目官方统计，但没人告诉你的是：同一台机器上，有人把Ollama换成原生llama.cpp后，推理速度直接涨了40%。

这不是个例。nullmirror团队去年完整记录了迁移过程，他们测试了从7B到70B的多个模型，结果出奇一致——去掉Ollama这层"壳"，token生成速度全线提升。更扎心的是，很多用户根本不知道自己被默认设置坑了多久。

4K上下文：一个藏在默认值里的陷阱

Ollama的context window（上下文窗口）默认只有4096 tokens。这个数字什么概念？你贴一段中等长度的代码进去，可能就触顶了。

官方文档倒是写得明白：做网页搜索、Agent、编程工具这类任务，"至少要用64000 tokens"。但文档不会主动弹窗告诉你，你得自己去翻。更隐蔽的是动态调整机制——只有显存超过24GB的显卡，Ollama才会自动放宽限制。主流消费级显卡？老老实实守着4K上限。

Gemma 4已经支持128K甚至256K上下文，新架构的KV缓存优化让长文本不再吃显存。但Ollama的默认值还停留在几年前，像给跑车装了个自行车限速器。当你把它嵌在别的工具后面用时，这个瓶颈几乎无法察觉，除非你专门去测。

改num_ctx参数有三种方式：环境变量、命令行、API调用。对新手来说，每种都有门槛。Ollama的设计哲学是"一行命令跑起来"，但真要调优时，你会发现这行命令背后藏了一堆需要手动覆盖的假设。

那层"Docker式"的抽象，正在吃掉你的算力

Ollama常被比作"本地LLM界的Docker"。这个类比精准，因为创始人确实来自Docker背景。但Docker的隔离是有代价的——多一层抽象，就多一层开销。

llama.cpp是裸金属，Ollama是集装箱。集装箱方便搬运，但你要跑计算密集型任务时，直接焊在主板上的效率永远更高。nullmirror的实测数据摆在那里：同一硬件、同一模型、同一量化级别，裸跑就是更快。

差距有时候很小，有时候很明显。当你等模型输出等到烦躁时，那几秒的延迟会无限放大。更麻烦的是Ollama替你做的选择，很多改不了。它封装了编译参数、调度策略、内存分配——这些在llama.cpp里可以精细调节的选项，在Ollama里要么隐藏，要么锁定。

对想"开箱即用"的人来说，这是 feature。但对跑了一年本地模型的老用户，这成了 technical debt（技术债）。你迟早要还。

开源社区的裂痕：从"默认推荐"到"谨慎观望"

2023年，Ollama几乎是本地LLM的入门标配。YouTube教程、自建指南、开源项目README，三句话不离它。但2024年下半年开始，一些微妙的变化在发生。

llama.cpp原作者Georgi Gerganov从未公开批评过Ollama，但他在多次访谈中强调"直接调用原生API"的重要性。社区里的声音更直接：Hacker News上关于Ollama性能的讨论帖，高赞回复 increasingly 指向替代方案。

真正让人警觉的是项目方向。Ollama的更新日志里，企业功能占比在上升，开源协议的边界在模糊。它仍然开源，但"开放"的程度在收缩——某些新特性只出现在官方托管服务里，某些配置选项被标记为"实验性"后长期不文档化。

这不是指控，是观察。当你依赖一个工具作为基础设施时，它的治理模式和你的使用场景是否匹配，比功能列表更重要。

一位在GitHub上维护本地LLM编排工具的开发者告诉我：「我们开始把Ollama列为'兼容层'而非'推荐方案'，新用户先用着，但文档里会埋一条脚注，指向llama.cpp和vLLM的深度配置指南。」

替代方案：没有银弹，只有 trade-off

离开Ollama后，主流选择有三条路径。

llama.cpp是最直接的替代。你得自己编译，自己写启动脚本，自己管依赖。但回报是完整的控制权：CPU/GPU调度、批处理大小、缓存策略，全部可调。Gerganov的代码库更新极快，新模型支持通常比Ollama早几天到几周。

vLLM走另一条路。它瞄准的是高吞吐场景，用PagedAttention（分页注意力）技术把显存利用率榨干。适合已经跑通基础流程、想上强度的用户。部署复杂度比Ollama高两档，但单卡服务多并发的能力确实强。

还有一类人选择"半托管"——用Ollama做快速原型验证，生产环境切到原生方案。这种 hybrid 模式在中小团队里很常见，前提是有人愿意维护两套配置。

没有完美的选择。Ollama的易用性是真实的，它的性能损耗也是真实的。问题在于很多用户从未被告知这个 trade-off 的存在，他们以为"一行命令"和"最优性能"可以兼得。

那谁还应该用Ollama？

三类人：刚接触本地LLM、想30秒内看到模型跑起来的；硬件配置复杂、懒得折腾驱动和CUDA版本的；以及把大模型当"高级搜索引擎"用、对延迟不敏感的。

但如果你在本地跑Agent、做代码补全、或者试图用消费级显卡服务小团队——那个4096的默认上下文，那层抹不平的抽象开销，迟早会撞上来。

nullmirror团队在迁移报告的结尾写了一句挺有意思的话：「我们花了两周优化Ollama配置，最后发现直接删掉它，问题解决了90%。」