Gemma 4 ble lansert uten MTP-data — Her er hvorfor det betyr noe

Google lanserte Gemma 4 den 3. april 2026 — en familie med åpne vektmodeller med sterke benchmarkresultater, multimodale egenskaper og opptil 256K kontekst. På papiret er det en imponerende utgivelse. Men i løpet av timer oppdaget fellesskapet noe som manglet: Multi-Token Prediction-hodene hadde blitt fjernet fra de offentlige vektene.

Modellen ble trent med MTP. Googles eget LiteRT-rammeverk inkluderer MTP-komponentene. Men versjonen alle kan laste ned fra HuggingFace? Kun standard autoregressiv generering. Ingen hastighetsøkning. Ingen spekulativ dekoding.

Dette innlegget forklarer hva MTP er, hvorfor det betyr noe, og hva denne beslutningen innebærer for alle som kjører Gemma 4 på egen maskinvare.

Hva er Gemma 4?

Gemma 4 er Google DeepMinds nyeste familie med åpne vektmodeller, utgitt under Apache 2.0-lisensen. Den kommer i fire størrelser:

Viktige egenskaper inkluderer innebygd multimodal støtte, funksjonskall, strukturert JSON-utdata og trening på over 140 språk. 31B-varianten rangerer som #3 på LMArena-tekst-topplisten.

Under panseret introduserer Gemma 4 flere arkitektoniske nyvinninger: vekslende lokale glidende vindu- og globale oppmerksomhetslag, proporsjonal RoPE (p-RoPE), Per-Layer Embeddings (PLE), delt KV-cache og en «Keys equal Values»-minneoptimalisering.

Tallmessig er dette en sterk utgivelse. Problemet er det som ikke er med i de offentlige vektene.

Hva er Multi-Token Prediction?

Standard store språkmodeller genererer tekst ett token om gangen. Hvert token krever en full forward pass gjennom modellen. Neste token kan ikke starte før det forrige er ferdig. Dette er autoregressiv dekoding, og det er iboende sekvensielt.

Multi-Token Prediction (MTP) endrer dette ved å legge til ekstra prediksjonshodene i modellen. I stedet for å predikere bare neste token, predikerer modellen tokens N+1, N+2, N+3 og så videre — alt i en enkelt forward pass.

Slik fungerer det:

1. Treningsfase: Ekstra lette prediksjonshodene trenes sammen med hovedmodellen. Hvert hode lærer å predikere en annen fremtidig posisjon (1 fremover, 2 fremover, 3 fremover osv.)
2. Inferensfase: De ekstra hodene genererer «utkast»-tokens parallelt. Hovedmodellen verifiserer deretter alle i en enkelt forward pass.
3. Verifisering: Hvis utkast-tokenene matcher det hovedmodellen ville ha generert, aksepteres de alle på en gang — og hopper over flere sekvensielle dekodingstrinn. Hvis et utkast-token er feil, faller genereringen tilbake til den posisjonen.

Dette er nært beslektet med spekulativ dekoding, men med en nøkkelfordel: utkast-tokenene kommer fra modellen selv i stedet for å kreve en separat, mindre «utkast-modell».

Hvor mye raskere er MTP?

Hastighetsøkningen avhenger av hvor ofte utkast-tokenene er korrekte («akseptraten»). DeepSeek V3 demonstrerte den virkelige effekten:

En akseptrate på 2,4 betyr at hver forward pass gjennom hovedmodellen i gjennomsnitt produserer 2,4 tokens i stedet for 1. Utdataen er matematisk identisk med standard dekoding — hvert token er verifisert. Du får samme kvalitet med nesten dobbel hastighet.

Klar til å vokse bedriften din?

Start din gratis prøveperiode i dag og se resultater i løpet av få dager.

Be om demo Logg inn

Hva skjedde med Gemma 4

En HuggingFace-bruker (@shadowlilac ) oppdaget at Googles LiteRT-pakke for Gemma 4 inneholder MTP-prediksjonshodene og multi-token prediction-funksjonalitet. Men de offentlig utgitte vektene på HuggingFace har ingenting av dette.

MTP-komponentene ble bevisst fjernet:

• Ingen MTP-hoder i sjekkpunktet
• Ingen MTP i modellkonfigurasjonen
• Ingen MTP i forward pass

Googles forklaring

En Google-ingeniør (@srikanta-221 ) bekreftet at dette var tilsiktet:

Den offentlige modellen eksponerer kun et standard autoregressivt grensesnitt «for bred kompatibilitet.» MTP-hoder er ekskludert fra modellkonfigurasjonen, forward pass og sjekkpunktet. Dette sikrer kompatibilitet med HuggingFace Transformers API-er og opprettholder konsistent sjekkpunkt- og kjøretidsatferd.

Google fremstiller MTP som en «distribusjonsdelt-tidsoptimalisering» snarere enn en kjernefunksjon i modellen. MTP-prediksjonhodene er kun bevart i de LiteRT-eksporterte modellene — Googles eget rammeverk for inferens på enheten.

Hvorfor dette er et problem

Forklaringen holder ikke mål ved nærmere granskning:

1. Modellen ble trent med MTP. Funksjonaliteten eksisterer. Å fjerne den fra utgivelsen er et valg, ikke en teknisk begrensning.

2. Tredjepartsmotorer kan ikke implementere det. vLLM, llama.cpp, SGLang og andre inferensrammeverk kan ikke bruke MTP-basert spekulativ dekoding uten prediksjonhodene. Disse motorene betjener det store flertallet av LLM-distribusjoner med åpen kildekode.

3. Brukere får den trege versjonen. Uten MTP kjører Gemma 4 med standard autoregressive hastigheter. Ytelsesgapet er allerede synlig i praksis:

4. Det skaper økosystem-innlåsing. Googles eget LiteRT-rammeverk får hastighetsfordelen. Alle andre får en tregere modell. For en «åpen vekt»-utgivelse under Apache 2.0 er dette en betydelig asymmetri.

Hvordan spekulativ dekoding fungerer (og hvorfor MTP er bedre)

For å forstå hvorfor de manglende MTP-hodene betyr noe, er det nyttig å se hvor MTP passer inn i utviklingen av inferensoptimalisering.

Tilnærming 1: Tradisjonell spekulativ dekoding

En separat, mindre «utkast-modell» foreslår tokens. Hovedmodellen verifiserer dem parallelt. Hvis utkastene er korrekte, aksepteres flere tokens per steg.

• Fordeler: Fungerer med alle modellpar
• Ulemper: Krever vedlikehold og lasting av en ekstra modell; kvaliteten på utkast-modellen begrenser hastighetsøkningen; ekstra minneoverhead

Tilnærming 2: MTP (innebygde prediksjonshodene)

Hovedmodellen har sine egne lette prediksjonshodene som genererer utkast-tokens. Ingen separat modell nødvendig.

• Fordeler: Ingen ekstra modell nødvendig; tettere integrasjon betyr høyere akseptrater; lavere minneoverhead
• Ulemper: Fungerer kun hvis prediksjonhodene er inkludert i utgivelsen

Hvorfor MTP vinner

MTP-prediksjonshodene trenes sammen med hovedmodellen. De deler de samme interne representasjonene og lærer modellens egen token-distribusjon. Dette gir vanligvis høyere akseptrater enn en ekstern utkast-modell, som betyr flere tokens akseptert per verifiseringssteg og raskere generering totalt sett.

Prediksjonhodene er også små — de legger vanligvis bare til 1–3 % av modellens totale parameterantal. Minneoverheaden er ubetydelig sammenlignet med å laste en separat utkast-modell.

Bli med i vårt nyhetsbrev

Få de siste tipsene, trendene og tilbudene gratis.

E-postadresse

Abonner

Den bredere konsekvensen

Dette handler ikke bare om Gemma 4. Beslutningen setter presedens for hvor «åpne» utgivelser med åpne vekter faktisk er.

Hva brukerne mister:

• MTP-basert spekulativ dekoding på alle tredjeparts inferensmotorer
• Muligheten til å finjustere eller eksperimentere med MTP-hodene
• Ytelseslikhet med Googles egne distribusjonsverktøy

Hva brukerne fortsatt har:

• Basismodellvektene (som er genuint gode)
• Tradisjonell spekulativ dekoding med en separat utkast-modell (vLLM issue #38893 sporer Eagle3-støtte for Gemma 4)
• Standard kvantisering og optimaliseringsteknikker

Fellesskapets respons har vært direkte. 24-timers-konsensus var at Gemma 4s benchmarkresultater er konkurransedyktige — den ligger likt med eller litt bak Qwen 3.5 — men produktet «er ikke ferdig.» Hastighet, stabilitet og verktøystøtte trenger arbeid. Ytterligere problemer inkluderer at HuggingFace Transformers i starten manglet arkitekturstøtte for Gemma 4, PEFT håndterer ikke de nye lagtypen, og Mac-brukere opplever krasj ved lasting av større modeller.

Hva kan du gjøre?

Hvis du vurderer Gemma 4 for distribusjon, her er praktiske alternativer:

Bruk tradisjonell spekulativ dekoding. Eksterne utkast-modeller kan fortsatt akselerere Gemma 4-inferens. Rammeverk som vLLM legger til Eagle3 spekulativ dekoding-støtte spesifikt for Gemma 4. Hastighetsøkningen vil ikke matche innebygd MTP, men det er bedre enn ingenting.

Vurder alternativer for hastigheskritiske arbeidsbelastninger. Qwen 3.5 leverer betydelig bedre tokens-per-sekund på tilsvarende maskinvare. Hvis inferenshastighet er din primære begrensning, tilbyr Qwen for øyeblikket et bedre hastighet-til-kvalitet-forhold.

Følg med på fellesskapets løsninger. LiteRT-eksportene inneholder MTP-hodene. Forskere kan finne måter å trekke ut og koble dem tilbake til HuggingFace-vektene, selv om Google ikke offisielt har støttet denne veien.

Gi tilbakemelding. Googles ingeniører overvåker aktivt HuggingFace-diskusjonsstrådene. Klare, tekniske forespørsler om utgivelse av MTP-hodene har innflytelse.

Konklusjon

Gemma 4 er en kapabel modellfamilie med genuine arkitektoniske nyvinninger og sterke benchmarkresultater. Beslutningen om å fjerne MTP-prediksjonhodene fra den offentlige utgivelsen — mens de beholdes i Googles eget LiteRT-rammeverk — undergraver det «åpne» i åpne vekter.

MTP er ikke en mindre optimalisering. Det kan levere 1,5–2x raskere inferens med null påvirkning på utdatakvalitet. Å holde tilbake det fra de offentlige vektene mens modellen tydelig ble trent med det, skaper et todelt system: rask inferens for Googles verktøy, treg inferens for alle andre.

For AI-fellesskapet med åpen kildekode er budskapet klart: sjekk hva som faktisk er i vektene, ikke bare benchmarkene. En åpen lisens betyr ikke alltid en åpen utgivelse.

Bygget med FlowHunt . Hold deg oppdatert med den siste utviklingen innen åpen kildekode-AI på vår blogg .