Vi pruned MiniMax-M2.7: første offentlige REAP-variant, publisert 72 timer etter release

Hovedfunn (TL;DR)

• Første offentlige REAP-40%-variant av MiniMax-M2.7, publisert 72 timer etter modellens release
• 229 milliarder parametere redusert til 139 milliarder uten målbar kvalitetstap (5/5 smoke-test, 83,3 % HumanEval pass@1 på fullførte problemer)
• Seks åpne modell-formater på HuggingFace: Safetensors BF16, GGUF i 6 kvantiseringer, FP8, NVFP4, AWQ og NVFP4-GB10
• Q4_K_M-varianten (84 GB) passer på 96 GB Mac Studio M4 Max med plass til KV-cache
• Del av m51 Lab sin åpne forskningsserie: tidligere NorskGemma4-31B, NorskMistral-119B og SeoGemma4 v2

MiniMax AI slapp M2.7 den 12. april 2026. En 229-milliarders Mixture-of-Experts-modell, 10 milliarder aktive parametere per token, og i standard-kvantisering for stor til å kjøre utenfor et datasenter. Tre dager senere hadde m51 Lab publisert seks åpne pruned varianter, den minste av dem (Q4_K_M på 84 GB) kjørbar på et 96 GB Mac Studio.

Dette er historien om det arbeidet, og hvorfor en markedsføringsplattform gjør det.

Kort teknisk kontekst: MoE og REAP

Mixture-of-Experts (MoE) er arkitekturen bak de fleste frontier-modeller i 2026. I stedet for at alle parametere er aktive for hver token, ruter modellen hver token til en liten delmengde av såkalte «eksperter». MiniMax-M2.7 har 256 eksperter per lag og bruker top-8-ruting, noe som gir kvaliteten til en 229-milliarder-parametere-modell med regnekostnaden til en 10-milliarder-modell, forutsatt at du får den til å kjøre.

REAP (Router-weighted Expert Activation Pruning) fra Cerebras Research, publisert oktober 2025, identifiserer de minst viktige ekspertene i en MoE-modell basert på hvor ofte de aktiveres og hvor mye de bidrar på kalibreringsdata. REAP-40 % fjerner 40 % av ekspertene (256 til 154 per lag) og kutter modellstørrelsen fra 140 GB til 84 GB i Q4_K_M uten målbar effekt på kvaliteten.

Katalysatoren for dette prosjektet: Cerebras sin offisielle REAP-implementasjon støtter seks modellfamilier (Qwen, Llama, Mixtral, DeepSeek, Ernie, Glm). MiniMax var ikke på listen. Ingen andre hadde publisert en M2.7-REAP. Førstemann-vinduet sto åpent.

Hvorfor m51 Lab gjør dette

M51 AI OS er en AI-drevet markedsføringsplattform som daglig driver 17 spesialiserte AI-agenter hos norske kunder: agenter som skriver annonsetekst, genererer rapporter, gjør SEO-auditer, analyserer konkurrenter og koordinerer kampanjer. Når vi anbefaler en modell eller en arkitektur til en kunde, står vi ansvarlige for at den faktisk fungerer under reelle arbeidsforhold.

Problemet er at AI-bransjen kommuniserer i glanspunkter. «GPT 5.4 scorer 92 % på MMLU.» «Claude Opus 4.6 leder på SWE-bench.» Alt sant. Ingenting forteller hvordan modellen oppfører seg når du tvinger den til å kjøre på en brøkdel av datasenteret, i kontinuerlig drift, med realistisk trafikk.

Derfor har vi Lab-avdelingen. Vi presser modeller og verktøy til vi vet hvor grensene går. MiniMax-M2.7-prosjektet er det siste stykket i en pågående serie.

Les også: Vi trente en open-source AI til å skrive SEO-auditer, og testet den mot Claude Sonnet

Tre dager, seks leveranser

Pipelinen hadde ni stadier: FP8-nedlasting, BF16-dequantisering, REAP-pruning, imatrix-kalibrering, GGUF-konvertering, kvantisering i flere formater, evaluering og publisering. Estimert wall-clock 22-28 timer; faktisk kjøretid 20 timer aktiv pipeline fordelt over tre dager. Total kostnad i GPU-tid: ca. 775 USD.

Dag 1: Diagnose

REAPs offisielle kode har to registre for modellstøtte, MODEL_ATTRS og OBSERVER_CONFIG_REGISTRY. MiniMax-M2.7 sto i ingen av dem. Etter fem restart-runder med patcher til datasettformater, chat-templater og transformers-versjoner, kom vi til forward pass på 4× H200.

Der møtte vi den reelle veggen. REAP-observeren allokerer (antall eksperter × batch × sekvens × hidden_dim) × 4 bytes i FP32 per MoE-blokk. For MiniMax-M2.7 ga det 96 GB per lag med batch=16. Ingen enkelt flagg slår det av. En strukturell inkompatibilitet mellom REAPs observer-design og MiniMax sine arkitektur-parametre, ikke modellen selv. Lærdom: FP32-aktiveringer er den skjulte memory-killeren, ikke vektene.

Dag 2: Pruning

Løsningen var å patche observer-koden selv og bytte FP32 til BF16 i allokeringene. Det halverer memory. Med 8× H100 SXM og batch=4 traff vi 41 sekunder per sample, lineært og stabilt. 768 kalibreringssamples tok 8 timer og 45 minutter. Forward pass gikk gjennom, save krasjet først på en liten type-bug (num_experts som int i stedet for string), og deretter fanget vi at REAP prunet ekspert-vektene men glemte e_score_correction_bias-tensorene. 30 linjer Python re-skrev 55 av 56 shards med korrekt bias-form.

Dag 3: Konvertering, evaluering, publisering

Fra et 260 GB BF16-sjekkpunkt konverterte vi til seks varianter: GGUF i Q3_K_M, IQ4_XS, Q4_K_M, Q6_K og Q8_0; FP8 W8A8 for vLLM og TRT-LLM; NVFP4 W4A16 for Blackwell-native inferens; AWQ INT4 W4A16 for bred kompatibilitet; og NVFP4-GB10 W4A4 for DGX Spark. HumanEval-evaluering av Q4_K_M-varianten. Metodologi-transparent publisering på HuggingFace med alle kalibreringsdetaljer, bias-fix-dokumentasjon og minnebudsjett-tabeller.

Totalt 14 strukturelle patcher mot REAP-kodebasen. Alle dokumentert. Ingen hemmeligholdt.

Hva vi leverte: seks modell-varianter

Alle publisert under Modified MIT-lisens, arvet fra MiniMaxAI. Modellkort inkluderer fulle kalibreringsdetaljer, benchmark-metodologi og memory-budsjett-tabeller per kontekstlengde.

Safetensors BF16 (hovedrepo)

GGUF (6 kvantiseringer for llama.cpp)

FP8 (W8A8, for H100/H200)

NVFP4 (W4A16, for Blackwell + Hopper fallback)

AWQ (INT4 W4A16)

NVFP4-GB10 (W4A4, for DGX Spark / GB10)

Kvalitet: hva koster 40 % pruning?

Vi evaluerte Q4_K_M-varianten (84 GB, Mac Studio-målgruppen) på en smoke-test med fem enkle prompter og på hele HumanEval (164 kodeproblemer). Smoke-testen: 5/5 PASS på norsk, matte, Python, forklaringer og JSON. Bias-fix-imperfeksjonen på lag 0 har ingen observerbar effekt.

HumanEval pass@1 gir tre tall, og metodologien bak dem er selve poenget:

• 83,3 % på fullførte problemer (90 av 108 der modellen fikk nok token-budsjett til å avslutte reasoning)
• 54,9 % strict (90 av 164 totalt, der 56 problemer traff 32K-token-taket fordi modellen gikk dypt i chain-of-thought)
• 65,2 % med raw-completion-metoden (modellen tvunget til prompt-completion i stedet for chat-modus)

MiniMax-M2.7 er RLHF-tunet til å emittere tenke-blokker før endelig svar. På komplekse engineering-problemer bruker den lett 15 000+ tokens på intern resonnering. 83,3 % er modell-kvaliteten. 54,9 % er det du får i produksjon med realistiske budsjetter. 65,2 % er et alternativt metodologi-tall. Vi publiserer alle tre, transparent.

Et benchmark-tall uten metodologi-kontekst er nær verdiløst. Det gjelder ikke bare vår modell, det gjelder alt du leser om LLM-benchmarks i 2026.

Tre prinsipper vi tar med oss til kundearbeid

1. Modellens størrelse på disk er ikke kapasitetsplanen din

En modell på «84 GB i Q4_K_M» er 84 GB på disk. Under inferens er det vekter pluss aktiveringer pluss KV-cache pluss compute-buffers. KV-cachen alene varierer 3-4× mellom arkitekturer: MiniMax-M2.7 bruker 250 MB per 1K tokens, Qwen3-30B 94 MB, DeepSeek V3 med MLA 72 MB. Når vi dimensjonerer infrastruktur for en AI-arbeidslast hos en kunde, regner vi alt, ikke bare modellstørrelsen. Feil i dette regnestykket er en hovedårsak til at AI-pilotprosjekter feiler.

2. Benchmark-tall uten metodologi er nær verdiløst

Samme modell, samme benchmark, tre ulike tall avhengig av token-budsjett. Dette gjelder enhver reasoning-modell i 2026. Når vi evaluerer modeller for kundene våre, kjører vi dem mot deres faktiske arbeidslast og oppgir alltid test-forhold, ikke generiske benchmark-tall fra produsentenes whitepapers.

3. Åpen-kildekode-økosystemet modnes raskt, men ujevnt

REAP er produksjonsklart for seks modellfamilier. Den sjuende krevde 14 strukturelle patcher. Dette er naturen av spesialiserte AI-verktøy: støtte-flaten er smalere enn markedsføringen antyder. Vi kan navigere det. Når en kunde kommer om tre måneder og spør «har dere testet X?», er svaret oftere «ja» enn «nei», fordi Lab-arbeidet gir oss reell hands-on-erfaring med hvert nytt modell-økosystem.

Se også: annen m51 Lab-forskning

SeoGemma4 v2 vs Claude Sonnet: kan open source skrive norske SEO-auditer?

NorskMistral-119B: Norges beste open-source språkmodell

NorskGemma4-31B: mindre modell, bedre resultat (83,6 % NorEval)

Open source vs kommersiell AI på norsk marked: våre modeller mot GPT og Gemini

Om M51 AI OS

M51 AI OS er en norsk SaaS-plattform som gir markedsføringsteam og byråer et komplett AI-drevet operativsystem. 17 spesialiserte AI-agenter jobber med kundedata og merkevarekontekst for å automatisere analyse, rapportering, annonseproduksjon, SEO og kampanjeoptimalisering. I produksjon kjører plattformen på en kurert miks av Claude Sonnet/Opus, GPT og våre egne finetunede modeller.

m51 Lab er forsknings- og utviklingsavdelingen bak plattformen. Vi publiserer åpne modeller på HuggingFace, dokumenterer forskningen transparent, og lar læringene derfra flyte direkte inn i arkitektur-valgene vi gjør for kundene. MiniMax-M2.7-eksperimentet står ikke alene: det er det siste i en serie som også inkluderer NorskGemma4-31B, NorskMistral-119B og SeoGemma4 v2.