Installare un modello di intelligenza artificiale in locale è diventato molto più accessibile, ma scegliere bene resta difficile. Il nome commerciale o il numero di parametri non bastano: contano formato dei pesi, quantizzazione, memoria disponibile, lunghezza del contesto, concorrenza, runtime e qualità sul compito reale.
Questa guida non promette un elenco di “tutti i modelli”, perché checkpoint e fine-tune cambiano continuamente. Offre invece un metodo verificabile per passare dal caso d’uso all’hardware, con esempi ricavati dalle schede ufficiali dei produttori.
Open source, open weight e licenza: non sono sinonimi
Un modello scaricabile può pubblicare i pesi senza rendere aperti tutti i dati e il processo di addestramento. Prima di portarlo in azienda occorre leggere la licenza del checkpoint preciso, non quella attribuita genericamente alla famiglia: uso commerciale, redistribuzione, fine-tuning e obblighi possono cambiare tra una versione e l’altra.
Cinque esempi verificati che mostrano quanto sia diverso il mercato
| Modello | Dati confermati dalla fonte ufficiale | Cosa insegna per il dimensionamento |
|---|---|---|
| Phi-4-mini-instruct | Microsoft indica 3,8 miliardi di parametri, architettura dense e contesto fino a 128K token. | Una classe compatta può essere interessante per estrazione, classificazione e assistenti leggeri, ma il contesto massimo non è automaticamente quello da usare in produzione. |
| Gemma 3 | Google documenta taglie 1B, 4B, 12B e 27B; 4B, 12B e 27B accettano anche immagini e arrivano a 128K token di input. | La stessa famiglia può coprire dispositivi molto diversi: bisogna scegliere taglia e modalità, non soltanto il nome “Gemma”. |
| Qwen3.5-9B | La model card ufficiale Qwen identifica un modello 9B multimodale e licenza Apache 2.0, utilizzabile tramite Transformers, vLLM e SGLang. | Il formato originale della model card e una quantizzazione consumer non sono la stessa cosa: memoria e prestazioni vanno misurate sul file realmente distribuito. |
| Ministral 3 8B Instruct | Mistral AI lo presenta come modello Instruct della famiglia 8B con capacità visive; la scheda principale è distribuita in FP8. | “8B” descrive la classe del modello, non garantisce che ogni checkpoint o runtime entri nella stessa quantità di RAM o VRAM. |
| gpt-oss-20b e gpt-oss-120b | La documentazione OpenAI riporta 21B parametri totali e 3,6B attivi per 20b; 117B totali e 5,1B attivi per 120b. Entrambi hanno contesto 131.072 token; OpenAI indica che 120b entra in una singola GPU H100. | Nei Mixture-of-Experts i parametri attivi spiegano parte del costo di calcolo, ma i pesi complessivi restano determinanti per la memoria. |
Dense e Mixture-of-Experts: perché il numero “B” può ingannare
In un modello dense quasi tutti i parametri partecipano alla generazione di ogni token. In un Mixture-of-Experts, o MoE, viene attivata soltanto una parte degli esperti per ogni passaggio. Questo può ridurre il calcolo, ma non trasforma un modello enorme in un modello da PC: i pesi totali devono comunque essere disponibili in memoria o gestiti con offload, con conseguenze sulla latenza.
La memoria dei pesi è soltanto il punto di partenza
Come stima iniziale, i soli pesi richiedono circa 2 byte per parametro in FP16/BF16, circa 1 byte in 8 bit e poco più di mezzo byte per parametro nelle comuni quantizzazioni a 4 bit. Non è però il consumo finale. Bisogna aggiungere runtime, buffer, sistema operativo, encoder visivo, cache KV e margine operativo.
La quantizzazione riduce memoria e spesso rende possibile l’esecuzione su hardware più piccolo, ma può modificare qualità e velocità. Il progetto llama.cpp documenta quantizzazioni da 1,5 a 8 bit proprio per ridurre uso di memoria e accelerare l’inferenza. Per un confronto serio va fissato il formato preciso, per esempio un determinato GGUF Q4 o Q5.
Il contesto lungo costa memoria
Una finestra dichiarata da 128K non significa che sia opportuno usarla sempre. La cache del contesto cresce con numero di token, batch e richieste parallele. La documentazione di Ollama chiarisce che la RAM richiesta scala con richieste parallele e lunghezza del contesto; se la memoria non basta, i modelli vengono scaricati o le richieste accodate.
Per una PMI è spesso meglio partire con 8K, 16K o 32K realmente necessari, misurare memoria e latenza e aumentare solo quando i documenti o il workflow lo richiedono.
Configurazioni prudenti da cui iniziare
| Hardware disponibile | Primo test ragionevole | Attenzione principale |
|---|---|---|
| 16 GB RAM, CPU senza GPU dedicata | Modelli 3B–4B quantizzati; poi 8B–9B se memoria e latenza restano accettabili. | Lasciare margine al sistema operativo e non usare subito contesti enormi. |
| 32 GB RAM, CPU o GPU integrata | 8B–14B quantizzati e confronto con modelli compatti. | La banda memoria può limitare i token al secondo anche quando il modello entra. |
| GPU con 8–16 GB VRAM | Modelli compatti quantizzati, verificando quanto resta per cache e concorrenza. | Il file dei pesi non deve occupare tutta la VRAM disponibile. |
| GPU con 24 GB VRAM | Classi medie quantizzate, RAG e workload di coding più strutturati. | Multimodalità e contesti lunghi riducono il margine. |
| Server da 48–80 GB o multi-GPU | Modelli grandi o MoE dopo un benchmark di capacità e throughput. | Interconnessione, alimentazione, raffreddamento e utenti concorrenti. |
Queste sono soglie di partenza, non certificazioni del produttore. Il test va eseguito sul modello, sulla quantizzazione e sul contesto realmente scelti.
CPU, NVIDIA, AMD e Apple Silicon
La CPU è sufficiente per prototipi, automazioni non interattive e modelli compatti; la banda della RAM diventa spesso il limite. NVIDIA offre lo stack più maturo per molti runtime GPU. AMD può essere valida, ma la compatibilità va controllata sulla scheda e sulla versione del runtime. Apple Silicon sfrutta memoria unificata, utile quando la capacità conta più della compatibilità CUDA. Una NPU integrata non sostituisce automaticamente una GPU: serve un modello e un runtime che la supportino davvero.
Quale runtime scegliere
| Runtime | Uso ideale | Verifica da fare |
|---|---|---|
| Ollama | Installazione rapida, API locale, prototipi e piccoli server. | Contesto, modelli caricati e richieste parallele. |
| LM Studio | Confronto da desktop e gestione visuale dei modelli. | Backend usato, formato e offload GPU. |
| llama.cpp | GGUF, CPU, Apple Silicon e grande portabilità. | Quantizzazione, layer offload e build ottimizzata per la CPU/GPU. |
| vLLM | Serving GPU e molte richieste concorrenti. | Compatibilità del modello, batching e memoria necessaria. |
| SGLang | Workflow agentici e serving avanzato. | Parser dei tool, template chat e versione supportata. |
| Open WebUI | Interfaccia utenti sopra Ollama o API compatibili. | Autenticazione, permessi e isolamento dei backend. |
Il benchmark corretto usa il lavoro reale
Non scegliere un modello soltanto dai benchmark pubblici. Prepara 20–50 prove rappresentative: documenti, domande in italiano, estrazione dati, codice, chiamate a strumenti e casi in cui il modello deve rifiutare un’azione. Misura almeno:
- qualità e percentuale di attività completate correttamente;
- tempo al primo token e velocità di generazione;
- RAM o VRAM al contesto realmente usato;
- stabilità con più utenti;
- affidabilità di JSON, function calling e citazioni;
- comportamento con documenti ostili o prompt injection.
Un 4B che esegue correttamente un processo può essere più utile di un modello molto più grande ma lento o imprevedibile.
RAG, fine-tuning e agenti non risolvono lo stesso problema
RAG
Recupera parti rilevanti di manuali, procedure e documenti al momento della domanda. È normalmente il primo passo per collegare una knowledge base senza modificare i pesi.
Fine-tuning
Adatta comportamento e formato delle risposte. Richiede un dataset curato e una valutazione separata; non è il modo giusto per “memorizzare” documenti che cambiano spesso.
Agenti
Consentono al modello di usare API, database, file e applicazioni. Qui il controllo dei privilegi, la validazione degli argomenti e l’approvazione delle azioni contano quanto la qualità linguistica.
Sicurezza e privacy: locale non significa automaticamente sicuro
Il self-hosting può evitare che i prompt escano verso un provider, ma introduce API interne, container, modelli scaricati, log, database vettoriali e strumenti con privilegi. Servono autenticazione, segmentazione, patching, scansione delle dipendenze, backup e protezione dalle prompt injection nei documenti RAG.
Procedura di acquisto in sette passi
- Definire i compiti e il numero di utenti concorrenti.
- Selezionare due o tre model card ufficiali e controllare licenza e modalità.
- Scegliere il formato di esecuzione e stimare pesi più overhead.
- Limitare inizialmente il contesto al necessario.
- Provare il modello sull’hardware disponibile prima di acquistare.
- Misurare qualità, latenza, memoria e consumo energetico.
- Comprare hardware solo dopo aver individuato il collo di bottiglia reale.
FAQ
Con 16 GB di RAM si può usare l’AI locale?
Sì, partendo da modelli compatti quantizzati e lasciando memoria al sistema. Un 8B–9B può essere testato, ma velocità e contesto dipendono da CPU, banda memoria, formato e runtime.
Serve sempre una GPU?
No. La GPU migliora molto reattività e throughput, ma CPU-only è valida per modelli piccoli, prove e carichi non in tempo reale.
Il contesto massimo dichiarato va sempre abilitato?
No. È un limite del modello, non una configurazione gratuita: aumenta memoria e tempi di elaborazione.
Qual è il modello migliore?
Quello che supera il test sul proprio processo con qualità, latenza, licenza e costi accettabili. Non esiste un vincitore indipendente dal caso d’uso.
Conclusione
L’AI locale non richiede di comprare subito una workstation estrema. Il percorso corretto è scegliere pochi modelli con schede verificabili, fissare quantizzazione e contesto, provarli sul lavoro reale e dimensionare l’hardware sui risultati. Per approfondire l’evoluzione dei PC dedicati puoi leggere anche l’analisi EP Consulting su Microsoft Project Zenith.