Gemma 4 blev udgivet uden MTP-data — her er hvorfor det er vigtigt

Google udgav Gemma 4 den 3. april 2026 — en familie af open-weight-modeller med stærke benchmarkresultater, multimodale evner og op til 256K kontekst. På papiret er det en imponerende udgivelse. Men inden for få timer opdagede fællesskabet noget manglende: Multi-Token Prediction-hovederne var blevet fjernet fra de offentlige vægte.

Modellen blev trænet med MTP. Googles eget LiteRT-framework indeholder MTP-komponenterne. Men den version, alle kan downloade fra HuggingFace? Kun standard autoregressiv generering. Ingen hastighedsboost. Ingen speculative decoding.

Dette indlæg forklarer, hvad MTP er, hvorfor det er vigtigt, og hvad denne beslutning betyder for alle, der kører Gemma 4 på deres egen hardware.

Hvad er Gemma 4?

Gemma 4 er Google DeepMinds nyeste open-weight-modelfamilie, udgivet under Apache 2.0-licensen. Den kommer i fire størrelser:

Nøglefunktioner inkluderer native multimodal understøttelse, funktionskald, struktureret JSON-output og træning på 140+ sprog. 31B-varianten rangerer som #3 på LMArena-tekstranglisten.

Under motorhjelmen introducerer Gemma 4 flere arkitektoniske innovationer: alternerende lokale sliding-window- og globale attention-lag, proportional RoPE (p-RoPE), Per-Layer Embeddings (PLE), delt KV-cache og en “Keys equal Values”-hukommelsesoptimering.

Talmæssigt er det en stærk udgivelse. Problemet er, hvad der ikke er med i de offentlige vægte.

Hvad er Multi-Token Prediction?

Standard store sprogmodeller genererer tekst én token ad gangen. Hver token kræver et fuldt forward pass gennem modellen. Den næste token kan ikke starte, før den forrige er færdig. Dette er autoregressiv dekodning, og det er i sagens natur sekventielt.

Multi-Token Prediction (MTP) ændrer dette ved at tilføje ekstra prædiktionshoveder til modellen. I stedet for kun at forudsige den næste token, forudsiger modellen tokens N+1, N+2, N+3 og så videre — alt i et enkelt forward pass.

Sådan fungerer det:

1. Træningsfasen: Ekstra letvægts-prædiktionshoveder trænes sideløbende med hovedmodellen. Hvert hoved lærer at forudsige en forskellig fremtidig position (1 frem, 2 frem, 3 frem osv.)
2. Inferensfasen: De ekstra hoveder genererer “udkast”-tokens parallelt. Hovedmodellen verificerer dem derefter alle i et enkelt forward pass.
3. Verifikation: Hvis udkasttokens matcher, hvad hovedmodellen ville have genereret, accepteres de alle på én gang — og flere sekventielle dekodningsskridt springes over. Hvis en udkasttoken er forkert, falder genereringen tilbage til den position.

Dette er tæt beslægtet med speculative decoding, men med en vigtig fordel: udkasttokens kommer fra selve modellen i stedet for at kræve en separat, mindre “udkastmodel.”

Hvor meget hurtigere er MTP?

Hastighedsforøgelsen afhænger af, hvor ofte udkasttokens er korrekte (“acceptraten”). DeepSeek V3 demonstrerede den praktiske effekt:

En acceptrate på 2,4 betyder, at hvert forward pass gennem hovedmodellen i gennemsnit producerer 2,4 tokens i stedet for 1. Outputtet er matematisk identisk med standard dekodning — hver token er verificeret. Du får den samme kvalitet med næsten dobbelt hastighed.

Klar til at vokse din virksomhed?

Start din gratis prøveperiode i dag og se resultater inden for få dage.

Anmod om demo Log ind

Hvad skete der med Gemma 4

En HuggingFace-bruger (@shadowlilac ) opdagede, at Googles LiteRT-pakke til Gemma 4 indeholder MTP-prædiktionshoveder og multi-token prediction-funktionalitet. Men de offentligt udgivne vægte på HuggingFace har intet af det.

MTP-komponenterne blev bevidst fjernet:

• Ingen MTP-hoveder i checkpoint
• Ingen MTP i modelkonfigurationen
• Ingen MTP i forward pass

Googles forklaring

En Google-ingeniør (@srikanta-221 ) bekræftede, at dette var bevidst:

Den offentlige model eksponerer kun en standard autoregressiv grænseflade “for bred kompatibilitet.” MTP-hoveder er udelukket fra modelkonfigurationen, forward pass og checkpoint. Dette sikrer kompatibilitet med HuggingFace Transformers API’er og opretholder konsistent checkpoint- og runtime-adfærd.

Google fremstiller MTP som en “deploymenttidsoptimering” snarere end en kernefunktion i modellen. MTP-prædiktionshovederne er kun bevaret i de LiteRT-eksporterede modeller — Googles eget on-device inferens-framework.

Hvorfor dette er et problem

Forklaringen holder ikke ved nærmere eftersyn:

1. Modellen blev trænet med MTP. Kapaciteten eksisterer. At fjerne den fra udgivelsen er et valg, ikke en teknisk begrænsning.

2. Tredjepartsmotorer kan ikke implementere det. vLLM, llama.cpp, SGLang og andre inferens-frameworks kan ikke bruge MTP-baseret speculative decoding uden prædiktionshovederne. Disse motorer betjener langt størstedelen af open source LLM-deployments.

3. Brugerne får den langsomme version. Uden MTP kører Gemma 4 med standard autoregressive hastigheder. Ydelsesgabet er allerede synligt i praksis:

4. Det skaber økosystemlåsning. Googles eget LiteRT-framework får hastighedsfordelen. Alle andre får en langsommere model. For en “open-weight” Apache 2.0-udgivelse er dette en markant asymmetri.

Sådan fungerer speculative decoding (og hvorfor MTP er bedre)

For at forstå, hvorfor de manglende MTP-hoveder er vigtige, hjælper det at se, hvor MTP passer ind i udviklingen af inferensoptimering.

Tilgang 1: Traditionel speculative decoding

En separat, mindre “udkastmodel” foreslår tokens. Hovedmodellen verificerer dem parallelt. Hvis udkastene er korrekte, accepteres flere tokens per skridt.

• Fordele: Fungerer med ethvert modelpar
• Ulemper: Kræver vedligeholdelse og indlæsning af en anden model; udkastmodellens kvalitet begrænser speedup; ekstra hukommelsesomkostninger

Tilgang 2: MTP (indbyggede prædiktionshoveder)

Hovedmodellen har sine egne letvægts-prædiktionshoveder, der genererer udkasttokens. Ingen separat model nødvendig.

• Fordele: Ingen ekstra model nødvendig; tættere integration betyder højere acceptrater; lavere hukommelsesomkostninger
• Ulemper: Fungerer kun, hvis prædiktionshovederne er inkluderet i udgivelsen

Hvorfor MTP vinder

MTP-prædiktionshoveder trænes sideløbende med hovedmodellen. De deler de samme interne repræsentationer og lærer modellens egen tokenfordeling. Dette producerer typisk højere acceptrater end en ekstern udkastmodel, hvilket betyder flere tokens accepteret per verifikationsskridt og hurtigere generering samlet set.

Prædiktionshovederne er også små — de tilføjer typisk kun 1-3% til modellens samlede parameterantal. Hukommelsesomkostningerne er ubetydelige sammenlignet med at indlæse en separat udkastmodel.

Tilmeld dig vores nyhedsbrev

Få de seneste tips, trends og tilbud gratis.

E-mailadresse

Tilmeld

Den bredere påvirkning

Det handler ikke kun om Gemma 4. Beslutningen sætter en præcedens for, hvor “åbne” open-weight-udgivelser egentlig er.

Hvad brugerne mister:

• MTP-baseret speculative decoding på enhver tredjeparts inferensmotor
• Muligheden for at finjustere eller eksperimentere med MTP-hovederne
• Ydelsesparitet med Googles egne deploymentværktøjer

Hvad brugerne stadig har:

• Basismodellens vægte (som er genuint gode)
• Traditionel speculative decoding med en separat udkastmodel (vLLM issue #38893 sporer Eagle3-understøttelse til Gemma 4)
• Standard kvantiserings- og optimeringsteknikker

Fællesskabets reaktion har været direkte. Konsensussen efter 24 timer var, at Gemma 4’s benchmarkresultater er konkurrencedygtige — den ligger lige med eller en smule efter Qwen 3.5 — men produktet “er ikke færdigt.” Hastighed, stabilitet og værktøj mangler. Yderligere problemer inkluderer, at HuggingFace Transformers i starten manglede Gemma 4-arkitekturunderstøttelse, at PEFT ikke håndterer de nye lagtyper, og at Mac-brugere oplever nedbrud ved indlæsning af de større modeller.

Hvad kan du gøre?

Hvis du evaluerer Gemma 4 til deployment, er her praktiske muligheder:

Brug traditionel speculative decoding. Eksterne udkastmodeller kan stadig accelerere Gemma 4-inferens. Frameworks som vLLM tilføjer Eagle3 speculative decoding-understøttelse specifikt til Gemma 4. Speeduppen matcher ikke indbygget MTP, men det er bedre end ingenting.

Overvej alternativer til hastighedskritiske arbejdsbyrder. Qwen 3.5 leverer markant bedre tokens-per-sekund på tilsvarende hardware. Hvis inferenshastighed er din primære begrænsning, tilbyder Qwen i øjeblikket et bedre hastighed-til-kvalitet-forhold.

Hold øje med fællesskabets workarounds. LiteRT-eksporterne indeholder MTP-hovederne. Forskere kan finde måder at udtrække og genkoble dem til HuggingFace-vægtene, selvom Google ikke officielt har understøttet denne vej.

Giv feedback. Googles ingeniører overvåger aktivt HuggingFace-diskussionstrådene. Klare, tekniske anmodninger om udgivelse af MTP-hoveder har vægt.

Konklusion

Gemma 4 er en kompetent modelfamilie med genuint arkitektoniske innovationer og stærke benchmarkresultater. Beslutningen om at fjerne MTP-prædiktionshoveder fra den offentlige udgivelse — mens de bevares i Googles eget LiteRT-framework — underminerer det “åbne” i open-weight.

MTP er ikke en mindre optimering. Det kan levere 1,5–2x inferensspeedups uden påvirkning af outputkvalitet. At tilbageholde det fra de offentlige vægte, mens modellen tydeligt blev trænet med det, skaber et to-trins system: hurtig inferens til Googles værktøjer, langsom inferens til alle andre.

For open source AI-fællesskabet er budskabet klart: tjek hvad der faktisk er i vægtene, ikke kun benchmarks. En åben licens betyder ikke altid en åben udgivelse.

Bygget med FlowHunt . Hold dig opdateret med den seneste udvikling inden for open source AI på vores blog .