Intern-Decision-0.8B anlände utan tillkännagivande: Vad InternLM tyst lade upp på Hugging Face

GitHub-länken på modellkortet returnerar 404. Demo-Spacen returnerar 401. Det finns ingen samling, inget blogginlägg, ingen teknisk rapport och ingen sökträff någonstans för strängen "Intern-Decision" som inte är en jobbannons för en praktikplats — och ändå ligger Intern-Decision-0.8B på Hugging Face just nu som en komplett, nedladdningsbar Apache-2.0-checkpoint, finjusterad från Qwen3.5-0.8B, uppladdad i småtimmarna den 26 september 2026 tillsammans med två större syskon som dök upp inom samma tre minuter: Intern-Decision-2B och Intern-Decision-4B. InternLM har släppt på det här sättet tidigare, och det är därför allt nedan är sammanställt från själva repot i stället för från ett lanseringsinlägg. Distinktionen spelar större roll här än vanligt: ett repo talar om vad som finns, och bara leverantören kan tala om vad det är till för.

Vad repot faktiskt säger, i detalj, är tillräckligt ovanligt för att vara värt att läsa. Detta är inte chattmodeller och inte små språkmodeller i vanlig mening. Intern-Decision-0.8B tar en bit tillstånd, ett schema över namngivna frågor som du skriver i förväg, och valfritt upp till åtta bilder, och returnerar en svarsfördelning för varje fråga i en enda framåtpassning. Den anropar aldrig generate(). Den samplar aldrig. Det finns ingen textutdata att parsa, ingen JSON att reparera, ingen återförsöksloop kring en klammerparentes som aldrig stängdes. Snävheten är hela arkitekturen, och det placerar denna modell i samma lilla kategori som TypeSafe's Jev 1.13 och Convai's Laya — en kategori som InternLM uppenbarligen benchmarkade mot med avsikt, eftersom Jevbench är TypeSafe's egen benchmark och den är tabellens första kolumn.

Här är vad som går att veta utifrån checkpointen, vad som bara påstås av checkpointen, och vad ingen utanför InternLM för närvarande kan säga överhuvudtaget.

Vad finns egentligen i arkivet?

Modellkortet är kort och uppriktigt om härstamningen. Intern-Decision-0.8B beskrivs som ”en multimodal strukturerad beslutsmodell finjusterad från Qwen3.5-0.8B” – Qwen-basen som släpptes den 28 februari 2026 – och repositoriet innehåller en andra licensfil, LICENSE-QWEN, vid sidan av Apache-2.0-villkoren, vilket är vad en härledd modell förväntas göra och i sig är en liten ärlighetssignal. Hugging Faces index rapporterar 852 985 920 parametrar över tre shardar: en shard för språk på 1,50 GB, en shard för vision på 176 MB och en projektor på 25 MB. Den totala lagringen i repositoriet är cirka 1,73 GB inklusive tokenizerfiler, vilket gör att hela paketet med god marginal får plats på en enda konsument-GPU eller en välutrustad bärbar dator.

Konfigurationen avslöjar en arkitektur som Qwen har levererat genom 3.5-generationen snarare än ett skräddarsytt beslutsnätverk. Det är en Qwen3_5ForConditionalGeneration med 24 lager ordnade i ett upprepande mönster av tre linjära uppmärksamhetslager till ett fullt uppmärksamhetslager, 1 024 dold storlek, 8 uppmärksamhetshuvuden mot 2 nyckel-värde-huvuden, en huvuddimension på 256 och en maximal positionsinbäddning på 262 144 token. Ett enda multi-token-prediction-lager behålls. Vision-vägen är verklig: kortets text beskriver bildhantering, processorn tar emot bilder och checkpointen levererar ett vision-torn och en projektor för att betjäna den — så den multimodala taggen på repot backas upp av vikter, inte bara av taggar.

Familjebilden är värd att notera eftersom den formar hur man ska läsa allt annat. InternLM laddade upp tre storlekar på 40 sekunder: 0,8B, sedan 2B, sedan 4B. Parameterantalen är 852 985 920, 2 213 241 664 och 4 539 265 536. 4B-modellens kort har ett extra avsnitt – en kalibreringspilot med 96 fall och känd fördelning med poäng före och efter – som 0,8B-kortet inte har. Den asymmetrin är inte bevis för en defekt i den lilla modellen; den är bevis för att den lilla modellens dokumentation skrevs med en kortare budget, vilket är den typ av sak som en tyst lansering ser ut som.

Hur inferensvägen faktiskt fungerar

Den medföljande inference.py är den mest informativa filen i repot, eftersom den dokumenterar ett kontrakt snarare än en prompt. Sekvensen ser ut så här:

• Du tillhandahåller en begäran med tillstånd (det som bedöms), frågor (ett schema) och eventuellt bilder.

• Varje frågas svarsalternativ mappas till symboler för enskilda tokens — A till Z, sedan gemener, sedan siffror, upp till 62 alternativ per fråga.

• Systemprompten, tillståndet, schemat och ett komplett JSON-skelett för assistenten renderas med en <decision>-platshållare per fält.

• Ett kausalt framåtpass körs. Logits avläses vid positionen omedelbart före varje platshållare.

• En softmax beräknas endast över det fältets tillåtna kandidatsymboler, checkpointens kalibrering tillämpas och symbolerna mappas tillbaka till dina ursprungliga alternativvärden.

Motorn exponerar tre frågetyper. choice tar ett ordnat objekt som mappar alternativvärden till beskrivningar. score tar en lista – som blir strängvärdena "0", "1", "2" och så vidare – eller ett ordnat objekt med ändliga numeriska strängnycklar, vilket låter modellen returnera ett sannolikhetsviktat förväntat värde och inte bara en kategori. noul är ett binärt beslut där no kommer före yes. Svaret returnerar, per fält, den kalibrerade sannolikhetsfördelningen, en konfidens som är lika med den högsta kandidatsannolikheten, argmax-beslutet med lexikalisk tie-breakning, och för score-frågor det förväntade numeriska värdet och en teckenförklaring. Gränserna är explicita: en till sexton frågor per begäran, upp till 62 alternativ vardera, ett standardtak för indata på 8 192 token som avvisas i stället för att trunkeras, och högst åtta bilder vars token räknas mot detta tak.

Två detaljer i den listan förtjänar uppmärksamhet eftersom de avgör om du kan lita på resultatet. Den första är att inga facit läggs in i prompten – modellen poängsätter kandidater som den inte har fått se svaret på. Den andra är att usage.output_tokens inte är ett antal texttoken; den räknar poängsatta fält. Den som kopplar in detta i en befintlig tokenbudgetberäkning kommer att bli förvånad över det, och kortet säger det i stället för att låta det upptäckas.

Benchmark-tabellen, och hur mycket av den man bör tro på

Varning till läsaren för det här avsnittet: varje siffra nedan är leverantörsrapporterad och inte reproducerad. InternLM valde benchmarkarna, valde jämförelsemodellerna, körde utvärderingarna och publicerade tabellen. Det finns ingen oberoende körning av Intern-Decision-0.8B på någon offentlig resultattavla, och en sökning på Artificial Analysis ger inte ett enda resultat för modellen. Det gör inte tabellen falsk. Det gör den ogranskad, och det innebär att kolumnerna är mest användbara för att läsa resultatets form snarare än dess nivå.

• Jevbench, tre delningar — Intern-Decision-0.8B uppnår 97,92 på Easy, 80,56 på Original och 52,25 på Hard. TypeSafe:s Jev ligger på 100,00, 98,61 och 72,07 på samma delningar.

• Typat beslut — 0.8B får 77,35 mot Jevs 73,35. Detta är den enda kolumnen där den minsta modellen i fältet slår modellen som benchmarken är uppkallad efter.

• ToolACE — 94,52 för 0.8B mot 91,29 för Jev. ToolACE är ett benchmark för funktionsanrop, och ett beslutshuvud som överträffar Jev i verktygsval är det mest substantiella påståendet i tabellen.

• AG News – 88,61 mot Jevs 89,57. I praktiken jämnhöjd med frontlinjen inom denna kategori för fyraklassig ämnesklassificering.

• WildJailBreak — 64,48 mot Jevs 96,29. Det här är kollapsen. Det är rimligen den kolumn som spelar störst roll för en modell man skulle rikta mot opålitlig indata, och den där 0,8B ligger längst ifrån referensen.

• Medelvärde — 79,38 för 0,8B, 84,68 för dess egen 2B-syskonmodell, 90,02 för 4B. Familjen klättrar brant, vilket är precis vad man skulle förvänta sig och är i sig ett milt argument för att tabellen inte var baklängeskonstruerad för att smickra flaggskeppet.

• Kalibrering — Brier 0,530 och förväntat kalibreringsfel 0,066 för 0.8B. Jev rapporterar 0,358 och 0,095. Läser man de två tillsammans framträder en tydligare bild än vad endera siffran ger på egen hand: 0.8B är bättre kalibrerad än Jev i ECE-mening — dess angivna konfidenser följer dess träffsäkerhet närmare — samtidigt som den är betydligt mindre träffsäker totalt sett. Det är en trolig profil för en liten modell med en medvetet anpassad temperatur, och det är inte en smickrande kombination att publicera av misstag.

Jämförelseuppsättningen har en iögonfallande egenskap: den domineras av beslutsmodeller. Jev, Laya, SemIf, Kev och JevK5 förekommer alla; tabellens egen benchmark är TypeSafe:s. InternLM valde att mätas på en konkurrents hemmaplan, med en konkurrents testramverk, och publicerade sedan kolumnerna där dess minsta modell förlorar. Det är den sorts beslut ett team fattar när det inte planerar en marknadsföringskampanj kring lanseringen — vilket stämmer med allt annat kring hur detta släpptes.

Kalibreringstemperaturen är det mest intressanta talet.

Intern-Decision-0.8B anpassar en standardtemperatur på 2.747760550703, genom NLL-minimering över 1 728 utsedda kalibreringsfall med 1 693 separata valideringsfall. Kortet anger uttryckligen att testsvitens etiketter inte användes för att välja den. Den tillämpade transformen är p = softmax(candidate_logits.float()), som följs av calibrated_p = softmax(log(p) / T).

Det är kandidatsannolikhetskalibrering, inte en samplingstemperatur, och skillnaden är inte pedanteri. Eftersom transformen tillämpas efter softmax och bevarar ordningen kan den inte ändra argmax-beslutet alls. Den flyttar konfidens, nej/ja-sannolikheten och det förväntade värdet av en poängfråga — och lämnar huvudbeslutet identiskt. Om ditt arbetsflöde läser etiketten är temperaturen en no-op. Om ditt arbetsflöde läser sannolikheten — sätter tröskelvärden för den, rangordnar efter den eller matar in den i en nedströms beräkning av förväntat värde — är temperaturen skillnaden mellan ett tal som betyder något och ett tal som inte gör det. Att ange temperature=1 returnerar den okalibrerade fördelningen, vilket är en användbar nödutgång för den som vill tillämpa sin egen kalibrering ovanpå.

Temperaturen anpassas per checkpoint i stället för att delas. 4B-modellen använder ett annat värde, 1.99241824, och kortet instruerar dig att använda den inferensmodul som medföljer den storlek du laddade ner, så att dess standardkalibrering matchar. Den som kopierar en inferenswrapper från en systermodell till en annan kommer tyst att tillämpa fel temperatur.

Trettiofyra millisekunder, och ett resultat som inte borde vara möjligt

InternLM mätte end-to-end-latens per fråga på ett enda RTX 4090 via den lokala Hugging Face-vägen – en verklig mätning, men också den långsammaste möjliga serveringskonfigurationen, eftersom en produktionsdistribution skulle använda en kompilerad eller batchande runtime. Jev anges till 109,70 ms i medelvärde och 106,30 ms i median med ett p95 på 146,70 ms. Intern-Decision-0.8B ligger på 33,98 / 33,44 / 37,50 ms.

Talet som är värt att stanna vid är 2B-syskonet: 33,28 ms i medelvärde, 33,15 ms i median. 2B är snabbare än 0,8B, med en marginal som är liten nog att vara brus men inte i den riktning som parameterantalen förutsäger. Det är inte ett fel i tabellen och det handlar egentligen inte om modellerna. En beslutsmodell gör exakt en framåtpassning över en prompt vars längd bestäms av tillståndet, schemat och alternativbeskrivningarna – inte av något som modellen skriver, eftersom den inte skriver något. För prompter i den regimen dominerar promptbearbetningen och parameterantalet är en andra ordningens kostnad. Den praktiska konsekvensen är att det vanliga skälet att ta till den minsta checkpointen – du betalar per token – inte gäller här. Det verkliga skälet att välja 0,8B framför 2B är minnesavtryck och att hela dess repository får plats i 1,73 GB, inte genomströmning.

Vad som ännu inte kan fastställas

Det här är den del som ett lanseringsinlägg skulle ha svarat på och som ett repositorium inte kan.

Det finns inget angivet releasedatum, inget tillkännagivande och inget på InternLMs offentliga kanaler som beskriver familjen. GitHub-URL:en som står på modellkortet går inte att nå. Det demo-Space som hänvisas till i kortet är inte offentligt läsbart. Det finns ingen samling som sammanför de tre checkpointarna, vilket innebär att det enda sättet att hitta 2B eller 4B är att titta i organisationens modellista. Det finns ingen artikel, så träningsdata, finjusteringsreceptet, antalet träningssteg och vad "decision tuning" ändrade i vikterna anges inte. Det finns ingen oberoende utvärdering, ingen tredjepartsreplikering av latens och inga bevis ännu på att någon utanför InternLM har kört checkpointen.

Det finns också två frågor som kortet väcker utan att besvara. Den första är vad WildJailBreak-gapet innebär i praktiken: ett underskott i avvisningsrobusthet av den storleken är en egenskap hos finjusteringen, och huruvida det speglar basmodellen, beslutsjusteringsmålet eller det lilla parameterantalet är inget som repositoriet berättar för dig. Den andra är vad som händer vid indatataket. Begäranden över 8 192 token avvisas i stället för att trunkeras, vilket är rätt beteende för en poängsättningsmodell, men det innebär att det praktiska kontextfönstret inte är de 262 144 som konfigurationen utlovar — det är vad som ryms i 8 192 token av tillstånd, schema, alternativ och bildpatchar. För långa dokument med rika scheman kommer taket tidigare än arkitekturdiagrammet antyder.

Var detta befinner sig, och hur man provar det utan att satsa på det

Den ärliga formuleringen är att Intern-Decision-0.8B är en släppt checkpoint med ogranskade påståenden och ingen underbyggande dokumentation. Den kombinationen är inte ett skäl att ignorera den – en Apache-2.0-viktutgåva som du kan ladda ner och mäta på en eftermiddag är ett bättre läge än ett API med väntelista – men det betyder att valideringsbördan ligger på dig. Motorn laddas från en lokal katalog, körs på en GPU i 4090-klass eller mindre, och kortet tillhandahåller en färdig förfrågan som du kan klistra in. En dags utvärdering mot dina egna märkta fall kommer att säga dig mer om WildJailBreak-kolumnen än leverantörens tabell kan.

Om beslutsfattandelagret är den del du utvärderar, är det användbara jämförelsemålet ett hostat sådant. TypeSafe:s Jev 1.13 är modellen som InternLM benchmarkade mot, och den kan anropas idag via en enda OpenAI-kompatibel endpoint till 0,042 USD per miljon input-tokens med utdata som debiteras till noll — samma pris som leverantören publicerar, eftersom OrcaRouter för vidare leverantörens listpris utan påslag i stället för att lägga på en marginal. Att sätta ett självhostat 0,8B-beslutshuvud och ett hostat besluts-API på samma nyckel, samma eftermiddag, är ett betydligt billigare experiment än att koppla upp två separata avtal för att svara på samma fråga.

Det som skulle förändra den här bilden är inte ett benchmark. Det är att GitHub-repositoriet dyker upp, eller att InternLM publicerar finjusteringsreceptet, eller att en första oberoende körning av checkpointen landar på en leaderboard. Fram till att något av detta händer är den korrekta beskrivningen av Intern-Decision-0.8B snäv och osmickrande och helt och hållet till dess fördel: vikterna är verkliga, inferenskontraktet är dokumenterat bättre än vad de flesta lanserade modeller lyckas med, och marknadsföringen har inte börjat.