Decision 3.0 vs Intern-Decision-4B: twee teams fine-tuneden hetzelfde model en waren het over al het andere oneens

Zet d3-mini, het 4B-lid van Decision 3.0, naast Intern-Decision-4B en het eerste dat je opvalt is geen verschil. Beide zijn fine-tunes van hetzelfde basischeckpoint, Qwen3.5-4B. Beide staan vermeld met 4,54 miljard parameters. Beide nemen een toestand, een schema van benoemde vragen en een reeks kandidaatantwoorden, en retourneren een gekalibreerde waarschijnlijkheid per kandidaat zonder een token te genereren. Beide zijn Apache-2.0. Beide zijn uitgebracht zonder aankondiging — InternLM uploadde drie checkpoints in veertig seconden op 26 september 2026, en de Decision 3.0-familie van vLLM-SR verscheen op Hugging Face op 10 oktober 2026, waarbij het nieuws alleen via het X-account van het vLLM-project werd verspreid.

Alles daarna is een meningsverschil. Ze zijn het oneens over hoe je een waarschijnlijkheid uit het model afleest, over of video als invoer telt, over hoe lang een verzoek mag zijn, en — het scherpst — over of het team bereid is het getal te publiceren dat zegt dat zijn eigen zekerheid betrouwbaar is. Dit stuk gaat over die vier meningsverschillen en wat elk ervan je kost, niet over welk model "beter" is, omdat de twee niet op dezelfde schaal worden gemeten en niet tegen elkaar kunnen worden afgezet zonder werk te doen dat geen van beide leveranciers heeft gedaan.

Het toeval dat het waard is om als eerste te begrijpen

Dat twee labs binnen twee weken voor dezelfde 4B-backbone kiezen, is niet helemaal verrassend — {{1}}Qwen3.5-4B{{/1}} is een redelijke basis voor een model met gestructureerde output, en beide teams hebben er duidelijk naar gegrepen omdat het klein genoeg is om goedkoop te draaien en sterk genoeg om instructies te lezen. Wat verrassend is, is dat ze op hetzelfde aantal parameters uitkwamen, tot op vier significante cijfers. Dat vertelt je dat de fine-tuning de architectuur heeft behouden, en dat geen van beide een aparte visietoren heeft toegevoegd die groot genoeg is om het totaal te veranderen. Beide integreren hun multimodale capaciteit in dezelfde gewichten.

Het interessante deel is de uitlezing. Beide modellen beantwoorden vragen in principe op dezelfde manier — ze scoren kandidaatantwoorden in plaats van ze te genereren — en volledig anders qua mechanisme:

• Intern-Decision-4B — koppelt elke optie aan één enkel token-symbool (A–Z, dan a–z, dan 0–9), rendert een JSON-skelet in de prompt met een plaatsaanduiding per veld, en voert één causale forward pass uit, waarbij de logits worden uitgelezen op de positie direct vóór elke plaatsaanduiding. Het mechanisme wordt stap voor stap gedocumenteerd op de modelkaart, inclusief de exacte softmax- en temperatuurstap.

• d3-mini — levert een aangepaste architectuur in modeling_d3.py met een aparte readout-head in zijn eigen readout.safetensors, een decision_config.json die noncausal_full_attention en last-token pooling specificeert, en een token-naar-code-mapping die in de config wordt gedefinieerd in plaats van in proza beschreven.

Geen van beide benaderingen is duidelijk beter. De InternLM-route heeft als voordeel dat deze op een standaard Hugging Face-modelklasse draait met een gedocumenteerde numerieke reeks — je kunt de werking controleren. De vLLM-SR-route heeft als voordeel dat de readout een getrainde head is in plaats van een projectie van een bestaande token-embedding, wat een vrijere fit is, en de prijs is dat je trust_remote_code=True moet meegeven en hun code moet draaien om überhaupt iets te kunnen doen.

De limieten die elk publiceert

Dit is waar een voorkeur begint te ontstaan, omdat de ene kaart veel specifieker is dan de andere over waar hij ophoudt te werken.

• Invoerplafond — Intern-Decision-4B: standaard 8.192 tokens en verzoeken daarboven worden direct afgewezen, nooit afgekapt, waarbij het plafond wordt ingesteld via een constructorargument. d3-mini: max_length is null in de meegeleverde configuratie en er staat nergens een tokenbudget op de kaart.

• Vragen per verzoek — Intern-Decision-4B: 1 tot 16, met een opgegeven maximum van 62 opties in één enkele vraag. d3-mini: geen opgegeven limiet; de kaart zegt alleen dat vragen samen worden beantwoord, elk vanuit zijn eigen forward pass.

• Afbeeldingen — Intern-Decision-4B: maximaal acht per verzoek, geordend volgens een lijst die u aanlevert, waarbij de checkpoint-processor het formaat aanpast en tokens uitbreidt. d3-mini: meerdere per verzoek als paden, URL's, PIL-afbeeldingen of base64-data-URL's, elk gelezen met maximaal 1,6 megapixels, waarbij elke vraag elke afbeelding ziet.

• Video — Intern-Decision-4B: geen. d3-mini: meerdere video's, gelezen met 2 frames per seconde, beperkt tot 32 frames verspreid over de clip en 0,2 megapixels per frame.

Het invoerplafond is het punt dat voor de meeste mensen de doorslag zal geven. Een budget van 8.192 tokens, gedeeld tussen toestand, vraaginstructies en kandidaatbeschrijvingen, is een echte beperking voor het beoordelen van documenten en het routeren met lange context waarvoor deze modellen worden verkocht, en InternLM verdient lof omdat het dit ronduit zegt in plaats van het ontdekt te laten worden. Dat vLLM-SR het onvermeld laat, is het tegenovergestelde: geen verborgen limiet, maar een onbekende, en hoe grondig je de repository ook leest, het geeft geen uitsluitsel.

Kalibratie is de echte splitsing.

Elk beslissingsmodel doet dezelfde belofte: het getal dat het retourneert is een waarschijnlijkheid, en drempels die daartegen worden ingesteld, betekenen iets. Bijna geen van hen bewijst het. Dit is waar de twee releases het meest uiteenlopen, en de divergentie gaat in de tegenovergestelde richting van degene die je op basis van releasedata zou raden.

Intern-Decision-4B publiceert zelfstandig een Brier-score van 0,347 en een verwachte kalibratiefout van 0,065 over het gemiddelde van zijn zeven benchmarks, een gefitte temperatuur van 1,99241824 verkregen via NLL-minimalisatie op 1.728 aangewezen kalibratiecases met 1.153 afzonderlijke validatiecases, een expliciete verklaring dat test-suite-labels niet zijn gebruikt om die temperatuur te selecteren, en een diagnostische analyse van 144 gevallen waaruit blijkt dat zijn kalibratie verschuift van 0,628 Brier / 0,213 ECE vóór temperatuur naar 0,550 / 0,089 erna. Het vermeldt ook de standaardwaarde en zegt dat de kalibratie per checkpoint is, dus het gebruik van een andere grootte met deze module komt niet overeen.

Decision 3.0 publiceert een nauwkeurigheidsindex en een dekkingsclaim — elk van de 140.178 openbare verzoeken beantwoord, geen enkele zonder onderbouwing — en helemaal geen calibratiecijfer. Geen Brier-score, geen ECE, geen vermelde temperatuur, op geen van de zes checkpoints. temperatuur in de door d3 meegeleverde decision_config.json is 1.0, wat de identiteit is en al dan niet de gefitte waarde is; het bestand zegt het niet.

Lees de twee indexkoppen naast elkaar en de asymmetrie wordt alleen maar erger. De kaart van d3-mini rapporteert een Jev Decision Index 0.3 public-suite-score van 54,90, beschreven als gemeten met de officiële kit op de vrijgegeven gewichten, terwijl de vergelijkingsrijen op hetzelfde leaderboard worden beschreven als live leaderboardgegevens. Intern-Decision-4B rapporteert een gemiddelde van 90,02 over zijn eigen zeven benchmarks. Die twee getallen staan niet op dezelfde schaal, ze gebruiken niet dezelfde taken, en ze in één zin als vergelijking presenteren zou oneerlijk zijn. Wat wel vergelijkbaar is, is de openbaarmaking: de ene kaart vertelt je hoe onjuist zijn betrouwbaarheidsscores zijn, en de andere weet het niet of wil het niet zeggen.

Latentie, en waarom de twee sets milliseconden ook niet vergelijkbaar zijn

Beide kaarten publiceren de latency per verzoek, en ze op hun woord geloven zou om dezelfde reden een vergissing zijn als waarom de nauwkeurigheidscijfers niet vergelijkbaar zijn.

• Intern-Decision-4B — gemiddelde 44,16 ms, mediaan 44,03 ms, p95 44,60 ms, gemeten op een enkele RTX 4090 via het lokale Hugging Face-pad, beschreven als afhankelijk van de workload en de hardware.

• d3-mini — mediaan 17,5 ms voor tekst, 96,2 ms met een afbeelding, 371,5 ms met een video van tien seconden, op één AMD Instinct MI325X, één verzoek tegelijk.

Twee dingen maken ze onvergelijkbaar. Het eerste is de hardware en het softwarepad: een 4090 tegenover een MI325X, een standaard Hugging Face forward pass tegenover een aangepaste attention-implementatie met masked-layer-kernels die beschikbaar zijn via flash-linear-attention. Het tweede is de workload: het cijfer van InternLM wordt beschreven als per query end-to-end op een niet-gespecificeerde mix, en dat van vLLM-SR is uitgesplitst naar invoermodaliteit, dus de alleen-tekstvergelijking is de enige gelijkwaardige regel en zelfs die overspant twee GPU-leveranciers.

Het getal dat je uit beide kaarten moet halen, is niet de rangschikking; het is de vorm. Een beslissingsmodel wordt herhaaldelijk aangeroepen binnen één workflow — een supportrecord kan een bestemming, een terugbetalingscontrole, een escalatiebeslissing en een prioriteitsscore nodig hebben, vier vragen, en een batch van 128 records maakt daar 512 beslissingen van. Bij dat volume vallen 17 ms en 44 ms beide in het niet bij wat het generatieve model stroomafwaarts ook kost. De modaliteitsafhankelijke cijfers zijn de cijfers om in de gaten te houden, want een afbeeldings- of videoaanvraag kost volgens d3-mini's eigen cijfers tussen vijf en twintig keer zoveel als een tekstaanvraag, en als je beslissing op basis van een screenshot wordt genomen, heb je een kostenprofiel geïmporteerd dat de meeste implementaties van beslissingsmodellen niet hebben.

Welke moet ik nu eigenlijk kiezen?

Als de beslissing die je moet nemen afhangt van een video, is er geen wedstrijd en is er geen analyse nodig: Decision 3.0 leest video en Intern-Decision-4B niet. Dat is het volledige antwoord voor alles met schermopnamen, cameraclips of framereeksen, en het is het verschil in capaciteiten dat op zichzelf het bestaan van de nieuwere familie rechtvaardigt.

Als je invoer tekst en af en toe afbeeldingen is, draait de keuze om twee dingen, en geen van beide is het leaderboard.

Neem Intern-Decision-4B wanneer je moet redeneren over drempelwaarden. Het is de enige van de twee die je vertelt of een 0,9 negen van de tien keer betekent, het noemt zijn temperatuur, het vermeldt op welke gevallen die temperatuur is gefit, en het documenteert zijn inferentie als een korte genummerde procedure die je opnieuw kunt implementeren tegen een standaard modelklasse. Voor een scorer die voor een geautomatiseerde actie zit, is dat de eigenschap die ertoe doet, en die is zeldzamer dan nauwkeurigheidspunten.

Kies Decision 3.0 wanneer je het gamma of de modaliteiten nodig hebt. Zes checkpoints van 0,59B tot 26,09B betekenen dat hetzelfde aanvraagformaat kan worden afgehandeld door een edge-model van 6,7 ms en een model van 27B, en de familie deelt één interface, dus wisselen tussen niveaus is een configuratiewijziging in plaats van een herschrijving. Het addertje onder het gras is dat je vertrouwt op een niet-gespecificeerd inputbudget en een niet-geauditeerde kalibratieclaim, en het grootste model in de familie is het model waarvan de leverancier het indexnummer op zijn eigen testharnas heeft gemeten.

Geen van beide is vandaag een veilige standaardoptie. d3's meest gedownloade checkpoint staat ongeveer een dag op Hugging Face; Intern-Decision-4B staat er al twee weken en heeft ongeveer 3.200 downloads en 83 likes opgeleverd, wat aandacht is, maar geen productieverkeer. Beide zijn goedkoop genoeg om te testen, en geen van beide heeft een evaluatie door een derde partij achter zich. Als je een scorer voor iets zet dat geld uitgeeft, is de juiste zet om beide op je eigen gelabelde gevallen te draaien en de kalibratiecurves te vergelijken, niet de indexrijen.

Waar een router past, eerlijk gezegd

OrcaRouter ondersteunt geen van deze modellen. De checkpoints van Decision 3.0 vormen een lokaal Python-inferentiepad in een Hugging Face-repository zonder gepubliceerd HTTP-eindpunt, en Intern-Decision-4B wordt geleverd als een DecisionEngine-klasse die je zelf instantieert. Geen van beide is iets dat we vandaag zouden kunnen routeren, en niets in dit artikel mag worden gelezen als een beschikbaarheidsclaim.

Wat wij wel aanbieden, is het gehoste uiteinde van dezelfde familie. typesafe/jev-1.13 staat in onze catalogus, aangeboden via POST /v1/systemone — hetzelfde contract voor state en benoemde vragen dat beide open modellen hierboven implementeren — voor $0,042 per miljoen inputtokens zonder kosten voor een completion, aangezien het er nooit een genereert. Het staat naast meer dan 200 andere modellen, en dat is het praktische punt voor iedereen die deze twee vergelijkt: de scorer is het goedkope deel van de lus en het model dat op de beslissing handelt is het dure deel. Beide routeren via één sleutel, met automatische failover wanneer een provider hapert en de lijstprijs van de provider doorgegeven tegen 0% opslag, betekent dat het evalueren van een beslissingsmodel niet vereist dat je een tweede contract ondertekent of de aanroepplaats herschrijft wanneer je van backend wisselt. Als je midden in een evaluatie zit — wat vandaag voor beide modellen geldt — dan is dat het deel dat het waard is om op te zetten voordat je je aan een van beide vastlegt.

De open vraag

De twee kaarten verschillen van mening over wat een modelauteur een lezer verschuldigd is, en dat meningsverschil is interessanter dan de modellen. InternLM publiceerde een temperatuur en de gevallen waarop die was gefit, en publiceerde daarna de diagnostiek die laat zien hoeveel de kalibratie verbeterde. vLLM-SR publiceerde bestandshashes, vastgezette basisrevisies, een opgegeven hardwaretarget, een dekkingsclaim — echt herkomstwerk — en helemaal geen kalibratiegetal.

De test om te bepalen welke release volwassen wordt, is niet welke er een leaderboard wint. Het is of het volgende Decision-checkpoint uitkomt met een Brier-score erop, en of de volgende upload van InternLM video bereikt. Beide zijn van buitenaf zichtbaar, beide zijn goedkoop te controleren, en geen van beide is al gebeurd.