Gemma 4 a fost lansat fără date MTP — De ce contează acest lucru

Google a lansat Gemma 4 pe 3 aprilie 2026 — o familie de modele cu ponderi deschise, cu rezultate puternice la benchmark-uri, capabilități multimodale și context de până la 256K. Pe hârtie, este o lansare impresionantă. Dar în câteva ore, comunitatea a descoperit ceva lipsă: capetele de Multi-Token Prediction fuseseră eliminate din ponderile publice.

Modelul a fost antrenat cu MTP. Propriul framework LiteRT al Google include componentele MTP. Dar versiunea pe care oricine o poate descărca de pe HuggingFace? Doar generare autoregresivă standard. Fără accelerare. Fără decodare speculativă.

Acest articol explică ce este MTP, de ce contează și ce înseamnă această decizie pentru oricine rulează Gemma 4 pe propriul hardware.

Ce este Gemma 4?

Gemma 4 este cea mai recentă familie de modele cu ponderi deschise de la Google DeepMind, lansată sub licența Apache 2.0. Vine în patru dimensiuni:

Capabilitățile cheie includ suport multimodal nativ, apelarea funcțiilor, output JSON structurat și antrenare pe peste 140 de limbi. Varianta 31B se clasează pe locul 3 în clasamentul text LMArena.

Sub capotă, Gemma 4 introduce mai multe inovații arhitecturale: straturi alternante de atenție locală cu fereastră glisantă și atenție globală, RoPE proporțional (p-RoPE), Per-Layer Embeddings (PLE), cache KV partajat și o optimizare de memorie „Keys equal Values".

Ca cifre, este o lansare solidă. Problema este ce nu se află în ponderile publice.

Ce este Multi-Token Prediction?

Modelele de limbaj mari standard generează text câte un token pe rând. Fiecare token necesită un pas forward complet prin model. Token-ul următor nu poate începe până când cel anterior nu este finalizat. Aceasta este decodarea autoregresivă și este inerent secvențială.

Multi-Token Prediction (MTP) schimbă acest lucru prin adăugarea de capete de predicție suplimentare modelului. În loc să prezică doar token-ul următor, modelul prezice token-urile N+1, N+2, N+3 și așa mai departe — toate într-un singur pas forward.

Iată cum funcționează:

1. Faza de antrenament: Capete de predicție suplimentare ușoare sunt antrenate alături de modelul principal. Fiecare cap învață să prezică o poziție viitoare diferită (1 înainte, 2 înainte, 3 înainte etc.)
2. Faza de inferență: Capetele suplimentare generează token-uri „draft" în paralel. Modelul principal le verifică apoi pe toate într-un singur pas forward.
3. Verificare: Dacă token-urile draft corespund cu ce ar fi generat modelul principal, toate sunt acceptate simultan — sărind mai mulți pași de decodare secvențiali. Dacă un token draft este greșit, generarea revine la acea poziție.

Aceasta este strâns legată de decodarea speculativă, dar cu un avantaj cheie: token-urile draft provin din modelul însuși, fără a necesita un model „draft" separat, mai mic.

Cât de rapid este MTP?

Accelerarea depinde de cât de des sunt corecte token-urile draft („rata de acceptare"). DeepSeek V3 a demonstrat impactul real:

O rată de acceptare de 2,4 înseamnă că, în medie, fiecare pas forward prin modelul principal produce 2,4 token-uri în loc de 1. Output-ul este matematic identic cu decodarea standard — fiecare token este verificat. Obții aceeași calitate la aproape dublu de viteză.

Pregătit să îți dezvolți afacerea?

Începe perioada de probă gratuită astăzi și vezi rezultate în câteva zile.

Solicită demo Autentificare

Ce s-a întâmplat cu Gemma 4

Un utilizator HuggingFace (@shadowlilac ) a descoperit că pachetul LiteRT al Google pentru Gemma 4 conține capete de predicție MTP și funcționalitate de multi-token prediction. Dar ponderile publicate pe HuggingFace nu conțin nimic din toate acestea.

Componentele MTP au fost eliminate deliberat:

• Fără capete MTP în checkpoint
• Fără MTP în configurația modelului
• Fără MTP în pasul forward

Explicația Google

Un inginer Google (@srikanta-221 ) a confirmat că acest lucru a fost intenționat:

Modelul public expune doar o interfață autoregresivă standard „pentru compatibilitate largă." Capetele MTP sunt excluse din configurația modelului, pasul forward și checkpoint. Aceasta asigură compatibilitatea cu API-urile HuggingFace Transformers și menține un comportament consistent al checkpoint-ului și al runtime-ului.

Google prezintă MTP ca o „optimizare la momentul implementării" mai degrabă decât o funcționalitate de bază a modelului. Capetele de predicție MTP sunt păstrate doar în modelele exportate pentru LiteRT — propriul framework de inferență pe dispozitiv al Google.

De ce este aceasta o problemă

Explicația nu rezistă la o analiză atentă:

1. Modelul a fost antrenat cu MTP. Capabilitatea există. Eliminarea ei din lansare este o alegere, nu o limitare tehnică.

2. Motoarele terțe nu o pot implementa. vLLM, llama.cpp, SGLang și alte framework-uri de inferență nu pot utiliza decodarea speculativă bazată pe MTP fără capetele de predicție. Aceste motoare deservesc marea majoritate a implementărilor LLM open-source.

3. Utilizatorii primesc versiunea lentă. Fără MTP, Gemma 4 rulează la viteze autoregresive standard. Diferența de performanță este deja vizibilă în practică:

4. Creează dependență de ecosistem. Propriul framework LiteRT al Google beneficiază de avantajul de viteză. Toți ceilalți primesc un model mai lent. Pentru o lansare „cu ponderi deschise" sub Apache 2.0, aceasta este o asimetrie semnificativă.

Cum funcționează decodarea speculativă (și de ce MTP este mai bun)

Pentru a înțelege de ce contează capetele MTP lipsă, ajută să vedem unde se încadrează MTP în evoluția optimizării inferenței.

Abordarea 1: Decodare speculativă tradițională

Un model „draft" separat, mai mic, propune token-uri. Modelul principal le verifică în paralel. Dacă draft-urile sunt corecte, mai multe token-uri sunt acceptate per pas.

• Avantaje: Funcționează cu orice pereche de modele
• Dezavantaje: Necesită menținerea și încărcarea unui al doilea model; calitatea modelului draft limitează accelerarea; overhead de memorie suplimentar

Abordarea 2: MTP (Capete de predicție integrate)

Modelul principal are propriile capete de predicție ușoare care generează token-uri draft. Nu este nevoie de un model separat.

• Avantaje: Nu necesită un model suplimentar; integrarea mai strânsă înseamnă rate de acceptare mai mari; overhead de memorie mai redus
• Dezavantaje: Funcționează doar dacă capetele de predicție sunt incluse în lansare

De ce MTP câștigă

Capetele de predicție MTP sunt antrenate alături de modelul principal. Acestea partajează aceleași reprezentări interne și învață propria distribuție de token-uri a modelului. Aceasta produce de obicei rate de acceptare mai mari decât un model draft extern, ceea ce înseamnă mai multe token-uri acceptate per pas de verificare și generare mai rapidă per ansamblu.

Capetele de predicție sunt, de asemenea, mici — adaugă de obicei doar 1-3% din numărul total de parametri ai modelului. Overhead-ul de memorie este neglijabil comparativ cu încărcarea unui model draft separat.

Abonează-te la newsletter-ul nostru

Primește cele mai recente sfaturi, tendințe și oferte gratuit.

Adresă de email

Abonează-te

Impactul mai larg

Aceasta nu este doar despre Gemma 4. Decizia stabilește un precedent pentru cât de „deschise" sunt de fapt lansările cu ponderi deschise.

Ce pierd utilizatorii:

• Decodare speculativă bazată pe MTP pe orice motor de inferență terț
• Posibilitatea de a face fine-tuning sau a experimenta cu capetele MTP
• Paritate de performanță cu propriile instrumente de implementare ale Google

Ce au încă utilizatorii:

• Ponderile de bază ale modelului (care sunt cu adevărat bune)
• Decodare speculativă tradițională folosind un model draft separat (issue-ul vLLM #38893 urmărește suportul Eagle3 pentru Gemma 4)
• Tehnici standard de cuantizare și optimizare

Reacția comunității a fost directă. Consensul la 24 de ore a fost că rezultatele benchmark Gemma 4 sunt competitive — egalează sau este ușor în urma Qwen 3.5 — dar produsul „nu este finalizat." Viteza, stabilitatea și instrumentele necesită îmbunătățiri. Probleme suplimentare includ faptul că HuggingFace Transformers nu avea inițial suport pentru arhitectura Gemma 4, PEFT nu gestionează noile tipuri de straturi, iar utilizatorii Mac experimentează blocări la încărcarea modelelor mai mari.

Ce poți face?

Dacă evaluezi Gemma 4 pentru implementare, iată opțiuni practice:

Folosește decodarea speculativă tradițională. Modelele draft externe pot accelera în continuare inferența Gemma 4. Framework-uri precum vLLM adaugă suport de decodare speculativă Eagle3 special pentru Gemma 4. Accelerarea nu va egala MTP-ul integrat, dar este mai bine decât nimic.

Consideră alternative pentru sarcinile critice de viteză. Qwen 3.5 oferă semnificativ mai multe token-uri pe secundă pe hardware echivalent. Dacă viteza de inferență este constrângerea ta principală, Qwen oferă în prezent un raport viteză-calitate mai bun.

Urmărește soluțiile comunității. Exporturile LiteRT conțin capetele MTP. Cercetătorii pot găsi modalități de a le extrage și reatașa la ponderile HuggingFace, deși Google nu a susținut oficial această cale.

Oferă feedback. Inginerii Google monitorizează activ firele de discuție de pe HuggingFace. Solicitările clare și tehnice pentru lansarea capetelor MTP au greutate.

Concluzie

Gemma 4 este o familie de modele capabilă, cu inovații arhitecturale autentice și rezultate puternice la benchmark-uri. Decizia de a elimina capetele de predicție MTP din lansarea publică — păstrându-le în propriul framework LiteRT al Google — subminează termenul „deschis" din ponderi deschise.

MTP nu este o optimizare minoră. Poate oferi accelerări de 1,5–2x la inferență cu zero impact asupra calității output-ului. Reținerea acestora din ponderile publice, în timp ce modelul a fost clar antrenat cu ele, creează un sistem cu două niveluri: inferență rapidă pentru instrumentele Google, inferență lentă pentru toți ceilalți.

Pentru comunitatea AI open-source, mesajul este clar: verificați ce se află de fapt în ponderi, nu doar benchmark-urile. O licență deschisă nu înseamnă întotdeauna o lansare deschisă.

Construit cu FlowHunt . Rămâi la curent cu cele mai recente evoluții în AI open-source pe blogul nostru.