The choice between 64GB and 128GB of unified memory for running language models locally comes down to one blunt question: which model size has to fit in RAM. On Apple Silicon and other unified-memory machines, the model weights live in the same pool the GPU reads from, so memory capacity, not core count, decides whether a model loads at all. At 64GB you live comfortably in the 32B class. At 128GB the 70B tier and beyond opens up.

Quick Answer

64GB runs 32B coding models with room to spare and can even accommodate a 70B Q4 model at around 40GB. 128GB is what you want if you regularly run 70B-plus models, or stack a vision model, an LLM and text-to-speech at once. If a 32B model is your daily driver, 64GB is the smarter spend.

What Actually Fits at Each Tier

A quantised model's file size is roughly its memory footprint. A 4-bit 32B coding model lands around 18 to 20GB, which leaves a 64GB machine substantial headroom for context and other apps. A 70B model at Q4 needs roughly 40GB, so a 64GB machine technically handles it, though you are giving up most of that headroom to a single model.

128GB changes the conversation. With around 104 to 112GB usable for models after system overhead, you can load the largest open-weight releases available today, into the 120B-plus mixture-of-experts class, and still keep a big context window open. That is the real reason to pay for it: not faster tokens on a 32B model, but access to model sizes a 64GB machine simply cannot hold.

Bandwidth Decides Speed, Capacity Decides What Loads

It is worth separating two things people often conflate. Memory capacity decides whether a model fits. Memory bandwidth decides how fast it generates tokens once loaded. A high-end unified-memory chip pushing 600GB/s or so will generate noticeably faster than an entry chip near 150GB/s, because token generation is bound by how quickly the weights can be streamed.

So a 128GB part with high bandwidth gives you both: it holds larger models and reads them faster. But if you never load a model bigger than 32B, that extra capacity sits idle, and the bandwidth that matters for a 32B model is the same whether you bought 64GB or 128GB of the same chip class.

The 32B Workhorse Case

For most local coding and chat work, a 32B model is the practical ceiling on quality you actually need day to day. A 4-bit 32B coder runs at high-teens tokens per second on a strong chip with good accuracy, and fits 64GB with space for a generous context. This is why 64GB is the value pick for developers: it covers the model class most people run without paying for capacity they will rarely touch.

When 70B Headroom Earns Its Keep

The 70B tier matters if you do work where the larger model's reasoning genuinely shows: complex multi-step coding, long-document analysis, or workflows where you want to run several models at the same time. Stacking a vision model, a chat model and a speech model simultaneously eats memory fast, and that is exactly where 128GB prevents you from swapping to disk and crawling. If your workflow is a single model at a time and that model is 32B, you will not feel the difference.

Multimodal Stacks and the Case for 128GB

Developers working with multimodal pipelines in 2026 are more likely to hit 128GB as a genuine floor rather than a luxury. Keeping a vision-language model resident alongside a code completion model means two sets of weights sit in memory at once. Add a local embedding model for retrieval-augmented workflows and the total climbs fast. Community data from early 2026 showed combined memory footprints of 40 to 50GB for setups running a coding assistant, a separate vision model and an embedding service simultaneously. On 64GB that leaves almost no room for your editor and browser. On 128GB the same stack is comfortable.

If your AI work is single-model and that model is a coding specialist, multimodal stacking is irrelevant. If you want a single machine to handle vision, text and retrieval tasks without swapping models in and out, 128GB is the tier that makes it practical.

What This Means for a Local AI Build

Buy memory at purchase time, because unified memory is soldered and cannot be upgraded later. Base the decision on the biggest model you will realistically run over the next two to three years. If that is 32B, 64GB is right and frees budget for faster storage or a better display. If you know you will work in the 70B-plus world or run multimodal stacks, pay for 128GB once. Machines suited to on-device inference sit in the AI PCs range at Evetech, and if you want to compare full configurations the top-selling PCs at Evetech show which builds developers are actively buying.

Frequently Asked Questions

Can 64GB run a 70B local model?

Yes, just. A 70B model at 4-bit quantisation needs around 40GB, so it loads on a 64GB machine, but it uses most of your headroom and leaves little for a large context window. For comfortable 70B work, 128GB is the safer choice.

Is 128GB worth it if I only run 32B models?

No. A 32B model fits 64GB with ease, and the token-generation speed on a 32B model is governed by the chip's bandwidth, not by whether you have 64 or 128GB. The extra capacity would sit unused.

Why can't I upgrade unified memory later?

Unified memory is soldered to the package so the CPU and GPU can share a single high-speed pool. There are no slots to add modules, so you must choose your capacity when you buy the machine.

What's the largest model 128GB can run?

With roughly 104 to 112GB usable, 128GB can load the largest open-weight models available today, into the 120B-plus mixture-of-experts class, at 4-bit quantisation while keeping context open.

Does more memory make tokens generate faster?

Not on its own. Capacity decides which models fit; bandwidth decides generation speed. Two configs of the same chip class run a 32B model at the same speed whether they have 64 or 128GB.

Sizing a machine for local AI? Compare unified-memory configurations in the AI PCs range at Evetech and pick the memory tier that matches the largest model you will actually run.