Microsoft-Decision-1 vs Intern-Decision-2B: Nio millisekunder snabbare och mätbart sämre kalibrerad

Det finns ett nummer i InternLM:s egen tabell som inte borde finnas, och det är anledningen till att den här jämförelsen är värd mer än specifikationsbladet. Intern-Decision-2B — 2 213 241 664 parametrar, finjusterad från Qwen/Qwen3.5-2B, uppladdad till Hugging Face den 26 september 2026 kl. 05:36:19 UTC utan något tillkännagivande — uppvisar en 33,28 ms genomsnittlig svarstid per fråga på ett enda RTX 4090, vilket är marginellt snabbare än dess egen syskonmodell med 852 miljoner parametrar på 33,98 ms. Den uppvisar också den sämsta kalibreringen i sin familj: ett förväntat kalibreringsfel på 0,100 mot 0,8B-modellens 0,066, med en anpassad temperatur på 2,100509348278 mot 0,8B-modellens 2,747760550703. SamtidigtMicrosoft-Decision-1, allmänt tillgänglig på Microsoft Foundry sedan 8 oktober 2026, publicerar varken någon svarstidssiffra eller något kalibreringsfel alls — bara ett metodstycke som beskriver hur båda mättes. Så frågan den här matchen egentligen ställer är inte vilken av de två som är bättre. Det är vad du köper när du köper mellanstorleken av vad som helst.

Båda modellerna är beslutspoängsättare: tillstånd in, en avgränsad frågeuppsättning in, kalibrerade sannolikheter ut, ingen genererad text och inga tokens att tolka. Det gemensamma kontraktet är det som gör skillnaderna tydliga. Microsoft-Decision-1 är ett hostat Foundry-API för enbart text på en Qwen3.5-9B-bas med ett fönster på 32 768 tokens, inga distribuerade vikter och ingen väg för finjustering. Intern-Decision-2B är en checkpoint under Apache-2.0 med den uppströms Qwen-licensen bevarad som LICENSE-QWEN, ett repository på cirka 4,46 GB, anpassad inferenskod och ingen hostad slutpunkt någonstans.

Vad mellanstorleken faktiskt är till för

InternLM släppte tre checkpoints på fyrtio sekunder: 0.8B kl. 05:35:57, den här kl. 05:36:19, 4B kl. 05:36:37. Enligt leverantörens eget genomsnitt över sju sviter klättrar familjen i den ordning man skulle hoppas — 79,38, 84,68, 90,02 — vilket är det enda stället där 2B framstår som ett förnuftigt köp. Överallt annars framstår den som den storlek ingen skulle ha valt med avsikt.

Promptbearbetning dominerar ett beslutsanrop, och det är den mekaniska förklaringen till latensinversionen snarare än ett mysterium. En scorer gör exakt en framåtpassning över en prompt vars längd bestäms av tillståndet, schemat och alternativbeskrivningarna – aldrig av något som modellen skriver, eftersom den inte skriver något. I den regimen är parameterantalet en andra ordningens kostnad, så det vanliga skälet att ta den minsta checkpointen gäller inte: du sparar inte tid, du sparar minne. 0.8B:s hela repo är ungefär 1,73 GB mot den här modellens 4,46 GB, och det är det ärliga skälet att föredra den. 2B:s enda riktiga anspråk är att den råkar vara den snabbaste av de snabba, med en marginal som är så liten att den är brus.

Ställt mot Microsoft-Decision-1 är det påståendet nästan irrelevant, eftersom de två modellerna inte befinner sig i samma latensregim. En hostad ändpunkts hastighet är en funktion av din distributionsform — serverlös kontra provisionerad genomströmning på samma standard-SKU — innan den är en funktion av modellen, och Microsoft publicerar ingen siffra per anrop att jämföra med. Vad Microsoft däremot publicerar är en hård operativ begränsning som verkar i motsatt riktning: batchinferens är inaktiverad. Det finns ingen offlinekanal att amortera en masskörning för poängsättning genom, så en Microsoft-Decision-1-pipeline betalar den interaktiva kostnaden för varje beslut, medan en egenhostad checkpoint betalar i GPU-timmar oavsett om den utför poängsättning eller inte.

Kalibreringskolumnen, där mitten förlorar

Läs de tre Intern-Decision-korten tillsammans och familjen slutar bete sig förutsägbart. Noggrannhet är monoton i storlek; kalibrering är det inte. 2B har en ECE på 0.100 — det svagaste av de tre — och en anpassad temperatur på 2.100509348278, långt under 0.8B:s 2.747760550703. Kortet instruerar dig att använda den inferensmodul som medföljer den storlek du laddade ner, eftersom standardkalibreringarna är per checkpoint; den som kopierar en wrapper från en syskonmodell till en annan tillämpar tyst fel temperatur.

Själva transformen är värd att förstå innan du behandlar den där 0,100 som en dom över vikterna. Det är en softmax över fältets kandidatlogits, följt av en andra softmax över logaritmen av den fördelningen delad med temperaturen. Eftersom den körs efter den första softmaxen och bevarar ordningen kan den inte ändra argmax alls. Den flyttar konfidensen, ja-sannolikheten och det förväntade värdet av en poängfråga, och lämnar etiketten oförändrad. Om din pipeline läser etiketter är temperaturen en no-op och ECE:n en kuriositet. Om din pipeline läser sannolikheter – trösklar dem, rangordnar efter dem, matar in dem i en beräkning av förväntat värde – då är en ECE på 0,100 skillnaden mellan en tröskel som betyder det du skrev och en som inte gör det. Rätt svar är att anpassa din egen temperatur på dina egna etiketterade fall, inte att dra slutsatsen att vikterna är dåliga.

Microsoft-Decision-1 efterfrågar exakt samma arbete, med mindre att utgå ifrån. På fliken Benchmarks står det att noggrannhet, kalibreringsfel, säkerhetsrecall, falskpositiva frekvenser och rättvisekonsekvens mättes på offentliga och community-baserade beslutsbenchmarkar samt internt undanhållna testset, att ordningen på alternativen varierades, att parade statistiska tester tillämpades, och att modellen "presterar i nivå med ledande beslutsmodeller och bättre än andra öppna beslutsmodeller som utvärderats med samma metodik." Ingen ECE. Ingen Brier. Ingen temperatur. Ingen noggrannhetstabell. Modellen vars hela värdeerbjudande är en tillförlitlig sannolikhet är den i den här jämförelsen som inte har något publicerat kalibreringstal alls.

Kontraktsgränser: fyra saker som den hostade modellen inte kommer att göra

De två modellerna tar vad som ser ut att vara samma anrop, och skillnaderna ligger i kanterna av det.

• Modalitet — Microsoft-Decision-1 är uttryckligen endast text och accepterar ingen bild, ljud eller video. Intern-Decision-2B accepterar upp till åtta bilder tillsammans med tillståndet, vilket gör den till en kandidat för triage av skärmbilder och layoutkontroller som det värdbaserade API:et inte kan utföra med någon som helst noggrannhet.

• Indatatak och felläge — Microsoft-Decision-1 utför ett enda anrop på upp till 32 768 tokens. Intern-Decision-2B deklarerar DecisionEngine(max_length=8192) och avvisar för stora indata i stället för att trunkera dem, vilket är korrekt beteende för en poängsättare och även en hård vägg, eftersom tillståndet, schemat och skelettet alla måste finnas med i en enda genomgång; ingen chunkningsstrategi bevarar kontraktet.

• Frågans utformning — InternLM dokumenterar en till sexton frågor per anrop med upp till 62 alternativ vardera över tre fälttyper (choice, score, noul), där noul är ett binärt ja/nej som returnerar en sannolikhet och score returnerar ett sannolikhetsviktat förväntat värde på en skala som du anger. Microsoft dokumenterar formaten — ja/nej, flerval, betyg, klassificering, bedömningsmatris — plus ett uttryckligen stött avståelsealternativ som "kan inte avgöra" när bevisningen är otillräcklig, vilket är den enskilt mest användbara raden på sidan för alla som skriver eskaleringslogik.

• Pris — modellsidan för Microsoft-Decision-1 anger ingen taxa; prissättningen länkar ut till Microsofts prissättningsyta, så kostnaden per beslut är något man läser av från Azure eller från en faktura, där 0 % av den kan tillskrivas utdatatokens eftersom det inte finns några. Intern-Decision-2B kostar ingenting per anrop och allt i GPU-tid, och den har ingen hostad leverantör. Dess lagring är ungefär 4,46 GB fördelat på en språk-shard på 3,76 GB, ett visionstorn på 612,5 MB och en projektor på 50,3 MB.

Vad är bekräftat, och vad är bara säljarens snack

Att hålla isär de två kategorierna är hela disciplinen med den här familjen. Bekräftat av en filförteckning eller ett HTTP-svar: parametrantalet, shard-kartan, licensparet, basmodellen, arkitekturen därunder — en Qwen3_5ForConditionalGeneration med 24 lager, en dold storlek på 2 048, 8 query-huvuden mot 2 key-value-huvuden, en huvuddimension på 256, ett återkommande mönster med tre linear-attention-lager mot ett full-attention-lager, ett bibehållet multi-token-prediction-lager och ett inbäddningstak på 262 144 positioner som motorns tak på 8 192 tokens gör praktiskt taget irrelevant.

Leverantörsrapporterade och icke-reproducerade: varje noggrannhetssiffra, varje latenssiffra och temperaturen. Det finns ingen artikel, ingen arXiv-post, inget lanseringsinlägg, ingen ändringslogg och ingen oberoende utvärdering. Demo Space svarar 401, vilket betyder att det inte är offentligt, inte att det är trasigt. GitHub-förrådet som dök upp efter modellen – tre commits, träningskod, två backendar för inferens, ett utvärderingspaket med 10 751 testrader, ett kalibreringsbenchmark med 96 fall och en reproduceringsguide – är mer dokumentation än vad de flesta tysta lanseringar får, och det levereras utan vikter, utan träningsdata och utan kodlicens. Microsoft befinner sig i en annan men närliggande position: dess metodik är verklig och dess påstående är kvalitativt, och inget av företagen är för närvarande i en position där dess centrala siffra kan granskas av någon annan än du.

Var OrcaRouter sitter i en pipeline som den här

Ingen av modellerna finns i vår katalog, och inget här bör läsas som ett påstående om tillgänglighet. En modell som returnerar sannolikheter i stället för text är inget man dirigerar chattkompletteringar till, och det gäller båda dessa. Det vi faktiskt erbjuder är den generativa halvan av den loop som dessa bedömare finns till för att betjäna: de över 200 modeller bakom en enda OpenAI-kompatibel nyckel som skriver rubricen, tar fram utkast till kandidatsvaren och skickar ut det verktygsanrop som en bedömare sedan betygsätter innan det körs. Leverantörens listpris förs vidare med 0 % påslag, så en prissänkning från leverantören på den genererande sidan slår igenom hos oss samma dag, och om du hellre vill slippa satsa din tröskel på en enda domare komponerar routing-DSL:en flera modeller till ett enda anrop och modellfusion rapporterar deras samstämmighet som ett fält du kan poängsätta. Automatisk failover håller den sidan vid liv när en enskild leverantör försämras, vilket spelar större roll i en loop som betygsätter allt den ser än i en som svarar en användare då och då.

Slutsats

Microsoft-Decision-1 har varit allmänt tillgänglig på Microsoft Foundry sedan den 8 oktober 2026: värdbaserad, endast text, 32 768 tokens, en Qwen3.5-9B-bas eftertränad av Microsoft, inga distribuerade vikter, och ett benchmarkavsnitt som dokumenterar sin metodik utan att ange en siffra – inte ens någon latens, med batchinferens avstängd. Intern-Decision-2B är en Apache-2.0-checkpoint med 2 213 241 664 parametrar från den 26 september 2026 som är snabbast av sina tre syskon med 33,28 ms på ett 4090 och den sämst kalibrerade med ett ECE på 0,100, med en anpassad temperatur på 2,100509348278 som inte kan ändra en etikett men kommer att ändra varje konfidensvärde du trösklar på. Om du vill ha den mellersta storleken är den ärliga motiveringen för den tunn: betala de extra 2,7 GB för 4B:s noggrannhet eller acceptera 0,8B:s fotavtryck, och i båda fallen bör du anpassa din egen kalibrering innan ett tröskelvärde kommer i närheten av produktion.

Det vi däremot tillhandahåller är den generativa halvan av loopen som dessa bedömare finns för att betjäna: de över 200 modellerna bakom en OpenAI-kompatibel nyckel som skriver bedömningsmallen, utformar kandidatsvaren och skickar verktygsanropet som en bedömare sedan betygsätter innan det körs.