Ollama 0.40 on Mac Tested: MLX Becomes Default Engine, Disk Usage Doubles

Ollama 0.40 made a quiet but far-reaching change on Apple Silicon: supported models now run on the MLX inference framework by default. At the same time, it silently keeps a backup copy of every model each time you load one — doubling your disk usage. Combined, these two changes amount to a bill that Mac local LLM enthusiasts need to seriously reckon with.

MLX Becomes the Default: The Performance Equation on Apple Chips

MLX is Apple's open-source machine learning framework built for Apple Silicon. Compared to the llama.cpp backend that Ollama previously used by default, it can take fuller advantage of the unified memory architecture and Metal GPU. For M-series chip users, this typically means better generation speed and memory efficiency for the same model.

The change in Ollama 0.40 isn't about offering MLX as an option — it's about switching supported models to run directly on MLX. What users feel is this: after upgrading, without any configuration, models just run differently than before. This is a silent migration, not a new feature toggle.

For developers already running local models on Mac, this default deserves attention. It lowers the barrier to trying out MLX, but it also means your inference behavior, VRAM usage curves, and even output quality may differ subtly from the old version — and need re-validation.

llama.cpp is an open-source LLM inference engine written in C/C++, originally known for efficiently running GGUF-format quantized models on consumer hardware (especially CPUs). Its strengths are cross-platform support, minimal dependencies, and a mature community model-conversion toolchain, which is why it was long Ollama's default backend on Mac. But llama.cpp is relatively conservative in how it calls on Apple Silicon's unified memory and Metal GPU — more "it works" than "squeeze every drop."

Unified Memory Architecture is a core feature of Apple Silicon: the CPU, GPU, and neural engine share the same physical memory, so data doesn't need to be copied back and forth between CPU memory and VRAM. In theory, this lets LLM inference avoid the traditional PC dilemma of "VRAM runs out, so it falls back to CPU" — but it also requires the inference framework to be specifically optimized for this shared layout. MLX was designed by Apple precisely for this, while llama.cpp's general-purpose architecture is at an inherent disadvantage here.

Disk Usage Doubles: The Cost of Backup Copies

Even easier to overlook than MLX is the disk behavior. When loading a model, Ollama 0.40 keeps a backup copy of every model. The original model file is still there, the backup is there too, and disk usage simply doubles.

For a 7B-class quantized model, the extra overhead could be several GB; if you've stashed a dozen or so models locally, the extra space adds up fast. The problem is this behavior isn't obvious — there's no popup telling you "copying a backup now," so users often only notice when disk space runs critically low.

Ollama's official documentation describes this mechanism as a safety design, but the cost genuinely falls on the user's disk. For Mac users short on storage, this is a bill that must be calculated clearly before upgrading.

Quantized models refer to the technique of compressing model size by reducing weight numerical precision (e.g., from FP16 down to 4-bit or 5-bit). Taking a 7B-parameter model as an example, it needs roughly 14GB under FP16, but can be compressed to around 4GB with 4-bit quantization. The "several GB of extra overhead" mentioned in the article is estimated based on the post-quantization size — backing up a 4GB model takes up an additional 4GB. This also explains why disk pressure accumulates rapidly once you have many models: each one gets multiplied by two.

How to Clean Up: Reclaiming Occupied Space

Since the copies are generated by Ollama itself, cleaning them up also needs to be done the Ollama way. The most direct approach is to use ollama list to view your local model inventory, then ollama rm <model-name> to delete models you no longer need — deletion typically removes both the original file and the backup together.

If you just want to confirm what's actually eating your disk, you can inspect the file structure in Ollama's model directory (usually under ~/.ollama/models on macOS) and compare the size difference before and after the upgrade. For models you're certain you'll keep using, it's not advisable to manually delete the backup, as that could interfere with Ollama's loading logic.

A pragmatic strategy: upgrade first, observe disk changes, clear out unused models, then evaluate whether this "disk tax" is worth it.

Is This Upgrade Worth It

From a functional standpoint, Ollama 0.40's direction is clear: make MLX — which delivers a better experience on Apple Silicon — the default, reducing configuration burden for users. For Mac users chasing local inference performance, this is a positive step.

But the disk-doubling side effect is also real, especially for users who treat Ollama as a daily tool with a dozen or so weights sitting in their model library. The performance gains from upgrading come at the cost of some storage space.

The criterion is actually simple: if you mainly run one or two frequently used models and still have disk headroom, there's no hesitation about upgrading; if you have many local models and use a small-capacity MacBook, it's best to do a cleanup round before upgrading — or simply wait for a later version to see if the official team makes the backup behavior optional.

Either way, Ollama 0.40 reminds us of one thing: when it comes to local LLMs, performance optimization and resource consumption are often two sides of the same coin. MLX makes inference faster, backups make disks fuller — and every Mac user has to do this math themselves.

One-line Summary

Ollama 0.40 switches to MLX inference by default on Mac and keeps model backups, boosting performance while doubling disk usage.

Paragraph Summary

Ollama 0.40 makes two inconspicuous changes for Apple Silicon users: first, it switches supported models to Apple's in-house MLX inference framework by default, leveraging unified memory and Metal GPU without manual configuration for better generation speed and memory efficiency; second, it silently keeps a backup copy each time a model is loaded, directly doubling disk usage. The former is a performance bonus, the latter a hidden cost. The article suggests users re-validate inference behavior after upgrading, clean up unused models with ollama list and ollama rm, and decide whether to upgrade immediately based on their local model count and disk headroom.