Report operativo: ottimizzare l’uso di LLM locali/on-premise

Vantaggi e motivazioni dell’AI locale

La spinta verso l’adozione di modelli linguistici di grandi dimensioni (LLM) in locale o on-premise non è motivata solo da considerazioni tecniche, ma rappresenta una scelta strategica che incide su privacy, economia e autonomia operativa. Le motivazioni principali possono essere ricondotte a quattro macro-aree: la protezione dei dati, l’ottimizzazione dei costi, la resilienza operativa e la sovranità digitale.

Privacy e controllo dei dati

Il vantaggio più immediato e percepibile dell’esecuzione locale di un LLM è la garanzia di riservatezza dei dati. Quando un modello viene eseguito su un’infrastruttura propria (un PC con GPU, un server aziendale o una VPS dedicata), i dati elaborati—che si tratti di documenti legali, cartelle cliniche, codice sorgente proprietario o informazioni commerciali sensibili—non lasciano mai il perimetro di controllo dell’organizzazione.

Questo elimina alla radice il problema della trasmissione di informazioni riservate a server di terze parti, un rischio concreto quando si utilizzano API pubbliche. Anche se i fornitori di servizi cloud garantiscono policy di non utilizzo dei dati per l’addestramento, il dato transita comunque sulla rete e viene processato su infrastrutture esterne, esponendo l’organizzazione a potenziali intercettazioni, violazioni o richieste legali da parte di autorità straniere. Con un modello locale, il dato è scritto su un disco rigido controllato e l’accesso può essere gestito con le stesse policy di sicurezza già adottate per gli altri asset informatici.

Un ulteriore livello di controllo riguarda il modello stesso: l’organizzazione può verificare la provenienza dei pesi, applicare tecniche di fine-tuning su dati proprietari senza condividerli e gestire l’intero ciclo di vita del modello in modo autonomo.

Riduzione dei costi operativi

Dal punto di vista economico, il passaggio a modelli locali può determinare un cambio di paradigma nel calcolo del totale costo di proprietà (TCO). Gli abbonamenti ai servizi AI commerciali sono convenienti per l’uso personale, ma quando si supera una certa soglia di utilizzo, il conto delle API cresce in modo lineare e può diventare insostenibile. Con agenti automatici, processi di automazione e workload continui, i costi di inferenza basati sul numero di token processati possono accumularsi rapidamente, rendendo l’investimento in hardware locale un’opzione che si ripaga in pochi mesi.

L’analisi comparativa è chiara: una workstation con una GPU dedicata (ad esempio con 16-24 GB di VRAM) o un server condiviso ben configurato rappresentano un costo fisso una tantum. Dopo l’ammortamento, il costo marginale per ogni richiesta al modello tende a zero, limitato solo dal consumo elettrico. Questa struttura di costo è particolarmente vantaggiosa per scenari ad alto volume, come l’elaborazione batch di documenti, la generazione di report automatici o l’uso di agenti che interagiscono continuamente con il modello.

Inoltre, l’ottimizzazione dell’hardware gioca un ruolo cruciale: l’evoluzione di runtime come llama.cpp e l’integrazione di Vulkan (ora abilitato di default in Ollama 0.30) estendono l’accelerazione GPU a un ventaglio più ampio di schede, incluse quelle AMD e Intel, riducendo la dipendenza da hardware NVIDIA di fascia alta. Anche su CPU, i progressi nella quantizzazione dei modelli (dai Q4_K_M ai più recenti approcci a 1-bit con parametri ternari) permettono di eseguire modelli di dimensioni significative su macchine "normali", abbassando ulteriormente la barriera d’ingresso.

Indipendenza da API revocabili (kill switch)

L’affidamento a servizi API di terze parti introduce una vulnerabilità strutturale: la possibilità che il fornitore revochi l’accesso, modifichi i termini di servizio, cambi i prezzi o cessi del tutto il servizio. Questo rischio, definito in gergo come "kill switch", è particolarmente rilevante in un contesto geopolitico instabile, dove un fornitore americano potrebbe essere obbligato a interrompere l’erogazione di servizi verso determinate aree geografiche o settori industriali per motivi di sanzioni o di sicurezza nazionale.

La dipendenza da API esterne rende l’intera infrastruttura applicativa vulnerabile a decisioni prese altrove, senza alcun controllo diretto. Un’organizzazione che basa i propri processi critici su un’API commerciale si trova esposta a un rischio esistenziale: se il servizio viene interrotto, l’operatività si blocca. I modelli open-weight (come quelli di Google, Mistral, o i modelli cinesi Qwen e DeepSeek) possono essere scaricati una volta e utilizzati per sempre, senza alcuna dipendenza dalla continuità del servizio di un fornitore terzo.

Questa indipendenza si estende anche alla capacità di aggiornamento: l’organizzazione può decidere autonomamente quando e se migrare a una versione più recente di un modello, senza essere vincolata alle finestre di rilascio o alle policy di deprecazione del fornitore.

Sovranità digitale

Il concetto di sovranità digitale va oltre la semplice privacy e tocca la capacità di un’organizzazione (o di una nazione) di controllare la propria infrastruttura tecnologica critica. In un panorama dove le principali AI commerciali sono sviluppate da aziende americane, l’uso diffuso di queste tecnologie crea una dipendenza tecnologica che ha implicazioni strategiche.

L’adozione di modelli locali open-weight rappresenta una strategia di "Sovranità Elastica", un approccio a più livelli che consente di mantenere il controllo sui dati e sulle infrastrutture, pur potendo attingere ai servizi cloud quando necessario. Questa strategia prevede un livello base di modelli locali per i dati più sensibili, un livello intermedio per workload che possono tollerare una minore riservatezza, e un livello cloud solo per operazioni non critiche o per test.

Questo approccio è particolarmente rilevante per le organizzazioni europee, che si trovano a dover bilanciare l’accesso a tecnologie avanzate con il rispetto del GDPR e con la necessità di non dipendere da fornitori extra-UE. La capacità di eseguire modelli come Gemma 4 12B o altri modelli open-weight su infrastrutture locali offre la possibilità di sviluppare competenze interne, di personalizzare i modelli e di mantenere il controllo sull’intera catena del valore, senza rinunciare all’innovazione.

L’ascesa dei modelli open-weight cinesi ha inoltre introdotto un elemento di competizione che democratizza l’accesso alla tecnologia: modelli di alta qualità (come Qwen e DeepSeek) sono disponibili con licenze permissive, spingendo i colossi americani a migliorare i propri modelli open-source e offrendo alle organizzazioni un ventaglio più ampio di scelte, riducendo la dipendenza da un unico fornitore.

Hardware e piattaforme consigliate

La scelta dell’hardware determina in modo diretto quali modelli è possibile eseguire e con quale qualità di risposta. La regola pratica che governa l’intero ecosistema è semplice: la dimensione del modello, espressa in miliardi di parametri, deve trovare corrispondenza nella capacità della memoria video (VRAM) della scheda grafica o nella memoria unificata del sistema. Un modello che non entra in memoria non viene eseguito; un modello che entra a malapena produce output molto lentamente. La tabella che segue riassume i requisiti orientativi in base alla quantizzazione dei pesi.

Requisiti minimi e consigliati

Dimensione modello	Quantizzazione	VRAM/RAM necessaria	Tipologia hardware	Uso consigliato
1-3B	Q4_K_M	2-4 GB	CPU con 16 GB RAM, GPU entry-level, smartphone	Task semplici, autocomplete, classificazione
7-9B	Q4_K_M	6-8 GB	GPU 8 GB VRAM (RTX 3060/4060), Mac con 16 GB unificati, CPU potente	Assistenza generale, riassunti, estrazione informazioni
12-14B	Q4_K_M	8-12 GB	GPU 12-16 GB VRAM (RTX 4070/4080), Mac con 24-32 GB unificati	Uso professionale quotidiano, analisi documentale, tool calling
26-32B	Q4_K_M	16-24 GB	GPU 24 GB VRAM (RTX 4090/5090), Mac Studio 48-64 GB, VPS con GPU dedicata	Workload intensivi, elaborazione batch, agenti complessi
70B+	Q4_K_M	40-48 GB	Multi-GPU (2x 24 GB), server dedicato, Mac Studio 128 GB	Ricerca, fine-tuning pesante, casi d’uso enterprise

I requisiti minimi per un utilizzo dignitoso di modelli piccoli (fino a 9B) si attestano su una CPU moderna con 16 GB di RAM e, idealmente, una scheda grafica con almeno 8 GB di VRAM. Con questa configurazione si possono eseguire modelli come Llama 3.1 8B o Gemma 4 12B (quest’ultimo in quantizzazione più aggressiva), ottenendo tempi di risposta accettabili per interazioni interattive. Il salto di qualità avviene con 16-24 GB di VRAM, che permettono di eseguire modelli nella fascia 12-32B con quantizzazione Q4_K_M, la soglia in cui la qualità delle risposte diventa paragonabile—per molti task—a quella dei modelli commerciali via API. Per un uso professionale continuativo, una GPU con 24 GB di VRAM (RTX 3090/4090 usata o RTX 5090) rappresenta oggi il punto di equilibrio ottimale tra costo e capacità.

GPU vs CPU vs Apple Silicon (MLX)

La scelta della piattaforma di calcolo non è neutrale e incide profondamente su prestazioni, consumi e compatibilità.

• GPU NVIDIA: rappresentano ancora lo standard de facto dell’ecosistema. Con Ollama 0.30, le ottimizzazioni contribuite direttamente dal team NVIDIA e da llama.cpp portano a un incremento di throughput fino al 20% su hardware NVIDIA (testato con Gemma 4 26B in Q4_K_M su RTX 5090). Il supporto CUDA è il più maturo, con la più ampia compatibilità software (llama.cpp, LM Studio, Ollama, vLLM) e la migliore documentazione. Le schede con 16-24 GB di VRAM (RTX 4080/4090/5090) sono il riferimento per l’uso professionale locale. Le RTX 3060/4060 con 12-16 GB rappresentano l’opzione economica per iniziare.

• GPU AMD e Intel: fino a poco tempo fa considerate opzioni di ripiego, oggi beneficiano dell’abilitazione di Vulkan come backend predefinito in Ollama 0.30. Questo significa che l’accelerazione GPU funziona "out of the box" su un ventaglio molto più ampio di schede, senza bisogno di installare librerie specifiche del fornitore (come ROCm per AMD o oneAPI per Intel). Le prestazioni restano inferiori a quelle NVIDIA a parità di prezzo per la maggior parte dei workload, ma il divario si sta riducendo, e per chi possiede già una scheda AMD o Intel, la possibilità di eseguire modelli in locale senza ulteriori investimenti è un vantaggio concreto.

• Apple Silicon (MLX): l’ecosistema Apple offre un vantaggio architetturale unico: la memoria unificata. Su un Mac con 64 GB di RAM unificata, il processore (CPU+GPU+NPU) può accedere a tutta la memoria per l’inferenza, consentendo l’esecuzione di modelli molto più grandi di quanto sarebbe possibile su una GPU discreta con la stessa VRAM. Il runtime MLX, sviluppato da Apple e integrato in Ollama, è altamente ottimizzato e offre prestazioni notevoli in termini di token al secondo per watt consumato. Un Mac Studio con 64-128 GB di memoria unificata può eseguire modelli da 32B a 70B in quantizzazione Q4 che, su una workstation NVIDIA, richiederebbero l’acquisto di due schede da 24 GB. Il costo di ingresso è però elevato, e l’ecosistema software (sebbene in crescita) è meno pervasivo di quello CUDA. La scelta tra GPU NVIDIA e Mac diventa quindi una questione di volume di lavoro: per utilizzi sporadici, un Mac con 16-32 GB può bastare; per workload continui, una GPU NVIDIA dedicata offre il miglior rapporto prestazioni/costo.

• CPU pura (inferenza): l’ultima frontiera è rappresentata dall’inferenza puramente su CPU, che sfrutta le istruzioni AVX/AVX2/AVX-512 e la memoria di sistema. Con modelli quantizzati a 4-bit, una CPU moderna a 8+ core riesce a generare tra i 5 e i 15 token al secondo su modelli da 7-13B, sufficiente per chatbot e riassunti ma inadeguato per agenti complessi. Questo approccio è ideale per server in cui la GPU non è disponibile o per l’elaborazione batch notturna, dove la latenza non è critica e il costo del calcolo è irrilevante.

VRAM e dimensioni dei modelli

La memoria video è il collo di bottiglia più importante e la sua gestione determina l’esperienza d’uso. La regola è che la dimensione in memoria del modello in quantizzazione Q4_K_M è approssimativamente pari a 4 bit per parametro, più i pesi del layer di embedding e il contesto. In pratica, un modello da 12B in Q4_K_M occupa circa 7-8 GB di VRAM, mentre uno da 26B ne occupa circa 15-16. La finestra di contesto gioca un ruolo non trascurabile: con 128K di contesto, il KV-cache può consumare ulteriori 4-8 GB di memoria a seconda della dimensione del modello. L’utilizzo di quantizzazioni più aggressive (Q3_K_M o Q2_K) permette di ridurre il footprint di memoria del 20-30%, ma a costo di un calo evidente della qualità delle risposte, soprattutto su task di ragionamento complesso. La quantizzazione Q4_K_M rappresenta il punto di equilibrio oggi, con perdite di qualità minime rispetto al modello a piena precisione.

La scelta del modello deve quindi partire dalla memoria disponibile, non dal desiderio: con 8 GB di VRAM è ragionevole puntare a modelli nella fascia 7-9B in Q4_K_M (es. Llama 3.1 8B, Gemma 4 12B in Q3); con 16 GB si sale ai modelli da 12-14B in Q4_K_M (Gemma 4 12B, Qwen 2.5 14B); con 24 GB si possono eseguire modelli da 26-32B in Q4_K_M (Gemma 4 26B, Mistral Large, Qwen 2.5 32B). Superare questa soglia richiede architetture multi-GPU (due RTX 4090 collegate via NVLink o PCIe) o l’adozione di sistemi Apple Silicon con memoria unificata molto ampia (64-128 GB). Per i casi d’uso più comuni, come l’analisi documentale e l’assistenza alla scrittura, la fascia 12-14B rappresenta la scelta più razionale: qualità elevata, requisiti contenuti e velocità di generazione ai limiti del reale.

La scelta dell’hardware non deve però essere guidata solo dal momento presente. L’ecosistema sta evolvendo verso modelli sempre più efficienti (i parametri ternari a 1-bit promettono di ridurre i requisiti di memoria di un fattore 4 rispetto al Q4, riportando modelli da 70B su hardware consumer) e runtime più ottimizzati (le ottimizzazioni di llama.cpp sono in continuo miglioramento). Investire in una GPU con ampiezza di VRAM superiore al minimo richiesto oggi è una strategia prudente che consente di sfruttare i miglioramenti futuri senza dover ricomprare hardware. In questo contesto, la memoria unificata di Apple Silicon offre il vantaggio strutturale di essere ripartibile dinamicamente tra CPU e GPU, proteggendo meglio l’investimento nel tempo.

Strumenti di esecuzione locali

Strumenti di esecuzione locali

L’ecosistema degli strumenti per eseguire LLM in locale ha raggiunto una maturità notevole, con soluzioni che coprono l’intero spettro delle esigenze: dal singolo utente che vuole sperimentare sul proprio PC, all’organizzazione che deve gestire workload continui su infrastrutture dedicate. La scelta dello strumento non è neutrale e va operata in base a fattori come il tipo di hardware disponibile, la necessità di integrazione con altri sistemi, la familiarità con la riga di comando e il grado di controllo richiesto sulla configurazione.

Ollama e compatibilità GGUF/llama.cpp

Ollama si è affermato come lo strumento di riferimento per l’esecuzione locale di LLM, grazie a un equilibrio riuscito tra semplicità d’uso e flessibilità. La sua architettura si basa su llama.cpp come motore di inferenza sottostante, il che garantisce un’ampia compatibilità con l’ecosistema GGUF (GPT-Generated Unified Format), il formato di fatto per la distribuzione di modelli quantizzati. La versione 0.30, rilasciata di recente, ha consolidato questa posizione introducendo miglioramenti significativi sia in termini di prestazioni sia di compatibilità hardware.

Sul fronte delle prestazioni, le ottimizzazioni contribuite direttamente dal team NVIDIA e dai maintainer di llama.cpp portano a un incremento di throughput fino al 20% su hardware NVIDIA. Il dato, testato con il modello Gemma 4 26B in quantizzazione Q4_K_M su una RTX 5090, è indicativo di un trend più ampio: le ottimizzazioni a livello di kernel e di scheduling delle operazioni GPU stanno progressivamente riducendo il divario tra l’inferenza locale e quella via API. Per l’utente finale, questo si traduce in tempi di risposta più rapidi e nella possibilità di utilizzare modelli più grandi a parità di hardware.

L’aspetto più rilevante della versione 0.30 è però l’abilitazione di Vulkan come backend predefinito. Questo cambiamento estende l’accelerazione GPU a un ventaglio molto più ampio di schede, includendo AMD e Intel, senza richiedere l’installazione di librerie specifiche del fornitore come ROCm o oneAPI. Per chi possiede hardware non NVIDIA, il vantaggio è concreto: l’accelerazione GPU funziona "out of the box", abbassando la barriera d’ingresso per un’ampia fetta di utenti che in precedenza erano costretti a configurazioni manuali complesse o all’inferenza su CPU.

La compatibilità con l’ecosistema GGUF si è ampliata fino a includere famiglie di modelli di recente pubblicazione, come LFM di Liquid AI, i modelli Prism e i fine-tuning pubblicati da Unsloth. Il workflow per utilizzare un modello GGUF da Hugging Face è semplice e ben documentato: si scarica il file GGUF (o una directory contenente più file), si crea un Modelfile con il comando FROM che punta al percorso del file, e infine si crea ed esegue il modello con ollama create e ollama run. Questo approccio consente di utilizzare qualsiasi modello pubblicato in formato GGUF senza attendere che venga aggiunto al registro ufficiale di Ollama.

Un aspetto che merita attenzione è il supporto al tool calling, la capacità del modello di invocare funzioni esterne. Se un modello GGUF supporta questa funzionalità, essa viene ereditata automaticamente da Ollama, consentendo l’integrazione con agenti e assistenti come Claude Code, Hermes Agent o OpenClaw tramite il comando ollama launch. La verifica della capacità di tool calling si effettua con ollama show my-model, che elenca le capabilities del modello. Questa caratteristica è fondamentale per scenari di automazione e per l’uso di agenti che devono interagire con strumenti esterni, API o database.

L’ecosistema di Ollama include anche il supporto a MLX, il framework di Apple per l’apprendimento automatico su Apple Silicon. Questo significa che su un Mac con chip M-series, Ollama può utilizzare il backend MLX per l’inferenza, sfruttando la memoria unificata e le unità Neural Engine del chip. La combinazione di llama.cpp per l’hardware tradizionale e MLX per Apple Silicon rende Ollama uno strumento universale, in grado di coprire l’intero spettro delle piattaforme hardware oggi disponibili.

LM Studio

LM Studio rappresenta l’alternativa con interfaccia grafica a Ollama, pensata per utenti che preferiscono un approccio visuale alla configurazione e all’esecuzione dei modelli. L’applicazione, disponibile per Windows, macOS e Linux, integra al suo interno il motore di inferenza di llama.cpp e offre una libreria integrata di modelli scaricabili direttamente dall’interfaccia, con ricerca e filtri per famiglia, dimensione e quantizzazione.

Il punto di forza di LM Studio è la sua accessibilità: l’utente può cercare un modello, scaricarlo e avviarlo in pochi clic, senza dover interagire con la riga di comando. L’interfaccia include un pannello di chat con supporto alla gestione del contesto, alla selezione del modello attivo e alla configurazione dei parametri di generazione come temperatura, top-p e lunghezza massima della risposta. È inoltre possibile caricare più modelli contemporaneamente e passare da uno all’altro senza interruzioni, una funzionalità utile per confrontare le risposte di modelli diversi sullo stesso input.

Dal punto di vista tecnico, LM Studio espone un server API locale compatibile con il formato OpenAI, il che lo rende utilizzabile come backend per applicazioni esterne, strumenti di sviluppo e framework di orchestrazione. Questa caratteristica lo rende una scelta interessante per chi vuole prototipare un’applicazione basata su LLM locali senza investire tempo nella configurazione di un server dedicato. La compatibilità con il formato GGUF garantisce l’accesso allo stesso ecosistema di modelli di Ollama, con la differenza che la gestione avviene tramite interfaccia grafica.

Il limite principale di LM Studio rispetto a Ollama è la minore automazione e la mancanza di un ecosistema di comandi da riga di comando paragonabile. Per scenari di automazione e integrazione in pipeline, Ollama offre un controllo più fine e una più facile integrazione in script e processi. LM Studio si posiziona quindi come lo strumento ideale per l’esplorazione e la sperimentazione, mentre per l’uso operativo continuativo Ollama o l’uso diretto di llama.cpp sono spesso preferibili.

Llamafile: distribuisci ed esegui LLM con un singolo file

Llamafile, sviluppato da Mozilla (progetto "Ocho"), introduce un paradigma radicalmente diverso nella distribuzione e nell’esecuzione dei modelli: un singolo file eseguibile che contiene sia il runtime sia i pesi del modello. Questo approccio elimina alla radice i problemi di installazione, configurazione e gestione delle dipendenze: il file è autonomo e funziona su qualsiasi sistema operativo (Windows, macOS, Linux) senza richiedere l’installazione di librerie o runtime aggiuntivi.

Il funzionamento è semplice: si scarica il file llamafile (che può pesare da pochi GB a diverse decine di GB a seconda del modello), si imposta il permesso di esecuzione e si avvia. Il file contiene al suo interno sia il motore di inferenza (basato su llama.cpp) sia i pesi del modello in formato GGUF. All’avvio, llamafile può operare in due modalità: come interfaccia a riga di comando per interazioni dirette, oppure come server API locale che espone un endpoint compatibile con il formato OpenAI, consentendo l’integrazione con applicazioni esterne.

Il vantaggio principale di llamafile è la portabilità estrema: un singolo file può essere copiato su una macchina, eseguito e rimosso senza lasciare tracce. Questo lo rende ideale per scenari di distribuzione rapida, demo, ambienti di test o situazioni in cui non si vuole (o non si può) installare software. È anche uno strumento didattico eccellente: chi vuole sperimentare con gli LLM locali può farlo senza dover apprendere la configurazione di runtime complessi.

Il limite è altrettanto evidente: ogni modello richiede un file separato, e la gestione di più modelli comporta la duplicazione del runtime per ciascuno di essi. Inoltre, la personalizzazione della configurazione (parametri di generazione, quantizzazione, backend GPU) è più limitata rispetto a Ollama o LM Studio, che offrono un controllo più granulare. Llamafile si posiziona quindi come strumento complementare: ideale per la distribuzione e la condivisione di modelli specifici, meno adatto come piattaforma di gestione centralizzata per workload diversificati.

MLX per Apple Silicon

MLX è il framework di apprendimento automatico sviluppato da Apple, progettato specificamente per sfruttare l’architettura dei chip Apple Silicon (M-series). A differenza di CUDA o ROCm, che sono ottimizzati per GPU discrete con memoria video dedicata, MLX è pensato per la memoria unificata dei chip Apple, dove CPU, GPU e Neural Engine condividono lo stesso spazio di memoria. Questa architettura consente di eseguire modelli di grandi dimensioni senza la frammentazione della memoria tipica delle GPU tradizionali.

Il vantaggio di MLX rispetto a llama.cpp su Apple Silicon è duplice. In primo luogo, MLX è ottimizzato nativamente per l’hardware Apple, il che si traduce in prestazioni superiori a parità di modello e quantizzazione. In secondo luogo, MLX supporta l’utilizzo della memoria unificata in modo più efficiente, consentendo di allocare dinamicamente la memoria tra CPU e GPU in base alle esigenze del workload. Questo significa che un Mac con 64 GB di memoria unificata può eseguire modelli che, su una workstation NVIDIA, richiederebbero due schede da 24 GB di VRAM.

L’integrazione di MLX in Ollama è un elemento chiave dell’ecosistema: su un Mac con chip M-series, Ollama utilizza automaticamente il backend MLX per l’inferenza, senza richiedere configurazioni manuali. Questo rende l’esperienza d’uso trasparente: l’utente interagisce con Ollama allo stesso modo su qualsiasi piattaforma, ma su Apple Silicon l’inferenza sfrutta il motore ottimizzato di MLX. Anche LM Studio supporta MLX, offrendo un’alternativa con interfaccia grafica per chi preferisce questo approccio.

Il runtime MLX è disponibile anche come libreria Python autonoma, il che consente agli sviluppatori di integrare l’inferenza locale nelle proprie applicazioni senza passare da Ollama o LM Studio. Questo livello di controllo è particolarmente utile per chi sviluppa applicazioni che richiedono un’integrazione profonda con il modello, come pipeline di elaborazione personalizzate o agenti con logica di orchestrazione complessa.

La scelta tra MLX e llama.cpp su Apple Silicon dipende dal caso d’uso: MLX offre prestazioni superiori e una migliore gestione della memoria, ma llama.cpp ha un ecosistema più ampio e una maggiore compatibilità con modelli e quantizzazioni specifiche. Per la maggior parte degli utenti, la decisione è già presa a monte: Ollama e LM Studio utilizzano MLX automaticamente su Apple Silicon, e l’utente può beneficiare dei vantaggi senza dover operare scelte tecniche. Per chi invece ha esigenze specifiche (ad esempio, l’esecuzione di un modello in una quantizzazione non supportata da MLX), llama.cpp rimane disponibile come alternativa.

Un’osservazione finale: l’ecosistema degli strumenti di esecuzione locale è in rapida evoluzione, e le differenze tra i vari strumenti tendono a ridursi nel tempo. Ollama sta integrando progressivamente il supporto a MLX e Vulkan, LM Studio aggiunge funzionalità di automazione, llamafile espande la compatibilità con i modelli. La scelta dello strumento dovrebbe quindi basarsi sulle esigenze immediate, ma anche sulla traiettoria di sviluppo di ciascun progetto, per evitare di investire tempo in uno strumento che potrebbe perdere rilevanza nel medio periodo.

Modelli locali performanti

Gemma 4 12B multimodale

Il modello Gemma 4 12B di Google rappresenta un punto di svolta per l’AI locale, combinando tre caratteristiche che lo rendono unico nel panorama attuale: è multimodale, è open-weight con licenza Apache 2.0, e può essere eseguito su hardware consumer con 16 GB di VRAM. Con 12 miliardi di parametri e una finestra di contesto di 256K token, questo modello colma il divario tra i modelli puramente testuali e le capacità multimodali che fino a poco tempo fa erano appannaggio esclusivo dei servizi cloud.

La multimodalità di Gemma 4 12B copre input visivi (immagini, diagrammi, screenshot), audio (trascrizione e analisi di file audio) e OCR (estrazione di testo da documenti scansionati). In un contesto professionale, questo significa che un singolo modello locale può processare fatture, contratti scansionati, screenshot di interfacce o registrazioni di riunioni, senza dover inviare dati a servizi esterni. La capacità di tool calling è nativa e viene ereditata automaticamente da runtime come Ollama, consentendo l’integrazione con agenti software per l’automazione di flussi di lavoro complessi.

Il modello è disponibile in formato GGUF per Ollama, LM Studio e llama.cpp, e in formato MLX per Apple Silicon. La quantizzazione Q4_K_M riduce il footprint di memoria a circa 7-8 GB di VRAM, rendendolo eseguibile su schede come RTX 3060/4060 con 12 GB di VRAM. Per chi dispone di 16 GB di VRAM (RTX 4080/4090), il modello può essere eseguito con una finestra di contesto significativa, sfruttando appieno i 256K token. Su Apple Silicon, un Mac con 24-32 GB di memoria unificata può eseguire Gemma 4 12B con prestazioni elevate grazie al backend MLX.

La scelta di Gemma 4 12B è particolarmente indicata per scenari che richiedono l’elaborazione di documenti misti (testo + immagini), l’analisi di screenshot di applicazioni o siti web, o la trascrizione e analisi di file audio. In questi casi, la multimodalità elimina la necessità di pipeline separate per OCR, estrazione testo e analisi, semplificando l’architettura e riducendo la latenza complessiva.

Qwen, DeepSeek, Mistral open-weight

L’ecosistema dei modelli open-weight si è ampliato in modo significativo, offrendo alternative valide e spesso specializzate rispetto ai modelli proprietari. Tre famiglie si distinguono per qualità, efficienza e disponibilità di formati GGUF: Qwen (Alibaba), DeepSeek e Mistral.

Qwen 2.5 (Alibaba) è disponibile in tagli da 0.5B, 1.5B, 7B, 14B, 32B e 72B parametri, coprendo l’intero spettro delle esigenze hardware. Il modello da 14B in Q4_K_M è un candidato eccellente per l’uso professionale su GPU con 16 GB di VRAM, offrendo qualità comparabile a Llama 3.1 8B su task di ragionamento e scrittura, ma con una finestra di contesto nativa di 128K token. Il modello da 32B richiede 24 GB di VRAM e rappresenta il punto di equilibrio per workload intensivi su singola GPU. Qwen 2.5 eccelle in task di codifica, ragionamento matematico e comprensione di documenti lunghi, grazie a un training specifico su dataset multilingue e di codice.

DeepSeek (DeepSeek, Cina) ha attirato l’attenzione per l’efficienza dei suoi modelli, in particolare DeepSeek-V2 e DeepSeek-Coder. Il modello DeepSeek-Coder-V2, con 16B parametri, è specializzato nella generazione e comprensione del codice, superando modelli di dimensioni doppie su benchmark di programmazione. La famiglia DeepSeek include modelli con architettura Mixture of Experts (MoE) che, pur avendo un numero totale di parametri elevato (ad esempio 236B totali), attivano solo una frazione dei parametri per ogni token, riducendo i requisiti di VRAM e accelerando l’inferenza. Per l’esecuzione locale, i modelli DeepSeek sono disponibili in formato GGUF con quantizzazioni che vanno da Q2_K a Q8_0, consentendo l’esecuzione su hardware con VRAM limitata a costo di una riduzione della qualità.

Mistral (Mistral AI, Francia) si distingue per l’attenzione all’efficienza e alla qualità su modelli di dimensioni contenute. Mistral 7B è stato a lungo lo standard di riferimento per l’uso su hardware consumer, offrendo prestazioni superiori a Llama 2 7B e comparabili a Llama 3 8B. Mistral Large (disponibile in versione open-weight con 123B parametri) è invece un modello di fascia alta che richiede architetture multi-GPU o Apple Silicon con memoria unificata molto ampia. Mistral ha inoltre rilasciato modelli specializzati per la codifica (Codestral) e per la comprensione di documenti (Mistral Embed), che possono essere integrati in pipeline RAG per migliorare la qualità del retrieval.

La scelta tra queste famiglie dipende dal caso d’uso specifico. Qwen 2.5 14B è la scelta più equilibrata per uso generale su GPU consumer. DeepSeek-Coder è preferibile per task di programmazione e analisi di codice. Mistral 7B rimane un’opzione solida per hardware con VRAM limitata (8 GB), offrendo un buon rapporto qualità/requisiti. Per applicazioni che richiedono finestre di contesto molto ampie (oltre 128K token), Qwen 2.5 è la scelta più robusta, grazie al training specifico su sequenze lunghe.

Modelli a 1-bit/ternari per efficienza

L’evoluzione più promettente per l’esecuzione locale di LLM è rappresentata dai modelli a parametri ternari, noti come "1-bit LLMs". L’articolo "The Era of 1-bit LLMs" (arXiv:2402.17764) ha dimostrato che è possibile rappresentare i pesi di un modello utilizzando solo tre valori (-1, 0, +1) invece dei tradizionali 16 o 32 bit in virgola mobile, riducendo il footprint di memoria di un fattore 4-8 rispetto alla quantizzazione Q4_K_M.

Il principio alla base di questi modelli è che l’informazione utile per l’inferenza è contenuta principalmente nel segno e nella magnitudine dei pesi, non nella loro precisione numerica. Utilizzando una rappresentazione ternaria, un modello da 70B parametri può essere memorizzato in circa 10 GB di memoria, contro i 40-50 GB richiesti da una quantizzazione Q4_K_M. Questo significa che modelli di dimensioni enterprise (70B+) diventano eseguibili su hardware consumer con 16-24 GB di VRAM, una prospettiva che cambia radicalmente il panorama dell’AI locale.

I modelli ternari non sono ancora disponibili su larga scala in formato GGUF, ma la ricerca è in fase avanzata e diversi progetti stanno lavorando all’implementazione pratica. BitNet b1.58 di Microsoft è un esempio di architettura ternaria che ha dimostrato prestazioni competitive su benchmark di ragionamento e comprensione del linguaggio, con un risparmio di memoria e un aumento di velocità significativi. Anche il progetto llama.cpp ha iniziato a esplorare il supporto per pesi ternari, sebbene non sia ancora disponibile in produzione.

L’impatto concreto per l’utente locale è duplice. Da un lato, la possibilità di eseguire modelli di grandi dimensioni su hardware consumer apre scenari di uso professionale che oggi richiedono workstation multi-GPU o server dedicati. Dall’altro, la riduzione del consumo energetico e della generazione di calore rende l’inferenza locale più sostenibile per workload continui, avvicinando l’esperienza d’uso a quella dei modelli via API in termini di velocità e reattività.

Per chi sta valutando l’acquisto di hardware oggi, la prospettiva dei modelli ternari suggerisce di privilegiare la quantità di VRAM rispetto alla potenza di calcolo pura: una GPU con 24 GB di VRAM sarà in grado di eseguire modelli ternari da 70B+ non appena saranno disponibili, mentre una GPU con 16 GB di VRAM potrebbe essere limitata a modelli da 30-40B. La memoria unificata di Apple Silicon offre in questo senso un vantaggio strutturale, consentendo di allocare fino a 128 GB di memoria per l’inferenza, sufficienti per modelli ternari di dimensioni enterprise.

Criteri di scelta

La selezione del modello locale più adatto si basa su un insieme di criteri che vanno oltre la semplice dimensione in parametri. La tabella seguente riassume i criteri decisionali per i casi d’uso più comuni.

Caso d’uso	Modello consigliato	VRAM minima	Note
Assistenza generale, chatbot, riassunti	Mistral 7B, Llama 3.1 8B, Qwen 2.5 7B	8 GB	Buona qualità su task semplici, eseguibile su hardware entry-level
Analisi documentale, estrazione informazioni	Gemma 4 12B, Qwen 2.5 14B	12-16 GB	Multimodalità per documenti misti, finestra di contesto ampia
Programmazione e codifica	DeepSeek-Coder-V2 16B, Qwen 2.5-Coder 14B	12-16 GB	Specializzati per codice, superano modelli generici di dimensioni doppie
Ragionamento complesso, matematica	Qwen 2.5 32B, Mistral Large 123B (ternario futuro)	24-48 GB	Richiedono hardware dedicato o multi-GPU, qualità prossima ai modelli commerciali
Automazione con agenti (tool calling)	Gemma 4 12B, Qwen 2.5 14B, Mistral 7B	8-16 GB	Supporto nativo tool calling, integrabile con Claude Code, Hermes Agent
Elaborazione batch, workload continui	Qwen 2.5 14B (Q4_K_M)	12-16 GB	Bilanciamento tra qualità e velocità, costo per token prossimo allo zero

I criteri di scelta si articolano su quattro dimensioni principali.

Dimensione del modello e VRAM disponibile: è il vincolo più stringente. La regola pratica è che un modello in Q4_K_M occupa circa 4 bit per parametro. Con 8 GB di VRAM si eseguono modelli fino a 9B; con 12-16 GB si sale a 12-14B; con 24 GB si arriva a 32B. Per modelli superiori, servono architetture multi-GPU o Apple Silicon con memoria unificata ampia. La quantizzazione Q4_K_M rappresenta il punto di equilibrio tra qualità e requisiti di memoria; scendere a Q3_K_M o Q2_K riduce il footprint del 20-30% ma con un calo evidente della qualità su task di ragionamento.

Multimodalità e tipologia di input: se il caso d’uso richiede l’elaborazione di immagini, audio o documenti scansionati, Gemma 4 12B è la scelta obbligata, essendo l’unico modello multimodale open-weight di dimensioni contenute. Per task puramente testuali, Qwen 2.5 14B offre una finestra di contesto più ampia (128K contro 256K di Gemma 4) e una qualità leggermente superiore su task di ragionamento.

Specializzazione del modello: per la codifica, DeepSeek-Coder-V2 e Qwen 2.5-Coder superano i modelli generalisti di dimensioni doppie. Per la comprensione di documenti lunghi, Qwen 2.5 14B è superiore grazie al training specifico su sequenze estese. Per la generazione di testo creativo, Mistral 7B e Llama 3.1 8B offrono risultati più naturali e meno ripetitivi.

Supporto a tool calling e agenti: se il modello deve essere integrato con agenti software (Claude Code, Hermes Agent, OpenClaw), è essenziale verificare la capacità di tool calling. Gemma 4 12B e Qwen 2.5 14B supportano nativamente questa funzionalità, che viene ereditata automaticamente da Ollama e LM Studio. La verifica si effettua con ollama show my-model, che elenca le capabilities del modello. Un modello senza tool calling è limitato a interazioni puramente testuali e non può invocare funzioni esterne, API o database.

La scelta finale deve considerare anche la traiettoria di sviluppo del modello. Qwen e Mistral hanno un track record di aggiornamenti frequenti e miglioramenti continui, mentre Gemma 4 è un modello di prima generazione che potrebbe evolvere rapidamente. DeepSeek ha dimostrato capacità di innovazione significative, ma la sua dipendenza da un’azienda cinese potrebbe sollevare questioni di affidabilità a lungo termine per organizzazioni europee o americane. In ogni caso, la disponibilità di modelli in formato GGUF garantisce la portabilità tra runtime e la possibilità di cambiare modello senza dover riconfigurare l’infrastruttura.

Integrazione con agenti e tool calling

Integrazione con agenti e tool calling

L’integrazione con agenti software e la capacità di tool calling rappresentano il salto qualitativo che trasforma un LLM locale da semplice chatbot a componente attivo di pipeline automatizzate. Un modello che può invocare funzioni esterne, interrogare API, leggere database e orchestrare flussi di lavoro complessi diventa un vero e proprio motore di automazione, e i runtime locali hanno ormai raggiunto un livello di maturità che rende questa integrazione pratica e affidabile.

MCP Server e integrazione strumenti

Il Model Context Protocol (MCP) si sta affermando come lo standard de facto per l’integrazione tra LLM e strumenti esterni. MCP definisce un protocollo uniforme che consente a un modello di scoprire, invocare e ricevere risultati da un insieme di tool esposti da un server MCP. L’architettura è simile a quella di un filesystem: il modello vede una gerarchia di risorse e strumenti disponibili, può esplorarli e invocarli tramite chiamate standardizzate, senza dover conoscere i dettagli implementativi di ciascun servizio.

Nel contesto dell’AI locale, MCP risolve un problema strutturale. Ogni agente o applicazione che vuole integrare il modello con strumenti esterni deve gestire la comunicazione con API diverse, formati di dati differenti e meccanismi di autenticazione eterogenei. MCP astrae questa complessità: un singolo server MCP può esporre al modello una serie di strumenti (ricerca documentale, interrogazione database, invio email, chiamate API REST) e il modello li invoca con una sintassi uniforme. Questo approccio riduce drasticamente il codice di integrazione necessario e rende l’architettura modulare: aggiungere un nuovo strumento significa estendere il server MCP, non modificare l’agente.

L’integrazione con i runtime locali è già operativa. Ollama, ad esempio, supporta il lancio di agenti come Claude Code, Hermes Agent e OpenClaw tramite il comando ollama launch, che instrada automaticamente le richieste del modello verso il server MCP configurato. Il modello locale diventa quindi il cervello dell’agente, mentre il server MCP fornisce le mani: accesso a file, API, database, servizi di automazione. La verifica della compatibilità con MCP si effettua controllando le capabilities del modello con ollama show my-model: se il modello supporta tool calling, l’integrazione con MCP funziona senza configurazioni aggiuntive.

Per scenari più articolati, la configurazione di un server MCP dedicato consente di centralizzare l’accesso agli strumenti aziendali. Un’organizzazione può esporre tramite MCP i propri sistemi gestionali, i database documentali, i servizi di posta elettronica e le API interne, rendendoli disponibili a qualsiasi agente basato su LLM, locale o cloud. Questo approccio ha un duplice vantaggio: da un lato, la logica di integrazione è scritta una volta sola e riutilizzata da tutti gli agenti; dall’altro, le policy di sicurezza e autenticazione sono gestite centralmente nel server MCP, riducendo il rischio di esposizione accidentale di credenziali o dati sensibili.

Tool calling nei modelli locali

La capacità di tool calling—ovvero la capacità del modello di generare chiamate strutturate a funzioni esterne durante la generazione del testo—è ormai una funzionalità standard nei modelli open-weight di fascia media. Gemma 4 12B e Qwen 2.5 14B supportano nativamente questa funzionalità, e la supportano anche modelli più piccoli come Mistral 7B. Il meccanismo funziona in modo simile su tutti i runtime: il modello riceve in input la descrizione degli strumenti disponibili (nome, parametri, descrizione) e, quando necessario, genera una chiamata strutturata che il runtime intercetta e instrada verso lo strumento corrispondente.

La qualità del tool calling varia significativamente tra modelli. I modelli addestrati specificamente per questa funzionalità (come Gemma 4 e Qwen 2.5) generano chiamate corrette e ben formate anche su task complessi, con tassi di errore contenuti. Modelli generalisti non ottimizzati per il tool calling tendono invece a produrre chiamate malformate o a dimenticare parametri obbligatori, richiedendo logiche di validazione e retry più robuste. La scelta del modello per applicazioni basate su agenti dovrebbe quindi tenere conto della qualità del tool calling come criterio primario, non secondario.

Un aspetto pratico rilevante è la gestione del contesto. Quando un agente interagisce con più strumenti in sequenza, il contesto della conversazione si arricchisce dei risultati delle chiamate, che possono essere lunghi e articolati. La finestra di contesto del modello diventa quindi un fattore critico: modelli con 128K o 256K token di contesto (come Qwen 2.5 e Gemma 4) possono gestire sequenze operative lunghe, mentre modelli con contesto limitato (8K-32K) rischiano di perdere informazioni rilevanti nel corso dell’interazione. Per agenti complessi che eseguono molteplici chiamate a strumenti in sequenza, la finestra di contesto è spesso più importante della dimensione del modello.

La verifica della capacità di tool calling di un modello GGUF si effettua con ollama show my-model, che elenca le capabilities supportate. Se il modello non supporta il tool calling, l’integrazione con agenti e server MCP non funziona, e il modello può essere utilizzato solo per interazioni testuali dirette. È importante verificare questa caratteristica prima di investire tempo nell’integrazione, poiché non tutti i modelli open-weight supportano questa funzionalità.

Best practice di integrazione

L’integrazione di LLM locali con agenti e strumenti esterni richiede un approccio metodico che bilanci flessibilità, robustezza e sicurezza. Le pratiche che seguono derivano dall’esperienza operativa su scenari reali e sono applicabili a contesti che vanno dal singolo sviluppatore all’organizzazione enterprise.

Partire da un modello con tool calling nativo: la scelta del modello è il primo fattore critico. Modelli come Gemma 4 12B e Qwen 2.5 14B hanno il tool calling integrato nel training e producono chiamate ben formate con alta affidabilità. Utilizzare un modello generalista senza tool calling nativo richiede l’implementazione di logiche di parsing e validazione delle chiamate, aumentando la complessità e il tasso di errore. Per applicazioni basate su agenti, il tool calling nativo non è un optional ma un requisito.

Configurare il server MCP come strato di astrazione: invece di integrare l’agente direttamente con le API dei singoli servizi, esporre gli strumenti tramite un server MCP centralizzato. Questo approccio separa la logica di orchestrazione (nell’agente) dalla logica di integrazione (nel server MCP), rendendo il sistema modulare e manutenibile. L’aggiunta di un nuovo strumento richiede solo l’estensione del server MCP, senza modifiche all’agente. La centralizzazione facilita anche la gestione delle credenziali e delle policy di accesso.

Validare e sanitizzare gli input degli strumenti: quando un agente invoca uno strumento, i parametri della chiamata provengono dal modello e possono contenere errori, formati inattesi o valori malevoli. È buona pratica validare i parametri lato server prima di eseguire l’azione, verificando tipi, range e vincoli. La sanitizzazione degli input è particolarmente critica per strumenti che eseguono operazioni irreversibili (invio email, scrittura su database, esecuzione di comandi). Un approccio difensivo prevede che lo strumento richieda conferma esplicita per operazioni distruttive o che l’agente operi in modalità "dry-run" durante le fasi di test.

Gestire il contesto con strategie di trimming e riepilogo: le interazioni con più strumenti in sequenza tendono a saturare la finestra di contesto. È necessario implementare strategie di gestione del contesto: riepiloghi periodici delle interazioni precedenti, rimozione selettiva di messaggi meno rilevanti, o suddivisione di task complessi in sotto-task con contesto dedicato. Modelli con finestre di contesto ampie (128K+) offrono maggiore margine, ma non eliminano la necessità di una gestione attenta. La qualità delle risposte degrada quando il contesto si avvicina al limite, e i modelli tendono a "dimenticare" dettagli delle interazioni precedenti.

Implementare retry e fallback: le chiamate a strumenti esterni possono fallire per molteplici ragioni: timeout, errori di rete, dati mancanti, permessi insufficienti. L’agente dovrebbe gestire questi fallimenti in modo robusto, con logiche di retry (con backoff esponenziale) e fallback (ad esempio, un modello più piccolo per task semplici, o un modello cloud per task che richiedono capacità superiori). La strategia di fallback è particolarmente rilevante in un contesto di "Sovranità Elastica", dove il modello locale rappresenta il livello base e i modelli cloud sono utilizzati solo quando necessario.

Monitorare le performance e i costi: l’integrazione con agenti aumenta il volume di richieste al modello e, di conseguenza, i tempi di risposta e il consumo di risorse. È importante monitorare la latenza delle chiamate, il throughput del modello e l’utilizzo della VRAM, per identificare colli di bottiglia e dimensionare correttamente l’hardware. In un contesto di workload continui, la scelta di un modello più piccolo ma sufficiente per il task può fare la differenza in termini di esperienza d’uso e sostenibilità del sistema.

Testare con scenari realistici: prima di mettere in produzione un agente, è essenziale testarlo con scenari realistici che coprano i casi d’uso principali e i casi limite. I test dovrebbero verificare non solo la correttezza delle risposte, ma anche la robustezza del sistema in condizioni di errore, la gestione del contesto su interazioni lunghe e il comportamento con input inattesi. Un agente ben testato riduce il rischio di comportamenti imprevisti in produzione e facilita la manutenzione successiva.

Documentare le capabilities e i limiti del sistema: ogni agente basato su LLM locale ha capacità e limiti specifici, determinati dal modello, dalla finestra di contesto, dagli strumenti disponibili e dalla configurazione hardware. Documentare questi aspetti è essenziale per gli utenti del sistema e per chi lo mantiene: cosa può fare l’agente, cosa non può fare, come si comporta in situazioni di errore, quali sono i tempi di risposta attesi. Una documentazione chiara riduce le aspettative errate e facilita il troubleshooting.

La combinazione di LLM locali con tool calling e server MCP apre scenari applicativi che fino a poco tempo fa richiedevano infrastrutture cloud dedicate. Un agente che può leggere documenti, interrogare database, inviare email e interagire con API interne, il tutto eseguito su hardware locale con dati che non lasciano mai il perimetro aziendale, rappresenta un salto qualitativo nell’automazione dei processi. La maturità dei runtime (Ollama, LM Studio, llamafile), la disponibilità di modelli con tool calling nativo e lo standard MCP rendono questa architettura non solo fattibile ma anche mantenibile nel tempo.

Casi d’uso e scenari reali

Il panorama applicativo per gli LLM locali si è ampliato ben oltre la semplice chat o il riassunto di testo. I casi d’uso reali che seguono illustrano come l’inferenza locale, combinata con modelli multimodali, tool calling e server MCP, risolva problemi concreti in contesti professionali e operativi. I punti descritti sono il frutto dell’incrocio tra le capacità tecniche emerse nelle sezioni precedenti (modelli come Gemma 4 12B, runtime come Ollama, protocollo MCP) e le esigenze operative di chi deve gestire dati sensibili, lavorare in mobilità o offrire servizi a terzi.

Parsing documenti e certificati

L’elaborazione di documenti misti—fatture, contratti, cartelle cliniche, certificati—rappresenta uno dei casi d’uso più immediati e ad alto ritorno per un LLM locale. Il vantaggio competitivo in questo scenario è duplice: la riservatezza dei dati trattati e la multimodalità. Un modello come Gemma 4 12B, eseguibile su una workstation con 16 GB di VRAM, è in grado di processare immagini, applicare OCR su documenti scansionati ed estrarre informazioni strutturate senza che il documento lasci mai il perimetro aziendale.

L’architettura tipica per questa pipeline è lineare e non richiede agenti complessi. Il documento (PDF, immagine, screenshot) viene passato al modello multimodale, che genera un output strutturato—ad esempio JSON con campi come numero fattura, data, importo, fornitore. Il tool calling nativo di Gemma 4 12B consente di instradare l’output direttamente verso un database o un sistema gestionale tramite un server MCP, eliminando la necessità di un passaggio intermedio di validazione umana per i casi non ambigui.

Il caso dei certificati è emblematico. Un ente certificatore o uno studio professionale che riceve centinaia di certificati al giorno (di conformità, di origine, sanitari) può utilizzare un modello locale per estrarre i campi chiave—numero di certificato, data di rilascio, ente emittente, oggetto—e confrontarli con un database di riferimento per verifiche di autenticità o scadenze. La finestra di contesto di 256K token di Gemma 4 12B consente di processare documenti molto lunghi in un’unica passata, mantenendo la coerenza tra le informazioni estratte all’inizio e alla fine del documento.

Il risparmio rispetto alle API cloud non è solo economico ma anche procedurale. L’elaborazione batch di documenti, che su API comporterebbe un costo per token crescente e la trasmissione di dati sensibili a server terzi, diventa un’operazione interna con costo marginale prossimo allo zero dopo l’ammortamento dell’hardware. La latenza, per workload batch, non è un fattore critico: un modello da 12-14B in Q4_K_M processa un documento di 10 pagine in tempi nell’ordine dei minuti, accettabili per una pipeline notturna o per un’elaborazione asincrona.

RAG su wiki locale vs fine-tuning

La scelta tra Retrieval-Augmented Generation (RAG) su una wiki locale e fine-tuning del modello è tra le decisioni architetturali più importanti per chi adotta LLM locali. Le due tecniche rispondono a esigenze diverse e non sono mutuamente esclusive; comprenderne i confini evita costosi errori di progettazione.

Il RAG su wiki locale è la soluzione più flessibile e meno costosa per fornire al modello conoscenze aggiornate e specifiche del dominio. Il funzionamento è noto: i documenti della wiki vengono segmentati, indicizzati in un database vettoriale e recuperati al momento della query per arricchire il contesto del modello. Il vantaggio strutturale rispetto al fine-tuning è l’assenza di riaddestramento: quando un documento viene aggiunto, modificato o rimosso dalla wiki, l’indicizzazione viene aggiornata e il comportamento del modello cambia di conseguenza, senza dover toccare i pesi del modello. Questa caratteristica rende il RAG la scelta obbligata per knowledge base in continuo aggiornamento, come manuali tecnici, procedure aziendali, normative.

Il fine-tuning, al contrario, incide sulla "personalità" del modello—il suo stile di risposta, la sua capacità di seguire formati specifici di output, la sua padronanza di un lessico tecnico particolare. Se l’obiettivo è che il modello risponda sempre in un certo formato (ad esempio, JSON con campi obbligatori per l’integrazione con un sistema gestionale) o che adotti un tono e uno stile definiti da linee guida aziendali, il fine-tuning su un dataset di poche centinaia di esempi può essere più efficace del RAG, che non modifica il comportamento intrinseco del modello ma solo il contesto disponibile.

La scelta pratica si articola su tre scenari. Per una wiki aziendale in evoluzione, il RAG è la scelta naturale: costi di implementazione contenuti (un database vettoriale, un modello di embedding, la pipeline di chunking), aggiornabilità immediata e trasparenza sulle fonti. Per un modello che deve generare output in un formato rigido e ripetitivo (estrazione dati, classificazione, generazione di report standardizzati), il fine-tuning su un dataset di esempi curati produce risultati più affidabili del RAG, che può introdurre variazioni indesiderate nell’output. Il terzo scenario, il più avanzato, combina le due tecniche: fine-tuning per insegnare al modello il formato e lo stile, RAG per fornire la conoscenza aggiornata. Questa architettura ibrida è quella che produce i risultati migliori in contesti professionali, ma richiede competenze e risorse per la gestione di entrambe le componenti.

Assistente offline per tecnici di campo

Uno dei casi d’uso più convincenti per l’AI locale è l’assistente offline per tecnici di campo. In questo scenario, l’operatore si trova in un ambiente senza connettività affidabile—un cantiere, una sala server remota, una zona industriale—e deve consultare manuali, diagnosticare guasti, seguire procedure di manutenzione o compilare report. La dipendenza da API cloud renderebbe lo strumento inutilizzabile in queste condizioni; un LLM locale, eseguito su un laptop con GPU o su un mini-PC ruggedizzato, garantisce la continuità operativa.

L’architettura ideale combina un modello di dimensioni contenute (7-9B in Q4_K_M, eseguibile su CPU con 16 GB di RAM o su una GPU entry-level) con una knowledge base locale in formato RAG. I manuali tecnici, le schede di sicurezza, gli schemi elettrici e le procedure operative vengono pre-caricati sul dispositivo e indicizzati localmente. Il tecnico interagisce con l’assistente in linguaggio naturale: descrive il sintomo, il modello recupera i passaggi rilevanti dai manuali e genera una procedura di diagnostica passo-passo. La multimodalità di modelli come Gemma 4 12B aggiunge un livello ulteriore: il tecnico può fotografare un componente o un quadro elettrico, e il modello analizza l’immagine per identificare il modello del componente o evidenziare anomalie visibili.

L’aspetto cruciale è la progettazione dell’interazione. In un contesto operativo, il tecnico non può permettersi di attendere risposte lente o di correggere errori di comprensione. Il sistema deve quindi essere progettato per minimizzare la latenza percepita: modelli piccoli e quantizzati in modo aggressivo (Q3_K_M o Q2_K) possono ridurre i tempi di risposta a scapito della qualità, ma in molti task operativi—recupero di una procedura, identificazione di un componente da foto—la qualità di un modello da 7-9B è sufficiente. La gestione del contesto è altrettanto critica: l’assistente deve mantenere la memoria della sessione di lavoro (quale componente si sta riparando, quali passaggi sono già stati eseguiti) senza saturare la finestra di contesto, utilizzando strategie di riepilogo periodico delle interazioni.

Il report finale dell’intervento può essere generato dal modello stesso, in formato strutturato per l’integrazione con il sistema gestionale una volta ripristinata la connettività. Anche in questo caso, il tool calling nativo consente al modello di compilare un modulo standardizzato o di aggiornare un database locale, che verrà sincronizzato con il server centrale al rientro in sede.

Modello di business VPS per cliente

L’evoluzione dell’hardware e dei runtime ha reso economicamente sostenibile un modello di business che fino a pochi anni fa era prerogativa dei grandi fornitori cloud: la vendita di una Virtual Private Server (VPS) configurata con un LLM preinstallato e ottimizzato per le esigenze del cliente. Questo scenario trasforma l’infrastruttura AI locale in un servizio a valore aggiunto, con margini interessanti per il fornitore e vantaggi concreti per il cliente.

L’architettura di riferimento è una VPS con GPU dedicata (o anche solo CPU potente, a seconda dei modelli coinvolti), sulla quale sono preinstallati un runtime (Ollama o LM Studio) e un set di modelli open-weight selezionati in base al dominio del cliente. La configurazione include un server MCP che espone al cliente gli strumenti necessari per il suo caso d’uso: accesso al database documentale, API verso il sistema gestionale, servizi di posta. Il risultato è un’infrastruttura "chiavi in mano" che il cliente può utilizzare senza competenze tecniche specifiche.

Le varianti di questo modello di business sono tre, e la scelta dipende dal posizionamento del fornitore e dal tipo di cliente.

Variante condivisa: più clienti condividono la stessa infrastruttura hardware, con modelli isolati tramite container o namespace. Il vantaggio è il costo contenuto per il cliente, che paga una quota mensile proporzionale al proprio utilizzo. Il limite è la contendibilità delle risorse: un cliente con workload intensivi può degradare le performance degli altri. Questa variante è adatta a PMI con esigenze moderate e budget limitati.

Variante CPU-only: il fornitore utilizza una VPS senza GPU, sfruttando l’inferenza su CPU con modelli quantizzati (7-14B in Q4_K_M). I costi di infrastruttura sono minimi, ma le prestazioni sono limitate (5-15 token al secondo su modelli da 7-13B). Adeguata per task non interattivi: elaborazione batch, generazione di report, estrazione dati da documenti. La latenza non è un problema per workload asincroni, e il costo per il cliente può essere significativamente inferiore rispetto a una VPS con GPU.

Variante pre-fine-tunato: il fornitore esegue un fine-tuning del modello sui dati del cliente—procedure operative, lessico tecnico, formato dei report—prima di consegnare la VPS. Il modello risultante è più efficace del modello base per i task specifici del cliente, ma il fine-tuning è un’operazione che richiede competenze e tempo. Questa variante si posiziona nel segmento alto del mercato, con margini più elevati e contratti di durata maggiore, e rappresenta la modalità più diretta per applicare le tecniche di fine-tuning descritte in precedenza al caso d’uso di un singolo cliente.

Lo scenario concreto che emerge con chiarezza è quello di uno studio legale. Un modello come Qwen 2.5 14B in Q4_K_M, eseguito su una VPS con GPU da 24 GB di VRAM, può gestire l’analisi di contratti, la ricerca di giurisprudenza (in combinazione con un database locale), la redazione di bozze di pareri e l’estrazione di informazioni da fascicoli. Il fine-tuning su un dataset di modelli di contratto e stile di redazione dello studio rende il modello significativamente più efficace su questi task. Per lo studio legale, i vantaggi sono evidenti: i dati dei clienti restano su un’infrastruttura dedicata, non transitano su API americane e non possono essere oggetto di richieste da parte di autorità straniere; il costo mensile della VPS è prevedibile e ammortizzabile, a differenza del conto API che cresce linearmente con l’utilizzo. Per il fornitore, il margine deriva dalla differenza tra il costo dell’infrastruttura (hardware ammortizzato, energia, connettività) e il canone mensile applicato al cliente, che include il valore del fine-tuning e della manutenzione.

Gli scenari futuri di questo modello di business si articolano su tre traiettorie. Nello scenario ottimistico, i progressi nei modelli ternari a 1-bit e l’abbassamento dei requisiti hardware (modelli da 70B eseguibili su GPU consumer) rendono i modelli locali competitivi con i colossi cloud su tutti i fronti, e il mercato delle VPS con LLM si espande a macchia d’olio. Nello scenario realistico, l’adozione procede gradualmente, concentrata su settori regolamentati (legale, sanitario, pubblico) e su organizzazioni con requisiti stringenti di privacy, che rappresentano il mercato naturale per questa offerta. Nello scenario pessimistico, la pressione al ribasso sui prezzi delle API cloud e la continua espansione delle capacità dei modelli commerciali erodono il vantaggio competitivo dei modelli locali, e il modello di business si concentra su una nicchia di clienti con esigenze estreme di sovranità digitale, disposti a pagare un premio per l’indipendenza dai fornitori cloud.

Strategia di sovranità elastica

La strategia di sovranità elastica si fonda su un principio operativo: nessun fornitore, nessuna infrastruttura e nessun modello deve diventare un punto di dipendenza critico. L’obiettivo è costruire un sistema che possa adattare il proprio livello di autonomia in base al contesto—disponibilità di rete, sensibilità dei dati, costo del calcolo, scenario geopolitico—senza richiedere riprogettazioni architetturali. Questa strategia si articola su tre dimensioni: l’architettura a livelli che separa edge, on-premise e cloud; la matrice decisionale che guida la scelta tra modelli americani, cinesi e ibridi; e la gestione dei rischi specifici di ciascuna opzione.

Architettura a livelli (edge, on-premise, cloud)

L’architettura proposta organizza l’infrastruttura di inferenza in tre livelli distinti, ciascuno con un proprio ruolo, vincoli e modalità di attivazione. La separazione non è gerarchica ma funzionale: ogni livello può operare in autonomia, e la transizione tra livelli avviene in base a regole definite, non a decisioni umane in tempo reale.

Livello edge: è il livello più vicino all’utente e al dato. Esegue su hardware locale—laptop, mini-PC, workstation, dispositivo mobile—con modelli di dimensioni contenute (7-14B in Q4_K_M, fino a 32B su hardware dedicato). Il suo ruolo è garantire la continuità operativa in assenza di connettività, per task a bassa latenza (assistente offline per tecnici di campo, parsing documentale in mobilità, chatbot locale) e per il trattamento di dati che non possono lasciare il dispositivo per ragioni di riservatezza o normativa. L’edge è il livello predefinito per il 70-80% delle interazioni quotidiane in uno scenario professionale tipico. La scelta del modello per l’edge deve privilegiare l’efficienza: modelli come Gemma 4 12B (multimodale, tool calling nativo, finestra 256K) o Qwen 2.5 14B rappresentano il punto di equilibrio ottimale, eseguibili su GPU con 16 GB di VRAM o su Apple Silicon con 24 GB di memoria unificata. La gestione del livello edge è completamente autonoma: non dipende da infrastrutture esterne per funzionare, e i dati non lasciano mai il dispositivo.

Livello on-premise: è il livello intermedio, eseguito su server dedicati all’interno del perimetro aziendale o su VPS con GPU dedicata fornita da un partner di fiducia. Il suo ruolo è gestire workload che superano le capacità dell’edge—modelli più grandi (32-70B), elaborazione batch di volumi elevati di documenti, fine-tuning periodico, knowledge base RAG con indicizzazione centralizzata. L’on-premise opera in modo indipendente dalla connettività esterna: può sincronizzarsi con il cloud per aggiornamenti o per task che richiedono capacità superiori, ma non ne dipende per il funzionamento quotidiano. È il livello in cui si applica il modello di business VPS per cliente descritto in precedenza: il fornitore gestisce l’infrastruttura, il cliente mantiene il controllo dei dati e della configurazione. La scelta hardware per l’on-premise deve privilegiare la VRAM e la flessibilità: GPU con 24-48 GB di VRAM (RTX 4090/5090, A5000) o Apple Silicon con 64-128 GB di memoria unificata per modelli fino a 70B.

Livello cloud: è il livello di riserva, attivato solo quando i livelli edge e on-premise non sono sufficienti—per task che richiedono modelli di dimensioni enterprise (oltre 70B), per accesso a modelli multimodali di ultima generazione non ancora disponibili in formato open-weight, o per picchi di carico imprevedibili. Il cloud opera con API di fornitori terzi (OpenAI, Anthropic, Google, o fornitori europei come Mistral AI) e deve essere configurato con criteri stringenti di routing dei dati: solo i task autorizzati e solo i dati non sensibili possono transitare su questo livello. L’attivazione del cloud deve essere esplicita e tracciata, non automatica per default: un meccanismo di escalation che, superata una soglia di complessità o di carico, richiede conferma umana prima di instradare la richiesta verso l’esterno.

La transizione tra livelli segue regole definite in fase di progettazione. Un task di analisi documentale parte dall’edge se il documento è di dimensioni contenute e il modello locale è sufficiente; se il documento supera una soglia di complessità o lunghezza, viene reindirizzato all’on-premise; solo se il task richiede capacità non disponibili nei modelli locali (ad esempio, analisi video complessa o generazione di codice in un linguaggio specializzato) viene attivato il cloud. Questo approccio garantisce che il 90-95% delle interazioni rimanga all’interno dei primi due livelli, riducendo al minimo la dipendenza da fornitori esterni e i costi variabili delle API.

Matrice decisionale AI americane vs cinesi vs ibride

La scelta del modello open-weight non è neutrale e comporta implicazioni geopolitiche, di sicurezza e di affidabilità a lungo termine. La matrice decisionale che segue fornisce criteri operativi per orientarsi tra le tre categorie, basandosi su fattori verificabili e non su percezioni o pregiudizi.

Modelli americani (Meta Llama, Google Gemma, Mistral AI): il vantaggio principale è l’ecosistema consolidato, la documentazione estesa e la tracciabilità del training. I modelli di Meta (Llama 3.1, Llama 4) e Google (Gemma 4) sono rilasciati con licenze permissive (Apache 2.0 per Gemma, licenza Llama personalizzata per Meta) e hanno un track record di aggiornamenti regolari e supporto della comunità. Mistral AI, pur essendo francese, opera in un contesto normativo europeo e offre garanzie di conformità al GDPR che i modelli cinesi non possono eguagliare. Il rischio principale è la revocabilità della licenza o la modifica delle condizioni d’uso, come già accaduto con alcuni modelli Meta in passato. Per organizzazioni europee o americane con requisiti stringenti di conformità normativa, i modelli americani (e europei) rappresentano la scelta più sicura dal punto di vista legale.

Modelli cinesi open-weight (Qwen, DeepSeek, Yi): il vantaggio è l’efficienza e la qualità spesso superiore a parità di dimensioni, frutto di investimenti massicci e di una competizione interna molto agguerrita. Qwen 2.5 14B supera Llama 3.1 8B su molti benchmark, e DeepSeek-Coder-V2 è lo stato dell’arte per la generazione di codice tra i modelli open-weight. Il rischio principale è duplice: da un lato, la possibilità di backdoor o bias incorporati nel training, difficili da rilevare senza un’analisi approfondita dei dataset e dei pesi; dall’altro, il rischio geopolitico di restrizioni all’export o di kill switch attivati da decisioni governative cinesi. La licenza di questi modelli è generalmente permissiva (Apache 2.0 per Qwen, licenza DeepSeek per DeepSeek), ma la giurisdizione cinese rende complessa qualsiasi azione legale in caso di violazione dei termini. Per task non critici e per ambienti in cui il rischio di backdoor è accettabile (ad esempio, prototipazione, ricerca, task senza dati sensibili), i modelli cinesi offrono il miglior rapporto qualità/costo. Per workload che coinvolgono dati sensibili o processi critici, il rischio è troppo elevato e la scelta deve cadere su modelli americani o europei.

Modelli ibridi: la strategia più robusta prevede l’utilizzo di modelli cinesi per task non critici (generazione di codice, riassunti, bozze) e modelli americani/europei per task che coinvolgono dati sensibili o decisioni con impatto legale o finanziario. Questa separazione deve essere implementata a livello di routing delle richieste, non di scelta manuale: il sistema instrada automaticamente i task verso il modello appropriato in base a policy definite (tipo di dato, contesto, livello di confidenza richiesto). L’architettura ibrida richiede la gestione di due ecosistemi di modelli, con aggiornamenti e validazioni separate, ma offre il vantaggio di massimizzare l’efficienza senza compromettere la sicurezza. In uno scenario di tensione geopolitica crescente, l’ibrido consente di disattivare selettivamente l’accesso ai modelli cinesi senza interrompere i flussi di lavoro che utilizzano modelli americani.

La matrice decisionale si applica anche alla scelta del fornitore cloud per il livello di riserva. Per il cloud, la scelta tra fornitori americani (OpenAI, Anthropic, Google), cinesi (Alibaba Cloud, Tencent) o europei (Mistral AI, Aleph Alpha) segue gli stessi criteri, con un livello di rischio aggiuntivo legato alla giurisdizione dei dati: un modello eseguito su API americane è soggetto al Cloud Act e può essere oggetto di richieste da parte di autorità statunitensi, indipendentemente dalla localizzazione fisica del server. Per organizzazioni europee, l’utilizzo di fornitori cloud europei (o l’esecuzione su infrastruttura on-premise) è l’unica opzione che garantisce la piena conformità al GDPR per i dati sensibili.

Gestione dei rischi (backdoor, bias, revocabilità)

La gestione dei rischi associati ai modelli open-weight richiede un approccio sistematico che copra l’intero ciclo di vita del modello, dalla selezione alla messa in produzione, fino al monitoraggio continuo.

Backdoor e sicurezza dei pesi: il rischio di backdoor—codice malevolo o comportamenti indesiderati incorporati nei pesi del modello durante il training—è reale e documentato. La ricerca di Anthropic ha dimostrato che un numero ridotto di campioni di training può introdurre backdoor persistenti in modelli di qualsiasi dimensione, difficili da rimuovere con il fine-tuning tradizionale. Per mitigare questo rischio, la strategia operativa prevede tre azioni: (1) utilizzare solo modelli provenienti da fonti verificate e con un track record di sicurezza (Hugging Face con verifiche della comunità, repository ufficiali dei fornitori); (2) eseguire una validazione iniziale del modello su un set di test progettato per rilevare comportamenti anomali, prima di metterlo in produzione; (3) per task critici, preferire modelli il cui training è documentato in modo trasparente e i cui dataset sono pubblici e verificabili. La validazione non può essere delegata a strumenti automatici: richiede un’analisi umana dei comportamenti del modello in scenari limite, con particolare attenzione a task che coinvolgono comandi di sistema, accesso a dati sensibili o decisioni con impatto legale.

Bias e allineamento: ogni modello incorpora bias derivanti dai dati di training e dalle scelte di allineamento dei suoi creatori. I modelli cinesi tendono a riflettere la narrativa del Partito Comunista Cinese su temi come Taiwan, Xinjiang e diritti umani; i modelli americani riflettono i valori e le priorità delle aziende che li hanno addestrati, con un focus sulla sicurezza e sull’evitamento di contenuti controversi che può limitare l’utilità in contesti professionali. La gestione del bias non consiste nell’eliminarlo (impresa impossibile) ma nel conoscerlo e nel compensarlo. Per task in cui il bias è irrilevante (estrazione dati, generazione di codice, riassunti fattuali), il problema non si pone. Per task in cui il bias può influenzare il risultato (analisi giuridica, valutazione di conformità, redazione di documenti con implicazioni politiche), è necessario utilizzare modelli il cui allineamento è noto e documentato, e prevedere un livello di revisione umana per le decisioni critiche. L’approccio più robusto è l’utilizzo di modelli specializzati per dominio, addestrati su dataset specifici del settore, che riducono l’impatto dei bias generalisti.

Revocabilità e continuità del servizio: il rischio più concreto per chi adotta modelli open-weight è la revocabilità della licenza o la cessazione del supporto da parte del fornitore. Meta ha già modificato i termini di licenza di Llama tra versioni successive, e un fornitore cinese potrebbe essere costretto a ritirare i propri modelli dal mercato internazionale in seguito a direttive governative. La strategia di mitigazione si basa su tre pilastri. (1) Diversificazione: non dipendere da un unico fornitore o famiglia di modelli. Mantenere in inventario almeno due modelli alternativi per ogni fascia di dimensioni, preferibilmente di fornitori diversi (ad esempio, Qwen 2.5 14B e Gemma 4 12B come alternative intercambiabili per la fascia media). (2) Congelamento dei pesi: una volta scaricato e verificato un modello, conservare i pesi in un repository locale, indipendentemente dalla disponibilità futura sul repository originale. Il modello continuerà a funzionare anche se il fornitore lo ritira o ne modifica la licenza. (3) Pianificazione delle migrazioni: definire in anticipo i criteri e le procedure per la sostituzione di un modello, inclusi i test di validazione, la migrazione dei prompt e la riconfigurazione delle pipeline. La migrazione non deve essere un evento traumatico ma un’operazione pianificata, con tempi e risorse allocate.

Kill switch e dipendenza da fornitori cloud: per il livello cloud, il rischio di kill switch—la disattivazione improvvisa del servizio per decisione del fornitore o per eventi geopolitici—è reale e ha precedenti storici. La strategia di mitigazione per il cloud è strutturale: il cloud deve essere configurato come livello di riserva, non come livello primario. Se il fornitore cloud diventa indisponibile, il sistema continua a funzionare sui livelli edge e on-premise, con una possibile riduzione della qualità o della velocità delle risposte ma senza interruzione del servizio. Per i task che dipendono esclusivamente dal cloud (modelli di dimensioni enterprise non disponibili in locale), è necessario prevedere un piano di fallback che utilizzi modelli più piccoli ma sufficienti per il task, o che accetti una latenza maggiore in attesa del ripristino del servizio.

La gestione dei rischi non è un’attività una tantum ma un processo continuo, che richiede monitoraggio, aggiornamento delle policy e formazione del personale. In un contesto di tensione geopolitica crescente e di evoluzione rapidissima del panorama dei modelli, l’organizzazione che adotta la strategia di sovranità elastica deve investire nella competenza di valutare e gestire questi rischi, non solo nella capacità tecnica di eseguire modelli in locale.

Raccomandazioni pratiche

Roadmap di implementazione

L’adozione di un’infrastruttura basata su LLM locali non è un evento puntuale ma un percorso graduale, che richiede di bilanciare investimenti, competenze e obiettivi. La roadmap proposta si articola in quattro fasi, ciascuna con obiettivi misurabili e criteri di avanzamento alla fase successiva.

Fase 1 – Valutazione e setup iniziale (1-2 settimane)

L’obiettivo è allestire un ambiente di test funzionante su hardware esistente, senza investimenti aggiuntivi. Si installa un runtime (Ollama o LM Studio) su una workstation con almeno 16 GB di RAM e, se disponibile, una GPU con 8-12 GB di VRAM. Si scaricano due modelli di riferimento: uno per la fascia bassa (Mistral 7B o Llama 3.1 8B in Q4_K_M) e uno per la fascia media (Qwen 2.5 14B o Gemma 4 12B in Q4_K_M). Si esegue una batteria di test su task rappresentativi del proprio dominio: riassunto di documenti, estrazione di informazioni strutturate, generazione di bozze, risposta a domande su una knowledge base locale. I criteri di avanzamento sono: latenza di risposta inferiore a 10 secondi per task semplici, tasso di errore inferiore al 5% su task di estrazione dati, e capacità di eseguire il modello di fascia media senza crash o out-of-memory. In questa fase si documentano anche i consumi energetici e la generazione di calore, parametri che influenzeranno le scelte hardware della fase successiva.

Fase 2 – Integrazione con strumenti esistenti (2-4 settimane)

Una volta verificato che il modello locale produce risultati di qualità accettabile, si procede all’integrazione con gli strumenti di lavoro quotidiani. Si configura un server MCP che espone gli strumenti più utilizzati: ricerca documentale su file system o database, invio email, aggiornamento di fogli di calcolo o database relazionali, accesso a API interne. Si testa l’integrazione con agenti come Claude Code o Hermes Agent, partendo da task semplici (recupero di un documento, compilazione di un modulo) e aumentando gradualmente la complessità. Si verificano la qualità del tool calling del modello scelto e la robustezza del sistema in caso di errori o timeout delle chiamate esterne. I criteri di avanzamento sono: l’agente completa correttamente almeno l’80% dei task di integrazione senza intervento umano, e il sistema gestisce gli errori di rete o di API senza bloccare l’intero flusso di lavoro. In questa fase si definiscono anche le policy di routing: quali task devono rimanere sul modello locale, quali possono essere reindirizzati a un modello cloud di riserva, e in quali condizioni.

Fase 3 – Ottimizzazione e scalabilità (1-2 mesi)

Con l’infrastruttura di base funzionante, si passa all’ottimizzazione delle performance e alla scalabilità del sistema. Si valuta l’opportunità di un fine-tuning leggero del modello sui dati specifici del dominio: un dataset di poche centinaia di esempi (domande e risposte attese) può migliorare significativamente la qualità delle risposte su task ripetitivi. Si implementa una pipeline RAG su una knowledge base locale, utilizzando un modello di embedding (ad esempio, Mistral Embed o BGE) e un database vettoriale (ChromaDB o Qdrant). Si ottimizzano i parametri di inferenza: dimensione del batch, finestra di contesto, strategia di caching del KV-cache. Si monitorano le performance con strumenti di logging (latenza, throughput, utilizzo VRAM) e si identificano i colli di bottiglia. I criteri di avanzamento sono: il sistema gestisce il carico di lavoro previsto senza degradare le performance, la qualità delle risposte con RAG è superiore a quella del modello base, e il fine-tuning produce un miglioramento misurabile su metriche specifiche del dominio (accuratezza dell’estrazione, completezza delle risposte, riduzione dei tassi di errore). In questa fase si valuta anche l’eventuale upgrade hardware: se il carico di lavoro supera le capacità dell’hardware esistente, si pianifica l’acquisto di una GPU con maggiore VRAM o l’attivazione di una VPS con GPU dedicata.

Fase 4 – Messa in produzione e monitoraggio continuo (continuativo)

L’ultima fase è la messa in produzione del sistema, con la definizione di processi di monitoraggio, manutenzione e aggiornamento. Si configurano alert per anomalie (latenza eccessiva, errori di tool calling, saturazione della VRAM) e si definiscono procedure di backup e ripristino dei modelli e delle configurazioni. Si stabilisce un calendario di aggiornamento dei modelli: ogni nuovo rilascio di un modello open-weight viene valutato su un set di test standardizzato, e se supera il modello in produzione su metriche chiave, si pianifica la migrazione. Si mantiene un inventario di modelli alternativi per ogni fascia di dimensioni, per garantire la continuità del servizio in caso di revoca della licenza o di scoperta di vulnerabilità. Si documentano le procedure di disaster recovery: cosa fare se il modello locale smette di funzionare, come attivare il fallback sul cloud, come ripristinare la configurazione da backup. Il monitoraggio continuo include anche la verifica della qualità delle risposte nel tempo, con un campionamento periodico delle interazioni e una valutazione umana della correttezza e completezza.

Ottimizzazione dei token e routing

La gestione efficiente dei token è il fattore che determina la sostenibilità economica e operativa di un’infrastruttura basata su LLM locali. Ogni token generato consuma tempo di calcolo, memoria e, in ultima analisi, energia. Ottimizzare l’uso dei token significa ridurre i costi operativi e migliorare l’esperienza d’uso, senza sacrificare la qualità delle risposte.

Strategie di compressione dei prompt

Il prompt è il principale consumatore di token in un’interazione tipica. Ridurre la lunghezza del prompt senza perdere informazioni rilevanti è la leva più efficace per aumentare il throughput e ridurre la latenza. Le strategie operative includono:

• Rimozione del contesto non necessario: molti prompt includono istruzioni ridondanti, esempi superflui o informazioni di contesto che il modello ha già elaborato in interazioni precedenti. Una revisione sistematica dei prompt può ridurre la lunghezza del 20-40% senza impatto sulla qualità delle risposte. Strumenti come llama.cpp offrono flag per il trimming automatico del contesto, ma la revisione manuale è più efficace.

• Uso di system prompt compatti: il system prompt dovrebbe essere il più breve possibile, contenendo solo le istruzioni essenziali sul comportamento atteso. Le informazioni di contesto (ruolo, tono, formato di output) possono essere condensate in poche righe. Un system prompt di 100-200 token è generalmente sufficiente per la maggior parte dei task; prompt più lunghi tendono a essere ignorati dal modello o a diluire le istruzioni importanti.

• Caching del contesto ricorrente: per task ripetitivi (ad esempio, estrazione dati da fatture), il contesto di sistema e gli esempi possono essere pre-calcolati e memorizzati in cache, evitando di ripetere la stessa elaborazione a ogni richiesta. Il KV-cache di llama.cpp e Ollama supporta il caching parziale, che può ridurre la latenza del 30-50% per richieste successive simili.

• Riepilogo periodico delle conversazioni: per agenti che mantengono conversazioni lunghe, il riepilogo periodico delle interazioni precedenti è più efficiente che mantenere l’intero storico. Un riepilogo di 200-500 token può sostituire un contesto di 10.000 token, con una perdita di informazioni minima se il riepilogo è ben strutturato.

Routing intelligente delle richieste

Non tutte le richieste richiedono lo stesso modello o la stessa quantità di risorse. Il routing intelligente instrada ogni richiesta verso il modello più appropriato in base a criteri predefiniti, ottimizzando l’uso delle risorse e riducendo i costi.

• Routing per complessità del task: i task semplici (riassunto di un paragrafo, classificazione binaria, estrazione di un campo) possono essere gestiti da modelli piccoli (7-9B) con latenza ridotta e consumo energetico contenuto. I task complessi (analisi di un documento lungo, ragionamento multi-step, generazione di codice articolato) richiedono modelli più grandi (14-32B). Il routing per complessità può essere implementato con una soglia di lunghezza del prompt o con un classificatore leggero che valuta la difficoltà del task.

• Routing per sensibilità dei dati: i dati sensibili (documenti legali, dati sanitari, informazioni finanziarie) devono rimanere su modelli locali o on-premise, senza transitare su API cloud. Il routing per sensibilità verifica la presenza di marcatori di riservatezza (tag, metadati, pattern di dati) e instrada la richiesta verso il livello appropriato dell’architettura a livelli.

• Routing per latenza richiesta: le interazioni in tempo reale (chat, assistenza in linea) richiedono latenze inferiori a 2-3 secondi e devono essere instradate verso modelli piccoli e ottimizzati. Le elaborazioni batch (analisi documentale notturna, generazione di report) possono tollerare latenze di minuti e possono utilizzare modelli più grandi o quantizzazioni più aggressive.

• Routing per disponibilità delle risorse: se la VRAM è satura o la GPU è occupata da un’altra elaborazione, le richieste possono essere reindirizzate a un modello CPU-only o a un modello cloud di riserva. Il routing per disponibilità richiede un monitoraggio in tempo reale delle risorse e una coda di priorità per le richieste.

Quantizzazione adattiva

La quantizzazione non è una scelta binaria (Q4_K_M o niente). Modelli diversi possono essere quantizzati in modo diverso in base al task e alle risorse disponibili. La quantizzazione adattiva prevede:

• Quantizzazione per task: per task semplici (classificazione, estrazione di campi), una quantizzazione Q3_K_M o Q2_K può essere sufficiente, riducendo il footprint di memoria del 20-30% rispetto a Q4_K_M. Per task complessi (ragionamento, generazione creativa), Q4_K_M o Q5_K_M sono necessari per mantenere la qualità.

• Quantizzazione per contesto: per task con finestre di contesto ridotte (fino a 8K token), la quantizzazione Q4_K_M è ottimale. Per task con finestre di contesto molto ampie (128K+), una quantizzazione più aggressiva (Q3_K_M) può liberare memoria per il KV-cache, che diventa il collo di bottiglia principale.

• Quantizzazione dinamica: alcuni runtime (come llama.cpp) supportano il caricamento di modelli con quantizzazione mista, dove i layer più critici per la qualità (i primi e gli ultimi) sono quantizzati meno aggressivamente dei layer intermedi. Questa tecnica può migliorare la qualità mantenendo un footprint di memoria ridotto.

Monitoraggio e valutazione

Un’infrastruttura basata su LLM locali non può essere lasciata in esecuzione senza supervisione. Il monitoraggio continuo e la valutazione periodica delle performance sono essenziali per garantire la qualità del servizio, identificare problemi prima che diventino critici e guidare le decisioni di aggiornamento e ottimizzazione.

Metriche di performance

Le metriche da monitorare si dividono in tre categorie: tecniche, di qualità e operative.

• Metriche tecniche: latenza di generazione (tempo al primo token, token al secondo), utilizzo della VRAM, utilizzo della GPU (percentuale di occupazione, temperatura), throughput (richieste al minuto), tasso di errore del runtime (crash, out-of-memory). Queste metriche sono raccolte automaticamente dai runtime (Ollama espone metriche via API, llama.cpp via log) e possono essere aggregate in un dashboard con strumenti come Prometheus e Grafana.

• Metriche di qualità: accuratezza delle risposte su un set di test standardizzato, completezza delle informazioni, conformità al formato di output richiesto, tasso di allucinazioni (informazioni non verificate o inventate). La valutazione della qualità richiede un campionamento periodico delle interazioni e una revisione umana, o l’uso di un modello di valutazione automatico (LLM-as-a-judge) che confronta le risposte con un gold standard. Per task strutturati (estrazione dati, classificazione), la qualità può essere misurata in modo oggettivo confrontando l’output con i valori attesi.

• Metriche operative: costi per richiesta (energia, ammortamento hardware), disponibilità del servizio (uptime), tempo medio di risoluzione degli incidenti, frequenza di aggiornamento dei modelli. Queste metriche sono rilevanti per la gestione del budget e per la pianificazione delle capacità.

Valutazione periodica dei modelli

I modelli open-weight vengono aggiornati frequentemente, e ogni nuovo rilascio può offrire miglioramenti significativi in termini di qualità, efficienza o capacità. La valutazione periodica dei modelli segue un processo standardizzato:

1. Selezione del set di test: si definisce un set di test rappresentativo dei task del dominio, con almeno 50-100 esempi per task. Il set di test deve coprire sia i casi d’uso principali sia i casi limite (input ambigui, richieste malformate, contesti molto lunghi).

2. Esecuzione del benchmark: ogni nuovo modello viene eseguito sul set di test, con gli stessi parametri di inferenza (quantizzazione, finestra di contesto, temperatura). Si raccolgono metriche di qualità (accuratezza, completezza) e tecniche (latenza, throughput, utilizzo VRAM).

3. Confronto con il modello in produzione: il nuovo modello viene confrontato con il modello attualmente in produzione su tutte le metriche. Se il nuovo modello supera il modello in produzione su metriche chiave (accuratezza superiore al 5%, latenza inferiore al 10%, o riduzione del tasso di errore), si pianifica la migrazione.

4. Validazione su casi reali: prima di mettere in produzione il nuovo modello, si esegue una validazione su un campione di interazioni reali, monitorando la qualità delle risposte e la robustezza del sistema per un periodo di 1-2 settimane.

Alert e escalation

Il sistema di monitoraggio deve generare alert per condizioni anomale che richiedono intervento umano. Gli alert si dividono in tre livelli di gravità:

• Warning: condizioni che indicano un potenziale problema futuro, ma non richiedono intervento immediato. Esempi: utilizzo della VRAM superiore all’80%, latenza media in aumento del 20% rispetto alla settimana precedente, tasso di errori di tool calling in aumento. Il warning viene registrato e rivisto durante il normale ciclo di manutenzione.

• Critical: condizioni che richiedono intervento entro poche ore. Esempi: crash del runtime, saturazione della VRAM con conseguente out-of-memory, latenza media superiore a 30 secondi, tasso di errori superiore al 10%. Il critical attiva una notifica immediata al team di gestione e una procedura di escalation predefinita.

• Emergency: condizioni che richiedono intervento immediato per ripristinare il servizio. Esempi: indisponibilità totale del modello locale, perdita di dati, violazione della sicurezza. L’emergency attiva il disaster recovery plan, con il fallback sul cloud o su un modello di riserva e la comunicazione agli utenti del servizio.

Prossimi passi

L’ecosistema degli LLM locali è in evoluzione rapidissima, e le decisioni prese oggi devono essere riviste periodicamente alla luce dei nuovi sviluppi. I prossimi passi operativi si articolano su tre orizzonti temporali.

A breve termine (1-3 mesi)

• Completare la fase 1 e 2 della roadmap: allestire l’ambiente di test, selezionare i modelli di riferimento, integrare con gli strumenti esistenti. Documentare le performance e le metriche di qualità per avere una baseline oggettiva.

• Valutare l’hardware attuale: verificare se l’hardware esistente è sufficiente per i carichi di lavoro previsti o se è necessario un upgrade. Considerare l’acquisto di una GPU con 16-24 GB di VRAM (RTX 4090 usata o RTX 5090) come investimento iniziale.

• Testare Gemma 4 12B: se il caso d’uso include documenti misti (testo + immagini) o audio, testare Gemma 4 12B come modello primario per la multimodalità. Verificare la qualità del tool calling e l’integrazione con agenti.

• Configurare il monitoraggio di base: installare strumenti di logging e metriche per raccogliere dati su latenza, throughput e utilizzo delle risorse. Definire le soglie di alert e le procedure di escalation.

A medio termine (3-6 mesi)

• Implementare il routing intelligente: configurare il routing delle richieste in base a complessità, sensibilità e latenza richiesta. Separare i task semplici (modelli piccoli) da quelli complessi (modelli grandi) per ottimizzare l’uso delle risorse.

• Avviare il fine-tuning: se la qualità delle risposte su task specifici non è soddisfacente, raccogliere un dataset di esempi curati e avviare un fine-tuning leggero del modello. Valutare l’impatto sulla qualità e sulla latenza.

• Valutare i modelli ternari: monitorare lo sviluppo dei modelli a 1-bit/ternari (BitNet b1.58, progetti correlati). Se diventano disponibili in formato GGUF, testarli per valutare il rapporto qualità/requisiti di memoria. Pianificare l’eventuale migrazione se i risultati sono promettenti.

• Espandere l’integrazione MCP: aggiungere nuovi strumenti al server MCP in base alle esigenze degli utenti. Automatizzare i flussi di lavoro più frequenti (estrazione dati, generazione report, aggiornamento database).

A lungo termine (6-12 mesi)

• Valutare l’architettura a livelli: se il carico di lavoro cresce, valutare l’implementazione dell’architettura a tre livelli (edge, on-premise, cloud) con routing automatico e fallback. Definire le policy di attivazione del cloud e i criteri di escalation.

• Pianificare la strategia di sovranità elastica: definire la matrice decisionale per la scelta tra modelli americani, cinesi e ibridi. Documentare i rischi e le mitigazioni per ciascuna opzione. Mantenere un inventario di modelli alternativi per garantire la continuità del servizio.

• Aggiornare l’hardware in base ai progressi: se i modelli ternari diventano disponibili e dimostrano qualità competitiva, valutare l’acquisto di hardware con maggiore VRAM (24-48 GB) per eseguire modelli di dimensioni enterprise su singola GPU.

• Formare il personale: investire nella formazione del team sulla gestione, manutenzione e valutazione dei modelli locali. La competenza interna è il fattore critico di successo per l’adozione a lungo termine.

L’adozione di LLM locali non è un progetto una tantum ma un percorso di apprendimento continuo. I modelli migliorano, l’hardware diventa più accessibile e i runtime più maturi. L’organizzazione che investe oggi nella competenza e nell’infrastruttura si posiziona per sfruttare i progressi futuri, mantenendo il controllo dei propri dati e riducendo la dipendenza da fornitori esterni.