Buying a Mac just a couple of years ago was fairly straightforward. You looked at how many apps you kept open, considered whether you edited photos or video, winced at Apple’s upgrade prices and bought as much RAM as your budget allowed.
But then AI crash-landed on our lives, and agents running on local models started invading our Mac, which made that decision considerably more complicated. And on top of that, RAMageddon happened.
After testing local AI on the M6 Mac mini and M5 Max Mac Studio, I have a bit more clarity on where the useful memory breakpoints are, and I thought I’d share that in this article.
For most people serious about experimenting with local AI on a Mac, I’d start with at least 32GB. I’d move to 64GB if running 70B-class models matters, and I’d only consider 128GB or more if 100B+ models or heavy generative workloads are genuinely part of your work.
How does unified memory work for local AI?
Apple Silicon uses unified memory rather than giving the CPU its own system RAM and the GPU a separate pool of VRAM. Both can access the same memory, which is especially useful for local AI because large models can consume tens of gigabytes before you account for context, caches, the operating system and whatever else the workflow needs.
This is the biggest reason a Mac with a lot of unified memory is much more interesting for AI, even when a discrete Nvidia GPU is substantially faster on workloads that fit within its VRAM. An RTX 5090, for example, has 32GB of VRAM. Our 128GB Mac Studio could load GPT-OSS 120B locally, whereas the 32GB RTX 5090 system I had previously tested could not fit the model entirely into VRAM.
But the important word is unified, not free. macOS still needs memory, your applications need memory, and AI workloads can allocate considerably more than the model file itself. That’s why you don’t want to choose a Mac solely on the download size of the model you want to run.
Is 16GB enough for local AI on a Mac?
I wouldn’t recommend it. While there are plenty of small quantised models that can run within 16GB, a 16GB Mac is more useful if most of your AI work happens through cloud services such as ChatGPT.
The problem isn’t that you won’t be able to run a model locally. It’s that you start close to the ceiling, leaving less room to try larger models, longer contexts or other applications alongside them. Think of 16GB as enough to learn the tools and run smaller local models, not as a configuration to build an AI workstation around.
24GB is better than 16, but…
Our Qwen3 30B-A3B testing shows why 24GB is a meaningful step up. Running the model at 4-bit quantisation with a 2K prompt peaked at 18.11GB of memory while generating at 131.4 tokens per second on the M5 Max Mac Studio.
That means a workload in this class can fit within 24GB, but there isn’t much headroom once macOS and everything else on the machine are accounted for. More importantly, increasing the prompt size to 64K pushed our measured peak memory usage to 24.26GB.
So 24GB is a good example of the difference between “can run” and “would recommend”. It’s a useful entry point for local AI and gives you considerably more freedom than 16GB, but I wouldn’t choose it for regular 30B-class work with large contexts.
32GB is the sweet spot for local AI experimentation
This is the configuration I’d start with for most people who genuinely want to experiment with local AI rather than occasionally launch a small model.
Our Qwen3 30B-A3B results stayed below 25GB even with a 64K prompt, leaving a 32GB Mac some breathing room for macOS and supporting applications. It also gives you more flexibility to test different quantisations and workloads without immediately reaching for swap.
There is another lesson in those results. Memory use increased from 18.11GB at 2K context to 24.26GB at 64K, but prompt-processing performance fell from 5,451.9 to 1,560.4 tokens per second. Having enough RAM doesn’t mean a huge context window is free; it simply means memory isn’t the first limitation you hit.
48GB is the entry point for some 70B-class models
The next meaningful jump in our testing came with Llama 3.3 70B at 4-bit quantisation. That workload peaked at 41.2GB of memory.
That immediately rules out 32GB if the goal is to keep the workload within physical unified memory. A 48GB Mac has enough capacity on paper, but again, the model isn’t the only thing using RAM. I would view 48GB as the point at which this class of model becomes possible rather than the configuration I’d choose for it without reservation.
If you expect 70B-class models to run regularly, 64GB is the more comfortable target. It leaves materially more room for macOS, context and supporting tools, and gives you space to experiment rather than tuning everything around a hard memory ceiling.
64GB makes good sense if large models are part of the plan
This is where I’d move from “AI enthusiast” to someone deliberately buying a Mac for larger local models.
Our 41.2GB Llama 70B result leaves useful headroom, while smaller 30B-class models leave plenty of memory for larger contexts, agents and other applications. You also have more room for workflows in which several components run at once, rather than a single benchmark process in isolation.
What 64GB doesn’t guarantee is that every 100B+ model becomes practical. GPT-OSS 120B, for example, was roughly 65GB in size in our testing. Even before allowing for macOS and runtime overhead, that is already beyond what I’d consider a sensible 64GB workload.
Who actually needs 128GB for local AI?
Our M5 Max Mac Studio is where I could stop thinking about whether the large language model would fit and start looking for other limits.
GPT-OSS 120B ran locally through Ollama at around 75 tokens per second, and I was able to connect it to OpenClaw, give the agent a 64K context window and analyse documents while the Mac was completely disconnected from the internet. That is the clearest argument for 128GB if 100B+ models are genuinely part of your work.
But the workload that used the most memory wasn’t the 120B language model. It was local generative video.
Using LTX-2.3 22B through MLX, I generated a 241-frame, 1024×768 image-to-video sequence with synchronised audio. During the main generation stage, total system memory was around 57GB. When the pipeline moved to VAE video decoding, Python climbed to 102.3GB and total memory usage reached 115.16GB, with macOS allocating 7.59GB of swap.
That’s a useful reminder that parameter count doesn’t tell the whole memory story. A 22B video model ultimately used far more system memory in our workflow than the 30B language model because the later decoding stage had to materialise 241 finished frames.
I pushed that test further with a 2x spatial upscale. Memory usage reached 125.75GB and swap climbed to 31.58GB, but the resulting video was unusable. I’m not counting that as a benchmark result, and I can’t say whether the failure was caused by memory pressure or the software pipeline itself. It does, however, show how quickly a heavy generative workflow can consume memory outside the model.
What about 256GB or 512GB?
There are obvious use cases for more than 128GB: substantially larger models, running multiple large models at once, research workloads, fine-tuning and generative pipelines with much larger memory requirements. But those are specialised scenarios, and I’d rather revisit this tier when I have measurements to support the advice.
Which Mac memory configuration should you buy for local AI?
The useful breakpoints from our testing are surprisingly clear. I wouldn’t choose memory based on the largest model you can technically squeeze into it. I’d leave enough headroom for macOS, context, agents and the rest of the workload.
| Unified memory | Who it’s for | My recommendation |
|---|---|---|
| 16GB | Cloud AI, learning the tools | Not what I’d buy specifically for local AI |
| 24GB | Small models and lighter 30B-class experimentation | A useful entry point, but limited headroom for larger contexts |
| 32GB | Most local-AI enthusiasts | The starting point I’d recommend for serious experimentation |
| 48GB | Users starting to explore 70B-class models | Enough for our 41.2GB Llama 70B test, but not much spare room |
| 64GB | Regular large-model users | The more comfortable choice for 70B-class models |
| 128GB | 100B+ models, agents and heavy generative workloads | Worth it when large local AI is genuinely part of the workload |
| 256GB+ | Specialised research and exceptionally large workloads | Beyond what we’ve independently tested so far |
I believe 32GB is the most sensible starting point if local AI is one of the reasons you’re buying a new Mac. It accommodates the 30B-class workload we tested with enough room to be useful, not merely functional.
64GB is the tier I’d choose for regular large-model work. Our 70B test makes the case clearly: 41.2GB is already beyond a 32GB machine’s physical memory, while 64GB leaves considerably healthier headroom.
128GB only becomes easy to justify when you can name the workload that needs it. GPT-OSS 120B is one. Our local video pipeline is another. If neither sounds remotely like something you’ll run, spending the money elsewhere is probably the better decision.
Buy memory for the workload, not the AI label
The biggest lesson from these tests is that there isn’t one memory requirement for “AI.” A 30B language model with a large context, a 70B dense model, a 120B model running inside an agent and a 22B video model all stress memory in different ways.
That’s why I’d resist buying the maximum memory configuration simply because AI is somewhere on your list of interests — especially considering the current price of memory. Start with the models and workloads you actually want to run, add sensible headroom, and choose the Mac from there.
For most enthusiasts, that points to 32GB. For genuinely large local models, 64GB is a much more useful target. And once you reach 128GB, the question changes from “will this model fit?” to whether your software and the rest of the pipeline can make useful use of all that memory.
If you’re choosing between Apple’s desktops and memory configurations, our Mac mini vs Mac Studio guide covers the broader performance, ports and pricing differences.
