Portare un llm in locale non significa solo “farlo girare sul proprio server”. Significa scegliere un assetto in cui dati, inferenza, log e integrazioni restano sotto il proprio controllo, con più prevedibilità su privacy, governance e costi ricorrenti. Se vuoi orientarti tra architetture, limiti e modelli, può essere utile partire da una panoramica più ampia sui modelli di intelligenza artificiale, così da capire dove si colloca davvero un deploy on premise rispetto alle API cloud. Le piattaforme più usate per iniziare oggi in locale, come Ollama, espongono anche endpoint compatibili con parte delle API OpenAI, mentre motori come llama.cpp e vLLM coprono scenari diversi: semplicità, quantizzazione, throughput e serving multiutente.null
Per una PMI o per un team tecnico, la domanda giusta non è “si può fare?”, ma “conviene davvero farlo?”. In alcuni casi sì: documenti interni, knowledge base riservate, workflow regolati, costi API poco prevedibili, necessità di tenere il dato in sede o in un’infrastruttura dedicata. In altri casi, invece, il cloud resta più efficiente, soprattutto quando servono modelli top di gamma, scalabilità elastica o tempi di avvio molto rapidi.null
Quando un llm locale ha davvero senso
Un llm locale ha senso quando il valore principale non è solo la qualità assoluta del modello, ma il controllo dell’intero sistema. Questo vale soprattutto in quattro scenari.
- Privacy e riservatezza: dati contrattuali, documenti HR, ticket tecnici, materiale legale o finanziario che non vuoi inviare a servizi esterni.
- Costi stabili: se hai volumi continui, un’infrastruttura interna ben dimensionata può rendere più prevedibile la spesa mensile.
- Integrazione stretta: processi con ERP, CRM, file server, SharePoint, database o document management interni.
- Governance: controllo su versioni del modello, policy di retention, logging, rete e accessi.
Questo approccio è particolarmente interessante quando l’LLM non lavora da solo, ma dentro un flusso più ampio fatto di retrieval, strumenti, classificazione, automazioni e supervisione umana. In pratica, il modello diventa un componente della tua architettura e non un servizio esterno “black box”. Framework open source come Haystack sono pensati proprio per costruire pipeline di retrieval-augmented generation e applicazioni LLM su dati proprietari.null
Quando il cloud resta la scelta più pratica
Il deploy locale non è automaticamente la scelta migliore. Se il team è piccolo, i volumi sono bassi e il progetto deve partire in pochi giorni, le API cloud riducono molto la complessità iniziale. Non devi occuparti di GPU, driver, monitoraggio, failover, patch di sicurezza o aggiornamenti del runtime.
Il cloud resta spesso preferibile anche quando servono:
- modelli di frontiera molto grandi;
- picchi di traffico variabili;
- latenza globale su utenti distribuiti;
- feature avanzate già pronte, come speech, multimodalità o orchestrazione gestita;
- benchmark qualitativi superiori a ciò che puoi far stare su hardware aziendale.
In altre parole, llm in locale non significa “meglio del cloud”, ma “più coerente con alcuni vincoli”. Se stai valutando diversi approcci e famiglie di modelli, può aiutare anche un confronto trasversale tra modelli AI e casi d’uso concreti, prima di bloccare budget su hardware o licenze.
Hardware: CPU, GPU, VRAM e RAM senza miti
Il punto critico di ogni progetto open-source llm on premise è quasi sempre l’hardware. La prima distinzione da fare è semplice: su CPU puoi fare test, su GPU lavori davvero. llama.cpp supporta molti backend, inclusi CUDA per GPU NVIDIA, Metal per Apple Silicon, HIP per AMD e altri acceleratori; Ollama supporta accelerazione GPU su Apple, NVIDIA e AMD, ma se la GPU non viene rilevata può ricadere sulla CPU con un calo netto delle prestazioni.null
Cosa incide davvero sulla memoria
La memoria necessaria dipende da più fattori:
- numero di parametri del modello;
- precisione o quantizzazione;
- lunghezza del contesto;
- numero di richieste concorrenti;
- cache KV e overhead del runtime.
La quantizzazione riduce il peso del modello e rende possibile usare modelli altrimenti troppo grandi per hardware consumer. Nel mondo llama.cpp il formato GGUF è lo standard più diffuso per eseguire modelli quantizzati localmente. Anche in Transformers esistono strategie per ridurre l’uso della KV cache, inclusa la cache quantizzata.null
Regole pratiche per partire
Per una PMI, queste stime sono utili come base iniziale. Sono valori indicativi, non numeri assoluti, perché il consumo reale varia in base al runtime, alla quantizzazione e al contesto richiesto.
| Taglia modello | Uso realistico | VRAM consigliata | RAM di sistema consigliata | Note operative |
|---|---|---|---|---|
| 3B–8B | Chat interne, FAQ, classificazione, assistenti base | 8–12 GB | 16–32 GB | Buon punto di partenza per test e primi casi d’uso |
| 7B–14B | RAG aziendale leggero, supporto documentale, task strutturati | 12–24 GB | 32–64 GB | Fascia spesso più equilibrata per costi e qualità |
| 20B–32B | Reasoning migliore, QA più robusto, tool use più affidabile | 24–48 GB | 64 GB+ | Serve attenzione a concorrenza e raffreddamento |
| 70B e oltre | Use case enterprise avanzati | Multi-GPU o server dedicati | 128 GB+ | Progetto infrastrutturale, non semplice “setup locale” |
La ragione è semplice: abbassare la precisione riduce lo spazio occupato dai pesi, ma non elimina overhead, cache e memoria necessaria per servire richieste reali. NVIDIA sottolinea anche che la gestione della memoria diventa centrale per inferenza e KV cache, tanto che alcune piattaforme puntano esplicitamente alla condivisione CPU-GPU per gestire modelli più grandi.null
Apple Silicon, workstation e server
Per prototipi interni, un Mac con Apple Silicon può essere comodo: installazione semplice, buona efficienza energetica, ambiente pulito per test locali. Per carichi continuativi e multiutente, però, nella pratica vince spesso una workstation Linux con GPU NVIDIA, perché l’ecosistema di serving e osservabilità è più maturo e la compatibilità è più ampia. llama.cpp supporta Metal su Apple Silicon, mentre vLLM è pensato soprattutto per serving ad alte prestazioni su GPU.null
Setup software: la stack minima che funziona
Se vuoi avviare un llm in locale senza complicarti la vita, la via più lineare è questa:
- Ollama per scaricare, avviare e servire modelli in pochi minuti;
- llama.cpp se vuoi massima flessibilità su GGUF, quantizzazione e runtime leggero;
- vLLM se il focus è il serving concorrente, con throughput più alto e API server compatibile OpenAI;
- un livello applicativo in Python o Node per autenticazione, business logic, logging e fallback.
Ollama è spesso il punto di partenza più rapido: gira in background, espone API su localhost e permette di pullare modelli locali con pochi comandi. Inoltre offre compatibilità con endpoint come /v1/chat/completions e /v1/responses, utile per riusare librerie già costruite per OpenAI.null
Un setup semplice per test interni
La configurazione minima per validare un progetto in azienda può essere questa:
- server Linux o macchina dedicata;
- Docker dove serve, ma senza containerizzare tutto dal giorno uno;
- Ollama o llama.cpp per inferenza locale;
- API interna che applica prompt template, filtri e permessi;
- database o vector store per i documenti aziendali;
- dashboard base per latenza, errori, saturazione GPU e code.
Se il progetto cresce, ha senso introdurre vLLM o un runtime più adatto al carico concorrente. La documentazione di vLLM evidenzia supporto al serving distribuito e al server compatibile OpenAI, incluse opzioni di parallelismo utili quando un modello non entra su una singola GPU.null
llm open source italiano: quando serve davvero
Molte aziende italiane non cercano il modello “più famoso”, ma quello che lavora meglio su documenti, terminologia e stile della lingua italiana. Qui entra in gioco il tema llm open source italiano.
Negli ultimi anni sono emersi progetti interessanti. Italia 9B di iGenius è stato presentato come una famiglia di modelli open source pensata per imprese e settori regolati, con enfasi su lingua italiana, trasparenza e sicurezza. Sul lato ricerca, il progetto Minerva di Sapienza NLP è nato come famiglia di modelli addestrati da zero per l’italiano, mentre la linea LLaMAntino rappresenta un altro filone rilevante per applicazioni italiane.null
Detto questo, la scelta non va fatta solo sulla bandiera “italiano”. In molti casi, un buon modello multilingue o un modello generalista ben integrato con retrieval e documenti aziendali rende di più di un modello specializzato ma meno robusto. La lingua del modello conta, ma contano altrettanto:
- qualità sulle istruzioni;
- capacità di seguire format e vincoli;
- uso di tool e function calling;
- robustezza su documenti lunghi;
- licenza, aggiornamenti e community.
Se stai valutando questa strada, può essere utile approfondire una selezione di LLM open source con focus su casi d’uso, trade-off e sostenibilità operativa.
RAG con modelli locali: il vero acceleratore per le PMI
Per molte aziende, la combinazione più sensata non è un modello enorme, ma un rag llm open source costruito bene. Il motivo è pratico: il modello non deve sapere già tutto. Deve recuperare i documenti giusti, usarli come contesto e produrre una risposta coerente.
Haystack definisce chiaramente questo spazio come il terreno naturale delle pipeline retrieval-augmented generation: recupero di documenti, passaggio del contesto al modello e generazione della risposta. È spesso il modo più efficiente per usare un modello locale su dati aziendali aggiornati e proprietari.null
Quando il RAG batte il modello più grande
Un RAG locale ben progettato può essere più utile di un modello più costoso in almeno tre casi:
- knowledge base interna con policy, manuali, procedure e contratti;
- assistenza tecnica con documentazione di prodotto;
- supporto commerciale o customer care con fonti controllate.
Questo approccio riduce le allucinazioni solo se la pipeline è fatta bene. Non basta “attaccare un vector DB”. Servono chunk sensati, metadati puliti, filtri per ruolo, versioning dei documenti e valutazione continua della qualità del retrieval.
Architettura minima RAG on premise
- ingestione documenti da cartelle, CMS, ERP o repository;
- pulizia e chunking del testo;
- embedding e indicizzazione vettoriale;
- retrieval con filtri e reranking dove utile;
- prompt con contesto e citazioni interne;
- tracciamento di fonti, score e feedback utente.
Questa è la strada più realistica per una PMI che vuole privacy, costi certi e qualità sufficiente senza inseguire modelli giganteschi.
Sicurezza, accessi e protezione dei dati
Un llm locale non è automaticamente sicuro solo perché gira “in casa”. Se esponi un endpoint interno senza controlli, hai spostato il rischio, non l’hai eliminato.
I livelli minimi da prevedere sono:
- segmentazione di rete tra server LLM, applicazioni e repository documentali;
- autenticazione e autorizzazione a livello API e interfaccia;
- cifratura del traffico interno e dei backup;
- sanitizzazione degli input per ridurre prompt injection e leakage;
- redazione dei log per evitare che dati sensibili finiscano in chiaro;
- policy di retention chiare su prompt, output e documenti temporanei.
In un sistema RAG, il rischio più concreto spesso non è il modello in sé, ma l’accesso ai documenti sbagliati. Per questo i permessi del retrieval devono seguire i permessi reali dell’organizzazione. Se un utente non può leggere un documento in origine, non deve poterlo ottenere tramite l’assistente.
Aggiornamenti, monitoraggio e manutenzione
Uno dei costi nascosti del deploy locale è la manutenzione. Modelli, driver, runtime, librerie e policy devono essere aggiornati con metodo. Anche quando usi strumenti molto semplici, come Ollama, restano comunque log, directory locali, aggiornamenti binari e dipendenze GPU da gestire.null
Cosa monitorare davvero
- latenza media e percentile alto;
- token al secondo;
- saturazione GPU e memoria;
- numero di richieste concorrenti;
- errori di timeout o out-of-memory;
- qualità delle risposte e fallback manuali.
Se il progetto serve utenti interni reali, è utile tracciare anche metriche di business:
- tempo risparmiato per task;
- riduzione dei ticket ripetitivi;
- percentuale di risposte corrette con fonte;
- adozione per reparto;
- costo per richiesta reale, non teorico.
Il monitoraggio deve coprire sia la parte tecnica sia la qualità applicativa. Un sistema veloce ma impreciso crea solo automazione del rumore.
Costi: dove finiscono davvero i soldi
Quando si parla di costi certi, molti pensano solo all’assenza di token pricing. In realtà il conto completo include:
- hardware iniziale o leasing;
- energia e raffreddamento;
- tempo DevOps e MLOps;
- setup di sicurezza e backup;
- monitoraggio e manutenzione;
- test, benchmark e aggiornamenti modello.
Il vantaggio economico del locale emerge soprattutto quando hai uso frequente, processi ripetitivi, contesto stabile e possibilità di standardizzare il carico. Se invece il traffico è intermittente o il progetto è ancora esplorativo, il cloud può restare più economico nel breve periodo.
La vera domanda è questa: quanto mi costa una risposta utile in produzione? Non una demo, non un benchmark isolato. Una risposta utile dentro un processo aziendale, con dati corretti, sicurezza, osservabilità e SLA interni.
Come partire senza bloccare il progetto
Il modo migliore per partire con un llm in locale non è comprare subito il server più costoso. È fare una prova guidata, con obiettivo stretto e metriche chiare.
Percorso consigliato in 30-45 giorni
- Fase 1: scegli un singolo caso d’uso ad alto valore e basso rischio, ad esempio ricerca su procedure interne.
- Fase 2: testa un modello 7B o 14B in locale con dataset ridotto e utenti pilota.
- Fase 3: misura qualità, latenza, costi operativi e bisogno reale di GPU più grandi.
- Fase 4: aggiungi RAG, permessi, logging e dashboard.
- Fase 5: solo dopo i risultati, scegli se consolidare on premise, restare ibrido o spostare parte del carico in cloud.
Questo approccio evita due errori comuni:
- comprare hardware sovradimensionato troppo presto;
- innamorarsi del modello e trascurare il processo.
Se devi anche orientarti tra modelli generalisti e alternative commerciali, un confronto su differenze pratiche tra assistenti e famiglie di modelli può aiutare a definire benchmark interni più sensati. In questo senso, una lettura come Claude vs ChatGPT vs Gemini è utile non per copiare il cloud, ma per capire quali aspettative qualitative abbia oggi il mercato.
Checklist finale per capire se il locale è sostenibile
- Hai dati che non vuoi o non puoi inviare a terzi?
- Hai un caso d’uso ripetibile e misurabile?
- Puoi accettare una qualità magari inferiore ai modelli top cloud in cambio di controllo e costi prevedibili?
- Hai almeno una persona tecnica che possa seguire setup, monitoraggio e aggiornamenti?
- Puoi partire con un pilota su 7B–14B invece di inseguire subito modelli enormi?
- Hai chiaro che il valore spesso sta più nel RAG e nell’integrazione che nel modello puro?
Se a queste domande rispondi spesso “sì”, allora un open-source llm on premise può essere una scelta concreta e sostenibile. Se invece ti manca governance, ownership tecnica o un caso d’uso chiaro, conviene partire in modo più leggero e lasciare che sia il progetto, non l’entusiasmo, a dirti quando portare davvero l’AI in casa.