LLM in locale: guida pratica per partire senza errori

Parlare di llm in locale oggi non significa solo “far girare un modello sul proprio PC”. Per molte aziende vuol dire proteggere dati sensibili, evitare dipendenze inutili dal cloud e costruire processi AI più prevedibili nei costi. Se vuoi orientarti tra modelli, scenari d’uso e scelte tecniche, può esserti utile partire anche da questa panoramica sui modelli AI per uso aziendale, così da capire subito dove il deploy locale ha davvero senso e dove invece rischia di complicare il progetto senza portare vantaggi reali.

Che cosa significa davvero usare un LLM in locale

Quando si parla di llm locale, si intende un modello linguistico eseguito su infrastruttura controllata direttamente dall’azienda: un PC workstation, un server interno, una macchina virtuale privata oppure un ambiente containerizzato on premise. In pratica, inferenza, file, log e flussi applicativi restano sotto il tuo controllo operativo, senza passare da API esterne per ogni richiesta. Soluzioni come Ollama, llama.cpp, vLLM e interfacce self-hosted come Open WebUI rendono questo approccio molto più accessibile rispetto a pochi anni fa. ([docs.ollama.com](https://docs.ollama.com/?utm_source=openai))

Questo non significa che tutto resti “automaticamente sicuro” solo perché è locale. Vuol dire però che puoi decidere dove vengono conservati i dati, chi accede ai log, quali modelli usare, quando aggiornare l’ambiente e come integrare il sistema nei flussi interni. È uno dei motivi per cui molte PMI valutano soluzioni open-source llm on premise per documentazione interna, knowledge base, supporto operativo e automazioni aziendali. ([qdrant.tech](https://qdrant.tech/documentation/?utm_source=openai))

Quando conviene davvero rispetto al cloud

La scelta tra locale e API cloud non dovrebbe mai essere ideologica. Ha senso portare un LLM in locale quando esistono almeno alcune di queste condizioni:

• dati riservati o regolati che non vuoi inviare a provider esterni;
• volumi di utilizzo elevati e prevedibili, dove il costo per token delle API diventerebbe rilevante;
• necessità di integrazione interna con file system, ERP, CRM o documenti aziendali;
• necessità di avere un endpoint stabile e controllato per workflow automatici;
• richiesta di lavorare anche offline o in ambienti con connettività limitata.

Al contrario, il cloud resta spesso più conveniente se ti serve partire in pochi giorni, testare più modelli premium, gestire carichi molto variabili o ottenere prestazioni elevate senza acquistare hardware. In molte realtà la soluzione migliore non è “solo locale” o “solo cloud”, ma una strategia ibrida: locale per dati interni e task ripetitivi, API esterne per casi complessi o picchi di domanda. Anche per questo è utile confrontare approcci e famiglie di modelli, ad esempio leggendo un approfondimento su modelli di intelligenza artificiale e relative applicazioni.

I vantaggi reali di un LLM in locale

Privacy e governance dei dati

Il vantaggio più citato è corretto: il dato non deve lasciare per forza il perimetro aziendale. Se costruisci il sistema bene, prompt, allegati, embedding e output possono restare su server controllati internamente. Questo è particolarmente utile per manuali tecnici, offerte commerciali, procedure, ticket, contratti e documentazione HR. Qdrant, ad esempio, è open source e può essere self-hosted, mentre Open WebUI è progettato per funzionare anche interamente offline con provider locali o compatibili OpenAI. ([qdrant.tech](https://qdrant.tech/documentation/?utm_source=openai))

Costi più prevedibili

Con il cloud paghi in genere a consumo. Con il locale il costo si sposta soprattutto su hardware, setup, energia, manutenzione e aggiornamenti. Se hai richieste frequenti e abbastanza stabili, il budget è spesso più prevedibile, soprattutto nei casi in cui il modello serve centinaia o migliaia di chiamate interne al giorno.

Maggiore controllo sul comportamento operativo

In locale puoi scegliere versione del modello, quantizzazione, finestra di contesto, motore di inferenza, policy di logging e modalità di esposizione API. Ollama, per esempio, permette di cambiare il context window tramite variabile d’ambiente o parametro di runtime, mentre llama.cpp e vLLM offrono approcci diversi per serving e integrazione applicativa. ([docs.ollama.com](https://docs.ollama.com/faq?utm_source=openai))

I limiti da considerare prima di partire

Prestazioni non sempre paragonabili ai modelli cloud migliori

Un LLM locale da 7B o 8B quantizzato può essere molto utile per classificazione, riassunti, drafting e Q&A su documenti interni. Ma non va confuso con modelli cloud di fascia alta in ragionamento complesso, coding avanzato o task multimodali più pesanti. Il rischio tipico è aspettarsi troppo dall’hardware disponibile.

Il collo di bottiglia è quasi sempre la memoria

Quando si valuta un llm in locale, la domanda iniziale non è “quanti parametri ha il modello?”, ma “quanta memoria mi serve per farlo girare bene?”. Per l’inferenza locale contano soprattutto VRAM della GPU, RAM di sistema, lunghezza del contesto, quantizzazione e numero di utenti simultanei. Ollama dichiara che il modello viene caricato in GPU se entra nella VRAM disponibile, altrimenti può usare una combinazione CPU/GPU o solo CPU; inoltre il context length di default dipende proprio dalla VRAM disponibile. Hugging Face conferma che la quantizzazione 8-bit e 4-bit riduce in modo significativo l’uso di memoria. ([docs.ollama.com](https://docs.ollama.com/faq?utm_source=openai))

La manutenzione non sparisce

Portare tutto in casa significa anche gestire driver, dipendenze CUDA o ROCm, aggiornamenti di runtime, compatibilità del modello, backup, metriche e procedure di rollback. Ollama, ad esempio, documenta percorsi log, upgrade e troubleshooting per Linux, Windows e container; vLLM e TGI espongono metriche monitorabili con stack come Prometheus. ([docs.ollama.com](https://docs.ollama.com/faq?utm_source=openai))

Requisiti hardware: come stimarli senza errori

Non esiste una tabella universale valida per tutti i modelli, ma esistono regole pratiche utili per una PMI che vuole evitare errori grossolani.

CPU

La CPU conta soprattutto se lavori senza GPU oppure se parte dell’inferenza resta in RAM. Puoi far girare molti modelli anche solo su CPU, ma la latenza sale molto. Per test interni, demo o piccoli workload va bene. Per uso quotidiano da team, spesso no.

GPU e VRAM

La GPU è il componente che più incide sull’esperienza. Più VRAM hai, più facilmente puoi:

• caricare modelli più grandi;
• usare contesti più lunghi;
• ridurre la parte eseguita su CPU;
• gestire più richieste contemporanee;
• mantenere tempi di risposta più stabili.

In termini pratici, per partire senza frizioni:

Questa tabella non sostituisce i test, ma evita un errore frequente: comprare hardware “sufficiente sulla carta” e scoprire poi che il contesto reale, la quantizzazione scelta o il numero di utenti simultanei mandano tutto in saturazione.

RAM di sistema

La RAM non va sottovalutata. Anche quando il modello gira in buona parte in GPU, servono memoria per sistema operativo, cache, processo di serving, embedding, vector store, documenti e strumenti accessori. Se vuoi usare un rag llm open source con pipeline documentale, 64 GB di RAM diventano una base molto più tranquilla di 16 o 32 GB.

Storage

Usa SSD NVMe. I modelli quantizzati in formato GGUF o altri formati ottimizzati occupano meno dei checkpoint originali, ma possono comunque richiedere molti gigabyte. A questo devi aggiungere database vettoriale, snapshot, log e backup.

Quantizzazione: il concetto chiave per far funzionare davvero il locale

Se vuoi far girare modelli utili senza una GPU enterprise, la quantizzazione è centrale. In sintesi, riduce la precisione numerica dei pesi del modello per abbassare il consumo di memoria e rendere l’inferenza più accessibile. Nella documentazione Hugging Face, il caricamento in 8-bit riduce circa della metà l’uso di memoria rispetto a versioni più pesanti, mentre il 4-bit spinge ancora di più il risparmio, con possibili compromessi qualitativi in base al modello e al task. ([huggingface.co](https://huggingface.co/docs/transformers/en/quantization/bitsandbytes?utm_source=openai))

In pratica:

• 8-bit è spesso un buon equilibrio tra qualità e memoria;
• 4-bit è molto utile per far stare modelli più grandi su hardware consumer;
• quantizzare troppo può peggiorare precisione, stabilità e resa su task specialistici;
• per document Q&A, drafting e classificazione, i compromessi sono spesso accettabili;
• per compiti ad alta precisione o compliance, conviene testare più configurazioni.

Quale stack scegliere per iniziare

Ollama: la scelta più semplice per i primi test

Ollama è oggi una delle strade più rapide per avviare un llm locale. Installa il runtime, scarica un modello compatibile, avvii il servizio e hai già API locali utilizzabili dalle tue applicazioni. La documentazione ufficiale spiega come gestire compatibilità GPU, contesto, log e aggiornamenti. Per un primo pilot interno è spesso la scelta più pragmatica. ([docs.ollama.com](https://docs.ollama.com/?utm_source=openai))

llama.cpp: flessibile e leggero

llama.cpp resta un riferimento per l’inferenza efficiente di modelli in formato GGUF, con supporto CPU e GPU e un server HTTP compatibile con API in stile OpenAI. È molto utile quando vuoi controllo fine, footprint ridotto e deployment semplici anche fuori da stack pesanti. ([github.com](https://github.com/NousResearch/llama.cpp?utm_source=openai))

vLLM o TGI: più adatti al serving strutturato

Se l’obiettivo è servire un modello a più utenti o applicazioni con più concorrenza, strumenti come vLLM o Hugging Face Text Generation Inference sono più adatti. Entrambi espongono metriche monitorabili; vLLM include un server compatibile OpenAI e dashboard/integrazioni per il monitoraggio, mentre TGI espone endpoint Prometheus per le metriche. ([docs.vllm.ai](https://docs.vllm.ai/_/downloads/en/v0.6.1/pdf/?utm_source=openai))

Open WebUI: interfaccia pronta per il team

Se vuoi far usare il sistema anche a utenti non tecnici, Open WebUI è una buona interfaccia self-hosted. Supporta Ollama e provider compatibili OpenAI, inclusi server locali come llama.cpp e vLLM. Questo permette di separare backend di inferenza e frontend d’uso, utile in aziende dove il reparto IT prepara la piattaforma e i team operativi la usano via browser. ([docs.openwebui.com](https://docs.openwebui.com/?utm_source=openai))

Se stai valutando quali modelli usare con un’impostazione locale o ibrida, può aiutarti anche un approfondimento dedicato agli LLM open source per aziende, utile per capire differenze pratiche tra modelli più leggeri e modelli più ambiziosi.

Setup pratico minimo per una PMI

Un setup sensato, senza complicare troppo il progetto, può essere questo:

• server Linux dedicato o workstation con GPU da almeno 12-24 GB VRAM;
• runtime Ollama oppure llama.cpp per il primo strato di inferenza;
• Open WebUI come interfaccia interna;
• Qdrant self-hosted per vector search se devi fare RAG;
• reverse proxy interno con autenticazione;
• backup di modelli, configurazioni e storage vettoriale;
• monitoraggio base di risorse, errori e tempi di risposta.

Questo approccio riduce il rischio di overengineering. Parti da un pilot, misuri l’uso reale, poi decidi se passare a un’architettura più robusta con vLLM, container orchestrati e bilanciamento del carico.

RAG con LLM open source: quando serve e come impostarlo

Molte aziende non hanno bisogno di “un modello più intelligente”, ma di un modello che risponda sui documenti giusti. Qui entra in gioco il rag llm open source: una pipeline in cui i documenti vengono indicizzati come embedding in un vector database, poi recuperati al bisogno e passati al modello insieme alla domanda. Qdrant supporta installazione self-hosted via Docker ed è pensato proprio per scenari di ricerca vettoriale anche in infrastrutture locali. ([qdrant.tech](https://qdrant.tech/documentation/guides/installation/?utm_source=openai))

In pratica, un sistema RAG locale richiede almeno quattro componenti:

• un modello per generare gli embedding;
• un database vettoriale come Qdrant;
• un processo di ingestione documentale;
• un modello generativo che usa i contenuti recuperati.

Il vantaggio è chiaro: puoi usare anche modelli non enormi, purché il recupero delle informazioni sia fatto bene. Per molte knowledge base interne questo approccio rende molto più di un semplice chatbot “generico”.

Sicurezza: gli errori più comuni nei deploy on premise

Un open-source llm on premise non è sicuro per definizione. Va progettato. Gli errori più frequenti sono:

• API locali esposte senza autenticazione;
• log che salvano prompt e allegati sensibili;
• assenza di segmentazione di rete;
• modelli scaricati senza controllo di provenienza e licenza;
• mancanza di policy su retention, accessi e backup;
• ambiente Docker o host non aggiornato.

La base minima dovrebbe includere rete interna o VPN, reverse proxy, controllo accessi, cifratura dei volumi sensibili, backup verificati, scansione delle immagini container e gestione ordinata delle versioni di modelli e runtime. Anche i log vanno trattati come dati aziendali, perché spesso contengono contenuti utili a ricostruire conversazioni e documenti processati.

Aggiornamenti, monitoraggio e manutenzione

Uno dei motivi per cui alcuni progetti si bloccano dopo il pilot è che il team sottostima la parte operativa. In realtà un llm in locale funziona bene solo se monitori almeno questi elementi:

• uso di GPU, VRAM e RAM;
• latenza media e picchi;
• numero di richieste simultanee;
• errori applicativi e saturazione del modello;
• spazio disco e crescita dei log;
• salute del vector store se usi RAG.

Ollama documenta chiaramente dove leggere i log su Linux, Windows e container. vLLM e TGI espongono metriche che possono essere raccolte con Prometheus e visualizzate in dashboard dedicate. In un ambiente di produzione, queste metriche non sono opzionali: sono ciò che ti permette di capire se il sistema sta reggendo davvero o sta solo “sembrando stabile” durante le demo. ([docs.ollama.com](https://docs.ollama.com/troubleshooting?utm_source=openai))

Come capire se il deploy locale è sostenibile per il tuo team

Per una PMI, la domanda giusta non è “posso farlo?”, ma “riesco a gestirlo bene per i prossimi 12 mesi?”. Di solito il deploy locale è sostenibile quando:

• hai un caso d’uso concreto, non solo esplorativo;
• il volume di richieste è abbastanza costante;
• puoi dedicare almeno una figura tecnica al setup e alla manutenzione;
• i dati trattati rendono davvero utile il controllo on premise;
• parti con un perimetro limitato e misurabile.

Se invece non hai ancora definito flussi, utenti, qualità attesa e responsabilità operative, spesso conviene iniziare da un pilot più snello o da un’architettura ibrida.

Piano di partenza consigliato per evitare blocchi

Fase 1: pilot tecnico di due settimane

• scegli 1-2 casi d’uso reali;
• prova un modello piccolo o medio quantizzato;
• misura tempi di risposta, qualità e stabilità;
• verifica il comportamento su documenti reali.

Fase 2: mini ambiente interno

• aggiungi interfaccia utente;
• attiva autenticazione;
• configura log e backup;
• coinvolgi 3-5 utenti interni.

Fase 3: valutazione economica e operativa

• confronta costo totale locale vs API cloud;
• stima manutenzione mensile;
• decidi se passare a server dedicato o setup ibrido.

Quali modelli scegliere all’inizio

Per partire bene, non serve inseguire subito il modello più grande. In molti casi conviene testare:

• modelli piccoli o medi per classificazione, estrazione e supporto interno;
• modelli instruction-tuned per chat e task documentali;
• embedding model separati per il RAG;
• versioni quantizzate per trovare il miglior equilibrio tra qualità e footprint.

Se vuoi confrontare l’approccio locale con soluzioni cloud più note e capire dove ciascuna opzione è più forte, è utile anche leggere un confronto tra Claude, ChatGPT e Gemini, soprattutto per chiarire quando il locale è una scelta strategica e quando invece è più pratico usare API esterne.

Errori da evitare subito

• Scegliere il modello prima del caso d’uso.
• Fare stime hardware senza considerare la lunghezza del contesto.
• Confondere demo in single user con uso reale multiutente.
• Ignorare monitoraggio, log e procedure di aggiornamento.
• Montare un RAG senza curare ingestione, chunking e qualità dei documenti.
• Pensare che “open source” significhi automaticamente gratuito da gestire.

Il criterio giusto per decidere

Un llm open source italiano o internazionale, usato in locale, ha senso quando il suo valore pratico supera la complessità operativa che introduce. Se il progetto deve lavorare su dati interni, con budget prevedibile e processi ripetibili, l’approccio locale può diventare molto solido. Se invece stai ancora cercando il caso d’uso, il cloud spesso ti aiuta a validare prima e investire dopo.

La scelta migliore, quasi sempre, è quella che ti permette di partire piccolo, misurare presto e mantenere il controllo tecnico senza rallentare il business.