top of page
Search

Local LLMs on Apple Silicon: Ollama vs. LM Studio vs. MLX

Writer: MacSmithAI
MacSmithAI
Aug 31
6 min read

The interesting thing about running local models on a Mac in 2026 is that the three-way choice mostly collapsed. For a couple of years the question was framed as Ollama versus LM Studio versus MLX, as if they were three competing engines. They are not anymore. Apple's MLX is the engine, and the others are increasingly wrappers around it.


Ollama shipped MLX support in a 0.19 preview on March 30, 2026 and has been iterating on it hard ever since. LM Studio has had an MLX engine for a while. So the real question for a Mac admin is not which framework is fastest — it is which wrapper you want between your users and Apple's runtime, and what that choice costs you in support and exposure.


What MLX actually is

MLX is an array framework for machine learning on Apple silicon, from Apple's machine learning research team, under an MIT license. It is not an app. It is closer to NumPy or PyTorch than to anything with a window.


The design point that matters is the unified memory model. In MLX, arrays live in shared memory, and operations can run on CPU or GPU without transferring data between them. On a discrete-GPU machine you copy tensors across a bus; on an M-series Mac you do not, because there is no bus to cross. That is the entire reason a MacBook Pro with enough RAM is a credible inference box despite having nothing that resembles an H100.


If you want to use MLX directly, pip install mlx-lm gets you the language-model layer. From there mlx_lm.generate --prompt "How tall is Mt Everest?" runs a one-shot generation, mlx_lm.chat gives you an interactive session, and mlx_lm.convert --model mistralai/Mistral-7B-Instruct-v0.3 -q pulls a model from Hugging Face and quantizes it. Also MIT-licensed. Worth knowing MLX is not strictly Apple-only anymore either — it supports CUDA on Linux and CPU-only installs — but Apple silicon is what it was built for.


Ollama

Ollama is the one your developers already have. MIT-licensed, a single CLI, a REST API on port 11434, and an OpenAI-compatible surface at http://localhost:11434/v1 so anything written against the OpenAI SDK points at it with a base-URL change.


The MLX work is recent and significant. The 0.19 preview claimed roughly 1.6× faster prefill and close to double the decode speed on Apple silicon, with the largest gains on M5-series chips thanks to their GPU Neural Accelerators. The catch at launch was scope: Ollama recommended a Mac with more than 32GB of unified memory, and model support started with Qwen3.5 alone, with more promised. That has broadened since — the June 11 update brought NVFP4 quantization with roughly 20% faster output than q4_K_M, and MLX builds surface as their own model tags rather than replacing the GGUF ones. Releases have been landing monthly.


That cadence is the thing to plan around. Ollama is moving fast enough that "which version is on the fleet" is a real question, and the answer changes what your users experience.


LM Studio

LM Studio is the GUI. That sounds dismissive; it is not. For anyone on your team who is not going to live in a terminal, a model browser, a chat window, and a toggle to start a server is the difference between using local inference and not.


It runs an MLX engine on Apple silicon and exposes an OpenAI-compatible server at http://localhost:1234/v1 covering /v1/models, /v1/chat/completions, /v1/completions, /v1/embeddings, and /v1/responses. There is a CLI, lms, with lms server start, and a documented headless service mode so it can run without the GUI in front of it.


The licensing detail matters more than anything technical here. As of July 8, 2025, LM Studio is free for use at work — no commercial license, no form, no contacting them. Before that, deploying it across a company was a procurement conversation. Now it is not. They sell an Enterprise plan on top for SSO, model gating, and access controls, which is the version you would actually want if you are handing this to a few hundred people.


Side-by-side

| | Ollama | LM Studio | MLX-LM | |---|---|---|---| | What it is | CLI + local REST daemon | Desktop GUI + CLI + server | Python package | | Apple silicon engine | MLX (since 0.19 preview, Mar 2026) plus GGUF/llama.cpp | MLX engine | MLX, directly | | Local API | localhost:11434, OpenAI-compatible at /v1 | localhost:1234/v1, OpenAI-compatible | Not documented as a server in the project README | | Runs headless | Yes, it is a daemon by design | Yes, documented service mode | It is a library — you build it | | Free for commercial use | Yes (MIT) | Yes since July 2025; Enterprise plan for SSO and access controls | Yes (MIT) | | Auth on the API | None, by design | Server is local by default | N/A | | Best for | Developers and scripted/agent workflows | Non-terminal users; anyone who wants a model browser | Fine-tuning, quantization, embedding inference into your own tooling |


The memory math is the whole decision

Everything above is secondary to how much unified memory the machine has, because on Apple silicon RAM is VRAM.


The planning rule that holds up well is roughly 0.6 GB per billion parameters at Q4_K_M quantization, plus headroom for context and the OS. Which gives you tiers: 16GB is the realistic floor in 2026 and gets you an 8B model at Q4; 24GB handles 14B; 36–48GB is the sweet spot for 20–30B models; 64–96GB is where 70B at Q4–Q5 becomes practical. An 8GB Mac can technically run a 3B model and that is about it.


There is one tuning knob worth knowing. macOS does not hand the GPU all of installed memory — on one tested 32GB M2 Max, Metal's recommended maximum working set came out to about 78% of installed RAM. You can raise it:


sudo sysctl iogpu.wired_limit_mb=28000

It resets to 0 at every boot, which is a safety feature rather than an annoyance. Be conservative with it: wired memory is the one thing macOS cannot page out, compress, or reclaim, so taking too much from the kernel and WindowServer buys you a stalled machine and lost work rather than a faster model. Raise it in small steps until the model loads, and stop there.


What this means when you manage the fleet, not the laptop

Two things change when this stops being one engineer's experiment.


The first is exposure, and it is not hypothetical. LeakIX found 12,269 Ollama instances reachable from the internet as of February 23, 2026. Ollama ships with no authentication and its maintainers have said they do not plan to add any — which is a defensible choice for a localhost daemon and a terrible one the moment someone binds it to all interfaces to reach it from another machine. On an exposed instance, /api/tags enumerates every model with sizes, /api/generate and /api/chat let anyone run inference on your hardware, and /api/pull and /api/push can move model weights in and out. Roughly a thousand of those instances were still running versions vulnerable to CVE-2024-37032 — "Probllama" — an unauthenticated path-traversal RCE that lands as root.


Port 11434 belongs on your egress and firewall policy. Not eventually.


The second is the reason to care at all: local-only inference is the version of AI adoption that does not require a data-handling conversation. Nothing leaves the machine. For a regulated org, or for anyone whose legal team is still working through vendor terms, "the model runs on the laptop" resolves a category of question that no amount of enterprise contract language fully closes. That is a real argument for putting effort into supporting this properly rather than tolerating it as shadow IT — which is what it becomes if you do nothing, because both of these are a free download away and nobody needs your approval to click it.


The practical takeaway

Standardize on two, not three. Deploy LM Studio as the sanctioned option for general users — it is free for commercial use, it has a GUI people will actually open, and the Enterprise tier gives you SSO and model gating when you need to control which models land on managed hardware. Let Ollama be the developer path, because it is already there and because agent tooling expects an OpenAI-compatible endpoint on 11434. Treat MLX-LM as a specialist tool for whoever is doing quantization or fine-tuning, not as something you deploy.


Then do the two boring things that matter more than the choice: set a memory floor for anyone you expect to use this seriously — 16GB is the minimum, 36–48GB if it is part of their actual job — and put port 11434 in your firewall policy today. The framework debate is close to settled, and it settled on MLX. The failure modes that will actually cost you are an underspecced Mac and an unauthenticated daemon on a network you assumed was internal.



Comments

bottom of page