VibeThinker‑3B landede 19. juni med en skarp pointe: mindre kan måle sig med større på specifikke, verificerbare opgaver. Modellen har 3 milliarder parametre, bygger på Qwen2.5‑Coder‑3B og frigives under MIT‑licens. Forskerne beskriver en Spectrum‑to‑Signal post‑træningspipeline – ikke en ny pretrain. Læs selv papiret her: arXiv. To hurtige forbehold oppe foran: papiret mangler per‑fase datamængder, datasætssammensætning, compute og eksakte hyperparametre, og man bør bekræfte hosting/mirrors af weights, før de hentes bag firewall.
Scope først. Paritet med giganter gælder de navngivne verifikationsbenchmarks – matematik og kode med facit eller unit‑tests. Ikke åbne videnopgaver. Læses sådan, giver resultaterne mening og undgår overfortolkning.
Hvad modellen er og hvem der står bag
VibeThinker‑3B er en tæt 3B‑model oven på Qwen2.5‑Coder‑3B. Post‑trænet med supervised fine‑tuning, reinforcement learning og selv‑distillation. MIT‑licens muliggør både forskning og kommerciel brug under vilkårene. Kilden er forskningsrapporten fra et team hos Sina Weibo, med MarkTechPost som sekundær opsummering. Målet er snævert og praktisk: opgaver hvor et eksternt system kan bekræfte svaret – matematik der kan regnes efter, kode der kan køres og testes.
Det gør vurderingen enkel og forventningerne realistiske. Når en verifikator findes, kan en kompakt model konkurrere. Uden verifikator – åben viden, friske nyheder – taber den terræn til store generalister.
Hvad forskerne faktisk gjorde
Post‑træningen kører i faser. Først to‑trins supervised fine‑tuning: bredt curriculum på tværs af math, code, STEM, dialog og instruktion; derefter et skarpere sæt med sværere, længere eksempler filtreret på løsningslængde og vanskelighed. Diversity‑bevarende distillation fastholder flere gyldige veje gennem løsningen – ikke kun én gylden kæde.
Dernæst RL. Papiret beskriver MaxEnt‑Guided Policy Optimization og fokuserer på prompts i kanten af modellens kunnen, hvor både korrekte og forkerte forløb findes. Træningen kører sekventielt på math, code og STEM. Et konkret valg: de droppede progressiv kontekstudvidelse og holdt 64K kontekst i RL‑fasen, fordi warm‑up med høj truncation skadede langt ræsonnement på denne skala. I math‑RL bruges Long2Short til at belønne kortere korrekte forløb højere end lange – for at skære tomgangstokker uden at tabe nøjagtighed.
Spectrum to Signal kort
Supervised‑delen bygger et spektrum af gyldige ræsonnementsstier. RL forstærker signalet – de stier der mest pålideligt rammer facit. RL‑checkpoints destilleres tilbage i en elevmodel. Til sidst finpudses instruktionsefterlevelse. De overordnede trin er beskrevet klart, men de eksakte datamængder pr. fase er ikke åbne. Det gør det sværere at vurdere, præcis hvad der gav gevinsten.
Pointen for teams er jordnær: metoden kræver streng datasætstyring og feedbackkvalitet. Uden tal for hvad der gik ind, bliver planlægning af en gentagelse et kalkuleret gæt.
Hårde tal fra tabellen
Papiret rapporterer bl.a. AIME26 94,3, HMMT25 89,3, BruMO25 93,8, LiveCodeBench v6 Pass@1 80,2, IMO‑AnswerBench 76,4 og OJBench 38,6. Med test‑time scaling via Claim‑Level Reliability løftes AIME26 til 97,1 og HMMT25 til 95,4. Tallene står i Tabel 2 som rækkerne “VibeThinker‑3B” og “VibeThinker‑3B +CLR”. De måler verifikationsopgaver: matematik med entydige facit, kode der består testcases første forsøg, og olympiadetunge sæt, hvor sandt‑falsk kan afgøres uden skøn.
Netop derfor siger resultaterne mere end generelle chatbenchmarks. Og netop derfor skal man ikke udvide konklusionen til åbne, videnstunge domæner, hvor GPQA‑Diamond i samme tabel viser et tydeligt hul til de største modeller.
Sammenlignet med de store
Tabel 2 stiller 3B‑modellen op mod bl.a. DeepSeek V3.2 og Kimi K2.5. Den vinder ikke over alt, men den ligger i topklasen på verificerbar math og code, målt mod modeller hundrede gange større. På GPQA‑Diamond er forskellen markant – og forventelig, fordi verifikator mangler.
Oversat til praksis: hvis jobbet har en dommer (unit‑tests, facitliste, evalscript), kan en lille specialist være nok. Uden dommer, og med behov for bred verdensviden, er de helt store stadig bedre køb – især når svar skal være friske.
Drift og deployment uden illusionsnumre
BF16‑vægtene er omkring 6 GB. Det betyder, at modellen kan læsses på en enkelt GPU – men husk KV‑cache, kontekst og batch. Realistisk har man det behageligt på 12–24 GB fornuftige batches og latency. Et stramt 8–12 GB kort kan gå med kvantisering og små batches, men latency bliver følsom.
En enkel tommelfinger: lav latency på en RTX 4070/4080 med lille batch og kort kontekst; højere gennemløb på en L4 eller A10G med batch og længere kontekst. Begge kræver versionsdisciplin. Papiret nævner transformers≥4.54.0 samt anbefaler vLLM 0.10.1 eller SGLang≥0.4.9.post6 til hurtig inferens. Lås dem i CI – det er billigere end at fejlsøge i prod.
Hvad CLR gør ved inference
Claim‑Level Reliability er test‑time scaling: modellen vurderer delpåstande og vægter svaret derefter. Man bytter ekstra gennemløb og kompleksitet for højere præcision på svære sæt. I Tabel 2 flytter det AIME26 og HMMT25 synligt opad. I drift bør det gates selektivt – f.eks. kun på højrisikoforespørgsler eller når første pass udviser lav sikkerhed – ellers stiger både latency og regning unødigt.
Kost i praksis følger antallet af pass gennem modellen. To pass vil typisk nær fordoble svartid og tokenforbrug. Log rationaler kort til audit, ikke romaner; og slå CLR fra for trivielle queries.
Hvor modellen giver mening
Verifikations‑tunge forløb. Autograding af kode med unit‑tests. Matematikvalidering i rapportudkast. Tekniske Q&A‑flows hvor svar kan kontrolleres mod specifikationer. Her kan en kompakt model, der kører on‑prem eller i VPC, være en reel driftsfordel – også ift. governance og omkostning.
Hvor bør man stadig gå større. Åbne forespørgsler, ukendt dokumentmasse, dagsaktuel viden. Her leverer brede foundation‑modeller typisk lavere hallucination og bedre dækning – især koblet med retrieval.
Risici, begrænsninger og compliance
Der er åbne huller: dataudspecificering pr. fase, compute og hyperparametre er ikke fuldt dokumenteret. Det svækker generaliserbarhed og gør replikation tung. OJBench på 38,6 viser også, at ikke al kodegenerering sidder lige i skabet. Sikkerhed fylder lidt i papiret: adversarial robusthed og prompt‑injection er ikke gennemtestet offentligt.
Compliance: holdet er fra Kina, udgivelsen er delt via åbne kanaler. Standardråd for danske organisationer: valider MIT‑licensens anvendelse på weights, tjek værtsdomæner for weights/spejle ift. eksport/sanktionsregler i egen branche, og afklar dataflow og logging i clouds. EU AI‑forordningen kan påvirke planer for autonome agenter; indbyg menneskelig oversight og dokumentation tidligt.
Operationalisering i et dansk team
Start småt og målbart. Brug evals der kan verificeres, ikke kun NLU‑mål. Indfør en CLR‑lignende test‑time skaleringssti i validering for at se, om gevinsten opvejer latency hos jer. Fastlås transformers og vLLM/SGLang i containere. Kør læk‑ og sikkerhedstests på promptgrænser. Og lad være med at koble modellen til produktionsdata, før audit og red‑team har været igennem.
Et kort, brugbart checklist‑udsnit:
- Datasæt: 50–200 interne math/kodeopgaver med facit eller unit‑tests. Inkludér 10–20 bevidst snedige fejlprompter.
- Metrikker: Pass@1, P95‑latency, tokenforbrug, CLR‑aktiveringsrate.
- Fail‑gates: stop hvis Pass@1 falder under baseline, eller hvis latency overstiger jeres SLA ved CLR‑aktivering.
- Adversarial: prompt‑injection‑forsøg i system‑ og tool‑kald, model‑output‑lækageprøver, og “spec change”‑tests hvor krav ændres midt i opgaven. Lav et kort red‑team‑scenarie med misuse, dataekstraktion og jailbreak.
- Driftprofiler: test to profiler – lav latency (lille batch, kort kontekst) og høj throughput (større batch, længere kontekst). Log kun det nødvendige til audit.
Strategiske konsekvenser
Budget kan flyttes fra rå compute til data‑kuratering, træning og orkestrering. Papiret peger på, at målrettet post‑træning kan gøre en 3B‑model konkurrencedygtig på verificerbare opgaver, hvor man ellers antog 70–100B. Det kræver disciplin i belønningssignaler og validering, men TCO kan tippe i den lille models favør, især hvis drift kan holdes på én GPU.
Arkitekturvalg følger samme mønster: lille specialist til det deterministiske, stor generalist koblet på retrieval til det åbne. Ikke enten‑eller. Mere en rolig arbejdsdeling.
Frossen viden og et naturligt supplement
Små, stærke modeller er træningsfrosne. Amazon har rullet Web Search ud i Bedrock AgentCore som managed connector, der leverer frisk webviden uden egne søge‑API’er og udgående credentials. Pointen fra Amazons blog er lige til: uden retrieval kan modeller ikke svare på hændelser efter træningstid. Et web‑ eller dokumentretrieval‑lag er derfor et oplagt supplement her.
Praktisk: bind agent‑gatewayen til connectoren, hold forespørgslerne i jeres cloud, og log kilder for sporbarhed. Det gør ikke modellen klogere af sig selv, men det holder svarene friske.
Det der stadig mangler
Rapporten er stærk på benchmarks, svagere på hallucination og adversarial robusthed. Tredjeparts‑replikation er ikke offentlig endnu, så paritets‑læsearten forbliver foreløbig og snævert bundet til verifikationssættene i Tabel 2. Indtil andre måler, står konklusionen på ét ben.
Konklusion
En 3B‑model kan – med klog post‑træning – levere høj kvalitet på verificerbare opgaver. Næste skridt er praktisk: kør en målrettet pilot på jeres egne math/kodeopgaver med facit, brug selektiv CLR‑gating, lås runtime‑versioner og gennemfør adversarial tests før alt andet. Læg retrieval ved siden af for friske svar. Man opdager først forskellen, når man sidder med det i hænderne.
