MiniMax M2.1: mitä päivitys muuttaa ja kenelle se sopii?

MiniMax M2.1 on kiinalaisen tekoäly-yhtiö MiniMaxin 23. joulukuuta 2025 julkaisema avoimien painojen päivitys koodaukseen ja tekoälyagentteihin. Siinä missä aiempi M2 profiloitui ennen kaikkea edullisena ja helposti saatavana mallina, M2.1 on suunnattu vaativampiin tosielämän tehtäviin: monikieliseen ohjelmistokehitykseen, full-stack-sovelluksiin, natiiviin mobiilikehitykseen ja toimistotyötä muistuttaviin automaatioprosesseihin. 34

Tärkeä varaus koskee suorituskykylukuja. Monet vahvimmista väitteistä perustuvat MiniMaxin omiin testeihin. Ne kertovat, mihin suuntaan julkaisu on viety, mutta niitä ei pidä tulkita lopulliseksi ja riippumattomaksi paremmuusjärjestykseksi suhteessa suljettuihin malleihin.

Mikä MiniMax M2.1 on?

M2.1 on mixture-of-experts-malli eli asiantuntijamallien yhdistelmä. Siinä on yhteensä 230 miljardia parametria, mutta jokaista tokenia kohden aktivoituu noin 10 miljardia parametria. Harva rakenne on suunniteltu tekemään päättelystä tehokkaampaa kuin mallissa, jossa kaikki parametrit aktivoituisivat jokaisella laskentakierroksella. 1

MiniMaxin perusajatus on, että hyödyllisen koodausmallin täytyy osata muutakin kuin tuottaa Python-esimerkkejä tai yksittäisiä funktioita. Oikeissa ohjelmistoprojekteissa yhdistyvät useat ohjelmointikielet, olemassa olevat koodivarastot, mobiilialustat, käyttöliittymät, projektikohtaiset ohjeet, työkalut ja pitkä ketju toisistaan riippuvia tehtäviä. M2.1 on rakennettu tätä laajempaa työnkulkua silmällä pitäen.

Miten M2.1 eroaa M2:sta?

MiniMax kuvaa M2.1:tä siirtymänä, jossa painopiste muuttuu M2:n kustannustehokkuudesta ja laajasta saatavuudesta monimutkaisten, tuotantoon tähtäävien tehtävien luotettavaan suorittamiseen. Erityisen huomion kohteena ovat ohjelmointi useilla kielillä sekä arkiset toimisto- ja agenttitehtävät. 4

Yhtiön ilmoittamat parannukset ovat seuraavat:

• Laajempi ohjelmointikielten tuki: Rust, Java, Go, C++, Kotlin, Objective-C, TypeScript ja JavaScript sekä Python ja muita kieliä. 37
• Kokonaiset full-stack-sovellukset: Mallin tavoitteena on rakentaa toimivia sovelluksia irrallisten koodinpätkien sijaan. 34
• Natiivi mobiilikehitys: MiniMax korostaa Android- ja iOS-kehityksen parantumista, sillä yhtiön mukaan mobiilisovellukset ovat olleet tekoälyjärjestelmille jatkuva heikkous. 4
• Kyvykkäämpi agenttityö: Malli on tarkoitettu työnkulkuihin, joissa työkalut, projektitiedostot, ohjeet, muisti ja useat peräkkäiset vaiheet on sovitettava yhteen. 4
• Toimisto- ja dokumentaatiotehtävät: MiniMax kertoo parantaneensa jäsenneltyä kirjoittamista, teknistä dokumentointia, dataan liittyvää työskentelyä ja jatkuvia agenttityönkulkuja. 4

MiniMaxin kuvauksen perusteella M2.1 ei siis ole vain suurempi tai halvempi koodausmalli. Tavoitteena on tehdä mallista luotettavampi tilanteissa, joissa tehtävään kuuluu vaatimuksia, käyttöliittymiä, työkalukutsuja ja toimitettava ohjelmisto – ei ainoastaan tuotettua tekstiä.

Mitä ohjelmointikieliä M2.1 tukee paremmin?

MiniMax kertoo parantaneensa M2.1:n osaamista järjestelmällisesti Rustissa, Javassa, Golangissa, C++:ssa, Kotlinissa, Objective-C:ssä, TypeScriptissä ja JavaScriptissä. Myös ulkopuolisessa raportoinnissa mainitaan Javaan, Go:hon, Rustiin, C++:aan, TypeScriptiin, JavaScriptiin, Ktotlinin ja Pythonin kaltaisiin kieliin keskittyviä asiantuntijoita. 37

Painotus on merkittävä organisaatioille, jotka ylläpitävät sekalaisia teknologiaympäristöjä. Python-tehtävissä hyvin toimiva malli ei välttämättä ole yhtä hyödyllinen tuotantokoodivarastossa, jossa taustapalvelut on kirjoitettu Javalla tai Golla, järjestelmätason koodi Rustilla tai C++:lla ja verkko- tai mobiilikäyttöliittymät TypeScriptillä, JavaScriptillä, Kotlinilla tai Objective-C:llä.

Miten M2.1 vertautuu Claude-malleihin?

MiniMaxin mukaan M2.1 päihittää Claude Sonnet 4.5:n monikielisissä ohjelmistokehitystehtävissä ja yltää lähelle Claude Opus 4.5:n tasoa. Yhtiö raportoi SWE-bench Multilingual -testissä tulokseksi 72,5 prosenttia. 316

Lukuun on syytä suhtautua varauksella. Lähteet eivät muodosta puolueetonta, riippumattomasti toistettua tulostaulukkoa, ja vertailuihin voivat vaikuttaa esimerkiksi kehotteet, agentin ympärille rakennettu työkalukerros, malliversiot ja testausmenetelmät. Myöhemmän ulkopuolisen analyysin mukaan M2.1 paransi tulostaan SWE-bench Verified -testissä M2:een verrattuna, mutta jäi kyseisessä vertailussa useiden vahvojen suljettujen järjestelmien taakse. 7

Varovainen johtopäätös on tämä: MiniMax tavoittelee erityisesti monikielistä, kokonaisiin koodivarastoihin ulottuvaa ohjelmistokehitystä, ja yhtiön julkaisemien tulosten perusteella edistys aiempaan malliin nähden on merkittävä. Tulokset eivät kuitenkaan osoita, että M2.1 päihittäisi Clauden jokaisessa projektissa tai työnkulussa.

Mikä on VIBE-arviointi?

VIBE on lyhenne sanoista Visual & Interactive Benchmark for Execution. MiniMax kehitti sen mittaamaan, pystyykö malli rakentamaan alusta loppuun kokonaisia ja käyttökelpoisia sovelluksia sen sijaan, että se tuottaisi vain uskottavalta näyttävää koodia tekstikenttään. 34

Arviointi kattaa viisi osa-aluetta:

• verkko
• simulaatio
• Android
• iOS
• taustajärjestelmät

Testaus perustuu käyttöönotettuihin sovelluksiin sekä vuorovaikutuksen ja visuaalisen toiminnan tarkistamiseen. Näin VIBE pyrkii mittaamaan asioita, joita perinteiset koodausarvioinnit eivät välttämättä tavoita: toimiiko sovellus käytössä, käyttäytyvätkö vuorovaikutukset oikein ja vastaako käyttöliittymä visuaalisia tavoitteita. 4

M2.1:n raportoidut VIBE-tulokset

MiniMax ilmoitti VIBE-arvioinnin kokonaispisteiksi 88,6, joista VIBE-Webissä 91,5 ja VIBE-Androidissa 89,7. 48

Luvut ovat kiinnostavia, koska ne ulottavat arvioinnin bugien korjaamisesta ja koodin täydentämisestä kokonaisen sovelluksen toimittamiseen. VIBE on kuitenkin MiniMaxin luoma arviointi, ja mallien väliset vertailut on tehty yhtiön omalla testausasetelmalla. Siksi tuloksia on pidettävä yhtiön raportoimana näyttönä mallin vahvuuksista, ei itsenäisesti vakiintuneena toimialan rankingina. 48

Mihin M2.1 pystyy mobiili-, verkko- ja sovelluskehityksessä?

MiniMax asemoi M2.1:n aiempaa vahvemmaksi malliksi natiivien Android- ja iOS-sovellusten kehittämiseen – ei vain selaimessa toimivien sovellusten rakentamiseen. Yhtiö kertoo parantaneensa myös visuaalisen suunnittelun ja estetiikan, monimutkaisten vuorovaikutusten, kolmiulotteisten tieteellisten simulaatioiden ja laadukkaiden visualisointien ymmärtämistä. 4

Yhdistelmä tukee kunnianhimoisempaa versiota niin sanotusta vibe codingista: käyttäjä kuvaa sovelluksen luonnollisella kielellä, ja agentti kokoaa kuvauksen perusteella toimivan tuotteen. MiniMaxin ilmoittama tavoite ei ole vain näyttävä demo, vaan ylläpidettävä ja toimituskelpoinen sovellus tuotantolähtöiseen käyttöön. 4

Tavoitteen toteutuminen on silti testattava oikeissa koodivarastoissa. Mobiilin koontijärjestelmät, riippuvuusristiriidat, alustakohtaiset käytännöt, saavutettavuus, tietoturva ja pitkäaikainen ylläpito ovat käytännön tarkistuksia, joita benchmark-pisteet eivät voi korvata.

Miten ”Interleaved Thinking” tukee monimutkaisia työnkulkuja?

MiniMax kuvaa Interleaved Thinking -menetelmää järjestelmälliseksi ongelmanratkaisuksi tehtävän suorittamisen aikana. Sen tarkoituksena on auttaa mallia pitämään samanaikaisesti mielessä useita rajoitteita, kuten järjestelmäohjeet, käyttäjän vaatimukset, muistin, työkalujen skeemat ja projektin ohjetiedostot. 4

Tämä on agenttityössä tärkeää, sillä onnistunutta lopputulosta ei määritä pelkästään se, käynnistyykö koodi. Agentin täytyy ehkä myös:

1. tutkia olemassa oleva projekti;
2. noudattaa koodivaraston omia ohjeita;
3. valita ja käyttää oikeita työkaluja;
4. tehdä koordinoituja muutoksia useisiin tiedostoihin;
5. tuottaa dokumentaatiota tai muuta jäsenneltyä sisältöä; ja
6. tarkistaa, että lopputulos täyttää alkuperäiset vaatimukset.

MiniMax yhdistää tämän kyvyn tekniseen dokumentointiin, jäsenneltyyn kirjoittamiseen, datankäsittelyyn ja pitkäkestoiseen toimistoautomaatioon. Kyse on edelleen asemointia tukevista väitteistä, ei todisteesta siitä, että jokainen monivaiheinen työnkulku valmistuisi luotettavasti. Ne kuitenkin selittävät, miksi julkaisu esitellään pelkän koodigeneraattorin sijaan koodaus- ja agenttimallina. 4

Miten kehittäjät voivat käyttää ja ottaa M2.1:n käyttöön?

Käyttöön on kaksi pääreittiä:

• Rajapinnan kautta: Kehittäjät voivat käyttää M2.1:tä MiniMaxin ylläpitämän API-rajapinnan kautta. 46
• Oman palvelun kautta: Mallin painot ovat julkisesti saatavilla Hugging Facessa, joten organisaatio voi hallinnoida itse omaa palvelinympäristöään. 46

MiniMaxin julkaistuissa ohjeissa suositellaan SGLangia, ja vLLM on niin ikään tuettu vaihtoehto ympäröivässä käyttöönottoekosysteemissä. 141 Itse ylläpidetty käyttöönotto voi antaa organisaatiolle API-pohjaista suljettua mallia suoremman kontrollin infrastruktuuriin, datan käsittelyyn, mallipalveluun, integraatioihin ja skaalaukseen.

Joustavuus ei kuitenkaan automaattisesti tarkoita pienempiä kokonaiskustannuksia. Oma käyttöönotto edellyttää riittävää GPU-kapasiteettia, suunnittelua, valvontaa, ylläpitoa ja operatiivista tukea. Taloudellinen lopputulos riippuu käyttöasteesta ja infrastruktuurivalinnoista, ei ainoastaan aktiivisten parametrien määrästä. 12

Käytännön johtopäätös

MiniMax M2.1:n merkittävin muutos M2:een verrattuna on painopiste. Uusi julkaisu tähtää monikieliseen, full-stack- ja agenttivetoiseen työskentelyyn sen sijaan, että kustannustehokkuus ja helppo saatavuus olisivat pääasia. Raportoitu 72,5 prosentin tulos SWE-bench Multilingual -testissä ja 88,6 pisteen VIBE-tulos tukevat tätä asemointia, kun taas Android- ja verkkokehityksen tulokset osoittavat, että MiniMax yrittää arvioida myös kokonaisen sovelluksen rakentamista perinteisen koodauksen rinnalla. 348

Kehittäjille tärkeimmät hyödyt ovat laajempi kielituki, avoimet painot, API-käyttö ja SGLangin tai vLLM:n tarjoama käyttöönoton joustavuus. Yrityksille kiinnostavaa on mahdollisuus ajaa monimutkaisempia koodaus- ja automaatiotyönkulkuja hallitummin sekä vaikuttaa itse palveluun ja datan käsittelyyn.

Varaus on yhtä tärkeä kuin lupaus: vahvimmat vertailut ja uudet VIBE-tulokset ovat pääosin MiniMaxin raportoimia. M2.1:tä arvioivien tiimien kannattaa testata sitä omilla koodivarastoillaan, mobiilikoosteillaan, dokumentaatiovaatimuksillaan, tietoturvakontrolleillaan ja automaatiotehtävillään ennen kuin benchmark-väitteitä pidetään tuotantokelpoisuuden todisteena.