Buying a Mac for local models: Air, Pro or a Mac mini?
Every Apple-silicon Mac runs local models the same way, with the same tools. What the enclosure decides is how much memory you can buy, how fast tokens arrive, and what it costs. So this is really a question about two numbers, not four product lines.
The two numbers. Unified memory decides what fits: a model either loads or it does not, and on a Mac the whole machine's memory is available to the model, which is the quiet superpower of the platform. Memory bandwidth decides how fast the words come out once it does. The same chip gives roughly the same result whether it sits in a laptop or a small silver box, which is why the chip pages in our hardware index are organised by chip, with the machines that ship it listed on each page.
MacBook Air is the machine you may already own, and it is a fine way to find out whether you care. Base chips run small models well. Two honest limits: the memory ceiling is low compared with the rest of the range, and there is no fan, so long generations slow down as the machine warms. Good for trying things; a stretch as a daily tool.
MacBook Pro is the laptop answer once local inference is part of your day. The Pro and Max chips carry several times the Air's memory bandwidth, the fan holds speed through long runs, and Max configurations reach memory sizes that hold genuinely capable models.
Mac mini is the most capability for the money, with one trick that changes the question: it does not have to be your main computer. A mini running Ollama serves a model to every other machine in the house — your laptop points its tools at the mini's address and stays cool and quiet. If you were pricing a bigger laptop purely for inference, a modest laptop plus a dedicated mini often beats it.
Mac Studio exists for one reason here: memory sizes into the hundreds of gigabytes, which is the territory of the largest open-weight models. If you cannot name the big model you intend to run, you do not need one yet.
How much memory, by what you'll actually do. The honest sizing question is not "how big a model fits" but "what job is it doing", because the jobs tolerate slowness very differently:
- Writing and chat — replacing a chat subscription for drafting, rewriting, thinking out loud — is the forgiving one. Text needs to arrive at reading speed, no faster, and mid-sized models are genuinely good at prose now. This works on the widest range of machines, including a base chip with modest memory.
- Coding in an editor — hooking a local model up to Cursor, Zed or a similar tool — is the demanding one, in a way that surprises people. It is not just the tokens coming out: an editor stuffs your files into every request, and reading that long prompt in is where Apple silicon is weakest relative to a discrete GPU. The wait before the first token grows with your codebase. Capable local coding models want the larger-memory Pro and Max configurations, and even then expect a pause a hosted service wouldn't have.
- Agentic workflows — chains of steps, tool calls, long contexts — compound both problems: every step re-reads a growing context, small models drop instructions that big ones follow, and each pause multiplies across the chain. This is the use case that justifies the expensive end of the range, and the one where being honest with yourself about "will I really run this locally?" saves the most money.
Two sizing notes that apply everywhere: the model's file size is not the whole cost — the working memory for a long context sits on top of it — and macOS itself needs room, so a model that "fits" into all of your memory does not actually fit.
How to choose in practice. Pick the models you want to run first, then let the fit verdicts pick the memory: check any machine against the catalogue, or open a chip's page in the hardware index to see what it holds at the standard quantization and roughly how fast it goes.
Where next: Check what a machine runs · Run your first model on it