MiniMax åpner M3-kjerner for raskere langkontekst

MiniMax har åpnet mer av infrastrukturen rundt M3. I en fersk post skriver MiniMax AI at kernel-arbeidet fra MiniMax og Fireworks AI nå er åpent for alle som vil forstå hva som skal til for å kjøre M3 med høy inferensytelse. To repoer er pekt ut: MiniMax MSA-grenen og Fireworks sitt minimax-kernels-repo.

Det høres smalt ut. Det er det ikke. For alle som vurderer åpne eller delvis åpne modeller i produksjon, er dette en nyttig påminnelse: vektene er bare én del av produktet. Det som avgjør kost, latenstid og reell brukbarhet er ofte serveringslaget, attention-kjernene, minnehåndteringen, batchingen og hvor godt hele stakken faktisk passer maskinvaren.

MiniMax M3 er posisjonert som en langkontekstmodell for koding, agentarbeid og multimodal bruk. M3 bruker MiniMax Sparse Attention, MSA, for å gjøre svært lange kontekstvinduer mindre brutale å kjøre. I MiniMax sin egen lansering ble modellen beskrevet med opptil 1 million tokens kontekst, native bilde- og videoinput, og benchmark-tall for kode- og agentarbeid. Fireworks har samtidig tilbudt M3 som en produksjonsmodell med vekt på lavere pris og rask servering.

Den nye delen er at mer av den ytelseskritiske motoren nå kan inspiseres. Fireworks-repoet beskriver GPU-kjerner for MiniMax-modeller, med en Blackwell SM100-implementasjon av M3 block-sparse attention. Det handler ikke om en ny chatbot-funksjon. Det handler om den delen av stakken som gjør at en lang kontekst ikke bare er en fin tallinje i en modelltabell.

Fireworks sin tekniske gjennomgang forklarer hvorfor dette er krevende. Sparse attention skal redusere beregning ved at hver query bare ser på de mest relevante KV-blokkene. Problemet er at dette skaper ujevn og datadrevet minneaksess. Teoretisk sparsitet kan derfor bli spist opp av dårlig GPU-utnyttelse. Fireworks sier at deres KV-stationary, eller KV-outer, design laster hver valgt KV-blokk én gang og lar alle relevante queries bruke den. I deres målinger på én B200 gir hovedkjernen rundt 980 TFLOP/s og omtrent 4,1 TB/s HBM-båndbredde, med 1,9 til 2,4 ganger fart over en query-stationary baseline og rundt 1,6 ganger over MiniMax sin åpne MSA-kjerne.

For en CIO eller CISO er ikke lærdommen at alle nå skal kompilere egne CUDA-kjerner. Lærdommen er at modellvalg i 2026 ikke kan vurderes på modellnavn alene. En åpen vekt uten åpen og moden inferensstakk kan fortsatt være dyr, treg eller vanskelig å drifte. En modell med 500 000 eller 1 million tokens kontekst kan være uinteressant hvis serveringen gjør den for langsom for agentløp, dokumentanalyse eller kodebaseforståelse.

Dette treffer særlig tre beslutninger. Først: innkjøp bør skille mellom modellrettigheter og produksjonsrettigheter. Kan leverandøren forklare hvilke kjerner, rutere og cache-strategier som faktisk brukes, eller selges bare benchmarken? Andre: team som bygger på åpne modeller bør teste den konkrete serveringsstakken, ikke bare kvaliteten i en API-demo. Tredje: arkitekturvalg bør ta høyde for at ytelse kan bli en leverandørlås. Hvis den beste ytelsen bare finnes i én lukket serveringsplattform, er åpne vekter mindre åpne i praksis.

Det positive med denne typen publisering er at flere kan reprodusere, teste og forbedre underlaget. MiniMax MSA-grenen er MIT-lisensiert, mens Fireworks-kjernene er Apache 2.0 med tydelige tredjepartsnotiser. Det gjør ikke M3 automatisk til et enkelt lokalt valg. Blackwell-krav, CUDA-stakk og produksjonstest er fortsatt tung materie. Men det flytter diskusjonen fra markedsføring til maskinvare, kode og målbar throughput. Det er sunnere.

Saken er også en liten realitetsorientering rundt «åpne modeller». De mest interessante åpne modellene blir større, mer multimodale og mer agentrettede. Da blir de også mer avhengige av spesialisert inferens. Kimi K3, MiniMax M3, DeepSeek og andre kan konkurrere på capability, men virksomheter må fortsatt spørre: kan vi faktisk kjøre dette stabilt, billig og kontrollerbart på våre vilkår?

Det er her åpne kernels betyr mer enn det ser ut som. De gir tekniske team bedre mulighet til å vurdere risiko, forstå flaskehalser og unngå blind tro på en leverandørs dashboard. De gir også hyperscalere, plattformteam og avanserte kunder et klarere utgangspunkt for benchmarking. For norske virksomheter med krav til kostkontroll, datasuverenitet og leverandørstyring er det akkurat slike detaljer som avgjør om en modellstrategi tåler revisjon.

Konklusjonen er nøktern: dette er ikke en ny toppmodell, men det er en viktig produksjonsbrikke rundt en modell som allerede prøver å konkurrere i agent- og langkontekstklassen. Når MiniMax og Fireworks åpner mer av ytelseslaget, blir M3 lettere å evaluere som reell plattform, ikke bare som modellkort. Det bør inn i kravlisten hos alle som vurderer åpne vekter seriøst.

Kilder og medier

• Primærkilde, MiniMax AI på X: https://x.com/MiniMax_AI/status/2082564514760048772
• Verifisert kode: https://github.com/MiniMax-AI/MSA/tree/fireworks-msa og https://github.com/fw-ai/minimax-kernels
• Teknisk bakgrunn: https://fireworks.ai/blog/kernel-optimization-for-minimax-m3-on-nvidia-blackwell
• MiniMax M3-lansering: https://www.minimax.io/blog/minimax-m3
• Thumbnail: OpenAI Image 2 / hogby.ai