Gemma 4 julkaistiin ilman MTP-dataa — miksi sillä on merkitystä

Google julkaisi Gemma 4:n 3. huhtikuuta 2026 — avoimen painojen malliperheen, jolla on vahvat vertailuarvotulokset, multimodaaliset ominaisuudet ja jopa 256K konteksti. Paperilla se on vaikuttava julkaisu. Mutta muutamassa tunnissa yhteisö havaitsi jotain puuttuvan: Multi-Token Prediction -päät oli poistettu julkisista painoista.

Malli koulutettiin MTP:llä. Googlen oma LiteRT-kehys sisältää MTP-komponentit. Mutta versio, jonka kaikki voivat ladata HuggingFacesta? Ainoastaan tavallinen autoregressiivinen generointi. Ei nopeushyötyä. Ei spekulatiivista dekoodausta.

Tässä artikkelissa selitämme, mikä MTP on, miksi sillä on merkitystä ja mitä tämä päätös tarkoittaa kaikille, jotka ajavat Gemma 4:ää omalla laitteistollaan.

Mikä on Gemma 4?

Gemma 4 on Google DeepMindin uusin avoimen painojen malliperheen julkaisu Apache 2.0 -lisenssillä. Se sisältää neljä kokoa:

Keskeisiä ominaisuuksia ovat natiivi multimodaalituki, funktiokutsut, strukturoitu JSON-tuloste ja koulutus yli 140 kielellä. 31B-variantti sijoittuu kolmanneksi LMArena-tekstituloslistalla.

Arkkitehtuurin alla Gemma 4 tuo useita innovaatioita: vuorottelevat paikalliset liukuikkunat ja globaalit attention-kerrokset, suhteellinen RoPE (p-RoPE), kerroskohtaiset upotukset (PLE), jaettu KV-välimuisti ja “Keys equal Values” -muistioptimointeja.

Lukujen valossa tämä on vahva julkaisu. Ongelma on siinä, mitä julkisista painoista puuttuu.

Mikä on Multi-Token Prediction?

Tavalliset suuret kielimallit tuottavat tekstiä yksi token kerrallaan. Jokainen token vaatii täyden eteenpäin-laskennan mallin läpi. Seuraavaa tokenia ei voi aloittaa ennen kuin edellinen on valmis. Tämä on autoregressiivinen dekoodaus, ja se on luonteeltaan peräkkäistä.

Multi-Token Prediction (MTP) muuttaa tämän lisäämällä malliin ylimääräisiä ennustuspäitä. Pelkän seuraavan tokenin ennustamisen sijaan malli ennustaa tokeneita N+1, N+2, N+3 ja niin edelleen — kaikki yhdellä eteenpäin-laskennalla.

Näin se toimii:

1. Koulutusvaihe: Päämallin rinnalle koulutetaan ylimääräisiä kevyitä ennustuspäitä. Kukin pää oppii ennustamaan eri tulevaa positiota (1 eteenpäin, 2 eteenpäin, 3 eteenpäin jne.)
2. Päättelyvaihe: Ylimääräiset päät tuottavat “luonnostokeneita” rinnakkain. Päämalli vahvistaa ne sitten yhdellä eteenpäin-laskennalla.
3. Vahvistus: Jos luonnostokenit vastaavat sitä, mitä päämalli olisi tuottanut, ne kaikki hyväksytään kerralla — ohittaen useita peräkkäisiä dekoodausvaiheita. Jos luonnostoken on väärä, generointi palaa kyseiseen kohtaan.

Tämä liittyy läheisesti spekulatiiviseen dekoodaukseen, mutta sillä on keskeinen etu: luonnostokenit tulevat mallista itsestään eikä erillistä, pienempää “luonnosmallia” tarvita.

Kuinka paljon nopeampi MTP on?

Nopeuslisä riippuu siitä, kuinka usein luonnostokenit ovat oikein (“hyväksymisaste”). DeepSeek V3 osoitti käytännön vaikutuksen:

Hyväksymisaste 2,4 tarkoittaa, että keskimäärin jokainen eteenpäin-laskenta päämallin läpi tuottaa 2,4 tokenia yhden sijaan. Tuloste on matemaattisesti identtinen tavalliseen dekoodaukseen — jokainen token vahvistetaan. Saat saman laadun lähes kaksinkertaisella nopeudella.

Valmis kasvattamaan liiketoimintaasi?

Aloita ilmainen kokeilujakso tänään ja näe tulokset muutamassa päivässä.

Pyydä demo Kirjaudu sisään

Mitä Gemma 4:lle tapahtui

HuggingFace-käyttäjä (@shadowlilac ) havaitsi, että Googlen Gemma 4:n LiteRT-paketti sisältää MTP-ennustuspäät ja monitokeniennustustoiminnallisuuden. Mutta julkisesti julkaistuissa HuggingFace-painoissa ei ole mitään näistä.

MTP-komponentit poistettiin tarkoituksella:

• Ei MTP-päitä tarkistuspisteessä
• Ei MTP:tä mallikonfiguraatiossa
• Ei MTP:tä eteenpäin-laskennassa

Googlen selitys

Googlen insinööri (@srikanta-221 ) vahvisti, että tämä oli tarkoituksellista:

Julkinen malli tarjoaa vain tavallisen autoregressiivisen rajapinnan “laajan yhteensopivuuden” vuoksi. MTP-päät on jätetty pois mallikonfiguraatiosta, eteenpäin-laskennasta ja tarkistuspisteestä. Tämä varmistaa yhteensopivuuden HuggingFace Transformers API:en kanssa ja ylläpitää yhdenmukaista tarkistuspisteen ja ajonaikaista käyttäytymistä.

Google kehystää MTP:n “käyttöönoton aikaiseksi optimoinniksi” eikä mallin ydinominaisuudeksi. MTP-ennustuspäät on säilytetty ainoastaan LiteRT-viedyissä malleissa — Googlen omassa laitepäättelykehyksessä.

Miksi tämä on ongelma

Selitys ei kestä tarkempaa tarkastelua:

1. Malli koulutettiin MTP:llä. Ominaisuus on olemassa. Sen poistaminen julkaisusta on valinta, ei tekninen rajoite.

2. Kolmannen osapuolen moottorit eivät voi toteuttaa sitä. vLLM, llama.cpp, SGLang ja muut päättelykehykset eivät voi käyttää MTP-pohjaista spekulatiivista dekoodausta ilman ennustuspäitä. Nämä moottorit palvelevat valtaosaa avoimen lähdekoodin LLM-käyttöönotoista.

3. Käyttäjät saavat hitaan version. Ilman MTP:tä Gemma 4 toimii tavallisilla autoregressiivisillä nopeuksilla. Suorituskykyero näkyy jo käytännössä:

4. Se luo ekosysteemilukon. Googlen oma LiteRT-kehys saa nopeusedun. Kaikki muut saavat hitaamman mallin. “Avointen painojen” Apache 2.0 -julkaisuksi tämä on merkittävä epäsymmetria.

Miten spekulatiivinen dekoodaus toimii (ja miksi MTP on parempi)

Ymmärtääksesi miksi puuttuvat MTP-päät ovat merkityksellisiä, on hyödyllistä nähdä, mihin MTP sijoittuu päättelyoptimoinnin kehityksessä.

Lähestymistapa 1: Perinteinen spekulatiivinen dekoodaus

Erillinen, pienempi “luonnosmalli” ehdottaa tokeneita. Päämalli vahvistaa ne rinnakkain. Jos luonnokset ovat oikein, useita tokeneita hyväksytään per vaihe.

• Edut: Toimii millä tahansa malliparilla
• Haitat: Vaatii toisen mallin ylläpidon ja lataamisen; luonnosmallin laatu rajoittaa nopeuslisää; ylimääräistä muistikuormaa

Lähestymistapa 2: MTP (sisäänrakennetut ennustuspäät)

Päämallin omat kevyet ennustuspäät tuottavat luonnostokeneita. Erillistä mallia ei tarvita.

• Edut: Ei ylimääräistä mallia; tiiviimpi integraatio tarkoittaa korkeampia hyväksymisasteita; pienempi muistikuorma
• Haitat: Toimii vain, jos ennustuspäät sisältyvät julkaisuun

Miksi MTP voittaa

MTP-ennustuspäät koulutetaan päämallin rinnalla. Ne jakavat samat sisäiset esitykset ja oppivat mallin oman tokenien jakauman. Tämä tuottaa tyypillisesti korkeampia hyväksymisasteita kuin ulkoinen luonnosmalli, mikä tarkoittaa enemmän hyväksyttyjä tokeneita per vahvistusvaihe ja nopeampaa generointia kokonaisuudessaan.

Ennustuspäät ovat myös pieniä — tyypillisesti ne lisäävät vain 1–3 % mallin kokonaisparametrimäärään. Muistikuorma on merkityksetöntä verrattuna erillisen luonnosmallin lataamiseen.

Liity uutiskirjeellemme

Saa uusimmat vinkit, trendit ja tarjoukset ilmaiseksi.

Sähköpostiosoite

Tilaa

Laajempi vaikutus

Tämä ei koske ainoastaan Gemma 4:ää. Päätös luo ennakkotapauksen sille, kuinka “avoimia” avoimen painojen julkaisut todella ovat.

Mitä käyttäjät menettävät:

• MTP-pohjaisen spekulatiivisen dekoodauksen kaikilla kolmannen osapuolen päättelymoottoreilla
• Mahdollisuuden hienosäätää tai kokeilla MTP-päitä
• Suorituskyvyn yhdenvertaisuuden Googlen omien käyttöönottotyökalujen kanssa

Mitä käyttäjillä on edelleen:

• Perusmallin painot (jotka ovat aidosti hyviä)
• Perinteinen spekulatiivinen dekoodaus erillisellä luonnosmallilla (vLLM-issue #38893 seuraa Eagle3-tukea Gemma 4:lle)
• Tavalliset kvantisointitekniikat ja optimointimenetelmät

Yhteisön reaktio on ollut suoraviivainen. 24 tunnin konsensus oli, että Gemma 4:n vertailuarvotulokset ovat kilpailukykyisiä — se on tasoissa tai hieman jäljessä Qwen 3.5:tä — mutta tuote “ei ole valmis.” Nopeus, vakaus ja työkalutuki vaativat työtä. Muita ongelmia ovat mm. HuggingFace Transformersin alun perin puuttuva Gemma 4 -arkkitehtuurituki, PEFT:n kyvyttömyys käsitellä uusia kerrostyyppejä ja Mac-käyttäjien kaatumisia suurempia malleja ladattaessa.

Mitä voit tehdä?

Jos arvioit Gemma 4:ää käyttöönottoa varten, tässä käytännön vaihtoehtoja:

Käytä perinteistä spekulatiivista dekoodausta. Ulkoiset luonnosmallit voivat edelleen kiihdyttää Gemma 4:n päättelyä. Kehykset kuten vLLM lisäävät Eagle3-spekulatiivisen dekoodauksen tukea nimenomaan Gemma 4:lle. Nopeuslisä ei vastaa sisäänrakennettua MTP:tä, mutta se on parempi kuin ei mitään.

Harkitse vaihtoehtoja nopeuskriittisille työkuormille. Qwen 3.5 tarjoaa merkittävästi paremman token-per-sekunti-suorituskyvyn vastaavalla laitteistolla. Jos päättelynopeus on ensisijainen rajoitteesi, Qwen tarjoaa tällä hetkellä paremman nopeus-laatu-suhteen.

Seuraa yhteisön kiertoratkaisuja. LiteRT-viennit sisältävät MTP-päät. Tutkijat saattavat löytää keinoja poimia ja liittää ne takaisin HuggingFace-painoihin, vaikka Google ei ole virallisesti tukenut tätä polkua.

Anna palautetta. Googlen insinöörit seuraavat aktiivisesti HuggingFacen keskusteluketjuja. Selkeät, tekniset pyynnöt MTP-päiden julkaisusta ovat painoarvoltaan merkittäviä.

Johtopäätös

Gemma 4 on kyvykäs malliperheen julkaisu, jossa on aitoja arkkitehtuurisia innovaatioita ja vahvat vertailuarvotulokset. Päätös poistaa MTP-ennustuspäät julkisesta julkaisusta — samalla kun ne säilytetään Googlen omassa LiteRT-kehyksessä — heikentää “avoimen” merkitystä avoimissa painoissa.

MTP ei ole vähäinen optimointi. Se voi tuottaa 1,5–2-kertaisen päättelynopeuden ilman minkäänlaista vaikutusta tulosteen laatuun. Sen pidättäminen julkisista painoista, kun malli selvästi koulutettiin sen kanssa, luo kaksitasoisen järjestelmän: nopea päättely Googlen työkaluille, hidas päättely kaikille muille.

Avoimen lähdekoodin tekoälyyhteisölle viesti on selvä: tarkista mitä painoissa todella on, älä pelkästään vertailuarvoja. Avoin lisenssi ei aina tarkoita avointa julkaisua.

Rakennettu FlowHuntilla . Pysy ajan tasalla uusimmista avoimen lähdekoodin tekoälyn kehityksistä blogissamme .