Quando si parla di intelligenza artificiale generativa, il dibattito pubblico tende a concentrarsi sui modelli di frontiera – Chat GPT, Claude, Gemini – accessibili esclusivamente via API o interfaccia web, con costi per token e dati che si approggiano si grandi infrastrutture.

È una visione parziale.

Esiste un ecosistema parallelo, meno visibile mediaticamente ma tecnicamente maturo, composto da modelli “open-weight” distribuiti liberamente e utilizzabili in locale, senza connessione a servizi esterni e senza cedere dati a nessuno. Modelli come la famiglia Llama di Meta, la serie Qwen di Alibaba, Gemma di Google, Mistral e decine di altri vengono rilasciati con pesi pubblici e possono girare su hardware consumer: un laptop sufficientemente dotato, una workstation, o – come nel caso di questo articolo – una macchina da sviluppo con una GPU mid-range. Strumenti come Ollama hanno ulteriormente abbassato la barriera d’ingresso, riducendo l’installazione e la gestione di questi modelli a pochi comandi. Il risultato è che oggi chiunque abbia una macchina ragionevole può eseguire in locale modelli che, fino a due anni fa, avrebbero richiesto hardware non alla portata dei singoli.

Chi lavora con modelli linguistici su hardware consumer sa bene che i compromessi esistono: una GPU da 8 GB di VRAM non è una A100, e le aspettative vanno calibrate di conseguenza. Eppure, anche in questo segmento – quello dei modelli che girano in locale su una macchina ragionevole, senza cloud e senza costi per token – la distanza tra un modello e l’altro può essere sorprendente.
Ho voluto verificarlo con mano, confrontando alcuni modelli utilizzabili senza hardware specializzato con Emma-5, il modello italiano che nelle scorse settimane ha guadagnato una certa visibilità mediatica. Il banco di prova è stata la mia macchina di sviluppo Linux: Ryzen 7, 64 GB di RAM, GPU (RTX5060) con 8 GB di VRAM e, ovviamente, Linux come sistema operativo. Nulla di esotico: esattamente il tipo di configurazione che un appassionato potrebbe avere sulla scrivania e un riferimento realistico per chi vuole lavorare con LLM in locale senza dipendere dal cloud.

I modelli in campo

Prima di entrare nei risultati, vale la pena capire cosa si confronta e perché certi numeri contano.

Il parametro più citato – e più frainteso – è il numero di parametri del modello, che indica grossomodo la complessità della rete neurale sottostante e, indirettamente, la quantità di informazione che può essere rappresentata durante l’addestramento. Non è una misura diretta della qualità, ma una correlazione esiste: a parità di architettura, dati e processo di training, un numero maggiore di parametri tende generalmente a produrre modelli più capaci. Negli ultimi anni, tuttavia, la qualità dei dati e le tecniche di addestramento hanno spesso inciso quanto, o più, della semplice crescita dimensionale.

L’altro numero rilevante è la context window, ovvero quanti token (unità di testo che corrispondono approssimativamente a sillabe o parole brevi) il modello riesce a mantenere nel contesto della conversazione.  Una finestra ridotta implica una minore capacità di mantenere coerenza e riferimenti lungo testi estesi.

Una nota sul peso dei file: i modelli vengono normalmente distribuiti in forma quantizzata, cioè con una rappresentazione numerica compressa dei pesi. Questo riduce drasticamente l’occupazione di memoria e spazio disco, con un impatto spesso limitato sulle prestazioni pratiche. Strumenti come Ollama gestiscono questa complessità in maniera trasparente.

I modelli utilizzati come termine di confronto sono tutti eseguibili localmente tramite Ollama:

* Gemma 4 4B (Google): 4 miliardi di parametri, context window fino a 128K token.
* Qwen2.5-Coder 7B (Alibaba): 7 miliardi di parametri, context window fino a 128K token.
* Qwen3 6B (Alibaba): circa 6 miliardi di parametri, context window da decine di migliaia di token e supporto a modalità di ragionamento esplicito.
* Emma-5 (Egomnia): circa 550 milioni di parametri e context window di 2048 token.

Vale la pena sottolineare che Emma-5 appartiene a una categoria dimensionale molto diversa rispetto agli altri modelli in prova. Non si tratta quindi di un confronto tra prodotti equivalenti, ma tra ciò che oggi è disponibile localmente per l’utente finale e il modello italiano che ha ricevuto maggiore attenzione mediatica.

Il test: una domanda solo apparentemente stupida

Per un pubblico non specialistico, i benchmark accademici raccontano poco. Ho preferito una domanda semplice, quasi banale, che però misura una capacità fondamentale: comprendere ciò che viene chiesto, non semplicemente generare testo plausibile.

La domanda era: “Di che colore era il cavallo bianco di Napoleone?”

Si tratta di un classico trabocchetto linguistico che richiede attenzione alla struttura della frase più che conoscenze storiche. Un modello linguistico che funziona dovrebbe riconoscerlo immediatamente:  non perché abbia senso dell’umorismo, ma perché dovrebbe essere in grado di analizzare la struttura della frase e coglierne il contenuto esplicito.
Naturalmente una singola domanda non permette di trarre conclusioni statisticamente significative sulle capacità complessive di un modello. Può però evidenziare categorie di errore particolarmente interessanti quando il fallimento riguarda la comprensione letterale della richiesta.

I risultati sono stati significativi

• Emma-5 non ha riconosciuto il trabocchetto e ha prodotto una risposta inventata: “Napoleone fu detto bianco per distinguerlo dal cavallo nero“. Una frase formalmente corretta ma priva di significato nel contesto della domanda.
• Gemma 4 4B ha evitato l’allucinazione, ma non ha riconosciuto il gioco linguistico. Ha risposto con una spiegazione storica articolata sul colore dei cavalli utilizzati da Napoleone e sulla loro rappresentazione iconografica.
• Qwen2.5-Coder 7B ha risposto che il cavallo era bianco, richiamando le rappresentazioni storiche più note, senza però cogliere il trabocchetto.
• Qwen3 6B ha invece risposto immediatamente: “Era bianco, come dice esplicitamente la domanda stessa”, con tanto di emoticon della faccina sorridente, mostrando di aver interpretato correttamente la struttura della richiesta.

Un solo modello su quattro ha individuato esplicitamente il trabocchetto.

Cosa ci dice questo, e cosa dovrebbe dirci

Un test con una singola domanda non è un benchmark. Non pretende di esserlo. Ma il tipo di errore che commette Emma-5 – non una risposta imprecisa, non una lacuna di conoscenza, ma la generazione di testo formalmente coerente e sostanzialmente privo di senso – è un indicatore preciso di qualcosa che va oltre la taglia del modello o la scarsità di risorse computazionali.

Il problema non è che Emma-5 sia piccolo. Qwen3 6B è piccolo. Gemma 4 4B è piccolo. Il problema è che Emma-5 non dimostra di aver raggiunto quella soglia minima di comprensione del linguaggio oltre la quale un modello smette di essere un generatore di testo plausibile e diventa uno strumento utilizzabile. Questa soglia esiste, non è banale da raggiungere, e richiede dati di qualità, architetture curate e – soprattutto – una valutazione onesta dei risultati prima di comunicarli all’esterno.

Il lancio di Emma-5 è stato accompagnato da una narrazione entusiasta, amplificata dai media italiani con il consueto riflesso pavloviano riservato a qualunque cosa venga presentata come “sovranismo italiano”. Una narrazione che ha un costo che non è immediatamente visibile: brucia credibilità, distorce le aspettative, e – cosa più seria – rischia di influenzare decisioni di investimento e policy basate su una percezione della maturità tecnologica che non corrisponde alla realtà.

L’Europa ha un problema strutturale nello sviluppo di modelli linguistici competitivi, e non è un problema che si risolve con il campanilismo tecnologico. Le ragioni sono note: frammentazione dei dati, barriere linguistiche che rendono costoso costruire dataset di qualità nelle singole lingue nazionali, assenza di infrastrutture di calcolo comparabili a quelle americane o cinesi, e un ecosistema di ricerca che fatica a trattenere i talenti migliori. A questo si aggiunge una tendenza, ad essere onesti non solo italiana, a celebrare il progetto prima di valutare il prodotto.

A mio parere, la strada credibile non passa per modelli “nazionali” costruiti con risorse insufficienti e lanciati prima del tempo. Passa per una strategia europea coordinata – su dati, infrastrutture e valutazione – che accetti di competere su scala continentale invece di replicare in miniatura, paese per paese, quello che altri fanno con ordini di grandezza diversi di risorse. Progetti come BLOOM, o più recentemente gli sforzi nell’ambito di OpenEuroLLM, indicano una direzione più sensata: masse critiche di dati multilingue, governance aperta, e la volontà di misurare i risultati con gli stessi criteri con cui si misurano i competitori internazionali.

Nel frattempo, sulla mia modesta macchina Linux da sviluppo, un modello cinese da 6 miliardi di parametri distribuito gratuitamente capisce le domande trabocchetto meglio del primo “modello italiano”. Non è una provocazione. È un dato.

È nel campo dell’intelligenza artificiale contano i risultati osservabili, non le narrazioni che li accompagnano.