Running local AI models on a Mac Mini M4: the storage math

What running AI locally on a Mac means

Four names come up whenever this is discussed, and each solves a different part of the problem.

• Ollama: a command-line tool and background service that downloads models from its own library with one command and runs them behind a local API (github.com/ollama/ollama, checked September 2026).
• LM Studio: a desktop app to "download and run local LLMs", with a chat interface and a local server that can "serve local models on OpenAI-like endpoints" to other apps (lmstudio.ai/docs/app, checked September 2026).
• MLX: described by its own repository as "an array framework for machine learning on Apple silicon, brought to you by Apple machine learning research", built around a unified memory model: "Arrays in MLX live in shared memory. Operations on MLX arrays can be performed on any of the supported device types without transferring data" (github.com/ml-explore/mlx, checked September 2026). It is Apple's own project, not a third-party port.
• llama.cpp: describes itself as "LLM inference in C/C++", built "to enable LLM (and VLM) inference with minimal setup and state-of-the-art performance on a wide range of hardware", and states that "Apple silicon is a first-class citizen" through ARM NEON, Accelerate and Metal (github.com/ggml-org/llama.cpp, checked September 2026).

The four overlap more than the list suggests: Ollama lists llama.cpp among its supported backends (github.com/ollama/ollama, checked September 2026), and LM Studio runs "llama.cpp (GGUF) or MLX models" (lmstudio.ai/docs/app, checked September 2026). Pick a tool for how you want to work, and keep in mind that each one keeps its own copy of what it downloads, which is where storage comes in.

The two limits: memory decides what runs, storage decides how much you keep

A model's weights, plus the working memory for whatever it is currently processing, have to fit in the Mac Mini M4's unified memory alongside macOS and everything else open: 16GB standard, configurable to 24GB or 32GB (support.apple.com/en-us/121555, checked September 2026). That choice is final: Apple states that the memory in the Mac mini (2024) is integrated into the chip package and can't be upgraded (support.apple.com/en-us/102328, checked September 2026).

Storage is a softer limit that grows quietly over time. Running one model does not use much of it, but nothing about this workflow deletes anything either, and several things accumulate beside the models themselves:

• Model downloads: every model you pull is a full local copy, and downloading the same model at a second quantisation to compare it is a second full copy.
• The Hugging Face cache: tools that download models directly from Hugging Face, rather than through Ollama or LM Studio, keep their own cache at ~/.cache/huggingface/hub by default, moved with the HF_HOME environment variable (huggingface.co/docs/huggingface_hub/guides/manage-cache, checked September 2026). It is easy to end up with the same weights cached twice, once by an app and once by this cache.
• Speech-to-text and image-generation models: if you run transcription or image generation locally as well, those models keep their own files on disk, separate from the text-model caches above.
• Python environments: MLX has a Python API alongside its C++, C and Swift ones (github.com/ml-explore/mlx, checked September 2026), and the transformers and diffusers libraries are Python libraries. Every virtual environment has "their own independent set of Python packages" (docs.python.org/3/library/venv.html, checked September 2026), so each project installs its own copy of PyTorch, MLX or similar libraries.

None of this shows up until it already has. One model next to a 256GB or even a 2TB drive looks trivial; a working set of several models, a Hugging Face cache that duplicates some of them, and a Python environment or two does not.

What common models actually cost to download

Model size scales with parameter count, and every model in Ollama's library has a default download; for the models below that default is 4-bit quantisation, Q4_K_M, except gemma2:9b at Q4_0. The figures below are each model's parameter count and default download size, read from its own page on Ollama's library in September 2026.

Source: ollama.com/library, each model's own tag page, checked September 2026. Across this table the default download works out to 0.58 to 0.62GB per billion parameters, roughly 0.6GB, our own arithmetic from the figures above, and it is the basis for the memory caveats further down. Ollama's library also lists Llama 3.1 at 406B parameters, a 243GB download at the same Q4_K_M quantisation (ollama.com/library/llama3.1, checked September 2026). That file fits on a 512GB or 2TB drive, but not on a stock 256GB one, where the budget below leaves 206GB once macOS and the tools are installed. Storage is not what rules it out, though: no Mac Mini M4 has anywhere near the memory to run it.

Model cards change. Check the library page for the model you actually want before budgeting for it.

The storage budget: a model library plus everything around it

Put a handful of the models above on a Mac Mini M4, add the tools that run them, and the base 256GB configuration is tight before a serious library exists. This is our own planning estimate, not a measurement of one specific setup.

That is 200GB by our estimate, on top of whatever else the machine already stores. On the base 256GB configuration it leaves 56GB, and installing a macOS update needs free space of its own while it runs (support.apple.com/en-us/102624, checked September 2026); on 512GB it leaves 312GB; on the 2TB module, 1800GB. These are planning numbers, not a measurement of any specific setup, and a single 70B-class download, 43GB in the table above, is enough on its own to take most of what the 256GB configuration has left. As with any drive, the capacity macOS shows reads a little lower than the advertised figure, because formatting and the operating system use some of the space (support.apple.com/en-us/102119, checked September 2026).

Checking the real numbers on your machine

The table above is a planning estimate. Two commands show what a given machine is actually using.

du -sh ~/.ollama/models
du -sh ~/.cache/huggingface

The first reports Ollama's own downloads, stored at ~/.ollama/models by default (docs.ollama.com/faq, checked September 2026); the second reports the Hugging Face cache described above. Neither command covers LM Studio's models, which live in the models directory set from the app's My Models tab (lmstudio.ai/docs/app/basics/download-model, checked September 2026).

Why an external drive is awkward for model caches

Model caches can be moved off the internal drive, but the awkwardness is not the space, it is the drive itself.

• Relocating caches is per tool, not global: Ollama moves with the OLLAMA_MODELS environment variable (docs.ollama.com/faq, checked September 2026), the Hugging Face cache moves with HF_HOME (huggingface.co/docs/huggingface_hub/guides/manage-cache, checked September 2026), and LM Studio's models directory is changed from its My Models tab (lmstudio.ai/docs/app/basics/download-model, checked September 2026); there is no single setting that relocates all three.
• Sleep and cables: macOS can put disks to sleep through the "Put hard disks to sleep when possible" setting under Energy in System Settings (support.apple.com/guide/mac-help/mchle41a6ccd/mac, checked September 2026), and an external drive adds a cable and an enclosure that both have to stay connected. A drive that is unplugged or loses power takes every model on it along until it is back.
• Load time: our module's product page lists 4400MB/s write and 3000MB/s read (checked September 2026). An external drive connects through one of the M4's three Thunderbolt 4 ports, up to 40Gb/s, or the two front USB-C ports, USB 3 up to 10Gb/s (support.apple.com/en-us/121555, checked September 2026). 10Gb/s is 1250MB/s before any protocol overhead, less than half the module's listed read speed. 40Gb/s is Thunderbolt 4's total link rate; a drive's data travels over its PCIe connection, where Intel sets a minimum of 32Gb/s (intel.com/content/www/us/en/gaming/resources/upgrade-gaming-accessories-thunderbolt-4.html, checked September 2026), about 4000MB/s before overhead, still above that read speed on paper; the real speed depends on the enclosure, the cable and the drive inside, which you would have to buy and verify yourself. By our arithmetic, reading deepseek-r1:32b's 20GB takes about 7 seconds at 3000MB/s and at least 16 seconds at 1250MB/s. Either way that is load time only, never how fast the model answers once loaded.

None of this rules out an external drive for a cold archive of models you rarely load; it is the working set you switch between often where relocating caches and risking a mid-load disconnect cost more than the space is worth.

The honest caveats

• The 16GB base configuration runs roughly 7B to 14B parameter models at 4-bit: at about 0.6GB per billion parameters, a 7B model is about 4.4GB (mistral:7b) and a 14B model about 9GB (qwen2.5:14b, phi4:14b). A 9GB model leaves about 7GB of 16GB for its context window, macOS and every other open app, our own arithmetic, which is why 14B is the upper edge on 16GB; a larger model can still be made to load, it just leaves little room for context.
• 32GB reaches the 30B class; 24GB falls short. Both are configure-to-order options at purchase (support.apple.com/en-us/121555, checked September 2026). deepseek-r1:32b's 20GB download leaves about 12GB of a 32GB machine for context and macOS, more than a 14B model leaves on 16GB; on 24GB it leaves about 4GB, below that 7GB edge, again our own arithmetic. The GPU budget is tighter still: llama.cpp takes its GPU memory budget on a Mac from Metal's recommendedMaxWorkingSetSize, not from the installed total (github.com/ggml-org/llama.cpp, its Metal backend source, checked September 2026), and a llama.cpp log from a 24GB Mac Mini with an M2 chip reports 16384MiB for it (github.com/ggml-org/llama.cpp/issues/3911, checked September 2026), about 17.2GB by our conversion, less than the 20GB model. Raising the system wired memory limit with a sysctl is an advanced step that mlx-lm's documentation describes for a model that fits in memory but runs slowly (github.com/ml-explore/mlx-lm, checked September 2026); it does not change the 24GB total.
• A 70B model is a memory question this SSD cannot answer: llama3.1:70b's default download is 43GB, more than the Mac Mini M4's maximum of 32GB of unified memory before context or macOS are counted (support.apple.com/en-us/121555, checked September 2026). The Mac Mini M4 Pro is configurable to 64GB (same source), which would leave about 21GB beside those weights by our arithmetic, but it is a different machine, and one this module does not fit. No amount of storage changes this: it is a memory ceiling, fixed at the moment of purchase.
• The SSD changes load time, not token speed: once a model's weights are in memory, how fast it generates tokens depends on memory bandwidth, 120GB/s on the M4 (support.apple.com/en-us/121555, checked September 2026), and the chip's own compute, both fixed by the configuration you bought. What the SSD changes is only how long it takes to read those weights off disk when a model loads; a faster drive starts a model sooner, it does not make it think faster.

None of these caveats are reasons to avoid running models locally; they are the numbers to check against a specific model before assuming it fits.