Per dimensionare un LLM locale devi sommare memoria dei pesi, stato del contesto e memoria di lavoro del runtime. Il file del modello è solo il punto di partenza. Lunghezza delle richieste e numero di utenti simultanei possono cambiare molto il risultato.
Tenere il calcolo sulla GPU può migliorare le prestazioni, ma non è una regola secondo cui ogni altra configurazione sia inutilizzabile. CPU, memoria unificata e offload hanno compromessi diversi. La scelta si misura sul compito che vuoi eseguire.
Primo conto: i pesi
Una stima elementare è parametri × bit per parametro ÷ 8. Un modello da 8 miliardi di parametri a 4 bit richiederebbe circa 4 GB decimali per i soli valori dei pesi. Il file reale può essere più grande per scale, metadati e tensori conservati a precisione diversa.
Per un modello MoE, i parametri attivati per token influenzano il lavoro di calcolo, ma non fanno sparire gli altri esperti dalla memoria o dallo storage. La scheda Qwen3-30B-A3B, per esempio, distingue esplicitamente parametri totali e attivati. Non userei il solo numero attivo per stimare la dimensione dei pesi.
Secondo conto: la KV cache
Nei transformer autoregressivi con attenzione, la cache di chiavi e valori evita di ricalcolare parte delle informazioni dei token precedenti. La documentazione delle strategie di cache descrive implementazioni con caratteristiche diverse, incluse quantizzazione e offload.
Per un’attenzione standard, una stima semplificata della KV cache è:
2 × layer × token × teste_KV × dimensione_testa × byte_per_valore × sequenzeIl fattore 2 rappresenta chiavi e valori. È un modello di calcolo: non include tutti i buffer e non si applica senza adattamenti a ogni architettura, per esempio modelli ibridi con stati ricorrenti o finestre di attenzione diverse.
Esempio ipotetico: 32 layer, 8 teste KV, dimensione 128, 8.192 token, valori da 2 byte e una sequenza. Il conto dà 1.073.741.824 byte, cioè 1 GiB. Due sequenze con lo stesso fabbisogno raddoppiano quella componente prima di eventuali condivisioni o ottimizzazioni del runtime.
Terzo conto: runtime e margine
Alla somma aggiungi buffer temporanei, attivazioni, cache di esecuzione e memoria occupata da altri processi. Alcuni sistemi riservano memoria al massimo contesto configurato, altri la gestiscono in blocchi o in modo dinamico. Controlla i log di avvio e la memoria durante le richieste, non soltanto a riposo.
Nel registro di una prova interna del 4 settembre 2026, l’aumento del contesto su un server quasi al limite della VRAM ha prodotto avvii riusciti e avvii falliti per memoria insufficiente. La configurazione è stata ritirata. Il fatto che un avvio funzioni non basta a definire una configurazione stabile.
Offload: bisogna sapere che cosa viene spostato
“Offload CPU” può indicare scelte differenti: alcuni layer eseguiti sulla CPU, tensori collocati in RAM, cache trasferita o altre strategie. Il costo dipende da backend, banda di memoria, collegamento tra componenti e quantità di lavoro.
Non è corretto affermare che ogni runtime copi tutti i pesi dalla RAM alla GPU a ogni token. Serve osservare la configurazione reale. Una GPU poco utilizzata può essere in attesa della CPU, ma anche del caricamento dei dati o di altre parti della pipeline.
Nel nostro benchmark CPU documentato del 5 settembre, un Qwen MoE ha generato oltre 30 token al secondo sul sistema provato. Il dato non rende superflua la GPU: mostra che architettura e carico contano più di una regola assoluta.
Memoria unificata: più capienza non equivale a più velocità
Con la memoria unificata, CPU e GPU possono accedere a un pool condiviso secondo le caratteristiche della piattaforma. La quantità fisica installata non coincide necessariamente con la quota che il runtime può usare: sistema operativo, limiti del driver e altre applicazioni hanno esigenze proprie.
Per confrontare due macchine distinguo capienza, banda e supporto software. Una macchina può contenere un modello più grande ma impiegare più tempo sul prompt. Un’altra può generare velocemente un modello piccolo senza avere spazio per il contesto richiesto. La scelta non si ricava dal numero di gigabyte da solo.
Il test minimo prima di comprare o cambiare configurazione
| Prova | Domanda a cui risponde |
|---|---|
| Prompt breve, una richiesta | Il runtime funziona e qual è la velocità di base? |
| Documento della lunghezza prevista | Quanto dura il prefill e quanta memoria serve? |
| Più richieste simultanee | Come cambiano latenza individuale e throughput totale? |
| Riavvii e carico prolungato | La configurazione conserva un margine operativo? |
llama-bench permette di separare elaborazione del prompt e generazione. Affiancherei comunque un test tramite il client utilizzato nel lavoro: chiamate agli strumenti e richieste ripetute possono dominare il tempo complessivo.
Il risultato utile è una configurazione che completa il compito con qualità e tempi accettabili, lasciando margine. Prima di spendere per più VRAM, voglio sapere quale componente limita il lavoro e quale modifica la migliorerà davvero.