Come funziona un LLM in locale

Guida: Intelligenza Artificiale Locale › Concetti tecnici

Per scegliere un LLM locale bisogna distinguere parametri e quantizzazione, memoria dei pesi, cache KV della finestra di contesto e prestazioni del runtime. Un modello che entra in VRAM con un contesto breve potrebbe non farlo con documenti lunghi o più richieste contemporanee. Questa guida introduce le grandezze da verificare prima dell’acquisto e rimanda ai requisiti hardware.

Come funziona davvero un modello (e perché ti serve saperlo)

L’obiettivo non è memorizzare sigle, ma fare tre verifiche: il modello e la sua quantizzazione sono supportati? Quanto spazio occupano pesi e cache di contesto nella configurazione prevista? Che velocità si ottiene sul lavoro reale, misurando tempo al primo token e token al secondo? Le risposte variano con runtime, driver, lunghezza dei prompt e parallelismo; non esiste un’unica soglia VRAM valida per tutti.

Il modello è un predittore della parola successiva

Alla base, un modello linguistico fa una cosa sola, e la fa benissimo: data una sequenza di testo, predice quale pezzo di testo viene dopo. Tutto ciò che sembra intelligenza — ragionare, scrivere, rispondere — emerge da questa capacità ripetuta milioni di volte su una quantità immensa di testo durante l’addestramento. Il modello non “capisce” nel senso umano: ha imparato, da una mole sterminata di esempi, regolarità statistiche così profonde da produrre risposte coerenti, pertinenti e spesso sorprendenti. Tenere a mente questa natura aiuta a usarlo bene: è uno strumento di completamento estremamente sofisticato, non un oracolo onnisciente.

Token e tokenizzazione: i mattoni del testo

Il modello non lavora su lettere o parole intere, ma su token, pezzetti di testo. Una parola comune può essere un token singolo; una rara può spezzarsi in più token. In italiano, mediamente, una parola vale circa un token e mezzo. La tokenizzazione è il processo che spezza il testo in token prima di darlo al modello, e li ricompone in testo all’uscita. Perché ti importa? Perché tutto si misura in token: la velocità (token al secondo), la memoria, i limiti. Quando senti “questo modello ha un contesto da 32.000 token”, pensa a circa venti-venticinquemila parole.

La finestra di contesto: la memoria di lavoro

Il contesto è la quantità di testo che il modello può “tenere davanti agli occhi” mentre lavora: la tua domanda, più la conversazione precedente, più eventuali documenti che gli hai dato. Si misura in token. Una finestra da 8.000 token tiene poche pagine; una da 128.000 tiene un libro intero; alcuni modelli del 2026 arrivano a milioni di token, abbastanza per interi archivi. Attenzione, però: il contesto non è gratis. Più contesto usi, più memoria serve, e — come vedremo — questo è uno dei modi più comuni in cui i principianti rendono lentissima una macchina veloce. Il contesto è memoria di lavoro temporanea: quando la conversazione finisce, sparisce. Il modello non ricorda nulla da una chat all’altra, ed è per questo che dargli conoscenza stabile richiede tecniche apposite (Parte V).

Due fasi della generazione: prefill e decode

Quando fai una domanda, il modello lavora in due fasi, ed è utile distinguerle perché si comportano in modo diverso. Nella fase di prefill (o “prompt processing”), il modello legge tutto l’input — la domanda e l’eventuale contesto — in un colpo solo. Questa fase è veloce e sfrutta la potenza di calcolo bruta: una buona scheda processa migliaia di token al secondo in prefill. Nella fase di decode (la generazione vera e propria), il modello produce la risposta un token alla volta, e ogni token dipende dai precedenti. Questa fase è più lenta ed è limitata dalla banda di memoria, non dalla potenza di calcolo. Ecco perché due numeri contano: il tempo al primo token (quanto aspetti prima che inizi a rispondere, dominato dal prefill) e i token al secondo (quanto velocemente scrive, dominato dal decode). Per un’esperienza fluida vuoi entrambi buoni, e capire questa distinzione ti aiuta a leggere i benchmark e a dimensionare l’hardware.

Temperatura e campionamento: la manopola della creatività

Il modello, a ogni passo, non sceglie semplicemente il token più probabile: sceglie tra i token probabili secondo dei parametri di campionamento che puoi regolare. La temperatura è il principale: bassa (vicina a zero) rende le risposte deterministiche, focalizzate, ripetibili — ideale per estrazione dati, codice, risposte fattuali; alta (verso uno o oltre) le rende più varie, creative, imprevedibili — utile per scrittura, brainstorming. Altri parametri come top_p e top_k limitano quanto “lontano” il modello può pescare tra le opzioni. Non devi diventare esperto subito, ma sapere che queste manopole esistono ti permette di calibrare l’assistente: un chatbot di assistenza vuole temperatura bassa per essere preciso e coerente; un generatore di idee la vuole più alta. Sono impostazioni che si regolano nel software (Ollama, Open WebUI) senza toccare il modello.

I concetti che decidono tutto

Adesso il cuore tecnico. Padroneggia questi sette concetti e qualunque decisione d’acquisto o configurazione diventa ovvia. Ignorali e rischi di buttare migliaia di euro. Sono il vocabolario con cui è scritto tutto il resto della guida.

Parametri: la “taglia” del cervello

Un modello si misura in parametri, in miliardi (in inglese billion, da cui la “B”). Un “7B” ne ha sette miliardi, un “70B” settanta. I parametri sono, in soldoni, le connessioni interne apprese durante l’addestramento: più parametri, in linea di massima, più il modello è capace e sfumato, ma anche più pesante da far girare. Le taglie tipiche: minuscoli da 1-4 miliardi (girano quasi ovunque, perfino su un telefono potente), medi da 7-14 miliardi (il punto dolce per la maggior parte delle persone), grandi da 27-70 miliardi (serve buon hardware), colossali da centinaia di miliardi o oltre il migliaio (territorio da server o cloud). Ma — e lo vedremo tra poco con i MoE — il numero totale di parametri da solo non racconta più tutta la storia.

Quantizzazione: comprimere senza buttare via troppo

Qui c’è il trucco che rende possibile tutto. Un modello “nasce” con i parametri memorizzati ad alta precisione (16 bit ciascuno, formato FP16 o BF16). In quella forma un 7B occupa circa 14 gigabyte. La quantizzazione riduce la precisione di ogni parametro — tipicamente a 4 bit — facendo crollare il peso a circa un quarto, con una perdita di qualità sorprendentemente piccola, spesso impercettibile nell’uso reale.

La regola pratica che useremo in tutta la guida: un modello quantizzato a 4 bit occupa, in gigabyte, all’incirca un numero pari ai suoi miliardi di parametri. Un 7B in Q4 sta sui 4-5 GB, un 13B sui 8 GB, un 30B sui 18-20 GB, un 70B sui 40 GB. Memorizza questo: decide quale hardware ti serve.

Le sigle che incontrerai, spiegate. Il formato dominante per l’uso locale è il GGUF, il contenitore dei modelli quantizzati che Ollama e llama.cpp usano. Dentro il GGUF trovi le varianti di quantizzazione. Le più diffuse sono le K-quant: Q4_K_M è la regina (4 bit, “Medium”, il miglior equilibrio qualità-peso, la scelta predefinita sensata); Q5_K_M e Q6_K sono un po’ più pesanti e precise; Q8_0 è a 8 bit, quasi indistinguibile dall’originale ma il doppio del peso del Q4; le Q3 e Q2 comprimono di più ma la qualità inizia a degradare visibilmente, da usare solo quando non hai scelta. Esistono anche le IQ (quantizzazioni “imatrix”, che spremono ancora di più con tecniche raffinate) e, per modelli serviti via vLLM in produzione, formati come AWQ e GPTQ (quantizzazioni ottimizzate per GPU) e FP8 (8 bit in virgola mobile, supportato dalle GPU più recenti). Una nota utile: alcuni modelli vengono addestrati fin dall’inizio a bassa precisione (le varianti QAT, quantization-aware training) e a parità di bit rendono meglio delle quantizzazioni applicate dopo. Per cominciare: scegli Q4_K_M e non pensarci troppo; sali a Q5 o Q6 se ti avanza memoria e vuoi più qualità; sali a Q8 solo per compiti dove la precisione è critica.

VRAM, RAM e memoria unificata: dove vive il modello mentre lavora

Questo è il concetto che separa chi compra bene da chi compra male, quindi leggilo due volte.

Per generare risposte a velocità decente, il modello deve stare interamente nella memoria del processore grafico, la VRAM della GPU. La VRAM è velocissima e massicciamente parallela, esattamente ciò che serve. Se il modello entra tutto in VRAM, vola. Se non entra, “trabocca” nella RAM di sistema, e la velocità crolla di dieci o venti volte: da fluido a frustrante. Un esempio concreto e reale: un modello da 70 miliardi di parametri su una buona scheda, quando entra tutto in VRAM, gira sui 45 token al secondo; lo stesso modello, sulla stessa scheda, se è costretto a traboccare nella RAM, scende a uno o due token al secondo, più lento di quanto tu legga. Stessa macchina, stesso modello, prestazioni inservibili, solo perché non c’è abbastanza VRAM.

Quindi la domanda d’acquisto numero uno non è “quanti core ha la CPU”, ma quanta VRAM ha la GPU. Con 8 GB fai girare comodo un 7B in Q4. Con 16 GB arrivi a 13-14B con respiro. Con 24 GB tocchi i 30B. Con 48 GB i 70B quantizzati. Tutto parte da questo numero.

Esiste una terza via, recente e dirompente: le architetture a memoria unificata (i Mac Apple Silicon, i nuovi mini PC con AMD Ryzen AI Max, la classe “Spark” basata sul chip Grace Blackwell di NVIDIA). Qui CPU e GPU condividono un’unica grande pozza di memoria velocissima. Un mini PC con 128 GB di memoria unificata può “ospitare” modelli che nessuna scheda grafica consumer riuscirebbe a contenere, perché non sei limitato dai 24 o 48 GB di una GPU. È un cambio di paradigma che nel 2026 sta ridisegnando le scelte, e gli dedicheremo una sezione intera.

La banda di memoria: il vero collo di bottiglia (che quasi nessuno spiega)

Ecco il concetto che ti fa capire più di metà dei benchmark, e che i venditori non ti dicono. La velocità con cui un modello genera testo (la fase di decode) non dipende quasi per niente dalla potenza di calcolo della GPU: dipende dalla banda di memoria, cioè da quanti gigabyte al secondo la scheda riesce a leggere dalla sua VRAM. Il motivo è semplice: per produrre ogni singolo token, il modello deve leggere i suoi parametri dalla memoria, e questo è il passaggio che fa da imbuto.

C’è una formula approssimata ma potentissima per stimare il soffitto di velocità: token al secondo massimi ≈ banda di memoria (GB/s) ÷ peso del modello letto per token (GB). Un esempio reale: una scheda con 1.792 GB/s di banda, su un modello denso da 32 miliardi di parametri in Q4 (che pesa circa 19 GB), ha un soffitto di circa 94 token al secondo. Lo stesso conto su un modello MoE da 30 miliardi totali ma con soli 3 miliardi attivi (legge circa 2 GB per token) dà un soffitto vicino agli 896 token al secondo. Stessa scheda, dieci volte la velocità, solo perché legge molta meno memoria per token.

Le implicazioni pratiche sono enormi. Primo: quando confronti due GPU per la generazione, la banda di memoria conta più del numero di core di calcolo. Secondo: ecco perché i modelli MoE (prossimo punto) sono così veloci. Terzo: ecco perché le architetture a memoria unificata, che hanno banda più bassa di una GPU dedicata di pari fascia, sono più lente nella generazione pur potendo ospitare modelli più grandi — un compromesso tra “quanto grande” e “quanto veloce” che devi conoscere per scegliere bene. La potenza di calcolo bruta conta invece nella fase di prefill (leggere un contesto lungo, processare un prompt enorme di un RAG): lì le schede più potenti volano davvero.

Dense contro MoE: il trucco che ha cambiato le carte

Fino a poco fa i modelli erano tutti dense: ogni singolo token attivava tutti i parametri. Un 70B dense fa lavorare tutti e settanta i miliardi per ogni parola, ed è pesante e relativamente lento di conseguenza.

I modelli MoE (Mixture of Experts, miscela di esperti) hanno spaccato questo schema, e nel 2026 dominano. Un MoE ha tanti parametri totali ma ne attiva solo una frazione per ogni token, scegliendo di volta in volta quali “esperti” interni usare. Esempi reali e attuali: gpt-oss:20b ha 21 miliardi di parametri totali ma ne attiva solo 3,6 per token; un Qwen3 30B-A3B ha trenta miliardi totali e tre attivi. Il risultato, ricordando la formula della banda, è straordinario: hanno la conoscenza di un modello grande ma la velocità di uno piccolo. Su una buona scheda un MoE da trenta miliardi gira a oltre 200 token al secondo, restando leggero. Li riconosci dalle sigle tipo “30B-A3B” (trenta totali, tre attivi).

Questo è il motivo per cui oggi puoi avere qualità sorprendente su hardware modesto: i MoE ti danno il meglio dei due mondi. Quando scegli un modello, guarda sempre se è MoE e quanti parametri attiva, perché cambia radicalmente cosa puoi permetterti e quanto andrà veloce. C’è un’avvertenza: un MoE occupa in VRAM lo spazio dei suoi parametri totali (deve essere tutto caricato), ma legge per token solo quelli attivi (quindi è veloce). Quindi un MoE grande ti serve comunque tanta memoria per ospitarlo, ma poi vola.

Token al secondo: la misura della velocità percepita

La velocità si misura in token al secondo (tok/s). Mediamente una parola italiana vale circa un token e mezzo. Come orientarsi: sotto i 5 tok/s l’esperienza è penosa, ogni risposta è un’attesa; 5-10 tok/s è usabile ma percepisci la lentezza, accettabile per compiti in background o batch notturni; 15-30 tok/s è fluido e piacevole, lo standard a cui puntare per un assistente interattivo; oltre i 40 tok/s è istantaneo, più veloce di quanto tu legga. Per un chatbot sul sito o un assistente che usi tutto il giorno, punta a stare stabilmente sopra i 15 tok/s anche con il contesto pieno.

La cache KV e la trappola del contesto

Ultimo concetto, ed è quello che frega più principianti, quindi merita attenzione. Mentre il modello genera, deve tenere in memoria una struttura chiamata cache KV (key-value), che memorizza l’elaborazione di tutto il contesto fino a quel punto. Questa cache cresce con la lunghezza del contesto, e occupa VRAM in aggiunta al modello. Più lungo è il contesto che usi, più grande è la cache, più memoria serve.

Ecco la trappola. Un modello che entrerebbe comodamente nella tua GPU con un contesto corto può traboccare se lo usi con la sua finestra di contesto massima, perché la cache KV gonfia l’occupazione di memoria oltre il limite. Caso reale: un modello denso da 32 miliardi su una scheda da 24 GB sta dentro con un contesto da 8.000 token, ma se lo lasci al suo contesto predefinito da 128.000 token, la cache KV fa straripare tutto nella RAM e la velocità collassa a poche unità di token al secondo. Stesso modello, stessa scheda, da fluido a inservibile solo per via del contesto lasciato al massimo per inerzia. La regola d’oro che ne deriva: dimensiona il contesto a ciò che ti serve davvero. Se l’assistente risponde su domande brevi, non gli serve un contesto da centomila token. Imposta un contesto ragionevole (Ollama lo gestisce con il parametro num_ctx) e la tua macchina resterà veloce. Si può anche quantizzare la cache KV per ridurne il peso, una tecnica utile sui contesti lunghi.

← IntroduzioneHardware →