Gemma 4 släpptes utan MTP-data — här är varför det spelar roll

Google släppte Gemma 4 den 3 april 2026 — en familj av modeller med öppna vikter med starka benchmarkresultat, multimodala funktioner och upp till 256K kontext. På pappret är det en imponerande release. Men inom några timmar upptäckte communityn att något saknades: Multi-Token Prediction-huvudena hade tagits bort från de publika vikterna.

Modellen tränades med MTP. Googles eget LiteRT-ramverk inkluderar MTP-komponenterna. Men versionen som alla kan ladda ner från HuggingFace? Enbart standard autoregressiv generering. Ingen hastighetsökning. Ingen spekulativ avkodning.

Det här inlägget förklarar vad MTP är, varför det är viktigt och vad detta beslut innebär för alla som kör Gemma 4 på sin egen hårdvara.

Vad är Gemma 4?

Gemma 4 är Google DeepMinds senaste modellfamilj med öppna vikter, släppt under Apache 2.0-licensen. Den kommer i fyra storlekar:

Nyckelförmågor inkluderar inbyggt multimodalt stöd, funktionsanrop, strukturerad JSON-utdata och träning på 140+ språk. 31B-varianten rankas som #3 på LMArenas textrankning.

Under huven introducerar Gemma 4 flera arkitektoniska innovationer: alternerande lokala glidande fönster- och globala uppmärksamhetslager, proportionell RoPE (p-RoPE), Per-Layer Embeddings (PLE), delad KV-cache och en “Keys equal Values”-minnesoptimering.

Sett till siffrorna är det en stark release. Problemet är vad som inte finns i de publika vikterna.

Vad är Multi-Token Prediction?

Standardspråkmodeller genererar text en token i taget. Varje token kräver ett fullständigt framåtpass genom modellen. Nästa token kan inte påbörjas förrän den föregående är klar. Detta är autoregressiv avkodning, och det är i grunden sekventiellt.

Multi-Token Prediction (MTP) ändrar detta genom att lägga till extra prediktionshuvuden till modellen. Istället för att bara förutsäga nästa token förutsäger modellen tokens N+1, N+2, N+3 och så vidare — allt i ett enda framåtpass.

Så här fungerar det:

1. Träningsfas: Ytterligare lättviktiga prediktionshuvuden tränas tillsammans med huvudmodellen. Varje huvud lär sig att förutsäga en annan framtida position (1 steg framåt, 2 steg framåt, 3 steg framåt osv.)
2. Inferensfas: De extra huvudena genererar “utkast”-tokens parallellt. Huvudmodellen verifierar sedan alla i ett enda framåtpass.
3. Verifiering: Om utkaststokens matchar vad huvudmodellen skulle ha genererat, accepteras alla på en gång — och flera sekventiella avkodningssteg hoppas över. Om en utkasttoken är felaktig, faller genereringen tillbaka till den positionen.

Detta är nära besläktat med spekulativ avkodning, men med en viktig fördel: utkaststokens kommer från modellen själv istället för att kräva en separat, mindre “utkastmodell.”

Hur mycket snabbare är MTP?

Hastighetsökningen beror på hur ofta utkaststokens är korrekta (“acceptansgraden”). DeepSeek V3 demonstrerade den verkliga effekten:

En acceptansgrad på 2,4 innebär att varje framåtpass genom huvudmodellen i genomsnitt producerar 2,4 tokens istället för 1. Utdatan är matematiskt identisk med standardavkodning — varje token verifieras. Du får samma kvalitet vid nästan dubbla hastigheten.

Redo att växa ditt företag?

Starta din kostnadsfria provperiod idag och se resultat inom några dagar.

Begär demo Logga in

Vad hände med Gemma 4

En HuggingFace-användare (@shadowlilac ) upptäckte att Googles LiteRT-paket för Gemma 4 innehåller MTP-prediktionshuvuden och multi-token prediction-funktionalitet. Men de publikt släppta vikterna på HuggingFace har inget av detta.

MTP-komponenterna togs medvetet bort:

• Inga MTP-huvuden i checkpointen
• Inget MTP i modellkonfigurationen
• Inget MTP i framåtpasset

Googles förklaring

En Google-ingenjör (@srikanta-221 ) bekräftade att detta var avsiktligt:

Den publika modellen exponerar enbart ett standard autoregressivt gränssnitt “för bred kompatibilitet.” MTP-huvuden är exkluderade från modellkonfigurationen, framåtpasset och checkpointen. Detta säkerställer kompatibilitet med HuggingFace Transformers API:er och upprätthåller konsekvent checkpoint- och körningsbeteende.

Google framställer MTP som en “optimering vid deployment” snarare än en kärnfunktion i modellen. MTP-prediktionshuvudena bevaras enbart i de LiteRT-exporterade modellerna — Googles eget ramverk för inferens på enheten.

Varför detta är ett problem

Förklaringen håller inte vid närmare granskning:

1. Modellen tränades med MTP. Förmågan finns. Att ta bort den från releasen är ett val, inte en teknisk begränsning.

2. Tredjepartsmotorer kan inte implementera det. vLLM, llama.cpp, SGLang och andra inferensramverk kan inte använda MTP-baserad spekulativ avkodning utan prediktionshuvudena. Dessa motorer driver den stora majoriteten av LLM-deployments med öppen källkod.

3. Användare får den långsamma versionen. Utan MTP körs Gemma 4 med standard autoregressiv hastighet. Prestandaskillnaden syns redan i praktiken:

4. Det skapar ekosysteminlåsning. Googles eget LiteRT-ramverk får hastighetsfördelen. Alla andra får en långsammare modell. För en “öppen vikter”-release under Apache 2.0 är detta en betydande asymmetri.

Hur spekulativ avkodning fungerar (och varför MTP är bättre)

För att förstå varför de saknade MTP-huvudena spelar roll, hjälper det att se var MTP passar in i utvecklingen av inferensoptimering.

Metod 1: Traditionell spekulativ avkodning

En separat, mindre “utkastmodell” föreslår tokens. Huvudmodellen verifierar dem parallellt. Om utkasten är korrekta accepteras flera tokens per steg.

• Fördelar: Fungerar med valfritt modellpar
• Nackdelar: Kräver underhåll och laddning av en andra modell; utkastmodellens kvalitet begränsar hastighetsökningen; extra minnesbelastning

Metod 2: MTP (inbyggda prediktionshuvuden)

Huvudmodellen har sina egna lättviktiga prediktionshuvuden som genererar utkaststokens. Ingen separat modell behövs.

• Fördelar: Ingen extra modell behövs; tätare integration ger högre acceptansgrad; lägre minnesbelastning
• Nackdelar: Fungerar bara om prediktionshuvudena ingår i releasen

Varför MTP vinner

MTP-prediktionshuvuden tränas tillsammans med huvudmodellen. De delar samma interna representationer och lär sig modellens egen tokenfördelning. Detta ger vanligtvis högre acceptansgrad än en extern utkastmodell, vilket innebär fler accepterade tokens per verifieringssteg och snabbare generering totalt sett.

Prediktionshuvudena är också små — de lägger vanligtvis bara till 1–3% av modellens totala parameterantal. Minnesbelastningen är försumbar jämfört med att ladda en separat utkastmodell.

Gå med i vårt nyhetsbrev

Få de senaste tipsen, trenderna och erbjudandena gratis.

E-postadress

Prenumerera

Den bredare påverkan

Det här handlar inte bara om Gemma 4. Beslutet skapar ett prejudikat för hur “öppna” releaser med öppna vikter faktiskt är.

Vad användare förlorar:

• MTP-baserad spekulativ avkodning på valfri tredjepartsinferensmotor
• Möjligheten att finjustera eller experimentera med MTP-huvudena
• Prestandaparitet med Googles egna deployment-verktyg

Vad användare fortfarande har:

• Basmodellens vikter (som verkligen är bra)
• Traditionell spekulativ avkodning med en separat utkastmodell (vLLM issue #38893 spårar Eagle3-stöd för Gemma 4)
• Standardtekniker för kvantisering och optimering

Communityns respons har varit tydlig. Konsensus efter 24 timmar var att Gemma 4:s benchmarkresultat är konkurrenskraftiga — den ligger jämnt med eller strax efter Qwen 3.5 — men produkten “är inte färdig.” Hastighet, stabilitet och verktyg behöver arbete. Ytterligare problem inkluderar att HuggingFace Transformers inledningsvis saknade stöd för Gemma 4-arkitekturen, att PEFT inte hanterade de nya lagertyperna och att Mac-användare upplevde krascher vid laddning av större modeller.

Vad kan du göra?

Om du utvärderar Gemma 4 för deployment, här är praktiska alternativ:

Använd traditionell spekulativ avkodning. Externa utkastmodeller kan fortfarande accelerera Gemma 4-inferens. Ramverk som vLLM lägger till Eagle3-stöd för spekulativ avkodning specifikt för Gemma 4. Hastighetsökningen matchar inte inbyggd MTP, men det är bättre än ingenting.

Överväg alternativ för hastighetsintensiva arbetsbelastningar. Qwen 3.5 levererar betydligt bättre tokens per sekund på likvärdig hårdvara. Om inferenshastighet är din främsta begränsning erbjuder Qwen för närvarande ett bättre förhållande mellan hastighet och kvalitet.

Håll utkik efter communityns lösningar. LiteRT-exporterna innehåller MTP-huvudena. Forskare kan hitta sätt att extrahera och återkoppla dem till HuggingFace-vikterna, även om Google inte officiellt har stött denna väg.

Ge feedback. Googles ingenjörer övervakar aktivt HuggingFace-diskussionstrådarna. Tydliga, tekniska förfrågningar om att släppa MTP-huvudena har genomslagskraft.

Slutsats

Gemma 4 är en kapabel modellfamilj med genuina arkitektoniska innovationer och starka benchmarkresultat. Beslutet att ta bort MTP-prediktionshuvuden från den publika releasen — samtidigt som de behålls i Googles eget LiteRT-ramverk — underminerar det “öppna” i öppna vikter.

MTP är inte en mindre optimering. Det kan leverera 1,5–2x snabbare inferens utan påverkan på utdatakvaliteten. Att undanhålla det från de publika vikterna när modellen uppenbarligen tränades med det skapar ett tvåskiktssystem: snabb inferens för Googles verktyg, långsam inferens för alla andra.

För AI-communityn med öppen källkod är budskapet tydligt: kontrollera vad som faktiskt finns i vikterna, inte bara benchmarks. En öppen licens innebär inte alltid en öppen release.

Byggd med FlowHunt . Håll dig uppdaterad med den senaste utvecklingen inom AI med öppen källkod på vår blogg .