Gemma 4 è stato rilasciato senza i dati MTP — Ecco perché è importante

Google ha rilasciato Gemma 4 il 3 aprile 2026 — una famiglia di modelli open-weight con risultati benchmark impressionanti, capacità multimodali e fino a 256K token di contesto. Sulla carta, è un rilascio notevole. Ma nel giro di poche ore, la comunità ha scoperto qualcosa di mancante: le teste di Multi-Token Prediction erano state rimosse dai pesi pubblici.

Il modello è stato addestrato con MTP. Il framework LiteRT di Google include i componenti MTP. Ma la versione che tutti possono scaricare da HuggingFace? Solo generazione autoregressiva standard. Nessun aumento di velocità. Nessuna decodifica speculativa.

Questo articolo spiega cos’è l’MTP, perché è importante e cosa significa questa decisione per chiunque esegua Gemma 4 sul proprio hardware.

Cos’è Gemma 4?

Gemma 4 è l’ultima famiglia di modelli open-weight di Google DeepMind, rilasciata con licenza Apache 2.0. È disponibile in quattro dimensioni:

Le capacità principali includono il supporto multimodale nativo, la chiamata di funzioni, l’output JSON strutturato e l’addestramento su oltre 140 lingue. La variante 31B si posiziona al terzo posto nella classifica testuale di LMArena.

Sotto il cofano, Gemma 4 introduce diverse innovazioni architetturali: livelli alternati di attenzione locale a finestra scorrevole e globale, RoPE proporzionale (p-RoPE), Per-Layer Embeddings (PLE), cache KV condivisa e un’ottimizzazione della memoria “Keys equal Values”.

Guardando i numeri, è un rilascio solido. Il problema è ciò che non c’è nei pesi pubblici.

Cos’è la Multi-Token Prediction?

I modelli linguistici di grandi dimensioni standard generano testo un token alla volta. Ogni token richiede un passaggio forward completo attraverso il modello. Il token successivo non può iniziare finché il precedente non è completato. Questa è la decodifica autoregressiva, ed è intrinsecamente sequenziale.

La Multi-Token Prediction (MTP) cambia questo paradigma aggiungendo teste di predizione extra al modello. Invece di predire solo il token successivo, il modello predice i token N+1, N+2, N+3 e così via — tutto in un singolo passaggio forward.

Ecco come funziona:

1. Fase di addestramento: Teste di predizione aggiuntive leggere vengono addestrate insieme al modello principale. Ogni testa impara a predire una posizione futura diversa (1 avanti, 2 avanti, 3 avanti, ecc.)
2. Fase di inferenza: Le teste extra generano token “bozza” in parallelo. Il modello principale poi li verifica tutti in un singolo passaggio forward.
3. Verifica: Se i token bozza corrispondono a ciò che il modello principale avrebbe generato, vengono tutti accettati in una volta — saltando più passaggi di decodifica sequenziali. Se un token bozza è errato, la generazione riparte da quella posizione.

Questo è strettamente correlato alla decodifica speculativa, ma con un vantaggio chiave: i token bozza provengono dal modello stesso piuttosto che richiedere un modello “bozza” separato e più piccolo.

Quanto è più veloce l’MTP?

L’accelerazione dipende dalla frequenza con cui i token bozza sono corretti (il “tasso di accettazione”). DeepSeek V3 ha dimostrato l’impatto nel mondo reale:

Un tasso di accettazione di 2,4 significa che in media, ogni passaggio forward attraverso il modello principale produce 2,4 token invece di 1. L’output è matematicamente identico alla decodifica standard — ogni token è verificato. Si ottiene la stessa qualità a quasi il doppio della velocità.

Pronto a far crescere il tuo business?

Inizia oggi la tua prova gratuita e vedi i risultati in pochi giorni.

Richiedi demo Accedi

Cosa è successo con Gemma 4

Un utente di HuggingFace (@shadowlilac ) ha scoperto che il pacchetto LiteRT di Google per Gemma 4 contiene teste di predizione MTP e funzionalità di predizione multi-token. Ma i pesi rilasciati pubblicamente su HuggingFace non ne contengono nessuna.

I componenti MTP sono stati deliberatamente rimossi:

• Nessuna testa MTP nel checkpoint
• Nessun MTP nella configurazione del modello
• Nessun MTP nel passaggio forward

La spiegazione di Google

Un ingegnere di Google (@srikanta-221 ) ha confermato che è stata una scelta intenzionale:

Il modello pubblico espone solo un’interfaccia autoregressiva standard “per ampia compatibilità.” Le teste MTP sono escluse dalla configurazione del modello, dal passaggio forward e dal checkpoint. Questo garantisce la compatibilità con le API di HuggingFace Transformers e mantiene un comportamento coerente del checkpoint e del runtime.

Google presenta l’MTP come un’“ottimizzazione in fase di deployment” piuttosto che una funzionalità core del modello. Le teste di predizione MTP sono preservate solo nei modelli esportati in LiteRT — il framework di inferenza on-device di Google.

Perché questo è un problema

La spiegazione non regge a un esame approfondito:

1. Il modello è stato addestrato con MTP. La capacità esiste. Rimuoverla dal rilascio è una scelta, non una limitazione tecnica.

2. I motori di terze parti non possono implementarla. vLLM, llama.cpp, SGLang e altri framework di inferenza non possono utilizzare la decodifica speculativa basata su MTP senza le teste di predizione. Questi motori servono la stragrande maggioranza dei deployment LLM open-source.

3. Gli utenti ottengono la versione lenta. Senza MTP, Gemma 4 funziona alle velocità autoregressiva standard. Il divario di prestazioni è già visibile nella pratica:

4. Crea lock-in nell’ecosistema. Il framework LiteRT di Google ottiene il vantaggio di velocità. Tutti gli altri ottengono un modello più lento. Per un rilascio “open-weight” con licenza Apache 2.0, questa è un’asimmetria significativa.

Come funziona la decodifica speculativa (e perché MTP è meglio)

Per capire perché le teste MTP mancanti sono importanti, è utile vedere dove si colloca l’MTP nell’evoluzione dell’ottimizzazione dell’inferenza.

Approccio 1: Decodifica speculativa tradizionale

Un modello “bozza” separato e più piccolo propone dei token. Il modello principale li verifica in parallelo. Se le bozze sono corrette, più token vengono accettati per passaggio.

• Pro: Funziona con qualsiasi coppia di modelli
• Contro: Richiede il mantenimento e il caricamento di un secondo modello; la qualità del modello bozza limita l’accelerazione; overhead di memoria aggiuntivo

Approccio 2: MTP (Teste di predizione integrate)

Il modello principale ha le proprie teste di predizione leggere che generano token bozza. Nessun modello separato necessario.

• Pro: Nessun modello extra necessario; un’integrazione più stretta significa tassi di accettazione più alti; minor overhead di memoria
• Contro: Funziona solo se le teste di predizione sono incluse nel rilascio

Perché MTP vince

Le teste di predizione MTP sono addestrate insieme al modello principale. Condividono le stesse rappresentazioni interne e apprendono la distribuzione dei token del modello stesso. Questo produce tipicamente tassi di accettazione più alti rispetto a un modello bozza esterno, il che significa più token accettati per passaggio di verifica e una generazione complessivamente più veloce.

Le teste di predizione sono anche piccole — aggiungono tipicamente solo l'1-3% al conteggio totale dei parametri del modello. L’overhead di memoria è trascurabile rispetto al caricamento di un modello bozza separato.

Iscriviti alla nostra newsletter

Ricevi gratuitamente gli ultimi consigli, tendenze e offerte.

Indirizzo email

Iscriviti

L’impatto più ampio

Questa non è solo una questione relativa a Gemma 4. La decisione crea un precedente su quanto siano realmente “aperti” i rilasci open-weight.

Cosa perdono gli utenti:

• La decodifica speculativa basata su MTP su qualsiasi motore di inferenza di terze parti
• La possibilità di fare fine-tuning o sperimentare con le teste MTP
• La parità di prestazioni con gli strumenti di deployment di Google

Cosa hanno ancora gli utenti:

• I pesi del modello base (che sono genuinamente buoni)
• La decodifica speculativa tradizionale utilizzando un modello bozza separato (la issue vLLM #38893 traccia il supporto Eagle3 per Gemma 4)
• Le tecniche standard di quantizzazione e ottimizzazione

La risposta della comunità è stata diretta. Il consenso nelle prime 24 ore è stato che i risultati benchmark di Gemma 4 sono competitivi — pareggia o è leggermente dietro a Qwen 3.5 — ma il prodotto “non è finito.” Velocità, stabilità e strumenti necessitano di lavoro. Ulteriori problemi includono il fatto che HuggingFace Transformers inizialmente non supportava l’architettura di Gemma 4, PEFT non gestiva i nuovi tipi di layer e gli utenti Mac riscontravano crash nel caricamento dei modelli più grandi.

Cosa puoi fare?

Se stai valutando Gemma 4 per il deployment, ecco le opzioni pratiche:

Usa la decodifica speculativa tradizionale. I modelli bozza esterni possono comunque accelerare l’inferenza di Gemma 4. Framework come vLLM stanno aggiungendo il supporto alla decodifica speculativa Eagle3 specificamente per Gemma 4. L’accelerazione non sarà pari a quella dell’MTP integrato, ma è meglio di niente.

Considera alternative per i carichi di lavoro critici in termini di velocità. Qwen 3.5 offre token-per-secondo significativamente migliori su hardware equivalente. Se la velocità di inferenza è il tuo vincolo principale, Qwen attualmente offre un miglior rapporto velocità-qualità.

Monitora i workaround della comunità. Gli export LiteRT contengono le teste MTP. I ricercatori potrebbero trovare modi per estrarle e ricollegarle ai pesi HuggingFace, anche se Google non ha ufficialmente supportato questo percorso.

Fornisci feedback. Gli ingegneri di Google stanno monitorando attivamente i thread di discussione su HuggingFace. Richieste chiare e tecniche per il rilascio delle teste MTP hanno il loro peso.

Conclusione

Gemma 4 è una famiglia di modelli capace con genuine innovazioni architetturali e risultati benchmark solidi. La decisione di rimuovere le teste di predizione MTP dal rilascio pubblico — mantenendole nel framework LiteRT di Google — mina il significato di “open” in open-weight.

L’MTP non è un’ottimizzazione minore. Può offrire accelerazioni dell’inferenza di 1,5–2x con zero impatto sulla qualità dell’output. Trattenere questa funzionalità dai pesi pubblici quando il modello è stato chiaramente addestrato con essa crea un sistema a due livelli: inferenza veloce per gli strumenti di Google, inferenza lenta per tutti gli altri.

Per la comunità AI open-source, il messaggio è chiaro: controllate cosa c’è effettivamente nei pesi, non solo i benchmark. Una licenza aperta non sempre significa un rilascio aperto.

Realizzato con FlowHunt . Resta aggiornato sugli ultimi sviluppi dell’AI open-source sul nostro blog .