I run local models every day on a Mac Studio with 64GB of unified memory. In mid-2026 that makes it the awkward middle machine of local AI. It is comfortable in one narrow band of models, locked out of the band above it, and there is an empty shelf in between because no lab ships into it. The local-AI content mill covers the 512GB flex builds and the entry-level laptop question. The content mill skips the 64GB tier, the one a lot of people bought. This is the guide I wanted when I bought mine.
Two numbers explain the whole tier: memory capacity and memory bandwidth. Neither leads the spec sheet.
Capacity decides what fits, bandwidth decides how it feels
Memory capacity decides what you can load. A model's weights sit in unified memory next to macOS, your apps, and the conversation's own scratch space. At 4-bit quantization a parameter costs about half a byte, so a 35B model wants roughly 18GB before you type a word.
Memory bandwidth decides how fast the loaded model produces tokens. Decode is a memory-bound loop: to produce one token, the chip reads the active weights out of memory, does a small amount of math, and repeats. Tokens per second is, to a first approximation, bandwidth divided by the bytes each token touches.
Mixture-of-experts models exploit the gap between those two numbers, which is why they fit this hardware tier best. Take Qwen3.6-35B-A3B, the class I use most. The name states it: 35 billion parameters total, about 3 billion active per token. Capacity pays for all 35B, roughly 18GB at 4-bit. Bandwidth only pays for the 3B that fire on each token, under 2GB of reads instead of 18. The result is a model that occupies memory like a 35B but streams at roughly the speed of a 3B. A dense 27B such as Qwen3.6-27B reads its full weights for every token, which is slower in the stream, and the token rate drops accordingly.
The comfortable class, the locked-out class, and the empty middle
The comfortable class on 64GB is the 27B to 35B band: Qwen3.6-27B dense, Qwen3.6-35B-A3B, the Gemma 4 31B class. At 4-bit-flavored quants these load with room left for a usable context window and a machine you can still work on.
The locked-out class is the open-weights frontier. GLM-5.2 (the current open-weights leader) is a 744B-parameter MoE. Unsloth's documentation puts it at about 239GB even in their 2-bit dynamic GGUF, down from 1.51TB at full precision, which means a 256GB-minimum machine. One X post claims a 1-bit GGUF of GLM-5.2 running at about 21 tokens per second on an M3 Ultra Mac Studio with quality "competitive with Claude Opus and GPT-5.5." I read the speed as plausible and the quality claim as promotional until someone publishes evals. Either way, it requires an M3 Ultra. On 64GB there is no version of it.
Between those bands is a gap the community has started to name. A June thread on r/LocalLLaMA asking for an 80-160B model makes the case: the unified-memory installed base (bigger Macs, Ryzen AI 395 boxes, DGX Spark, 128GB DDR5 rigs) has lots of slow RAM and almost nothing new sized for it, because recent releases cluster at 27-35B for laptops and 400B-plus for clusters. The math is especially frustrating on my machine. An 80B MoE with a few billion active parameters would cost about 40GB at 4-bit, fit on 64GB with headroom, and be the best model this machine ever ran. No lab has shipped it.
MLX, llama.cpp, and the KV cache nobody budgets for
On the Mac, momentum is with MLX. The clearest signal this spring is that Ollama shipped an MLX backend in preview, claiming 57 percent faster prefill and 93 percent faster decode than its previous Apple Silicon path, gated to Macs with 32GB or more of unified memory. A roughly doubled decode rate on the same hardware is enough to make people switch engines. llama.cpp and GGUF are where extreme quantization happens. The 1-bit GLM-5.2 experiment and the quantization-aware Gemma checkpoints run on GGUF. I run both stacks without partisanship: MLX for the daily server, GGUF when I want a quant MLX does not offer.
The hidden line item is the KV cache. Weights are a one-time capacity cost. The KV cache grows with every token of context you hold. On a 64GB machine under a 35B-class model, the ceiling is closer than it looks, and public bug reports show it more clearly than benchmarks do. One report against an MLX serving server describes its admission guard modeling cache growth at about 80MB per token and rejecting ordinary requests with HTTP 500s; the memory-pressure log in that report reads 45.2GB resident against a 44.1GB soft ceiling. Another desktop tool's tracker documents models loaded through its mobile companion bypassing auto-eviction, leaving more models loaded than the machine was budgeted for. KV-cache quantization exists to shrink the cache, and TurboQuant is the current name to know, but it is new enough that I test it before I trust it.
None of this argues against local. It just means you have to budget time for memory management. On this tier, memory management is part of the job, and I plan for it the way I plan for disk space.
What I run day to day
My workhorse is Qwen-family, one big model resident at a time. 64GB cannot hold two, and the eviction bugs above show what happens when tools assume it can. Lower-risk work runs local: summarization, extraction, classification, first-pass code. I route it through Cerebellum, a local AI router I open-sourced, which sends lower-risk calls to the local model under policy controls and writes a decision trail I can review later. Hard problems and long agentic sessions escalate to cloud models. I default to local and reach for the cloud when the task earns it.
For expectations, the number I trust comes from Vicki Boykis. Her six-month verdict on a 2022 M2 machine with 64GB of RAM, relayed through a developer digest, is that local agentic coding with the Gemma 4 family reaches roughly 75 percent of frontier accuracy and speed, and that GPT-OSS was the point where she stopped double-checking local output against API models. If you plan against 75 percent of frontier quality, the machine pays off. A large share of daily AI work does not need the last quarter of quality, and on that work the 64GB Mac Studio gives you privacy, no per-token bill, and no dependency on a vendor's uptime.
That last property was tested this June, when export controls took the strongest cloud model offline worldwide for 18 days. My local stack kept running through it. I will not oversell that; a 35B MoE is no frontier model, and during those weeks I still wanted the cloud for the hard problems. But 75 percent of frontier quality that no outside party can switch off is worth more, day to day, than 100 percent that they can. On 64GB, that is what your money buys.