Last week, the top post on r/LocalLLaMA — 1,175 upvotes, 345 comments — was titled "Stop using Ollama." Not "consider alternatives." Not "Ollama has limitations." Just: stop.

That's a strong statement. But the replies weren't angry. They were relieved. Like a whole community had been thinking the same thing for months and finally someone said it out loud.

Here's what's actually going on, and what it means if you're running models locally.

What Ollama got right

Before we get into the problems, credit where it's due. Ollama did something nobody else managed: it made running a local LLM feel like installing a brew package.

ollama pull llama3
ollama run llama3

Two commands. No CUDA headaches, no quantization math, no "which GGUF variant do I actually need?" It just worked. For a lot of people, Ollama was their first experience running an LLM on their own hardware, and that matters.

The project also built a curated model registry. You didn't have to navigate Hugging Face's overwhelming model zoo. Pick a name, pull it, chat. Simple.

That simplicity was the whole point. And for a while, it was enough.

The attribution controversy

The first crack showed up when someone noticed Ollama hadn't credited llama.cpp in its MIT license for over 400 days. That's not a minor nitpick. The MIT license has exactly one major requirement: include the copyright notice. Ollama didn't.

Co-founder Michael Chiang eventually added a single line to the README: "llama.cpp project founded by Georgi Gerganov." But the damage to community trust was done. Ollama had built its entire product on top of llama.cpp's inference engine, marketed itself as a friendly face of local LLMs, and for a long time didn't acknowledge the upstream project that made it possible.

This matters less for the license technically (MIT is permissive) and more for the vibe. The local LLM community runs on open source goodwill. When the most popular tool seems to be distancing itself from its roots, people notice.

The lock-in problem

This is the one that actually bites.

When you run ollama pull llama3, the model gets stored in ~/.ollama/models in a proprietary hashed blob format. That GGUF file — the thing you actually downloaded — becomes inaccessible to other tools. You can't point llama.cpp at it. You can't move it into LM Studio. You can't easily back it up or share it.

If you want to use the same model in a different tool, you download it again. From Hugging Face or wherever. That's not a feature, that's friction disguised as convenience.

Compare that to llama.cpp, where you download a GGUF file, put it wherever you want, and point any compatible tool at it. The file is yours. It sits on your disk in a format every local LLM tool understands. No vendor lock-in, no re-downloading, no proprietary storage.

For a project that markets itself on local-first, privacy-respecting AI, having a proprietary model storage layer is a strange choice.

Performance: slower than you think

This one surprised me. The default Ollama setup runs with conservative settings — low context length, limited parallel slots. For casual chatting, you won't notice. But if you're trying to do real work — running a model as a backend for coding tools, serving multiple requests, or just wanting the fastest inference your hardware can handle — Ollama leaves performance on the table.

Users consistently report that llama.cpp runs the same models faster, with lower memory usage. On AMD GPUs specifically, llama.cpp's ROCm support outperforms Ollama's implementation. And the gap widens when you tune parameters like --ctx-size and --parallel — settings that Ollama abstracts away (which is sometimes a feature and sometimes a problem).

A blog post that made the rounds on HN put it bluntly: "The local LLM ecosystem doesn't need Ollama." The argument wasn't that Ollama is bad. It's that llama.cpp has matured enough that the simplicity gap has closed, while the performance gap hasn't.

llama.cpp isn't what you remember

Here's the thing — if you tried llama.cpp a year ago and bounced off it, you should try again. The project has shipped a lot of quality-of-life improvements.

brew install llama.cpp
llama-server -hf ggml-org/gemma-4-E4B-it-GGUF --port 8000

That's it. One command installs it, one command pulls a model from Hugging Face and starts a server with a built-in web UI. OpenAI-compatible API on port 8000. Same vibe as Ollama, same two-command simplicity, but without the proprietary storage or performance overhead.

What else is new:

• Built-in GUI — llama-server ships with a web chat interface. No separate frontend needed.
• --hf flag — pull models directly from Hugging Face by name. No more hunting for the right GGUF download link.
• Router mode — hot-swap between models without restarting the server.
• MCP support — Model Context Protocol integration for agent workflows.
• Speculative decoding — MTP support for Qwen 3.6 dense models gets roughly 2x single-user speedup.

The learning curve is still slightly steeper than Ollama (you need to understand a few CLI flags), but the gap is nothing like it used to be. And the payoff is real: you get full control over your inference setup with no abstraction layer getting in the way.

The alternatives landscape

The r/LocalLLaMA community isn't just saying "switch to llama.cpp." The conversation has fractured into distinct camps based on what people actually need.

For desktop users who want a GUI: LM Studio is the frontrunner. Polished interface, built-in Hugging Face model search, OpenAI-compatible local API. It uses llama.cpp under the hood but wraps it in something that feels like a proper desktop app. The trade-off: it's closed-source on the core.

For privacy-first chat: Jan AI. Fully open-source (MIT), cross-platform, no telemetry. Clean enough for non-technical users, open enough for developers to trust.

For production serving: vLLM. This is the multi-GPU, high-throughput, continuous-batching option. If you're serving models to actual users and need tensor parallelism across multiple GPUs, vLLM is what you reach for. Not a desktop tool — an inference engine built for load.

For portable distribution: llamafile. Single executable, bundles the model, runs anywhere. Mozilla-backed. Great for demos or distributing AI tools to people who don't want to install anything.

For RAG and document chat: AnythingLLM. First-class support for multiple vector databases, workspace-based document management, built-in RAG pipelines.

For teams: Open WebUI. ChatGPT-like web interface, multi-user with admin controls, runs on Docker. Pairs with any OpenAI-compatible backend.

The point isn't that one tool replaces Ollama for everyone. It's that the ecosystem now has purpose-built tools for every use case, and most of them are more open and more performant than Ollama for their specific niche.

What the Ollama team is doing

To be fair, Ollama hasn't stood still. Version 0.24 shipped recently with Codex App support, a reworked MLX sampler for Apple Silicon, and a cached /api/show endpoint. The ollama launch integration surface is expanding, and there's active work on desktop-app integrations.

But the updates feel reactive rather than directional. The project is adding features to keep up, not pushing the ecosystem forward in the way llama.cpp's recent improvements have. And the proprietary storage format — the biggest community complaint — hasn't changed.

The real takeaway

The "stop using Ollama" movement isn't about Ollama being bad. It's about the local LLM community growing up.

When you're just getting started, ollama pull and ollama run are genuinely great. They lower the barrier to entry in a way nothing else has. But once you've been running local models for a while — once you care about performance tuning, model portability, GPU optimization, or building something on top of inference — Ollama's abstractions start to feel like walls instead of guardrails.

The ecosystem has matured. llama.cpp is easier to use than ever and faster than Ollama. LM Studio gives you a GUI without lock-in. vLLM handles production loads. And the community is vocal about wanting open, transparent tooling.

If Ollama is working for you and you don't need more, keep using it. But if you've been feeling like something's off — like the models are a little slower than they should be, like you're stuck in a walled garden, like the tool is making decisions for you that you'd rather make yourself — you're not imagining it. There are better options now, and the community is moving toward them.

The local LLM world got serious. About time.