LLM open source: miti e realtà in azienda

Il rumore attorno ai modelli aperti

Quando un team dirigenziale chiede per la prima volta dei LLM open source, la conversazione di solito inizia con una grande promessa e un dubbio ancora più grande. I miti circolano più velocemente della documentazione tecnica. E le decisioni vengono prese, in molti casi, con informazioni di seconda mano. Questo articolo non intende vendere l’adozione di modelli aperti, ma separare ciò che si può verificare da ciò che si ripete senza prove.

Mito 1: «L’open source è gratis»

Il peso del modello è scaricabile senza costi. Questo è vero. Ciò che non è gratis è tutto ciò che serve perché quel peso funzioni in modo stabile in produzione. I costi reali emergono su quattro fronti:

• Infrastruttura: una GPU con memoria sufficiente per servire un modello da 70B con contesto lungo non è un portatile. L’affitto a ore o l’acquisto dell’hardware hanno un costo che si ripete ogni mese.
• Ingegneria: qualcuno deve configurare il server di inferenza, ottimizzare il batching, monitorare le latenze e gestire le versioni del modello.
• Valutazione: ogni aggiornamento del modello o del prompt richiede di misurare nuovamente la qualità. Senza un banco di prova proprio, si naviga alla cieca.
• Manutenzione: i repository dei pesi e le librerie di inferenza evolvono rapidamente. Ciò che funzionava sei mesi fa può richiedere aggiustamenti oggi.

In pratica, il costo per token di un modello aperto servito su infrastruttura propria può essere competitivo o persino inferiore a quello di un’API chiusa, ma solo a partire da un certo volume sostenuto. Al di sotto di quella soglia, l’API di solito vince sul costo totale. Secondo la documentazione dei fornitori di infrastruttura cloud, l’utilizzo medio delle GPU dedicate all’inferenza nelle piccole imprese raramente supera il 30%, il che rende più caro ogni token servito.

L’errore di contare solo il prezzo del token

Un pattern che si ripete nei team che fanno il salto: confrontano il prezzo per milione di token dell’API con il prezzo orario della GPU e concludono che il modello aperto è più economico. Dimenticano il costo opportunità del team di piattaforma, le ore di integrazione e il tempo dedicato a risolvere incidenti. Un calcolo onesto include quelle ore, anche se in modo approssimativo.

Mito 2: «Se è aperto, i miei dati sono al sicuro per impostazione predefinita»

Eseguire il modello sulla propria infrastruttura elimina l’uscita dei dati verso terzi, ma non rende il sistema sicuro per magia. La sicurezza dipende da come viene distribuito, non solo da dove viene eseguito. I punti che di solito restano fuori dalla conversazione iniziale:

• I registri dei prompt e delle risposte. Se vengono archiviati senza controllo, il dato sensibile resta esposto, anche se il modello è locale.
• L’accesso all’endpoint di inferenza. Senza autenticazione e limiti di utilizzo, chiunque all’interno della rete può interrogare il modello con i permessi del servizio.
• La catena di fornitura del modello. I pesi scaricati da un repository pubblico devono essere verificati; un file corrotto o manomesso è un vettore reale.
• Il filtraggio dei contenuti. Un modello aperto non porta per impostazione predefinita i livelli di moderazione che un fornitore gestito applica nella sua API.

Il vantaggio della privacy esiste, ma è una condizione necessaria, non sufficiente. Richiede lo stesso lavoro di governance dei dati di qualsiasi altro sistema interno.

Mito 3: «Rendono peggio dei modelli chiusi»

Qui la sfumatura conta molto, e generalizzare è l’errore. In compiti di ragionamento complesso, matematica e codice, i modelli chiusi di prima fascia hanno mantenuto per buona parte del 2025 e all’inizio del 2026 un vantaggio nei benchmark pubblici. Ma in compiti circoscritti — classificazione di ticket, estrazione di campi da un documento, riassunto di conversazioni con formato fisso, generazione di risposte a partire da un contesto recuperato — i modelli aperti di dimensioni medie eguagliano o superano i modelli chiusi piccoli, con il vantaggio di poterli ottimizzare con i propri dati.

Un caso concreto che illustra bene la differenza: una compagnia assicurativa che elabora denunce di sinistro in PDF. Un modello chiuso generalista commetteva errori nell’estrarre gli importi quando il documento mescolava tabelle e testo libero. Dopo aver fatto fine-tuning di un modello aperto da 8B con 2.000 esempi annotati internamente, la precisione su quel formato specifico è aumentata in modo notevole e il costo per documento si è ridotto. Non perché il modello aperto fosse migliore in generale, ma perché era specializzato nella distribuzione esatta dei loro documenti. Questo è il terreno in cui i modelli aperti brillano.

Dove non arrivano (e conviene riconoscerlo)

Un modello aperto da 7B o 8B non risolverà richieste che esigono ragionamento multi-step su contesti di 200.000 token con la stessa solidità di un modello chiuso di fascia alta. Non è nemmeno l’opzione naturale per compiti creativi di ampio respiro dove la coerenza stilistica è critica. Se il tuo caso d’uso dipende da questo, il modello aperto non è la risposta, e forzarlo genera frustrazione nel team e sfiducia nella tecnologia.

Mito 4: «Basta scaricare il modello e il gioco è fatto»

La distanza tra scaricare i pesi e avere un servizio in produzione è la parte meno documentata negli articoli introduttivi. I passaggi intermedi includono:

• Scegliere una libreria di inferenza adeguata all’hardware disponibile.
• Definire lo schema di prompting e versionarlo insieme al codice.
• Configurare uno strato di recupero (RAG) se il modello necessita di conoscenza aggiornata dell’azienda.
• Stabilire metriche di qualità e un insieme di valutazione rappresentativo.
• Configurare limiti di utilizzo, code e degradazione controllata in caso di picchi di domanda.

Secondo la documentazione ufficiale delle principali librerie di serving, le prestazioni per GPU variano molto in base alla tecnica di quantizzazione e alla dimensione del batch. Uno stesso modello può passare dal servire 10 richieste al secondo a 40 a seconda della configurazione. Quella differenza non appare nella scheda del modello; appare quando si misura.

Mito 5: «L’open source garantisce l’indipendenza totale dal fornitore»

Sostituire la dipendenza da un’API chiusa con la dipendenza da un fornitore di GPU, da una libreria di inferenza specifica o da un unico repository di pesi non è indipendenza, è cambiare dipendenza. La libertà reale arriva quando il team può migrare il modello senza riscrivere l’applicazione. Questo richiede uno strato di astrazione nel codice, un formato di prompt portabile e un banco di prova che permetta di confrontare i candidati con lo stesso criterio.

Le aziende che hanno fatto bene questo passo di solito hanno un catalogo interno di modelli valutati, non un unico modello. Possono passare dall’uno all’altro in base a costo, latenza o qualità in un compito specifico. L’open source abilita questa flessibilità; non la garantisce.

Realtà: quando ha senso e quando no

Dopo aver visto diverse implementazioni, il pattern decisionale è abbastanza coerente:

Segnali a favore

• Volume elevato e stabile di inferenza che giustifica l’investimento in infrastruttura.
• Dati che non possono uscire dal perimetro per requisiti normativi o contrattuali.
• Necessità di specializzazione profonda in un dominio con dati propri etichettati.
• Latenza critica in ambienti dove la rete verso un fornitore esterno aggiunge un salto inaccettabile.
• Requisito di riproducibilità: sapere esattamente quale versione del modello ha risposto a cosa.

Segnali contrari

• Team senza profilo di piattaforma o MLOps e scadenze strette.
• Casi d’uso molto vari che esigono un modello generalista di massima qualità.
• Volumi bassi o intermittenti dove l’API chiusa costa meno.
• Assenza di dati propri per specializzare: senza fine-tuning né RAG, il modello aperto compete in svantaggio.

Un avvertimento sulle valutazioni

I benchmark pubblici sono un riferimento utile, ma non predicono le prestazioni nel tuo caso. Un modello che guida una classifica generalista può restare al di sotto nel compito specifico che ti interessa. L’unica misura affidabile è costruire un insieme di valutazione con esempi reali del tuo business, anonimizzati se necessario, e confrontare i candidati con lo stesso prompt e lo stesso criterio di correttezza. Senza quel banco di prova, qualsiasi decisione sui modelli aperti si basa su opinioni, non su dati.

E conviene ricordare un limite che non scompare: nessun modello, aperto o chiuso, garantisce risultati. La qualità del sistema dipende dal dato, dal design del prompt, dalla valutazione continua e dal criterio umano che rivede gli output nei punti critici. L’open source aggiunge controllo e opzioni; non sostituisce il lavoro.