Il sito usa solo cookie tecnici necessari al funzionamento: nessun tracciamento, nessuna profilazione. Cookie Policy

Salta al contenuto
Tutti i termini

Cos'è un LLM locale?

Un modello linguistico che gira su hardware che controlli tu, senza inviare i dati a un'API esterna.

Un LLM locale è un modello linguistico i cui pesi vengono scaricati ed eseguiti su hardware sotto il tuo controllo, un laptop, un server aziendale o una macchina in un data center privato, invece che interrogati come servizio tramite l'API di un fornitore. La differenza non è cosmetica: significa che il prompt e la risposta non lasciano mai la rete su cui giri, che il comportamento del modello resta fisso finché non decidi tu di aggiornarlo, e che il costo diventa quello dell'hardware invece che una tariffa per token. Richiede pesi aperti pubblicati dal produttore, che oggi coprono famiglie come Llama, Mistral, Qwen e Gemma, e uno strumento di esecuzione locale come Ollama, LM Studio o llama.cpp che carica quei pesi in memoria e gestisce l'inferenza. La domanda che decide se ha senso non è ideologica ma aritmetica: quanta memoria serve davvero, e cosa succede quando non basta.

L'aritmetica della memoria che nessuna guida spiega bene

I pesi del modello sono solo la prima voce di spesa in memoria. Un modello denso da 27 miliardi di parametri occupa circa 55 GB in BF16 (2 byte per parametro), scende intorno ai 27 GB con la quantizzazione a FP8 e a circa 14-17 GB a 4 bit, solo per i pesi. A questo si somma la KV cache, più i buffer di attivazione e l'overhead del driver GPU. Due dettagli cambiano il dimensionamento nei runtime desktop come Ollama e LM Studio: la KV cache viene riservata al caricamento per l'intera finestra di contesto dichiarata, non fatta crescere man mano, quindi il contesto va messo nel conto insieme ai pesi e non dopo; e se il totale non entra nella memoria della GPU il runtime non si rifiuta di partire, sposta parte dei layer nella RAM di sistema (un motore server come vLLM, al contrario, si ferma con un errore di memoria). La somma reale supera sempre il numero pubblicizzato per i soli pesi, e questo è il calcolo che chi pianifica l'hardware salta più spesso.

La soglia di usabilità: risponde non è uguale a funziona

Sotto una certa memoria il modello carica e genera token, ma smette di essere utile per compiti reali. La soglia non si misura in parametri, si misura con due domande, e la prima cambia peso a seconda dell'uso: la velocità di generazione sta sopra quella di lettura, soglia giusta per una chat e irrilevante per un flusso agentico, dove nessuno legge e conta solo il tempo dei dieci o venti passaggi in fila? E il contesto che il compito richiede entra in memoria insieme ai pesi? Su una scheda da 24 GB un modello da 27 miliardi di parametri a 4 bit tiene un ritmo comodo per una chat. Portato con una quantizzazione più aggressiva su una macchina da 16 GB, lo stesso modello continua a rispondere, ma con parte dei layer nella RAM di sistema, quindi a un passo che rende impraticabile qualunque lavoro agentico.

Un esempio enterprise

Uno studio legale che processa contratti riservati non può inviarli a un'API cloud per policy interna o per obbligo contrattuale col cliente. Un LLM locale da 27 miliardi di parametri, quantizzato a 4-8 bit su un server con 64 GB di memoria GPU o unificata, estrae clausole e genera bozze di sintesi restando interamente dentro il perimetro di rete dello studio: nessun documento transita su un'API terza, e la stessa versione dei pesi resta a disposizione mesi dopo, con la possibilità di ricostruire con quale modello e quale configurazione una risposta è stata prodotta, cosa che un endpoint gestito da un fornitore esterno non garantisce quando il modello dietro l'API cambia senza preavviso.

Perché conta per chi decide

Il vantaggio più sottovalutato è che i pesi sono un file statico e versionabile: non garantisce un output identico bit per bit, perché quello dipende dal campionamento e dal backend, ma garantisce di poter ricostruire mesi dopo con quale modello e quale configurazione una risposta è stata prodotta. È la proprietà che un modello di terze parti dietro un'API non offre, e in un audit è quella che conta. Gli altri vantaggi pesano meno: residenza del dato per settori regolamentati, costo prevedibile (prevedibile, non necessariamente più basso) e nessun lock-in su un fornitore. Il break-even economico resta una questione di volume e non appartiene a questa voce. La scelta della taglia del modello e il confronto fra motori di inferenza sono decisioni successive, non parte di questa.

Domande frequenti

Più della sola dimensione dei pesi. A un modello da 27 miliardi di parametri a 4 bit (circa 14-17 GB) vanno sommate KV cache, buffer di attivazione e overhead del driver: una macchina da 16 GB carica il modello e risponde, ma resta senza margine per il contesto lungo che un compito agentico consuma, mentre su 64 GB di memoria GPU o unificata pesi e contesto convivono senza che nulla debba essere spostato nella RAM di sistema.

No. Conviene quando il volume di richieste è alto abbastanza da ammortizzare l'hardware, o quando residenza del dato e riproducibilità pesano più del costo per token. Su volumi bassi l'API resta più economica perché l'investimento fisso non si ripaga.
  • SLM · Modello linguistico piccolo e specializzato: costa una frazione di un LLM, gira anche on-premise e per compiti mirati basta e avanza.
  • Open weights (pesi aperti) · Un modello di cui puoi scaricare i parametri ed eseguirlo dove vuoi, il che non lo rende open source né senza vincoli d'uso.
  • Ollama · Il runtime open source che scarica ed esegue modelli linguistici sul proprio computer, con un'API REST locale.
  • MLX · Il framework open source di Apple per il machine learning sui chip M, costruito sulla memoria unificata.
  • IA sovrana (Sovereign AI) · Sistemi di IA sviluppati e operati sotto controllo giurisdizionale locale: dove girano i modelli, chi li controlla, con quali dati sono addestrati.

Un termine che ti riguarda da vicino? Parliamone.

CONTATTAMI