For people running local LLMs, 64GB of unified memory has long been a blind spot: too small for a 70B model with real context, more than a 30B needs. A Reddit user who has spent ten days running a Qwen3.8 27B model quantized to 16GB in LM Studio on a 64GB Apple M4 Max tells a different story. With agentic coding sessions and context between 100k and 200k tokens, the engine process reaches 48GB, 46GB of it in GPU memory. At 164k tokens, the system has about 150MB free.

The memory breakdown is the most interesting part. Weights take 16GB. The KV cache takes about 11GB, roughly 64KB per token, because only 16 of the 64 layers use full attention. Then there is what looks like a second copy of the context for the prompt cache, linear attention checkpoints, and scratch memory that MLX holds after prefill. In practice, context costs almost as much as the model. That is the real break with the old reasoning: the 64GB 'dead zone' was calculated on weights, not on the operational cost of an agent.

The number that explains why the setup is usable is the prompt cache at 93%. Each turn processes about 1,000 new tokens instead of 160,000. When the cache misses, a full prefill takes about 20 minutes. That is not a technical detail: it is the line between a machine that responds and one that seems frozen. It changes the hardware evaluation criteria: bandwidth or weight capacity alone are not enough; cache and context must be included.

The author also explains the MLX constraint. LM Studio refuses KV cache quantization on the MLX vision path for this model. The text-only path allows it, but skips cache checkpoints when the cache is quantized, and on a hybrid model that means more full reprocessing. On 48GB, the setup does not fit unless you drop to around 128k context or move to llama.cpp with q8 KV, which should be about 25-30GB at 256k but with slower prefill. On 64GB it fits with no margin.

There is a structural shift here: 27B models are now good enough for real work, and agents move the bottleneck from weight size to context management. Anyone with a 64GB Mac finds themselves in an unexpectedly favorable position for long, local sessions, while 48GB users have to accept tradeoffs. Larger MoE models or two models loaded together still want 128GB, but that requirement no longer tells the whole story.

For those evaluating on-premise deployment, the case shows that tradeoffs need to be measured on real agentic workloads, not just inference benchmarks. AI-RADAR covers these evaluations in the analytical frameworks of the /llm-onpremise section. The author's open question remains: has anyone found acceptable prefill speeds on llama.cpp for Mac with long contexts?