Per chi fa girare LLM in locale, 64 GB di memoria unificata sono stati a lungo un punto cieco: troppo pochi per un modello da 70 miliardi di parametri con contesto reale, troppi per un 30B. Un utente su Reddit che da dieci giorni usa un Apple M4 Max da 64 GB con un Qwen3.8 27B quantizzato a 16 GB in LM Studio sta raccontando una storia diversa. Con sessioni di coding agentico e un contesto che viaggia tra 100k e 200k token, il processo del motore arriva a occupare 48 GB, di cui 46 nella memoria GPU. A 164k token, il sistema ha circa 150 MB liberi.

La composizione della memoria è la parte più interessante. I pesi occupano 16 GB. La cache KV ne prende circa 11, circa 64 KB per token, perché solo 16 dei 64 layer usano attenzione completa. Poi c'è quella che sembra una seconda copia del contesto per la prompt cache, i checkpoint dell'attenzione lineare e la memoria di scratch che MLX trattiene dopo il prefill. In pratica, il contesto costa quasi quanto il modello. Questa è la vera rottura con il vecchio ragionamento: la 'zona morta' dei 64 GB era calcolata sui pesi, non sul costo operativo di un agente.

Il dato che spiega perché il setup sia utilizzabile è la prompt cache al 93%. A ogni turno vengono processati circa 1.000 nuovi token invece di 160.000. Quando la cache manca, il prefill completo richiede circa 20 minuti. Non è un dettaglio tecnico: è il confine tra una macchina che risponde e una che sembra bloccata. Questo cambia il criterio di valutazione dell'hardware: non basta guardare la larghezza di banda o la capacità dei pesi, bisogna includere cache e contesto.

L'autore spiega anche il vincolo del percorso MLX. LM Studio rifiuta la quantization della KV cache sul percorso visione di MLX per questo modello; il percorso solo testo la consente, ma salta i checkpoint della cache quando la cache è quantizzata, e su un modello ibrido significa più rielaborazione completa. Su 48 GB, quindi, il setup non entra a meno di scendere a circa 128k di contesto o passare a llama.cpp con KV q8, che dovrebbe stare sui 25-30 GB a 256k ma con prefill più lento. Su 64 GB entra senza margine.

Qui sta il cambio strutturale: i modelli da 27B ora sono sufficienti per lavoro reale, e gli agenti spostano il collo di bottiglia dalla dimensione dei pesi alla gestione del contesto. Chi ha un Mac da 64 GB si ritrova in una posizione inaspettatamente favorevole per sessioni lunghe e locali, mentre chi ha 48 GB deve accettare compromessi. I modelli MoE più grandi o due modelli caricati insieme continuano a volere 128 GB, ma quel bisogno non racconta più l'intera storia.

Per chi valuta deployment on-premise, il caso mostra che i trade-off vanno misurati su carichi agentici reali, non su benchmark di sola inference. AI-RADAR dedica a queste valutazioni i framework analitici della sezione /llm-onpremise. Resta aperta la domanda dell'autore: qualcuno ha trovato su llama.cpp per Mac velocità di prefill accettabili per contesti lunghi?