Gemma 4 vyšla bez MTP dat — proč je to důležité

Google vydal Gemma 4 dne 3. dubna 2026 — rodinu modelů s otevřenými váhami, silnými benchmarkovými výsledky, multimodálními schopnostmi a kontextem až 256K. Na papíře je to impozantní vydání. Během několika hodin však komunita zjistila, že něco chybí: Multi-Token Prediction hlavy byly z veřejných vah odstraněny.

Model byl s MTP trénován. Vlastní LiteRT framework od Googlu MTP komponenty obsahuje. Ale verze, kterou si může každý stáhnout z HuggingFace? Pouze standardní autoregresivní generování. Žádné zrychlení. Žádné spekulativní dekódování.

Tento článek vysvětluje, co je MTP, proč je důležité a co toto rozhodnutí znamená pro každého, kdo provozuje Gemma 4 na vlastním hardwaru.

Co je Gemma 4?

Gemma 4 je nejnovější rodina modelů s otevřenými váhami od Google DeepMind, vydaná pod licencí Apache 2.0. Je dostupná ve čtyřech velikostech:

Mezi klíčové schopnosti patří nativní multimodální podpora, volání funkcí, strukturovaný JSON výstup a trénink na 140+ jazycích. Varianta 31B se umístila na 3. místě žebříčku LMArena pro text.

Pod kapotou přináší Gemma 4 několik architektonických inovací: střídající se lokální sliding-window a globální attention vrstvy, proporcionální RoPE (p-RoPE), Per-Layer Embeddings (PLE), sdílenou KV cache a paměťovou optimalizaci „Keys equal Values".

Podle čísel je to silné vydání. Problém je v tom, co ve veřejných váhách není.

Co je Multi-Token Prediction?

Standardní velké jazykové modely generují text po jednom tokenu. Každý token vyžaduje kompletní průchod modelem. Další token nemůže začít, dokud není předchozí dokončen. Jedná se o autoregresivní dekódování a je ze své podstaty sekvenční.

Multi-Token Prediction (MTP) toto mění přidáním dalších predikčních hlav do modelu. Místo predikce pouze dalšího tokenu model predikuje tokeny N+1, N+2, N+3 a další — vše v jednom průchodu.

Jak to funguje:

1. Fáze tréninku: Společně s hlavním modelem jsou trénovány další lehké predikční hlavy. Každá hlava se učí predikovat jinou budoucí pozici (1 dopředu, 2 dopředu, 3 dopředu atd.)
2. Fáze inference: Další hlavy generují „náčrtové" tokeny paralelně. Hlavní model je poté všechny ověří v jednom průchodu.
3. Ověření: Pokud se náčrtové tokeny shodují s tím, co by hlavní model vygeneroval, jsou všechny přijaty najednou — čímž se přeskočí více sekvenčních dekódovacích kroků. Pokud je náčrtový token chybný, generování se vrací na tuto pozici.

To úzce souvisí se spekulativním dekódováním, ale s klíčovou výhodou: náčrtové tokeny pocházejí ze samotného modelu, místo aby vyžadovaly samostatný, menší „náčrtový model".

O kolik je MTP rychlejší?

Zrychlení závisí na tom, jak často jsou náčrtové tokeny správné (míra přijetí, „acceptance rate"). DeepSeek V3 demonstroval reálný dopad:

Míra přijetí 2,4 znamená, že v průměru každý průchod hlavním modelem vyprodukuje 2,4 tokenu místo 1. Výstup je matematicky identický se standardním dekódováním — každý token je ověřen. Získáte stejnou kvalitu při téměř dvojnásobné rychlosti.

Připraveni rozšířit své podnikání?

Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.

Požádat o demo Přihlásit se

Co se stalo s Gemma 4

Uživatel HuggingFace (@shadowlilac ) zjistil, že LiteRT balíček od Googlu pro Gemma 4 obsahuje MTP predikční hlavy a funkcionalitu multi-token prediction. Veřejně vydané váhy na HuggingFace však nic z toho neobsahují.

MTP komponenty byly záměrně odstraněny:

• Žádné MTP hlavy v checkpointu
• Žádné MTP v konfiguraci modelu
• Žádné MTP v průchodu (forward pass)

Vyjádření Googlu

Inženýr Googlu (@srikanta-221 ) potvrdil, že šlo o záměr:

Veřejný model nabízí pouze standardní autoregresivní rozhraní „pro širokou kompatibilitu". MTP hlavy jsou vyloučeny z konfigurace modelu, průchodu a checkpointu. Tím je zajištěna kompatibilita s HuggingFace Transformers API a konzistentní chování checkpointu a běhového prostředí.

Google prezentuje MTP jako „optimalizaci při nasazení" spíše než jako klíčovou vlastnost modelu. MTP predikční hlavy jsou zachovány pouze v modelech exportovaných pro LiteRT — vlastní framework Googlu pro inference na zařízení.

Proč je to problém

Vysvětlení neobstojí při bližším zkoumání:

1. Model byl s MTP trénován. Schopnost existuje. Její odstranění z vydání je volba, nikoli technické omezení.

2. Enginy třetích stran ji nemohou implementovat. vLLM, llama.cpp, SGLang a další inference frameworky nemohou využívat spekulativní dekódování založené na MTP bez predikčních hlav. Tyto enginy obsluhují drtivou většinu open-source LLM nasazení.

3. Uživatelé dostávají pomalou verzi. Bez MTP běží Gemma 4 standardní autoregresivní rychlostí. Výkonnostní rozdíl je v praxi již patrný:

4. Vytváří to vendor lock-in. Vlastní LiteRT framework Googlu získává výhodu rychlosti. Všichni ostatní dostávají pomalejší model. Pro vydání s „otevřenými váhami" pod Apache 2.0 je to značná asymetrie.

Jak funguje spekulativní dekódování (a proč je MTP lepší)

Abychom pochopili, proč chybějící MTP hlavy záleží, pomůže vidět, kde se MTP nachází ve vývoji optimalizace inference.

Přístup 1: Tradiční spekulativní dekódování

Samostatný, menší „náčrtový model" navrhuje tokeny. Hlavní model je ověřuje paralelně. Pokud jsou náčrty správné, je přijato více tokenů za krok.

• Výhody: Funguje s jakoukoli dvojicí modelů
• Nevýhody: Vyžaduje údržbu a načítání druhého modelu; kvalita náčrtového modelu omezuje zrychlení; vyšší paměťová náročnost

Přístup 2: MTP (vestavěné predikční hlavy)

Hlavní model má vlastní lehké predikční hlavy, které generují náčrtové tokeny. Žádný samostatný model není potřeba.

• Výhody: Žádný další model; těsnější integrace znamená vyšší míru přijetí; nižší paměťová náročnost
• Nevýhody: Funguje pouze tehdy, pokud jsou predikční hlavy zahrnuty ve vydání

Proč MTP vítězí

MTP predikční hlavy jsou trénovány společně s hlavním modelem. Sdílejí stejné interní reprezentace a učí se vlastní distribuci tokenů modelu. To obvykle produkuje vyšší míru přijetí než externí náčrtový model, což znamená více přijatých tokenů na ověřovací krok a celkově rychlejší generování.

Predikční hlavy jsou navíc malé — obvykle přidávají pouze 1–3 % k celkovému počtu parametrů modelu. Paměťová náročnost je zanedbatelná ve srovnání s načítáním samostatného náčrtového modelu.

Přihlaste se k odběru newsletteru

Získejte nejnovější tipy, trendy a nabídky zdarma.

E-mailová adresa

Přihlásit se

Širší dopad

Nejde jen o Gemma 4. Toto rozhodnutí vytváří precedent pro to, jak „otevřená" jsou vydání s otevřenými váhami ve skutečnosti.

Co uživatelé ztrácejí:

• Spekulativní dekódování založené na MTP na jakémkoli inference enginu třetí strany
• Možnost doladit nebo experimentovat s MTP hlavami
• Výkonnostní paritu s vlastními nástroji Googlu pro nasazení

Co uživatelé stále mají:

• Váhy základního modelu (které jsou skutečně kvalitní)
• Tradiční spekulativní dekódování pomocí samostatného náčrtového modelu (vLLM issue #38893 sleduje podporu Eagle3 pro Gemma 4)
• Standardní kvantizační a optimalizační techniky

Reakce komunity byla přímočará. Během 24 hodin panoval konsensus, že benchmarkové výsledky Gemma 4 jsou konkurenceschopné — vyrovnává se nebo mírně zaostává za Qwen 3.5 — ale produkt „není hotový". Rychlost, stabilita a nástroje potřebují práci. Mezi další problémy patří, že HuggingFace Transformers zpočátku nepodporovaly architekturu Gemma 4, PEFT nezvládal nové typy vrstev a uživatelé Maců zažívali pády při načítání větších modelů.

Co můžete udělat?

Pokud zvažujete Gemma 4 pro nasazení, zde jsou praktické možnosti:

Použijte tradiční spekulativní dekódování. Externí náčrtové modely mohou stále zrychlit inference Gemma 4. Frameworky jako vLLM přidávají podporu Eagle3 spekulativního dekódování speciálně pro Gemma 4. Zrychlení nebude odpovídat vestavěnému MTP, ale je to lepší než nic.

Zvažte alternativy pro úlohy citlivé na rychlost. Qwen 3.5 poskytuje výrazně lepší tokeny za sekundu na ekvivalentním hardwaru. Pokud je rychlost inference vaším hlavním omezením, Qwen v současnosti nabízí lepší poměr rychlosti ke kvalitě.

Sledujte komunitní obcházení. LiteRT exporty obsahují MTP hlavy. Výzkumníci mohou najít způsoby, jak je extrahovat a znovu připojit k váhám na HuggingFace, ačkoli Google tuto cestu oficiálně nepodporuje.

Poskytněte zpětnou vazbu. Inženýři Googlu aktivně sledují diskuzní vlákna na HuggingFace. Jasné, technické požadavky na vydání MTP hlav mají váhu.

Závěr

Gemma 4 je schopná rodina modelů s autentickými architektonickými inovacemi a silnými benchmarkovými výsledky. Rozhodnutí odstranit MTP predikční hlavy z veřejného vydání — a zároveň je ponechat ve vlastním LiteRT frameworku Googlu — podkopává „otevřenost" v otevřených váhách.

MTP není drobná optimalizace. Může přinést 1,5–2× zrychlení inference s nulovým dopadem na kvalitu výstupu. Zadržování tohoto prvku ve veřejných váhách, když byl model jednoznačně s ním trénován, vytváří dvouúrovňový systém: rychlou inferenci pro nástroje Googlu, pomalou inferenci pro všechny ostatní.

Pro open-source AI komunitu je poselství jasné: kontrolujte, co je skutečně ve váhách, nejen v benchmarcích. Otevřená licence neznamená vždy otevřené vydání.

Vytvořeno s FlowHunt . Sledujte nejnovější vývoj v open-source AI na našem blogu .