AMD har offentliggjort Instella‑MoE‑16B‑A3B, en fuldt åben Mixture‑of‑Experts sprogmodel med 16 milliarder parametre, hvor kun omkring 2,8 milliarder er aktive per token. Vægte fra hvert træningsstadie, datasammensætninger, konfigurationer og inferenskode er frigivet, og hele løbet er kørt på Instinct MI300X og MI325X. Det er ikke bare endnu et modelslip; det er en brugbar opskrift på en moderne MoE‑stack, som både universiteter og enterprise R&D kan pille ved og reproducere i overskuelige bidder.
Kernen i nyheden: MoE samler mange specialiserede eksperter, men aktiverer kun få per token. Det sænker compute per token uden at smide kapacitet over bord. I praksis kan det give hurtigere svar og lavere pris i drift, især når ekspert‑trafikken pakkes fornuftigt på tværs af GPU’er. Hagens navn er licens. Vægtene ligger under ResearchRAIL, der typisk afskærer direkte kommerciel brug, mens træningskoden er MIT. Stærkt til forskning og metodegenbrug – ikke plug‑and‑play i en kommerciel tjeneste.
Arkitektur i korte og lange træk
Instella‑MoE er en decoder‑only MoE‑arkitektur med 27 lag, skjult dimension 2048, 16 attention‑hoveder og et ordforråd på 128.896 tokens. Hvert MoE‑lag har 2 delte eksperter og 64 routede eksperter, hvoraf 6 vælges per token. Den sparsomme aktivering lander omkring 2,8 milliarder aktive parametre kontra 16 milliarder i alt. For inferens betyder det markant lavere FLOPs per token end en monolitisk 16B‑model.
FarSkip og netværkets rolle
FarSkip‑Collective adresserer en driftsnær udfordring: at overlappe kommunikation mellem eksperter med beregning ved at sende delvise eller let forældede aktiveringer videre. AMD rapporterer cirka 12,7 procent hurtigere pre‑training og op til 39,2 procent lavere time‑to‑first‑token i serving med ekspert‑parallelisme. Hvis tallene holder i andres set‑ups, er det en reel gevinst – men metodeoplysninger om batch‑størrelser, sekvenslængder og antal GPU’er er ikke fuldt fremlagt offentligt, så behold en sund skepsis, indtil scripts og profiler kan køres på tværs af miljøer.
Pointen under motorhjelmen er enkel: expert‑parallel kræver kollektiv kommunikation, og netværket bliver ofte flaskehalsen. Et design der forskyder og overlapper trafikken, kan være forskellen mellem responsiv og hakkende inferens. Det handler om bedre pipeline i collective‑kald, ikke trylleri.
Træningspipeline og data
Pre‑training dækker cirka 7,1 billion tokens fra åbne korpora, inklusiv Nemotron‑CC‑v2, MegaMath, FineMath, RefineCode og TxT360. Mid‑training beskrives som et forløb med Dolma3 Dolmino 100B i tre varianter, der samles via vægt‑averaging. Det valg kan bevare generel viden uden at slibe nichekompetencerne væk fra data‑blandingerne – og det er usædvanligt velbeskrevet i materialet.
Lang kontekst skaleres fra 4K til 64K via YaRN, højere RoPE‑theta og dokumentmaskering. Opskriften ligner andre åbne projekter, men detaljegraden hjælper dem, der vil reproducere stabil 64K. Post‑træning går fra SFT på Dolci‑Think‑SFT‑7B plus Nemotron‑mix, over DPO med router‑bias‑opdateringer, til RL i Miles‑rammen: først cirka 1.400 skridt RLVR for instruktioner og derefter multi‑lærer on‑policy distillation for at fastholde gevinster uden at tabe kode og matematik. DPO‑trinnet nævner også, at load‑balancing‑tab for routeren slås fra for at undgå degradation. Små detaljer – nyttige til egne ablations.
Reproducerbarhed i praksis
AMD udgiver vægte fra hvert træningsstadie, datasammensætninger og konfigurationer samt inferenskode. For universitetsgrupper betyder det, at man kan køre målrettede ablation‑studier uden at genskabe hele 7,1T tokens. En realistisk plan er at genskabe mid‑training på mindre datasæt, validere routing‑adfærd og teste YaRN‑opgraderingen fra 4K til 32K før 64K. For enterprise R&D er MIT‑licensen på koden den mest genbrugelige del, da vægtlicensen spænder ben for direkte kommerciel udrulning.
Hvor mange GPU‑timer kræver et delstudie? Der er ikke ét tal. Med en håndfuld moderne datacenter‑GPU’er kan man køre småskala SFT og DPO på pipeline‑udsnit, mens MoE‑routing‑eksperimenter kan prøves på 1–2 lag i en frusen base. Ikke gratis – men heller ikke uoverkommeligt.
Licens og brug
Vægtene er udgivet under ResearchRAIL, som efter alt at dømme begrænser brugen til forskning og akademi. Træningskoden er MIT‑licenseret. Kombinationen passer til formålet: undersøg, genskab og byg videre metodisk – men pak ikke den præcise model i en kommerciel tjeneste. Den praktiske grænse for “research only” kan være uklar i gråzoner som virksomheders POC’er. Juridiske teams bør læse licensen nøje; ResearchRAIL er ikke en standardlicens som Apache eller MIT. Hvis teksten ikke er fuldt offentligt dokumenteret, er det et åbent punkt, der skal afklares før produktionstests.
Driftsøkonomi og serving
Hvorfor gør ~2,8B aktive parametre en forskel for omkostning per token? Fordi multiplikationer og hukommelsesbevægelser følger den aktiverede kapacitet – ikke totalen. En monolitisk 16B‑model flytter i grove træk hele vægten ved hvert token; her nøjes man forenklet med knap en femtedel. Det sænker latency og strømforbrug pr. svar, især ved små eller ujævne batches.
AMD angiver, at selve vægtene for 16B i BF16 ligger omkring 32 GB (2 bytes per parameter). Dertil kommer KV‑cache og aktiveringer, så et komfortabelt kort bør have mere. En enkelt høj‑hukommelses accelerator kan i princippet køre single‑GPU inferens, mens ekspert‑parallel serving fordeler eksperter på flere GPU’er. Så bliver netværket igen kritisk. FarSkip forsøger at holde kortene beskæftiget, mens data krydser interconnect.
Hvis I allerede har Nvidia‑klynger med velkendte inference‑runtimes, er spørgsmålet, om Instella‑stacken spiller pænt. AMD leverer SGLang‑baseret inferenskode. SGLang er effektiv på moderne hardware, men kompatibilitet og ydeevne i netop jeres Triton‑ eller DeepSpeed‑miljø skal måles. Et lille POC er fornuftigt, før man binder ressourcer i skala.
Sikkerhed, audit og dataetik
Åbenhed gør audit mere konkret. Med adgang til data‑mixtures og vægte fra flere stadier kan man spore kilder, måle toksicitet og finde problematiske domæner – en fordel i regulerede brancher. Bagsiden er, at offentlige data‑blandinger kan genbruges, hvor licenser ikke holder, eller hvor datasensitivitet ændrer risikoen. Kør licens‑ og datasporingsgennemgang, før modellen eller dens varianter rammer produktionsmiljøer.
Husk også, at RL‑trinnene kan ændre adfærd markant. Et sikkerhedsreview bør dække flere checkpoints, ikke kun slutmodellen. En mindre “SFT‑kun” variant kan reagere anderledes end en “Think”‑ eller “DPO”‑udgave. Test begge, hvis de findes.
Benchmark og position
Basemodellen rapporteres til et gennemsnit på 76,7 på en tværsuite og ligger foran Moonlight‑16B‑A3B på 76,2, SmolLM3‑3B‑Base på 70,5, OLMo‑3‑7B på 70,1 og OLMoE‑1B‑7B på 61,9. Den halter efter Qwen3.5‑4B‑Base på 79,5. Den topper WinoGrande med 86,5 og scorer 65,7 på HumanEval+. For lang kontekst nævnes 41,5 på HELMET og 79,4 på RULER. Post‑træning løfter fra SFT 71,58 til DPO 72,67 og Think 73,22, og IFEval stiger fra 77,08 til 83,70. Tallene er kun så gode som eval‑suiten og seed‑opsætningen, så dobbelttjek hvilke benchmarks og versioner, der er brugt.
Hvem bør kigge nærmere
Forskningsmiljøer, der vil undersøge MoE‑routing, long‑context stabilitet og RL‑effekter, får et rigt udgangspunkt. Man kan målrette undersøgelser mod Gated MLA’s rolle eller FarSkip‑overlappets konkrete bidrag. Enterprise R&D med egne domæner kan hente træningskoden og køre adapter‑studier, fx på dansk fagsprog, uden at være låst til proprietære værktøjer. Cloud‑udbydere med AMD‑kapacitet kan bruge modellen som reference for expert‑parallel serving og prissætning.
Hurtige spor til eksperimenter: byg en 4–8 ekspert minivariant og mål TTFT med og uden FarSkip. Træn en adapter på 100–200M domænetokens og mål effekten på jeres vigtigste KPI’er. Test 64K kontekst på rigtige dokumenter med sektioneret retrieval – og notér ærligt, hvor den begynder at glide.
Indkøb og infrastruktur
Hvornår giver AMD‑kapacitet mening frem for eksisterende Nvidia‑klynger? Kig på latency, cost per token og compliance. Hvis ekspert‑parallel spiller, og SGLang leverer lav TTFT på jeres vigtigste flows, kan skiftet give gevinst. Hvis jeres stack er tæt bundet til Triton og CUDA‑specifikke optimeringer, kan friktionen æde gevinsten. On‑prem giver kontrol og datasuverænitet; cloud giver elasticitet ved spidsbelastning. Ingen mirakler – kun trade‑offs.
For beslutningstagere er rækkefølgen vigtigere end brand: tjek netværksfabric og collective‑ydelse, før I tuner router‑hyperparametre. Kommunikationslaget kan ellers æde hele gevinsten.
Begrænsninger og åbne spørgsmål
ResearchRAIL sætter en klar streg for kommerciel brug af vægtene. Hvordan “research” præcist fortolkes i enterprise‑POC’er, er ikke fuldt afdækket i det offentlige materiale. De rapporterede speedups på 12,7 procent og 39,2 procent kræver reproducerbare scripts, der specificerer batch, sekvenslængde, antal GPU’er og netværksopsætning – forvent variation på tværs af miljøer.
Servingtårnet er desuden centreret om SGLang. Der er ikke dyb åben dokumentation om plug‑in‑kompatibilitet mod fx Triton eller DeepSpeed Inference. Test det i praksis med jeres jobmix, ellers risikerer I, at MoE‑gevinsterne forsvinder i runtime‑overhead.
Konkrete næste skridt
Tre jordnære ting: Læs ResearchRAIL‑licensen og afgør, om jeres POC’er falder inden for rammerne. Reproducer et enkelt MoE‑lag med 2 delte og 8 routede eksperter og mål TTFT og throughput med og uden FarSkip. Kør egne evals på domænedata ved 4K og 64K kontekst og skriv ned, hvor modellen fejler. De noter er guld, når I senere vælger hardware og serving‑stack – forskellen mærkes først, når man har det i hænderne.
