Decision 3.0 vs Intern-Decision-4B: Två team finjusterade samma modell och var oense om allt annat

Ställ d3-mini, 4B-medlemmen i Decision 3.0, bredvid Intern-Decision-4B och det första du lägger märke till är inte en skillnad. Båda är finjusterade versioner av samma bas-checkpoint, Qwen3.5-4B. Båda anges ha 4,54 miljarder parametrar. Båda tar ett tillstånd, ett schema med namngivna frågor och en uppsättning kandidatsvar, och returnerar en kalibrerad sannolikhet per kandidat utan att generera en token. Båda är Apache-2.0. Båda släpptes utan tillkännagivande — InternLM laddade upp tre checkpoints på fyrtio sekunder den 26 september 2026, och vLLM-SR:s Decision 3.0-familj landade på Hugging Face den 10 oktober 2026, med nyheten förmedlad endast via vLLM-projektets X-konto.

Allt efter det är en meningsskiljaktighet. De är oense om hur man läser ut en sannolikhet ur modellen, om video räknas som indata, om hur lång en förfrågan får vara och – allra skarpast – om teamet är villigt att publicera siffran som säger att dess egen konfidens är tillförlitlig. Den här artikeln handlar om dessa fyra meningsskiljaktigheter och vad var och en av dem kostar dig, inte om vilken modell som är "bättre", eftersom de två inte är på samma skala och inte kan ställas mot varandra utan att göra vad varje leverantör har gjort.

Sammanträffandet värt att förstå först

Att två labb väljer samma 4B-stomme inom loppet av två veckor är inte helt förvånande – Qwen3.5-4B är en rimlig bas för en modell för strukturerad utdata, och båda teamen grep uppenbarligen efter den eftersom den är tillräckligt liten för att köras billigt och tillräckligt stark för att läsa instruktioner. Det förvånande är att de kom fram till samma parameterantal med fyra värdesiffror. Det säger att finjusteringen bevarade arkitekturen, och att ingen av dem lade till ett separat visionstorn som var tillräckligt stort för att påverka totalen. Båda integrerar sin multimodala förmåga i samma vikter.

Det intressanta är utläsningen. Båda modellerna besvarar frågor på i princip samma sätt — de poängsätter kandidatsvar i stället för att generera dem — och helt olika till sin mekanism:

• Intern-Decision-4B — mappar varje alternativ till en enda tokensymbol (A–Z, sedan a–z, sedan 0–9), renderar ett JSON-skelett i prompten med en platshållare per fält och kör en kausal framåtpassning, där logits läses vid positionen omedelbart före varje platshållare. Mekanismen dokumenteras steg för steg på dess modellkort, inklusive det exakta softmax- och temperatursteget.

• d3-mini — levererar en anpassad arkitektur i modeling_d3.py med ett separat readout-huvud i sin egen readout.safetensors, en decision_config.json som deklarerar noncausal_full_attention och pooling av sista token, och en token-till-kod-mappning definierad i konfigurationen snarare än beskriven i prosa.

Ingen av metoderna är uppenbart bättre. InternLM-vägen har fördelen att den körs på en vanlig Hugging Face-modellklass med en dokumenterad numerisk sekvens – du kan granska dess arbete. vLLM-SR-vägen har fördelen att utläsningen är ett tränat huvud snarare än en projektion av en befintlig tokeninbäddning, vilket är en friare anpassning, och kostnaden är att du måste sätta trust_remote_code=True och köra deras kod för att kunna göra något överhuvudtaget.

Gränserna som var och en publicerar

Det är här en verklig preferens börjar ta form, eftersom ett kort är mycket mer specifikt än det andra om var det slutar fungera.

• Indatatak — Intern-Decision-4B: 8 192 tokens som standard och förfrågningar över det avvisas direkt, trunkeras aldrig, där taket sätts av ett konstruktorargument. d3-mini: max_length är null i den levererade konfigurationen och ingen tokenbudget förekommer någonstans på kortet.

• Frågor per begäran — Intern-Decision-4B: 1 till 16, med ett angivet maxantal på 62 alternativ i en och samma fråga. d3-mini: ingen angiven gräns; kortet säger bara att frågorna besvaras tillsammans, var och en från sin egen framåtpassning.

• Bilder — Intern-Decision-4B: upp till åtta per begäran, ordnade efter en lista du anger, med checkpoint-processorn som hanterar storleksändring och token-expansion. d3-mini: flera per begäran som sökvägar, URL:er, PIL-bilder eller base64-data-URL:er, var och en läses med upp till 1,6 megapixlar, varje fråga ser varje bild.

• Video — Intern-Decision-4B: inga. d3-mini: flera videor, läses med 2 bilder per sekund, max 32 bilder utspridda över klippet och 0,2 megapixlar per bild.

Taket för indata är den gräns som kommer avgöra detta för de flesta. En budget på 8 192 token som delas mellan tillstånd, frågeinstruktioner och kandidatbeskrivningar är en verklig begränsning för det arbete med dokumentbedömning och långkontextsrouting som dessa modeller säljs för, och InternLM förtjänar beröm för att ha sagt det rakt ut i stället för att låta det upptäckas. Att vLLM-SR låter det vara osagt är motsatsen: inte en dold gräns, utan en okänd sådan, och hur mycket man än läser repositoriet så avgör det inte saken.

Kalibrering är den verkliga skiljelinjen.

Varje beslutsmodell ger samma löfte: talet den returnerar är en sannolikhet, och tröskelvärden satta mot den betyder något. Nästan ingen av dem bevisar det. Det är här de två utgåvorna skiljer sig mest, och skillnaden går i motsatt riktning mot den man skulle gissa utifrån releasedatum.

Intern-Decision-4B publicerar på sitt eget modellkort en Brier-poäng på 0,347 och ett förväntat kalibreringsfel på 0,065 i sitt genomsnitt över sju benchmarks, en anpassad temperatur på 1,99241824 härledd genom NLL-minimering på 1 728 angivna kalibreringsfall med 1 693 separata valideringsfall, ett uttryckligt uttalande om att testsvitens etiketter inte användes för att välja den temperaturen, och en diagnostik med 96 fall som visar att dess kalibrering går från 0,628 Brier / 0,213 ECE före temperaturskalning till 0,550 / 0,089 efter. Den anger också standardvärdet och säger att kalibreringen är per checkpoint, så att använda en annan storlek med den här modulen kommer inte att matcha.

Decision 3.0 publicerar ett noggrannhetsindex och ett täckningsanspråk – alla 140 178 publika förfrågningar besvarade, ingen utan stöd – och ingen kalibreringssiffra alls. Ingen Brier-poäng, ingen ECE, ingen angiven temperatur på någon av de sex checkpoints. temperatur i d3:s medföljande decision_config.json är 1.0, vilket är identiteten och kan vara det anpassade värdet eller inte; filen säger inget.

Läs de två indexrubrikerna sida vid sida, och asymmetrin blir värre. d3-minis kort rapporterar en Jev Decision Index 0.3-public-suite-poäng på 54,90, beskriven som uppmätt med det officiella kitet på de släppta vikterna, medan jämförelseraderna på samma tavla beskrivs som livedata från tavlan. Intern-Decision-4B rapporterar ett genomsnitt på 90,02 över sina egna sju benchmarks. De två siffrorna ligger inte på samma skala, de använder inte samma uppgifter, och att sätta dem i en och samma mening som en jämförelse vore oärligt. Det som är jämförbart är redovisningen: ett kort berättar hur fel dess konfidensvärden är, och det andra vet inte eller vill inte säga.

Latens, och varför de två uppsättningarna millisekunder inte heller är jämförbara

Båda korten redovisar latens per förfrågan, och att ta dem bokstavligt vore ett misstag av samma skäl som att noggrannhetssiffrorna inte är jämförbara.

• Intern-Decision-4B — medelvärde 44,16 ms, median 44,03 ms, p95 44,60 ms, uppmätt på ett enda RTX 4090 via den lokala Hugging Face-vägen, beskrivet som beroende av arbetsbelastning och hårdvara.

• d3-mini — median 17,5 ms för text, 96,2 ms med en bild, 371,5 ms med en tio sekunder lång video, på en AMD Instinct MI325X, en förfrågan i taget.

Två saker gör dessa ojämförbara. Den första är hårdvaran och mjukvaruvägen: ett 4090 mot ett MI325X, en vanlig Hugging Face forward pass mot en anpassad attention-implementation med kärnor för maskerade lager tillgängliga via flash-linear-attention. Den andra är arbetsbelastningen: InternLM:s siffra beskrivs som per-query end-to-end på en oangiven mix, och vLLM-SR:s är uppdelad efter indatamodalitet, så jämförelsen av enbart text är den enda jämförbara raden och även den spänner över två GPU-tillverkare.

Det tal som ska utläsas ur båda korten är inte rankningen, utan formen. En beslutsmodell anropas upprepade gånger i ett och samma arbetsflöde – en supportpost kan behöva en destination, en återbetalningskontroll, ett eskaleringsbeslut och en prioritetspoäng, fyra frågor, och en batch med 128 poster gör att det blir 512 beslut. Vid den volymen försvinner både 17 ms och 44 ms i jämförelse med vad den generativa modellen nedströms än kostar. De modalitetsberoende siffrorna är de man bör hålla ögonen på, eftersom en bild- eller videoförfrågan kostar mellan fem och fem gånger så mycket som en textförfrågan enligt d3-minis egna siffror, och om ditt beslut fattas utifrån en skärmbild har du importerat en kostnadsprofil som de flesta driftsättningar av beslutsmodeller inte har.

Vilken ska man egentligen välja?

Om det beslut du behöver fatta beror på en video, finns det ingen tävlan och ingen analys krävs: Decision 3.0 läser video och Intern-Decision-4B gör det inte. Det är hela svaret för allt som involverar skärminspelningar, kameraklipp eller bildsekvenser, och det är kapacitetsgapet som i sig självt motiverar den nyare familjens existens.

Om dina indata är text och enstaka bilder, hänger valet på två saker, och ingen av dem är topplistan.

Ta Intern-Decision-4B när du behöver resonera om tröskelvärden. Det är den enda av de två som talar om för dig huruvida ett 0,9 betyder nio gånger av tio, den anger sin temperatur, den säger vilka fall temperaturen anpassades på, och den dokumenterar sin inferens som en kort numrerad procedur som du kan återimplementera mot en standardmodellklass. För en poängsättare som sitter framför en automatiserad åtgärd är det den egenskapen som spelar roll, och den är ovanligare än träffsäkerhetspoäng.

Välj Decision 3.0 när du behöver utbudet eller modaliteterna. Sex checkpoints från 0,59B till 26,09B innebär att samma förfrågningsformat kan hanteras av en edge-modell på 6,7 ms och en på 27B, och familjen delar ett gränssnitt, så att flytta mellan nivåer är en konfigurationsändring snarare än en omskrivning. Haken är att du litar på en outtalad indatabudget och ett ogranskat kalibreringspåstående, och den största modellen i familjen är den vars indexnummer leverantören mätte i sin egen testbänk.

Ingen av dem är ett säkert standardval i dag. d3:s mest nedladdade checkpoint har funnits på Hugging Face i ungefär ett dygn; Intern-Decision-4B har varit uppe i två veckor och fått ungefär 3 200 nedladdningar och 83 gillningar, vilket är uppmärksamhet men inte produktionstrafik. Båda är tillräckligt billiga att testa och ingen av dem har en tredjepartsutvärdering bakom sig. Om du sätter en scorer framför något som spenderar pengar är det rätta draget att köra båda på dina egna märkta fall och jämföra kalibreringskurvorna, inte indexraderna.

Var en router passar in, ärligt talat

OrcaRouter har inte någon av dessa modeller. Decision 3.0:s checkpoints är en lokal Python-inferensväg i ett Hugging Face-repositorium utan publicerad HTTP-endpoint, och Intern-Decision-4B levereras som en DecisionEngine-klass som du själv instansierar. Ingen av dem är något vi skulle kunna routa idag, och ingen del av den här artikeln bör läsas som ett påstående om tillgänglighet.

Det vi däremot erbjuder är den hostade delen av samma familj. typesafe/jev-1.13 finns i vår katalog och serveras via POST /v1/systemone – samma kontrakt för state och namngivna frågor som båda de öppna modellerna ovan implementerar – till $0.042 per miljon input-tokens utan avgift för completion, eftersom den aldrig genererar någon. Den finns sida vid sida med över 200 andra modeller, och det är den praktiska poängen för alla som jämför dessa två: scorern är den billiga delen av loopen och modellen som agerar på beslutet är den dyra delen. Att routa båda genom en och samma nyckel, med automatisk failover när en leverantör strular och leverantörens listpris som förs vidare med 0 % påslag, innebär att utvärdera en beslutsmodell inte kräver att man tecknar ett andra avtal eller skriver om anropsplatsen när man byter backend. Om du är mitt i en utvärdering – vilket båda dessa modeller är i dag – är det den delen som är värd att sätta upp innan du bestämmer dig för någon av dem.

Den öppna frågan

De två korten är oense om vad en modellförfattare är skyldig en läsare, och den oenigheten är mer intressant än modellerna. InternLM publicerade en temperatur och de fall den anpassades på, och publicerade sedan diagnosen som visade hur mycket kalibreringen förbättrades. vLLM-SR publicerade filhaschar, fastnaglade basrevisioner, ett angivet hårdvarumål, ett täckningspåstående — ett verkligt proveniensarbete — och inget kalibreringstal alls.

Testet på vilken release som mognar är inte vilken som vinner en resultattavla. Det är huruvida nästa Decision-checkpoint levereras med en Brier-poäng på sig, och huruvida InternLM:s nästa uppladdning når video. Båda är synliga utifrån, båda är billiga att kontrollera, och ingendera har hänt ännu.