Modelli AI open source e open weight: differenze, vantaggi e costi nascosti
I modelli AI open source e i modelli open weight vengono spesso descritti come equivalenti, ma non indicano lo stesso livello di apertura. La distinzione riguarda ciò che viene realmente reso disponibile: pesi, codice, informazioni sui dati, procedure di addestramento e libertà previste dalla licenza.
Per un’azienda la scelta non è ideologica. Incide su controllo dei dati, personalizzazione, costi infrastrutturali, sicurezza e dipendenza dal fornitore.
Open source e open weight: qual è la differenza?
Un modello open weight rende disponibili i parametri appresi durante l’addestramento. È quindi possibile scaricarlo, eseguirlo su infrastruttura propria e, se la licenza lo consente, adattarlo.
La disponibilità dei pesi non garantisce però che siano accessibili anche dataset, codice di training, criteri di filtraggio e processo completo con cui il modello è stato costruito.
Secondo la Open Source AI Definition 1.0 dell’Open Source Initiative, un sistema AI realmente open source deve offrire le libertà di utilizzo, studio, modifica e condivisione, insieme alla forma preferita per apportare modifiche. La definizione comprende informazioni sui dati, codice e parametri.
Perché il termine viene usato in modo impreciso
Nel software tradizionale il codice sorgente permette di studiare buona parte del funzionamento. In un modello generativo, il comportamento deriva anche dai dati e dal processo di addestramento. Pubblicare soltanto i pesi apre l’esecuzione, ma non rende necessariamente riproducibile la costruzione del modello.
Prima di adottare un prodotto bisogna quindi leggere la model card e la licenza, evitando di dedurre diritti dal solo pulsante di download.
Che cosa controllare prima del download
- Licenza: usi commerciali, redistribuzione, modifiche e restrizioni;
- pesi: formato, quantizzazione e dimensione;
- codice: inferenza, fine-tuning, tokenizer e strumenti di valutazione;
- dati: provenienza, lingue, limiti dichiarati e criteri di filtraggio;
- documentazione: benchmark, rischi, contesto massimo e modalità d’uso;
- dipendenze: librerie, runtime e hardware supportato;
- aggiornamenti: frequenza, compatibilità e gestione delle vulnerabilità.
“Disponibile su GitHub” non significa automaticamente “open source”, così come “gratuito” non significa privo di condizioni.
I vantaggi dei modelli aperti
Controllo dei dati
L’esecuzione locale o in un cloud privato può ridurre il trasferimento di informazioni verso servizi esterni. Rimangono necessari classificazione dei dati, controllo degli accessi, registrazione e politiche di conservazione.
Personalizzazione
Un modello scaricabile può essere adattato con fine-tuning, distillazione, quantizzazione o componenti di retrieval. Il vantaggio è rilevante quando il dominio è specifico e dispone di dati di qualità.
Portabilità e continuità
Gestire i pesi permette di cambiare infrastruttura e ottimizzare latenza o disponibilità. Riduce una parte della dipendenza dal provider, ma crea responsabilità operative interne.
Sperimentazione verificabile
Il team può confrontare versioni, parametri e configurazioni in un ambiente controllato. Questa libertà aiuta ricerca e prototipazione, purché i test riflettano il caso d’uso reale.
Il caso gpt-oss
Nell’agosto 2025 OpenAI ha pubblicato gpt-oss-120b e gpt-oss-20b, due modelli open weight con licenza Apache 2.0. La versione più grande è pensata per infrastrutture con circa 80 GB di memoria, mentre quella da 20 miliardi di parametri può funzionare con circa 16 GB.
L’esempio mostra l’utilità del termine open weight: i pesi sono scaricabili e il deployment è controllabile, ma la descrizione non deve essere trasformata automaticamente nell’etichetta open source per l’intero sistema.
I costi nascosti del self-hosting
Scaricare un modello può essere gratuito; mantenerlo in produzione non lo è. Il costo totale comprende:
- GPU o servizi cloud e relativi picchi;
- energia, storage e trasferimento dati;
- ottimizzazione di inferenza e code di richieste;
- monitoraggio di latenza, errori e qualità;
- patch, aggiornamenti e gestione delle dipendenze;
- valutazioni di sicurezza e red teaming;
- competenze MLOps e reperibilità operativa;
- backup, disaster recovery e continuità.
Il confronto corretto non oppone “modello gratuito” ad “API a pagamento”. Deve confrontare il costo complessivo per richiesta utile, il livello di servizio e il rischio operativo.
API oppure modello locale?
Una API gestita è spesso adatta quando servono rapidità, scalabilità e accesso immediato a modelli aggiornati. Il self-hosting diventa interessante quando contano residenza dei dati, personalizzazione, latenza prevedibile o volumi stabili.
Un approccio ibrido può instradare attività sensibili o ripetitive verso un modello locale e richieste complesse verso un servizio gestito. La scelta dovrebbe dipendere dalla classificazione del caso d’uso, non da una preferenza unica per tutta l’organizzazione.
Come confrontare due modelli
I benchmark pubblici sono un punto di partenza, non una decisione. Occorre costruire un set di valutazione con richieste reali, risposte attese e criteri misurabili:
- qualità e completezza della risposta;
- precisione su documenti aziendali;
- allucinazioni e capacità di dichiarare incertezza;
- latenza al primo token e tempo totale;
- memoria e costo per volume previsto;
- supporto della lingua italiana;
- tool calling e output strutturato;
- robustezza a input ostili.
L’articolo sui benchmark AI spiega perché una classifica generica non sostituisce un test applicativo.
Sicurezza: più controllo significa più responsabilità
Con un servizio gestito una parte delle difese è curata dal provider. Con un modello self-hosted l’organizzazione deve proteggere endpoint, pesi, prompt, documenti collegati e pipeline di aggiornamento.
I controlli minimi includono autenticazione, rate limit, segmentazione della rete, scansione delle dipendenze, validazione degli output e tracciamento degli accessi. La prompt injection rimane un rischio anche quando il modello gira internamente.
Una procedura di adozione in sette passaggi
- Definire attività, utenti e dati coinvolti;
- stabilire requisiti di qualità, privacy e latenza;
- verificare licenza e documentazione;
- testare almeno un modello aperto e un servizio gestito;
- calcolare costo totale a dodici mesi;
- realizzare un pilota con limiti e supervisione;
- decidere proprietario, monitoraggio e piano di uscita.
Il progetto dovrebbe includere anche la possibilità di sostituire il modello. Separare applicazione, livello di orchestrazione e provider riduce il costo di migrazione. Il context engineering aiuta a progettare questa architettura oltre il singolo prompt.
Errori frequenti
- Confondere pesi aperti e sistema interamente open source;
- ignorare le restrizioni della licenza;
- scegliere il modello solo per numero di parametri;
- non stimare personale e infrastruttura;
- usare benchmark lontani dal proprio dominio;
- portare dati sensibili in un prototipo non protetto;
- omettere logging, fallback e aggiornamenti;
- considerare il fine-tuning la prima soluzione.
Domande frequenti
Un modello open weight è sempre open source?
No. I pesi possono essere disponibili senza il codice, le informazioni sui dati e le libertà richieste da una definizione completa di open source AI.
Posso usare un modello aperto per fini commerciali?
Dipende dalla licenza specifica. Deve essere verificata prima del deployment e della redistribuzione.
Eseguire un modello in locale protegge automaticamente i dati?
No. Riduce alcuni trasferimenti esterni, ma richiede controlli su accessi, rete, log, documenti e backup.
Qual è la scelta più economica?
Dipende da volume, hardware, competenze e livello di servizio. Per volumi variabili una API può essere più efficiente; per carichi stabili il self-hosting può diventare competitivo.
Scegliere il grado di apertura adatto
I modelli AI open source e open weight ampliano le opzioni disponibili, ma non eliminano costi né responsabilità. La scelta migliore nasce da licenza, test sul caso reale, costo totale e capacità operativa. L’apertura è un requisito da misurare, non un’etichetta da presumere.