Il repository «Qwen3.8» più scaricato su Hugging Face non dichiara licenza né origine

Ieri abbiamo scritto che l’annuncio di Qwen3.8-Max — «i pesi apriranno la settimana prossima» — non è ancora un file scaricabile. Lo abbiamo riverificato stamattina: l’endpoint pubblico api/models/Qwen/Qwen3.8-Max risponde ancora 401, e sull’organizzazione Qwen di Hugging Face l’ultimo modello effettivamente pubblicato risale al 26 giugno 2026 — l’ultima modifica registrata su un repository già esistente, il 22 luglio, non è un nuovo modello, è una modifica di scheda. Cercando comunque «Qwen3.8» sull’hub, qualcosa compare: due repository di un solo autore, Ma7ee7, entrambi caricati il 30 luglio 2026 — quattro giorni prima che Qwen pubblicasse l’annuncio. Nessuno dei due è il modello ufficiale: sono un adattamento indipendente di un altro modello Qwen, reale, di un anno prima. Ma uno dei due, al momento in cui verifichiamo, ha circa 155 volte i download dell’altro — ed è quello che non dichiara né licenza né origine.

Due repository, un autore solo, due schede diverse

Il primo, Ma7ee7/Qwen3.8_4B_Distilled, è in formato safetensors e conta 90 download. La scheda è fatta bene: il frontmatter dichiara license: apache-2.0 e base_model: unsloth/Qwen3-4B-Thinking-2507-unsloth-bnb-4bit, e il corpo lo ripete in chiaro — «Developed by: Ma7ee7», «License: apache-2.0», «Finetuned from model: unsloth/Qwen3-4B-Thinking-2507-unsloth-bnb-4bit». Tutto quello che serve per risalire alla fonte è lì, dichiarato due volte.

Il secondo, Ma7ee7/Qwen3.8_4B_Distilled_GGUF, conta 13.965 download. Il frontmatter ha soltanto tre tag — gguf, llama.cpp, unsloth — nessun campo license, nessun campo base_model: l’API di Hugging Face restituisce entrambi come vuoti, non come «non specificato altrove». Il corpo dice solo che «this model was finetuned and converted to GGUF format using Unsloth», poi elenca i file: qwen3-4b-thinking-2507.Q4_K_M.gguf, ...Q5_K_M.gguf, ...Q8_0.gguf. C’è un Modelfile pronto per Ollama, e un comando che lo mette in esecuzione con una riga sola: llama-cli -hf Ma7ee7/Qwen3.8_4B_Distilled_GGUF --jinja.

Il nome di un repository è testo libero, non un’attestazione

Il nome «Qwen3.8» sta nel titolo di entrambi i repository. Nei file — nei nomi dei .gguf, nel base_model dichiarato dal primo — c’è scritto un altro nome: qwen3-4b-thinking-2507. È un modello reale, pubblicato da Qwen il 5 agosto 2025, un anno esatto prima di questo articolo. «Qwen3.8» non esisteva pubblicamente il 30 luglio, quando i due repository sono stati caricati; non esiste come pesi scaricabili nemmeno oggi. Nessuno ha falsificato un certificato: su Hugging Face il campo che identifica un repository è una stringa scelta da chi carica, senza verifica di corrispondenza con un modello reale. Chi cerca «Qwen3.8» e scarica per nome sta scaricando quella stringa, non una garanzia.

Un campo vuoto non è un permesso

Il repository con quasi quattordicimila download non ha un campo licenza. Non equivale a «licenza permissiva per omissione»: è l’assenza di qualunque concessione scritta. Il gemello dello stesso autore dichiara Apache 2.0 — ma sono due repository distinti, con due sha distinti, e ciò che vincola chi lo usa è il testo che accompagna il file scaricato, non quello del repository accanto. Chi mette in produzione il pacchetto GGUF non ha un titolo su cui appoggiarsi. È lo stesso problema che ieri abbiamo descritto per Qwen3.8-Max: un’assenza dichiarativa non equivale a un’autorizzazione, e le clausole che contano — soglie di fatturato, restrizioni di campo d’uso, condizioni di revoca — cambiano da un testo di licenza all’altro: quando il testo manca del tutto, non c’è nemmeno la prima riga da leggere.

La comodità e la tracciabilità vanno in direzioni opposte

Il formato pronto all’uso è anche il meno documentato, e non è un caso isolato di questo repository: è la traiettoria dei passaggi che lo separano dall’originale. Il 5 agosto 2025 Qwen pubblica Qwen3-4B-Thinking-2507 con licenza Apache 2.0. Il giorno dopo, Unsloth carica una riquantizzazione a 4 bit, base_model dichiarato, stessa licenza. Quasi un anno dopo, il 30 luglio 2026, Ma7ee7 la usa per un fine-tuning e dichiara ancora tutto — licenza, modello di partenza. Poi, pochi minuti dopo, converte lo stesso lavoro in GGUF: e in quei minuti i due campi spariscono dalla scheda. Tre passaggi, tre editori, e la documentazione si assottiglia mentre il formato diventa più comodo da eseguire — un comando, un Modelfile, nessuna dipendenza da installare. Dove finisce «il modello è aperto» e comincia «cosa resta davvero installabile» è la domanda che l’hub non fa mai da solo. E la catena non si è fermata il 30 luglio: mentre scriviamo, un altro account ha già derivato dal repository di Ma7ee7 un proprio fine-tuning e la relativa conversione in GGUF. Zero download, per ora — ma il meccanismo che allunga la catena è già in moto, una settimana dopo l’altra.

Non è una questione di buona fede

Va detto senza ambiguità: la scheda del repository safetensors è fatta bene, dichiara licenza e origine, e non c’è alcun elemento — né in quella scheda né nel resto di questa vicenda — che indichi un intento di ingannare. Il nome «Qwen3.8» può essere una convenzione personale, un esperimento, l’abitudine di chi carica molti fine-tuning nello stesso mese. Questo articolo non riguarda il comportamento di chi ha caricato i due repository: riguarda il dovere di verifica di chi scarica, e un difetto strutturale degli hub di modelli, dove il nome del repository è libero e la dichiarazione di licenza è facoltativa. Non è nemmeno un giudizio sul modello: non lo abbiamo eseguito, e la qualità tecnica non è il tema di questo pezzo.

Cosa fare, in pratica

Verificate che l’organizzazione che pubblica sia quella che dichiara di essere: un nome nel titolo del repository non equivale a un’organizzazione verificata su Hugging Face.
Leggete i nomi dei file, non il nome del repository: sono loro a portare, quasi sempre, il nome reale del modello di partenza.
Trattate l’assenza del campo license come un blocco all’adozione, non come un dettaglio da colmare in un secondo momento.
Risalite la catena base_model fino all’origine, passaggio per passaggio, e registrate ogni editore intermedio.
Conservate, per ogni modello installato, licenza, versione, origine dei pesi e data di verifica: il registro di cui abbiamo già scritto.

Come lo risolviamo noi

La verifica di provenienza, licenza e catena di derivazione di ogni modello che entra in produzione — non una volta, al primo download, ma a ogni aggiornamento — diventa un controllo che gira sui sistemi del cliente: un registro dei modelli installati con il nome reale del file, la licenza effettiva, il base_model risalito fino all’origine, la data dell’ultima verifica. Pronto da esibire a un’ispezione, non da ricostruire quando qualcuno lo chiede.

Lo stesso impianto tiene insieme i dati sparsi dell’organizzazione — archivi, gestionali, documenti, sensori, impianti — in un modello operativo unico su cui agenti AI eseguono decisioni con un operatore al comando: per grandi imprese, difesa, pubblica amministrazione, sanità. Siamo già sul campo, con sistemi in esercizio in diverse realtà enterprise e non solo. In entrambe le modalità — on-premise su macchine autonome che non richiedono integrazione profonda nella rete del cliente, oppure cloud dedicato con VPN dedicata e data center in Italia, locali che presidiamo direttamente — e sempre con gestione condivisa: chi non ha già in casa un team che amministra modelli AI non deve mettercelo per cominciare. E l’impianto è multimodello: il modello si sostituisce quando il cliente vuole, perché il valore sta nell’ontologia e nei dati, non nel file che gira oggi.

State per mettere in produzione un modello scaricato da un repository di terzi, con un nome che promette più di quanto la scheda dichiari? Mezz’ora con un nostro esperto: verifichiamo insieme licenza, base_model e catena di derivazione prima che diventi un’abitudine del team.