I pesi aperti riducono il divario, ma questo si azzera a ogni ciclo di rilascio

Il report è la versione 1,1 di una valutazione ricorrente che Mozilla ha pubblicato per la prima volta sul suo blog il 14 luglio. Secondo Tom's Hardware, si basa su un'indagine di Mozilla e SlashData su circa 1.400 sviluppatori, dati di traffico di OpenRouter e indici di benchmark di terze parti. Mozilla è un'organizzazione no profit che promuove i modelli aperti. TIME ha riportato il 14 luglio che il CTO di Mozilla, Raffi Krikorian, ha descritto il report come in parte un'attività di advocacy. Questa cornice è importante quando si leggono i numeri.

La tesi centrale di Mozilla è che il miglior modello aperto ha seguito il leader chiuso sull'Artificial Analysis Intelligence Index di tre punti, al 60% del prezzo, ed era indietro di due punti rispetto a Claude Fable 5 al 30% del prezzo. Adattando i dati METR task-horizon, Mozilla colloca il divario open-closed a circa 4,4 mesi, in linea con la stima di quattro mesi di Epoch AI. METR è un'organizzazione no profit di ricerca che valuta i modelli in base alla lunghezza del task, in tempo di lavoro umano, che completano per metà del tempo.

Cosa misura realmente il divario di quattro mesi

Secondo la stima adattata di Mozilla, i modelli chiusi gestiscono task che richiedono 8 a 12 ore a esperti umani. I modelli aperti raggiungono quel livello circa quattro mesi dopo. Mozilla calcola il raddoppio della capacità open ogni 3,9 mesi contro i 5,5 mesi per i modelli chiusi. Su Terminal-Bench 2.1 di vals.ai, che fa passare ogni modello attraverso lo stesso harness, GLM-5.2 di Z.ai ha ottenuto un punteggio entro un punto da Claude Opus 4.7 e circa quattro punti dietro Opus 4.8, a meno di un quinto del costo per test.

"Vediamo la decisione di pagare per i modelli chiusi come specifica del workload piuttosto che dell'organizzazione", ha detto Krikorian ad Ars Technica in una email.

L'adozione sul lato degli sviluppatori appare diversa dai ricavi. Su OpenRouter, un marketplace che instrada il traffico verso centinaia di modelli, Mozilla ha contato otto dei primi dieci modelli per volume di token ad agosto come open-weight, sette dei quali costruiti in Cina. I fornitori chiusi hanno comunque incassato il 96% dei ricavi del layer dei modelli su OpenRouter da maggio a settembre 2025, secondo la Linux Foundation. Token gratuiti o economici e ricavi a pagamento non sono lo stesso mercato.

Mozilla conta 16 rilasci open notevoli, ma nessuno fornisce la ricetta dei dati richiesta dalla definizione di Open Source Initiative. Questa distinzione è l'intero argomento di un post OSI del 19 settembre intitolato "Open Weights Are Good. Open Source Is Better." I pesi aperti, scrive OSI, permettono di eseguire un modello localmente, pagare a un terzo di ospitarlo, o fine-tunarlo sui propri dati. Non permettono di studiarlo completamente, perché il codice e i dati di addestramento o un resoconto dettagliato di come i dati sono stati costruiti non fanno parte del rilascio.

La riserva sul hardware

La cifra di 4,4 mesi e il prezzo token del 30% sono misurati API contro API su endpoint ospitati al prezzo di listino. Il grafico hardware di Mozilla racconta una storia più dura. Il miglior modello open che sta in un server ottiene 52,6; il miglior modello che sta in una GPU ottiene 40. La caduta dalla cima è di 10 e 23 punti rispettivamente, un divario più grande di quanto implichi il periodo di quattro mesi.

Il checkpoint MXFP4 nativo di Kimi K3 occupa circa 1,56TB su 96 shard, secondo il report. La configurazione di serving di Mozilla elenca 64 o più acceleratori, mentre vLLM richiede almeno otto GPU GB300, con più nodi per il traffico di produzione. Tom's Hardware ha posto il fabbisogno di memoria vicino a 1,5TB a luglio. Il report descrive questo come aperto ma non eseguibile dalla maggior parte di chi lo possiede. Un'eccezione che cita è Inkling-Small di Thinking Machines, sotto Apache 2.0, la cui versione NVFP4 sta in un B300 con un minimo di 180GB.

C'è anche un problema di tempistica. I dati del report si fermano al 1 settembre. Da allora, Artificial Analysis ha spostato il suo indice a v4.3 con un set di valutazione diverso. La classifica live ha Claude Fable 5.1 a 53 sul suo setting di sforzo massimo con Kimi K3 a 44, numeri che Mozilla non ha tracciato e che non sono confrontabili con le cifre v4.1.1 che ha usato. La classifica Terminal-Bench 2.1 di vals.ai, aggiornata l'11 settembre, è ora guidata da GPT-6 Astra all'87,27%, con Fable 5.1 all'85,02%. La didascalia del grafico di Mozilla recita: "il divario si azzera a ogni ciclo di rilascio."

K3 porta anche un'accusa dettagliata nel consiglio congiunto NSA, CISA e FBI del 8 settembre AA26-251A. L'affermazione, che il report di Mozilla descrive come "asserita, e non dimostrata", è che Moonshot ha estratto dati di Claude Fable 5 per addestrare K3 tramite distillazione, la pratica di addestrare un modello sugli output di un altro. Il 17 luglio, Artificial Analysis aveva K3 a 57 contro i 60 di Fable 5; il 1 settembre, Mozilla lo aveva a due punti di distanza.

Piccoli modelli, compiti ristretti

Non ogni rilascio open-weight insegue la frontiera. S1-mini di Superwhisper, pubblicato su Hugging Face, è un normalizzatore di testo da 0,6B parametri per l'output speech-to-text. Prende una trascrizione ASR grezza e la riscrive come testo scritto: rimuove i riempitivi, risolve i falsi avviamenti e le autocorrezioni, applica punteggiatura e maiuscole, e rende i numeri parlati, date, orari, valute e indirizzi email in forma scritta. Su un set di tenuta di 7.519 casi inglesi raggiunge il 94,8% di accuratezza token, e la build quantizzata è un file da 462 MiB che gira su una CPU di laptop.

La scheda del modello è insolitamente diretta su ciò che non è. S1-mini non è un modello di chat e non seguirà istruzioni generali. È fine-tunato da Qwen/Qwen3-0.6B e si aspetta una riga di controllo in cima all'input che specifichi stile, struttura e contesto. La scheda avverte di saltare il system prompt, cambiarne la formulazione, o inviare valori al di fuori dei set addestrati, e il modello può allucinare o produrre output incomprensibili. È solo in inglese, licenziato Apache 2.0 più una clausola di denominazione. La sidebar Hub riporta 0,8B parametri, ma la scheda spiega che model.safetensors memorizza lm_head.weight come copia materializzata dell'embedding di input, contando l'embedding da 155,6M parametri due volte: 751,6M elementi tensor contro 596,0M parametri unici. Il layout è ereditato da Qwen3-0.6B, che riporta 0,8B per la stessa ragione.

Un pattern simile emerge in un write-up di deployment del 22 settembre di James Cruce. Ha scelto Laya, un modello decisionale open-weight da 421M parametri, rispetto a Jev ospitato di TypeSafe per le piccole scelte limitate che i suoi agenti di coding fanno. Il checkpoint, convaiinnovations/laya-typed-decisions, ha un encoder ModernBERT-large e un limite di 1.024 token, e restituisce risposte tipizzate: una scelta tra opzioni nominate, un punteggio su una scala ordinata, o una probabilità per un'affermazione sì-no. Nessun paragrafo da analizzare. Jev, al contrario, è un servizio ospitato in accesso anticipato con un prezzo di $0,042 per milione di token in input senza carica per token in output, e TypeSafe dice che gestisce scelte con fino a 255 opzioni.

La ragione dichiarata di Cruce per il cambio non era il costo. Voleva decisioni di routine che girassero sul suo Mac Studio con dati locali che restano locali, e voleva controllo sul modello esatto, le opzioni permesse e il comportamento di fallimento. Non ha calcolato un punto di pareggio e dice di non avere un numero di risparmio da fornire. Segnala anche limiti: il publisher ha addestrato Laya su quattro workflow sintetici, e il model routing non è uno di essi, quindi il risultato è un deployment su un M3 Ultra con 256GB di memoria unificata, non un verdetto generale su Laya contro Jev. La scheda del modello avverte che il modello è eccessivamente sicuro di sé e ha bisogno di calibrazione specifica di dominio. "Una risposta tipizzata può essere strutturalmente perfetta e fattualmente sbagliata", scrive.

Il quadro legale sui pesi è altrettanto insediato. Un paper di A. Feder Cooper, Mark A. Lemley e co-autori, sottomesso per la prima volta l'18 maggio 2025 e rivisto fino al 20 luglio 2026, ha misurato la memorizzazione su 200 libri e 14 modelli open-weight in oltre 3.000 esperimenti. Il suo risultato taglia contro entrambi i lati delle lotte sul copyright. La maggior parte dei modelli non memorizza la maggior parte dei libri, in tutto o in parte. Ma Llama 3.1 70B memorizza interamente alcuni, incluso Harry Potter and the Sorcerer's Stone, al punto che l'intero libro può essere estratto quasi verbatim dalle prime poche parole come prompt. Gli autori scrivono che i loro risultati hanno implicazioni significative per i casi di copyright, anche se non chiaramente a favore di una parte o dell'altra.

Nessuna di queste cose stabilisce se i pesi aperti vincono. Le metriche che appaiono migliori per l'apertura, prezzo per token e quota di traffico instradato, stanno accanto a metriche che appaiono peggiori, capacità single-server e single-GPU e quota di ricavi. La didascalia di Mozilla è il riassunto onesto: il divario si azzera a ogni ciclo di rilascio.