Microsoft-Decision-1 vs Intern-Decision-2B: negen milliseconden sneller en meetbaar slechter gekalibreerd

Er zit een getal in InternLM's eigen tabel dat er niet zou mogen staan, en dat is de reden waarom deze vergelijking meer waard is dan het specificatieblad. Intern-Decision-2B — 2.213.241.664 parameters, fijnafgestemd op Qwen/Qwen3.5-2B, geüpload naar Hugging Face op 26 september 2026 om 05:36:19 UTC zonder enige aankondiging — laat een 33,28 ms gemiddelde latentie per query zien op één enkele RTX 4090, wat marginaal sneller is dan zijn eigen broertje met 852 miljoen parameters op 33,98 ms. Het laat ook de slechtste kalibratie in zijn familie zien: een verwachte kalibratiefout van 0,100 tegenover 0,066 van de 0.8B, met een gefitte temperatuur van 2,100509348278 tegenover 2,747760550703 van de 0.8B. Ondertussen publiceert Microsoft-Decision-1, algemeen beschikbaar op Microsoft Foundry sinds 8 oktober 2026, helemaal geen latentiecijfer en ook geen kalibratiefout — alleen een methodologieparagraaf die beschrijft hoe beide werden gemeten. De vraag die deze confrontatie dus eigenlijk stelt, is niet welke van de twee beter is. Het is wat je koopt wanneer je de middelste maat van wat dan ook koopt.

Beide modellen zijn beslissingsscorers: toestand erin, begrensde vragenset erin, gekalibreerde waarschijnlijkheden eruit, geen gegenereerde tekst en geen tokens om te parsen. Dat gedeelde contract is wat de verschillen leesbaar maakt. Microsoft-Decision-1 is een gehoste, alleen-tekst Foundry API op een Qwen3.5-9B-basis met een contextvenster van 32.768 tokens, geen gedistribueerde gewichten en geen fine-tuningroute. Intern-Decision-2B is een Apache-2.0-checkpoint met de upstream Qwen-licentie behouden als LICENSE-QWEN, ongeveer 4,46 GB aan repository, aangepaste inferentiecode, en nergens een gehost endpoint.

Waar de middelste maat eigenlijk voor dient

InternLM pushte drie checkpoints in veertig seconden: de 0,8B om 05:35:57, deze om 05:36:19, de 4B om 05:36:37. Op het eigen gemiddelde van de leverancier over zeven suites klimt de familie in de volgorde die je zou hopen — 79,38, 84,68, 90,02 — wat de enige plek is waar de 2B op een verstandige aankoop lijkt. Overal elders ziet hij eruit als het formaat dat niemand met opzet zou hebben gekozen.

Promptverwerking domineert een beslissingsaanroep, en dat is de mechanische verklaring voor de latentie-inversie, geen mysterie. Een scorer voert precies één forward pass uit over een prompt waarvan de lengte wordt bepaald door de toestand, het schema en de optiebeschrijvingen — nooit door iets wat het model schrijft, want het schrijft niets. In dat regime is het parameteraantal een tweederangs kostenpost, dus de gebruikelijke reden om naar de kleinste checkpoint te grijpen is niet van toepassing: je bespaart geen tijd, je bespaart geheugen. De hele repository van de 0.8B is ongeveer 1,73 GB tegenover 4,46 GB van dit model, en dat is de eerlijke reden om het te verkiezen. De enige echte claim van de 2B is dat hij toevallig de snelste van de snelle modellen is, met een marge die klein genoeg is om ruis te zijn.

Afgezet tegen Microsoft-Decision-1 is die bewering bijna irrelevant, omdat de twee modellen zich niet in hetzelfde latentieregime bevinden. De snelheid van een gehoste endpoint is een functie van je deploymentvorm — serverloos versus ingerichte doorvoer op dezelfde standaard-SKU — voordat het een functie van het model is, en Microsoft publiceert geen cijfer per aanroep om mee te vergelijken. Wat Microsoft wél publiceert, is een harde operationele beperking die de andere kant op werkt: batch-inferentie is uitgeschakeld. Er is geen offlinekanaal waarlangs een bulk-scoringsrun kan worden geamortiseerd, dus een Microsoft-Decision-1-pijplijn betaalt de interactieve kosten van elke beslissing, terwijl een zelfgehost checkpoint in GPU-uren betaalt, of het nu scoort of niet.

De kalibratiekolom, waar het midden verliest

Lees de drie Intern-Decision-kaarten samen en de familie gedraagt zich niet meer voorspelbaar. Nauwkeurigheid is monotoon in grootte; kalibratie is dat niet. De 2B heeft een ECE van 0,100 — de zwakste van de drie — en een gefitte temperatuur van 2,100509348278, ruim onder die van de 0.8B: 2,747760550703. De kaart instrueert je om de inferentiemodule te gebruiken die is meegeleverd met de grootte die je hebt gedownload, omdat de standaardkalibraties per checkpoint gelden; wie een wrapper van de ene variant naar de andere kopieert, past stilzwijgend de verkeerde temperatuur toe.

De transformatie zelf is het waard om te begrijpen voordat je die 0,100 als een oordeel over de gewichten beschouwt. Het is een softmax over de kandidaat-logits van het veld, gevolgd door een tweede softmax over de log van die verdeling gedeeld door de temperatuur. Omdat hij na de eerste softmax loopt en de ordening behoudt, kan hij de argmax helemaal niet veranderen. Hij verschuift het vertrouwen, de ja-kans en de verwachte waarde van een scorevraag, en laat het label onveranderd. Als je pipeline labels leest, is de temperatuur een no-op en is de ECE een curiositeit. Als je pipeline waarschijnlijkheden leest — er drempelwaarden op toepast, ze op basis daarvan rangschikt, ze invoert in een berekening van de verwachte waarde — dan is een ECE van 0,100 het verschil tussen een drempel die betekent wat je hebt geschreven en een die dat niet doet. De juiste reactie is om je eigen temperatuur te fitten op je eigen gelabelde gevallen, niet om te concluderen dat de gewichten slecht zijn.

Microsoft-Decision-1 vraagt om precies hetzelfde werk, met minder om mee te beginnen. Het tabblad Benchmarks vermeldt dat nauwkeurigheid, kalibratiefout, veiligheidsrecall, fout-positieve percentages en fairnessconsistentie zijn gemeten op openbare en community-beslissingsbenchmarks plus achtergehouden interne testsets, dat de optievolgorde werd gevarieerd, dat gepaarde statistische toetsen werden toegepast, en dat het model "presteert op hetzelfde niveau als toonaangevende beslissingsmodellen en beter dan andere open beslissingsmodellen die met dezelfde methodologie zijn geëvalueerd." Geen ECE. Geen Brier. Geen temperatuur. Geen nauwkeurigheidstabel. Het model waarvan de hele waardepropositie een betrouwbare waarschijnlijkheid is, is het model in deze vergelijking zonder enig gepubliceerd kalibratiegetal.

Contractgrenzen: vier dingen die het gehoste model niet zal doen

De twee modellen nemen wat op hetzelfde besluit lijkt, en de verschillen zitten aan de randen ervan.

• Modaliteit — Microsoft-Decision-1 is expliciet alleen tekst en accepteert geen afbeeldingen, audio of video. Intern-Decision-2B accepteert tot acht afbeeldingen naast de state, waardoor het een kandidaat is voor screenshot-triage en layoutcontroles die de gehoste API bij geen enkele nauwkeurigheid kan leveren.

• Invoerplafond en faalmodus — Microsoft-Decision-1 voert één enkele aanroep uit over maximaal 32.768 tokens. Intern-Decision-2B declareert DecisionEngine(max_length=8192) en weigert te grote invoer in plaats van die af te kappen, wat correct gedrag is voor een scorer en ook een harde grens, omdat de toestand, het schema en het skelet allemaal in één doorgang aanwezig moeten zijn; geen enkele chunkingstrategie behoudt het contract.

• Vorm van de vraag — InternLM documenteert één tot zestien vragen per aanroep met tot 62 opties per stuk, verdeeld over drie veldtypen (choice, score, noul), waarbij nouleen binaire ja/nee is die een waarschijnlijkheid retourneert en scoreeen waarschijnlijkheidsgewogen verwachte waarde retourneert op een schaal die je zelf benoemt. Microsoft documenteert de formaten — ja/nee, meerkeuze, beoordeling, classificatie, rubric — plus een expliciet ondersteunde onthoudingsoptie zoals "cannot tell" wanneer het bewijs onvoldoende is, wat de enkele nuttigste regel op de pagina is voor iedereen die escalatielogica schrijft.

• Prijs — de modelpagina van Microsoft-Decision-1 vermeldt geen tarief; prijsinformatie linkt door naar het prijsoverzicht van Microsoft, dus de kosten per beslissing zijn iets dat je van Azure of van een factuur afleest, waarbij 0% ervan toe te schrijven is aan outputtokens, omdat die er niet zijn. Intern-Decision-2B kost niets per aanroep en alles aan GPU-tijd, en het heeft geen gehoste provider. De opslag ervan is ongeveer 4,46 GB, verdeeld over een taal-shard van 3,76 GB, een visietoren van 612,5 MB en een projector van 50,3 MB.

Wat is bevestigd, en wat is alleen de leverancier die praat?

Die twee categorieën gescheiden houden is de hele discipline bij deze familie. Bevestigd door een bestandslijst of een HTTP-respons: het parameteraantal, de shardmap, het licentiepaar, het basismodel, de onderliggende architectuur — een Qwen3_5ForConditionalGeneration met 24 lagen, een verborgen grootte van 2.048, 8 query-heads tegenover 2 key-value-heads, een head-dimensie van 256, een terugkerend patroon van drie linear-attention-lagen op één full-attention-laag, één behouden multi-token-prediction-laag en een embedding-plafond van 262.144 posities dat het engine-plafond van 8.192 tokens praktisch irrelevant maakt.

Door de leverancier gerapporteerd en niet gereproduceerd: elk nauwkeurigheidscijfer, elk latentiecijfer en de temperatuur. Er is geen paper, geen arXiv-vermelding, geen lanceringsbericht, geen changelog en geen onafhankelijke evaluatie. De demo-Space antwoordt met 401, wat betekent dat die niet openbaar is in plaats van defect. De GitHub-repository die na het model verscheen — drie commits, trainingscode, twee inferentie-backends, een evaluatiebundel met 10.751 testrijen, een kalibratiebenchmark met 96 gevallen en een reproductiegids — bevat meer documentatie dan de meeste stille releases krijgen, en er worden geen gewichten, geen trainingsdata en geen codelicentie meegeleverd. Microsoft bevindt zich in een andere maar aangrenzende positie: zijn methodologie is echt en zijn claim is kwalitatief, en geen van beide bedrijven is momenteel in staat om zijn centrale cijfer door iemand anders dan jou te laten controleren.

Waar OrcaRouter zich bevindt in een pipeline zoals deze

Geen van beide modellen staat in onze catalogus, en niets hier mag worden gelezen als een beschikbaarheidsclaim. Een model dat waarschijnlijkheden retourneert in plaats van tekst, is niet iets waar je chatcompletions naartoe routeert, en dat geldt voor beide. Wat wij wel aanbieden is de generatieve helft van de lus waarvoor die scorers bestaan: de meer dan 200 modellen achter één OpenAI-compatibele sleutel die het beoordelingskader schrijven, de kandidaatantwoorden opstellen en de toolaanroep uitzenden die een scorer vervolgens beoordeelt voordat die wordt uitgevoerd. De lijstprijs van de provider wordt doorgegeven tegen 0% opslag, dus een prijsverlaging van een leverancier aan de genererende kant is dezelfde dag ook bij ons live, en als je je drempelwaarde liever niet op één beoordelaar baseert, voegt de routing-DSL meerdere modellen samen tot één enkele aanroep en rapporteert modelfusie hun overeenstemming als een veld dat je kunt scoren. Automatische failover houdt die kant draaiende wanneer één enkele provider degradeert, wat meer uitmaakt in een lus die alles wat hij ziet scoort dan in een die af en toe een gebruiker antwoordt.

Kortom

Microsoft-Decision-1 is sinds 8 oktober 2026 algemeen beschikbaar op Microsoft Foundry: gehost, alleen tekst, 32.768 tokens, een Qwen3.5-9B-basis die door Microsoft is nagetraind, geen gedistribueerde gewichten, en een benchmarksectie die zijn methodologie documenteert zonder een getal te noemen — inclusief geen latentie, met batch-inferentie uitgeschakeld. Intern-Decision-2B is een Apache-2.0-checkpoint met 2.213.241.664 parameters van 26 september 2026 dat het snelste van zijn drie broers en zussen is met 33,28 ms op een 4090 en het slechtst gekalibreerd met een ECE van 0,100, met een gefitte temperatuur van 2,100509348278 die geen label kan veranderen, maar wel elke confidence waarop je een drempel toepast, verandert. Als je het middelste formaat wilt, is het eerlijke argument ervoor mager: betaal de extra 2,7 GB voor de nauwkeurigheid van de 4B of accepteer de voetafdruk van de 0,8B, en voer in beide gevallen je eigen kalibratie uit voordat een drempel ook maar in de buurt van productie komt.

Wat wij wél leveren is de generatieve helft van de lus die die scorers dienen: de meer dan 200 modellen achter één OpenAI-compatibele sleutel die de rubric schrijven, de kandidaat-antwoorden opstellen en de tool call uitzenden die een scorer vervolgens beoordeelt voordat deze wordt uitgevoerd.