Snilld

Mellum2 fra JetBrains – hurtig ‘focal’ model med 128K kontekst og praktisk værdi for softwareteams

JetBrains åbner vægtene til Mellum2 under Apache 2.0. En 12B MoE-model målrettet softwareudvikling, tænkt som en hurtig, specialiseret brik i større multi‑model‑opsætninger. Vi går ned i arkitektur, latency‑tradeoffs, SWA og langkontekst, checkpoints og enterprise‑drift, og hvor den faktisk giver mening i hverdagen.

2. juni 2026 Peter Munkholm

Vi stod forleden med et monorepo, to gamle tests der flimrede, og en udvikler som bare ville have et hurtigt forslag, ikke en afhandling. Det er dér Mellum2 rammer. JetBrains har frigivet modellen og vægtene under Apache 2.0 og kalder den en “focal model” til multi‑model setups, ikke en alt‑i‑én afløser for frontier‑modeller (kilde 1671). Åbne vægte giver frihed. Og mere ansvar.

Mellum2 sigter efter lav ventetid og skarp specialisering i softwareopgaver. On‑prem eller private cloud er pludselig realistisk uden lockin, hvis man orker MLOps og governance. Vi gør. Det betaler sig, når man vil tæt på kodebasen uden at lække noget.

Hvad er Mellum2 i korte træk

Mellum2 er en Mixture‑of‑Experts model med 12B parametre, 64 eksperter og 8 aktiverede per token. Det giver cirka 2,5B aktivt compute per token, omtrent som en tæt ~2,5B model (kilde 1671). Arkitekturen har 28 lag, hidden size 2304, Grouped‑Query Attention med 32 query‑hoveder og 4 KV‑hoveder, og et vokabular på 98.304 (kilde 1671). Den håndterer tekst og kode, ikke billeder eller video (kilde 1671). Kontekstvinduet er rapporteret som 131.072 tokens, svarende til ~128K. JetBrains beskriver, at base‑vinduet blev udvidet til ~128K via en lag‑selektiv YaRN‑metode før post‑training. Begge tal peger altså på samme størrelsesorden (kilde 1671).

Modellen bruger en Multi‑Token Prediction head som ekstra mål i pre‑training og som indbygget draft‑motor til spekulativ decoding under inferens (kilde 1671). I praksis betyder det mindre tid på at vente token‑for‑token, bedre throughput og mere stabile P95‑målinger ved høj last, især hvis serveren ellers er sat korrekt op. JetBrains angiver bfloat16 til arkitektur/inferens og en FP8‑hybrid i træningen med Muon‑optimering og en Warmup‑Hold‑Decay plan (kilde 1671). Oversat: FP8‑hybrid er en træningsoptimering. I serving bør man forvente bfloat16.

Nærbillede af GPU‑nodes varmefinne med let støv og cyan‑refleks; detaljer der antyder intensiv drift og vedligehold.

Hvilke designvalg har størst praktisk betydning

Sliding Window Attention kører i tre ud af fire lag med et 1.024‑vindue, og fuld attention i det fjerde lag (kilde 1671). Det skærer den kvadratiske regning væk i hovedparten af lagene, men lader modellen samle trådene periodisk. På lange filer eller chats holder den fast i global kontekst uden at brænde hele GPU’en af (kilde 1671).

Vi har set, at kombien af SWA og periodisk fuld attention kan give markant lavere ventetid på lange inputs, mens sporing af fjerne referencer stadig virker. Det kræver dog, at der er luft i memory og at routeren ikke skaber køer. (Snilld vurdering)

MoE‑tradeoffs: latency, shards, routing og producibility

64 eksperter og 8 aktiverede per token er stærkt, fordi per‑token compute ligner en 2,5B tæt model. Men MoE vinder eller taber på routing, load balancing og topologi. Skæv fordeling skaber hotspots, netværkshop og barrieresync, som æder gevinsten (kilde 1671). Hold routeren tæt på eksperterne, undgå chatty netværk, og test flere temperaturer i routeren, før I går i produktion.

Batching bliver mere følsomt end i tætte modeller. Tætte modeller trives ofte ved store batches. MoE skal fordeles jævnt for at undgå enkelte eksperter, der sveder, mens andre keder sig. Vi så et SaaS‑team med ustabil P95, fordi to eksperter bar halvdelen af trafikken. Router‑temperatur en anelse ned og shard‑placement om, så faldt halen. Ikke plug‑and‑play, men til at styre. (Snilld vurdering)

Banner

Træningsspor og checkpoints – reproducérbarhed og tilpasning

Pre‑training: cirka 10,6T tokens i tre faser med stigende andel kurateret kode og matematik (kilde 1671). Træning brugte Muon, FP8‑hybrid, Warmup‑Hold‑Decay til nul og MTP‑head til både mål og spekulativ decoding (kilde 1671). Det peger mod robust kodeforståelse og fornuftig konvergens.

JetBrains har udgivet seks checkpoints, fra base til SFT og RL, hver i Instruct og Thinking (kilde 1671). Vælg Instruct når svar og tool‑calls skal være korte og hurtige. Vælg Thinking når der ønskes en kort, eksplicit reasoning‑trace, før modellen handler. Lås versionsstyring pr. checkpoint, så I kan rulle tilbage uden drama.

Et tæt foto af et netværkspatch: fiberbundter og en stram, farvet tie markerer en routing‑hotspot; indigo og cyan toner giver en teknisk, alvorlig stemning.

Hvordan Mellum2 passer i multi‑model setups

JetBrains’ “focal model”‑positionering er enkel: lad Mellum2 tage de snævre, hyppige opgaver, og eskalér til en stor frontier‑model ved tvivl eller komplekse spørgsmål (kilde 1671). Det sænker både ventetid og den daglige cloud‑regning. (Snilld vurdering)

Konkretion: Instruct til kodeforslag, let refaktorering, commit‑tekster og simple tool‑kald. Thinking til debugging og agentiske flows, hvor I vil have en sporbar tankekæde, før en ændring lander i repoet. Det er netop de to spor, JetBrains udstikker (kilde 1671).

SWA og langkontekst i drift

128K kontekst er kun nyttig, hvis serveren ikke drukner. SWA i tre ud af fire lag og fuld attention i det fjerde holder gennemløbet højt og lader modellen kigge bredt, når det er nødvendigt (kilde 1671). I store monorepos kan det være forskellen på en P95 i sekunder fremfor noget, der sniger sig op i det irriterende. Vi har stået ved en H100‑node, der kørte fuld attention på ~100K. Det blev varmt hurtigt. (Snilld vurdering)

YaRN‑udvidelsen før post‑training betyder, at langinput‑kvaliteten ikke kun afhænger af positionelle embeddings‑tricks. For driftsteams: mål reference‑hits, summarization‑drift og P95 på store filer, når I evaluerer den lange kontekst (kilde 1671).

Sikkerhed, governance og enterprise‑drift

MCP i produktion kræver finmasket adgangskontrol, dyb observability, beskyttelse mod data‑exfiltration og central credential‑styring (kilde 1673). En gateway som Amazon Bedrock AgentCore Gateway placerer sig mellem MCP‑servere og klienter og centraliserer credentials, logging og sikre forbindelser. Den giver også runtime‑funktioner som dynamisk listing, streaming/session management og elicitation (kilde 1673).

Én indgang giver ensartet politik‑håndhævelse og ét udsyn for sikkerhed. Alternativet er små lokale løsninger i hvert team, som sjældent skalerer og er svære at revidere. Det har vi set nok gange. (Snilld vurdering)

Split foto: til venstre roligt serverhjørne før belastning; til højre tætpakket GPU‑node med amber indikator og et teknikerblik — billedet visualiserer øget driftspres.

Konkrete implementeringsopsætninger og Snillds anbefalinger

Start med en PoC: Instruct som code‑review assistent i en isoleret pipeline. Brug syntetiske eller anonymiserede eksempler. Mål median og P95 latens per anmodning, andel forslag godkendt i første gennemløb, test‑pass‑rate efter forslag og hallucinationsrate (selvsikre ændringer der fejler tests). Fastlæg en baseline mod jeres nuværende tooling og en tæt 2–3B model. (Snilld vurdering; kilde 1672)

  • PoC‑målepunkter: P50/P95 latens ved 1K, 8K og 64K tokens. Batch 1/4/16. Eskalationsrate til større model. Hard‑fail rate i CI. CPU/GPU‑udnyttelse.
  • Succeskriterier: 20–40 procent hurtigere feedback på PR’er, uændret eller lavere defektrate efter merge, stabil P95 under jeres SLO. (Snilld vurdering; kilde 1672)

Driftsdetaljer der gør forskellen

Kør containeriseret serving med separat router‑ og ekspert‑lag. Placer eksperter tæt på routeren, pin enkelte eksperter hvis bestemte opgaver dominerer, og minimer netværkshop. Tuning af batch‑størrelse skal afspejle jeres rigtige trafikmønstre, ikke kun syntetiske ensartede prompts. Bruger I MCP, læg en gateway foran for central session‑ og credential‑styring og fuld observability (kilder 1672, 1673). (Snilld vurdering)

Banner

Overvåg to ting lige hårdt. Performance: median/P95 latens, tool‑call fejlrater, andel af eskaleringer til større model. Sikkerhed: uautoriserede ressourcetræk, eksfiltrationsforsøg via prompts og policy‑brud i repo‑/secrets‑forbrug. Hav en “known good” checkpoint og en let revert‑sti for nye fintuninger. (Snilld vurdering)

Begrænsninger og risici

Mellum2 er ikke multimodal. Billed‑ eller videoopgaver må håndteres andetsteds i kæden (kilde 1671). Forvent hallucinationer i ukendte kodeområder. Start der, hvor I har tests. Åbne vægte forpligter. Undgå kodelæk i logs, prompts og træningsdata via isolation og streng secrets‑styring. (Snilld vurdering)

Uafhængige benchmarks mangler. JetBrains deler egne tal i 4B–14B feltet, men der findes ikke standardiserede, tredjeparts sammenligninger mod tætte ~2,5B og større tætte modeller, og der er ingen klare omkostningsdata for MoE‑inferens (GPU‑tid, routing‑overhead, netværks‑IO). Test selv, før I beslutter stor udrulning (kilde 1671). Overvej et økonomi‑setup med pris per 1K tokens for både Mellum2 og jeres fallback‑model, samt P95 under 128K input som styret mål. (rapporteringshul)

Hvad konkurrenterne vil gøre

En open‑weight MoE med lang kontekst og kodeprofil presser proprietære mellemklasse‑modeller og open‑alternativer uden MoE. Vi forventer hurtig adoption i teams med agentiske udvikler‑assistenter og eksisterende MCP‑infrastruktur. Frontier‑modeller forsvinder ikke, men de kaldes sjældnere, når en hurtig “focal” kan tage første stik. (Snilld vurdering)

Andre open‑projekter vil svare med egne MoE‑varianter eller skarpe hosted‑priser. Valget bliver praktisk: økosystem, driftshistorik, sikkerhedsmodenhed. (Snilld vurdering)

Handlingsplan for ledere

1) Vælg 1–3 use cases med høj værdi og lav tolereret ventetid, fx code completion, automatisk bug‑triage eller mindre refaktoreringer. Track lead time for change og fejl fanget før merge. (Snilld vurdering; kilde 1672)

2) Kør kontrollerede fintuning‑PoC’er i isolerede miljøer. Hold trænings‑ og eval‑data fri for følsomheder, brug syntetik hvor muligt, og lås eval‑sæt tidligt. Versionér data, prompts og checkpoints. (Snilld vurdering; kilde 1672)

3) Deploy via gateway/MCP‑arkitektur med centraliseret credential‑management, observability og sikre forbindelser, så compliance kan følge med skaleringen (kilde 1673).

Det vi stadig er i tvivl om

Test disse scenarier hos jer: P50/P95 latens ved 1K, 8K og 64K+ tokens. Batches på 1, 4, 16. Enkelt‑ vs. multi‑GPU med forskellig ekspert‑placering. Rute‑hotspots når domæneopgaver er skæve. Mål også eskalationsraten til større model og effekten på fejlfri merges. (rapporteringshuller; Snilld vurdering)

Juridisk: Apache 2.0 på vægtene er fint, men få en gennemgang af licenser i trænings‑ og finetuning‑data samt rettigheder ved genereret kode. Kilderne oplyser ikke tilstrækkeligt om dataset‑proveniens. Lav en juridisk sanity‑check, før enterprise‑adoption. (rapporteringshul)

Afslutning

Mellum2 er stærk, fordi den ved, hvad den er. En hurtig specialist i en kæde. Kombinationen af 64 eksperter, 8 aktiverede per token og SWA over ~128K kontekst er logisk til kodeopgaver, hvor tempo og små præcise leverancer tæller (kilde 1671). Vægtene er åbne, så adgangen er lav, men driften kræver disciplin i MLOps, sikkerhed og governance. Tjek JetBrains’ officielle kanal for vægte og checkpoints, og sæt målinger på fra dag ét.

Vores anbefaling er ligetil: brug Instruct der, hvor svar skal lande hurtigt. Brug Thinking der, hvor I vil se sporbar reasoning. Resten handler om målinger, versioner og sikkerhed. Man opdager først forskellen, når den kører i jeres pipeline. (Snilld vurdering)

Kilder

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?