Gemma 4 Uitgebracht Zonder MTP-data — Waarom Dat Belangrijk Is

Google bracht Gemma 4 uit op 3 april 2026 — een familie van open-weight modellen met sterke benchmarkresultaten, multimodale mogelijkheden en tot 256K context. Op papier is het een indrukwekkende release. Maar binnen enkele uren ontdekte de gemeenschap dat er iets ontbrak: de Multi-Token Prediction-heads waren uit de publieke gewichten verwijderd.

Het model was getraind met MTP. Googles eigen LiteRT-framework bevat de MTP-componenten. Maar de versie die iedereen kan downloaden van HuggingFace? Alleen standaard autoregressieve generatie. Geen snelheidsboost. Geen speculative decoding.

Dit artikel legt uit wat MTP is, waarom het belangrijk is, en wat deze beslissing betekent voor iedereen die Gemma 4 op eigen hardware draait.

Wat Is Gemma 4?

Gemma 4 is de nieuwste open-weight modelfamilie van Google DeepMind, uitgebracht onder de Apache 2.0-licentie. Het is beschikbaar in vier formaten:

Belangrijke mogelijkheden zijn onder meer native multimodale ondersteuning, function calling, gestructureerde JSON-uitvoer en training op 140+ talen. De 31B-variant staat op #3 op het LMArena-tekstklassement.

Onder de motorkap introduceert Gemma 4 diverse architectuurinnovaties: afwisselende lokale sliding-window en globale aandachtslagen, proportionele RoPE (p-RoPE), Per-Layer Embeddings (PLE), gedeelde KV-cache en een “Keys equal Values”-geheugenoptimalisatie.

Qua cijfers is dit een sterke release. Het probleem zit in wat er niet in de publieke gewichten zit.

Wat Is Multi-Token Prediction?

Standaard grote taalmodellen genereren tekst één token per keer. Elk token vereist een volledige forward pass door het model. Het volgende token kan pas beginnen als het vorige klaar is. Dit is autoregressieve decodering, en het is inherent sequentieel.

Multi-Token Prediction (MTP) verandert dit door extra predictieheads aan het model toe te voegen. In plaats van alleen het volgende token te voorspellen, voorspelt het model tokens N+1, N+2, N+3, enzovoort — allemaal in één forward pass.

Zo werkt het:

1. Trainingsfase: Extra lichtgewicht predictieheads worden naast het hoofdmodel getraind. Elke head leert een andere toekomstige positie te voorspellen (1 vooruit, 2 vooruit, 3 vooruit, enz.)
2. Inferentiefase: De extra heads genereren “concept”-tokens parallel. Het hoofdmodel verifieert ze vervolgens allemaal in één forward pass.
3. Verificatie: Als de concepttokens overeenkomen met wat het hoofdmodel zou hebben gegenereerd, worden ze allemaal tegelijk geaccepteerd — waardoor meerdere sequentiële decodestappen worden overgeslagen. Als een concepttoken fout is, valt de generatie terug naar die positie.

Dit is nauw verwant aan speculative decoding, maar met een belangrijk voordeel: de concepttokens komen van het model zelf in plaats van dat er een apart, kleiner “concept-model” nodig is.

Hoeveel Sneller Is MTP?

De versnelling hangt af van hoe vaak de concepttokens correct zijn (de “acceptatiegraad”). DeepSeek V3 demonstreerde de praktische impact:

Een acceptatiegraad van 2,4 betekent dat elke forward pass door het hoofdmodel gemiddeld 2,4 tokens produceert in plaats van 1. De uitvoer is wiskundig identiek aan standaard decodering — elk token wordt geverifieerd. Je krijgt dezelfde kwaliteit tegen bijna dubbele snelheid.

Klaar om uw bedrijf te laten groeien?

Start vandaag uw gratis proefperiode en zie binnen enkele dagen resultaten.

Demo aanvragen Inloggen

Wat Er Gebeurde met Gemma 4

Een HuggingFace-gebruiker (@shadowlilac ) ontdekte dat Googles LiteRT-pakket voor Gemma 4 MTP-predictieheads en multi-token prediction-functionaliteit bevat. Maar de publiek vrijgegeven gewichten op HuggingFace bevatten hier niets van.

De MTP-componenten zijn bewust verwijderd:

• Geen MTP-heads in het checkpoint
• Geen MTP in de modelconfiguratie
• Geen MTP in de forward pass

Googles Uitleg

Een Google-engineer (@srikanta-221 ) bevestigde dat dit opzettelijk was:

Het publieke model biedt alleen een standaard autoregressieve interface “voor brede compatibiliteit.” MTP-heads zijn uitgesloten van de modelconfiguratie, forward pass en het checkpoint. Dit garandeert compatibiliteit met HuggingFace Transformers API’s en zorgt voor consistent checkpoint- en runtimegedrag.

Google presenteert MTP als een “deployment-time optimalisatie” in plaats van een kernfunctie van het model. De MTP-predictieheads zijn alleen bewaard in de LiteRT-geëxporteerde modellen — Googles eigen on-device inference-framework.

Waarom Dit Een Probleem Is

De uitleg houdt geen stand bij nader onderzoek:

1. Het model is getraind met MTP. De mogelijkheid bestaat. Het verwijderen uit de release is een keuze, geen technische beperking.

2. Third-party engines kunnen het niet implementeren. vLLM, llama.cpp, SGLang en andere inference-frameworks kunnen geen MTP-gebaseerde speculative decoding gebruiken zonder de predictieheads. Deze engines bedienen het overgrote deel van open-source LLM-implementaties.

3. Gebruikers krijgen de langzame versie. Zonder MTP draait Gemma 4 op standaard autoregressieve snelheden. Het prestatieverschil is in de praktijk al zichtbaar:

4. Het creëert ecosysteem-lock-in. Googles eigen LiteRT-framework krijgt het snelheidsvoordeel. Alle anderen krijgen een langzamer model. Voor een “open-weight” Apache 2.0-release is dit een aanzienlijke asymmetrie.

Hoe Speculative Decoding Werkt (en Waarom MTP Beter Is)

Om te begrijpen waarom de ontbrekende MTP-heads belangrijk zijn, helpt het om te zien waar MTP past in de evolutie van inferentie-optimalisatie.

Benadering 1: Traditionele Speculative Decoding

Een apart, kleiner “concept-model” stelt tokens voor. Het hoofdmodel verifieert ze parallel. Als de concepten correct zijn, worden er meerdere tokens per stap geaccepteerd.

• Voordelen: Werkt met elk modelpaar
• Nadelen: Vereist het onderhouden en laden van een tweede model; kwaliteit van het concept-model beperkt de versnelling; extra geheugenoverhead

Benadering 2: MTP (Ingebouwde Predictieheads)

Het hoofdmodel heeft zijn eigen lichtgewicht predictieheads die concepttokens genereren. Geen apart model nodig.

• Voordelen: Geen extra model nodig; strakkere integratie betekent hogere acceptatiegraden; minder geheugenoverhead
• Nadelen: Werkt alleen als de predictieheads zijn meegeleverd in de release

Waarom MTP Wint

MTP-predictieheads worden naast het hoofdmodel getraind. Ze delen dezelfde interne representaties en leren de tokenverdeling van het model. Dit levert doorgaans hogere acceptatiegraden op dan een extern concept-model, wat meer geaccepteerde tokens per verificatiestap betekent en snellere generatie overall.

De predictieheads zijn ook klein — ze voegen doorgaans slechts 1-3% toe aan het totale aantal parameters van het model. De geheugenoverhead is verwaarloosbaar vergeleken met het laden van een apart concept-model.

Schrijf u in voor onze nieuwsbrief

Ontvang gratis de nieuwste tips, trends en aanbiedingen.

E-mailadres

Abonneren

De Bredere Impact

Dit gaat niet alleen over Gemma 4. De beslissing schept een precedent voor hoe “open” open-weight releases werkelijk zijn.

Wat gebruikers verliezen:

• MTP-gebaseerde speculative decoding op elke third-party inference-engine
• De mogelijkheid om de MTP-heads te fine-tunen of ermee te experimenteren
• Prestatiepariteit met Googles eigen deployment-tools

Wat gebruikers nog steeds hebben:

• De basismodelgewichten (die oprecht goed zijn)
• Traditionele speculative decoding met een apart concept-model (vLLM-issue #38893 volgt Eagle3-ondersteuning voor Gemma 4)
• Standaard kwantisatie- en optimalisatietechnieken

De reactie van de gemeenschap was direct. De consensus na 24 uur was dat de benchmarkresultaten van Gemma 4 competitief zijn — het staat gelijk aan of loopt iets achter op Qwen 3.5 — maar het product “is niet af.” Snelheid, stabiliteit en tooling hebben werk nodig. Aanvullende problemen zijn onder meer dat HuggingFace Transformers aanvankelijk geen Gemma 4-architectuurondersteuning had, PEFT de nieuwe laagtypen niet aankan, en Mac-gebruikers crashes ervaren bij het laden van grotere modellen.

Wat Kun Je Doen?

Als je Gemma 4 evalueert voor deployment, zijn hier praktische opties:

Gebruik traditionele speculative decoding. Externe concept-modellen kunnen Gemma 4-inferentie nog steeds versnellen. Frameworks zoals vLLM voegen Eagle3 speculative decoding-ondersteuning toe specifiek voor Gemma 4. De versnelling zal niet gelijk zijn aan ingebouwde MTP, maar het is beter dan niets.

Overweeg alternatieven voor snelheidskritieke workloads. Qwen 3.5 levert aanzienlijk betere tokens-per-seconde op vergelijkbare hardware. Als inferentiesnelheid je primaire beperking is, biedt Qwen momenteel een betere snelheid-kwaliteitverhouding.

Houd community-workarounds in de gaten. De LiteRT-exports bevatten de MTP-heads. Onderzoekers vinden mogelijk manieren om deze te extraheren en opnieuw te koppelen aan de HuggingFace-gewichten, hoewel Google dit pad niet officieel ondersteunt.

Geef feedback. Googles engineers volgen de HuggingFace-discussiedraden actief. Duidelijke, technische verzoeken om vrijgave van de MTP-heads hebben gewicht.

Conclusie

Gemma 4 is een capabele modelfamilie met oprechte architectuurinnovaties en sterke benchmarkresultaten. De beslissing om MTP-predictieheads uit de publieke release te verwijderen — terwijl ze behouden blijven in Googles eigen LiteRT-framework — ondermijnt het “open” in open-weight.

MTP is geen kleine optimalisatie. Het kan inferentieversnellingen van 1,5–2x opleveren zonder enige impact op de uitvoerkwaliteit. Het achterhouden van de publieke gewichten terwijl het model er duidelijk mee getraind is, creëert een tweeledig systeem: snelle inferentie voor Googles tools, langzame inferentie voor alle anderen.

Voor de open-source AI-gemeenschap is de boodschap duidelijk: controleer wat er daadwerkelijk in de gewichten zit, niet alleen de benchmarks. Een open licentie betekent niet altijd een open release.

Gebouwd met FlowHunt . Blijf op de hoogte van de laatste ontwikkelingen in open-source AI op onze blog .