Intern-Decision-0.8B ist ohne Ankündigung erschienen: Was InternLM still auf Hugging Face veröffentlicht hat

Der GitHub-Link auf der Modellkarte liefert 404. Der Demo-Space liefert 401. Es gibt keine Sammlung, keinen Blogbeitrag, keinen technischen Bericht und nirgendwo ein Suchergebnis für die Zeichenfolge „Intern-Decision“, das keine Stellenanzeige für ein Praktikum ist — und doch sitzt Intern-Decision-0.8B gerade jetzt auf Hugging Face als vollständiger, herunterladbarer Apache-2.0-Checkpoint, feinabgestimmt auf Basis von Qwen3.5-0.8B, hochgeladen in den frühen Morgenstunden des 26. September 2026 zusammen mit zwei größeren Geschwistermodellen, die in denselben drei Minuten erschienen: Intern-Decision-2B und Intern-Decision-4B. InternLM hat schon früher auf diese Weise veröffentlicht, und deshalb ist alles Folgende aus dem Repository selbst zusammengestellt und nicht aus einem Launch-Post. Der Unterschied ist hier wichtiger als sonst: Ein Repo sagt dir, was existiert, und nur der Anbieter kann dir sagen, wofür es gedacht ist.

Was das Repository tatsächlich sagt, ist im Detail ungewöhnlich genug, um die Lektüre wert zu sein. Dies sind keine Chat-Modelle und keine kleinen Sprachmodelle im üblichen Sinne. Intern-Decision-0.8B nimmt ein Stück Zustand, ein Schema benannter Fragen, die man im Voraus schreibt, und optional bis zu acht Bilder und gibt in einem einzigen Forward Pass eine Antwortverteilung für jede Frage zurück. Es ruft niemals generate() auf. Es sampelt niemals. Es gibt keine Textausgabe zum Parsen, kein JSON zum Reparieren, keine Wiederholungsschleife um eine geschweifte Klammer, die nie geschlossen wurde. Die Enge ist die gesamte Architektur, und sie stellt dieses Modell in dieselbe kleine Kategorie wie TypeSafe's Jev 1.13 und Convai's Laya – eine Kategorie, gegen die InternLM offensichtlich absichtlich gebenchmarkt hat, denn Jevbench ist TypeSafe's eigener Benchmark und er ist die erste Spalte der Tabelle.

Hier ist, was sich aus dem Checkpoint wissen lässt, was nur vom Checkpoint behauptet wird und was derzeit niemand außerhalb von InternLM überhaupt sagen kann.

Was ist eigentlich im Repository?

Die Modellkarte ist kurz und offen, was die Abstammung angeht. Intern-Decision-0.8B wird als „ein multimodales strukturiertes Entscheidungsmodell beschrieben, das aus Qwen3.5-0.8B feinabgestimmt wurde“ – die Qwen-Basis, veröffentlicht am 28. Februar 2026 –, und das Repository enthält eine zweite Lizenzdatei, LICENSE-QWEN, neben den Apache-2.0-Bedingungen, was ein abgeleitetes Modell tun sollte und für sich genommen ein kleines Ehrlichkeitssignal ist. Der Index von Hugging Face meldet 852.985.920 Parameter über drei Shards: einen 1,50 GB großen Sprach-Shard, einen 176 MB großen Vision-Shard und einen 25 MB großen Projektor. Der gesamte Repository-Speicher beträgt etwa 1,73 GB einschließlich Tokenizer-Dateien, was das Ganze bequem auf eine einzelne Consumer-GPU oder einen gut ausgestatteten Laptop bringt.

Die Konfiguration offenbart eine Architektur, die Qwen über die 3.5-Generation hinweg ausliefert, statt eines maßgeschneiderten Entscheidungsnetzwerks. Es ist ein Qwen3_5ForConditionalGeneration mit 24 Schichten, die in einem sich wiederholenden Muster von drei Linear-Attention-Schichten zu einer Full-Attention-Schicht angeordnet sind, einer Hidden-Size von 1.024, 8 Attention-Heads gegenüber 2 Key-Value-Heads, einer Head-Dimension von 256 und einem maximalen Position-Embedding von 262.144 Tokens. Eine einzelne Multi-Token-Prediction-Schicht wird beibehalten. Der Vision-Pfad ist echt: Der Text der Modellkarte beschreibt Bildverarbeitung, der Prozessor nimmt Bilder entgegen, und der Checkpoint liefert einen Vision-Tower und einen Projektor mit, um ihn zu bedienen — das Multimodal-Tag am Repo ist also durch Gewichte belegt, nicht nur durch Tags.

Das Familienbild ist bemerkenswert, weil es bestimmt, wie alles andere zu lesen ist. InternLM hat drei Größen in 40 Sekunden hochgeladen: 0,8B, dann 2B, dann 4B. Die Parameterzahlen sind 852.985.920, 2.213.241.664 und 4.539.265.536. Die Modellkarte des 4B-Modells enthält einen zusätzlichen Abschnitt – einen Kalibrierungspiloten mit 96 Fällen bekannter Verteilung samt Vorher-Nachher-Werten –, den die 0,8B-Karte nicht hat. Diese Asymmetrie ist kein Hinweis auf einen Defekt des kleinen Modells; sie ist ein Hinweis darauf, dass die Dokumentation des kleinen Modells mit einem kürzeren Budget geschrieben wurde, und genau so sieht eine stille Veröffentlichung aus.

Wie der Inferenzpfad tatsächlich funktioniert

Die mitgelieferte inference.py ist die aussagekräftigste Datei im Repository, weil sie eher einen Vertrag als einen Prompt dokumentiert. Die Abfolge sieht so aus:

• Sie übergeben eine Anfrage mit state (dem zu bewertenden Objekt), questions (einem Schema) und optional images.

• Die Optionen jeder Frage werden auf Einzel-Token-Symbole abgebildet – A bis Z, dann Kleinbuchstaben, dann Ziffern, bis zu 62 Optionen pro Frage.

• Der System-Prompt, der Zustand, das Schema und ein vollständiges JSON-Gerüst des Assistenten werden mit einem <decision>-Platzhalter pro Feld gerendert.

• Es wird ein kausaler Forward-Pass ausgeführt. Die Logits werden an der Position unmittelbar vor jedem Platzhalter ausgelesen.

• Eine Softmax wird nur über die zulässigen Kandidatensymbole dieses Felds gebildet, die Kalibrierung des Checkpoints wird angewendet, und die Symbole werden zurück auf Ihre ursprünglichen Optionswerte abgebildet.

Die Engine bietet drei Fragetypen. choice nimmt ein geordnetes Objekt, das Optionswerte auf Beschreibungen abbildet. score nimmt eine Liste – die zu den Stringwerten „0", „1", „2" und so weiter wird – oder ein geordnetes Objekt mit endlichen numerischen String-Schlüsseln, wodurch das Modell einen wahrscheinlichkeitsgewichteten Erwartungswert zurückgeben kann und nicht nur eine Kategorie. noul ist eine binäre Entscheidung ohne vorheriges Ja. Die Antwort liefert pro Feld die kalibrierte Wahrscheinlichkeitsverteilung, eine Konfidenz gleich der maximalen Kandidatenwahrscheinlichkeit, die argmax-Entscheidung mit lexikalischem Tie-Breaking sowie bei score-Fragen den erwarteten numerischen Wert und eine Legende. Die Grenzen sind explizit: ein bis sechzehn Fragen pro Anfrage, bis zu 62 Optionen jeweils, eine standardmäßige Eingabeobergrenze von 8.192 Tokens, die abgelehnt statt abgeschnitten wird, und maximal acht Bilder, deren Tokens auf diese Obergrenze angerechnet werden.

Zwei Details in dieser Liste verdienen Aufmerksamkeit, weil sie bestimmen, ob man der Ausgabe vertrauen kann. Das erste ist, dass keine Gold-Antworten in den Prompt eingefügt werden – das Modell bewertet Kandidaten, für die ihm die Antwort nicht gezeigt wurde. Das zweite ist, dass usage.output_tokens keine Text-Token-Anzahl ist; es zählt bewertete Felder. Wer dies in eine bestehende Token-Budget-Berechnung einbindet, wird davon überrascht sein, und die Karte sagt das, statt es die Leser selbst herausfinden zu lassen.

Die Benchmark-Tabelle und wie viel man davon glauben sollte

Vorsicht, Leser, bei diesem Abschnitt: Jede Zahl unten wurde vom Anbieter gemeldet und nicht reproduziert. InternLM hat die Benchmarks ausgewählt, die Vergleichsmodelle ausgewählt, die Evaluierungen durchgeführt und die Tabelle veröffentlicht. Es gibt keinen unabhängigen Lauf von Intern-Decision-0.8B auf irgendeinem öffentlichen Leaderboard, und eine Suche bei Artificial Analysis liefert für das Modell überhaupt nichts. Das macht die Tabelle nicht falsch. Es macht sie ungeprüft, und es bedeutet, dass die Spalten am nützlichsten sind, um eher die Form des Ergebnisses als sein Niveau abzulesen.

• Jevbench, drei Splits — Intern-Decision-0.8B erzielt 97,92 auf Easy, 80,56 auf Original und 52,25 auf Hard. Jev von TypeSafe liegt bei 100,00, 98,61 und 72,07 auf denselben Splits.

• Typisierte Entscheidung — das 0,8B erzielt 77,35 gegenüber Jevs 73,35. Dies ist die einzige Spalte, in der das kleinste Modell im Feld das Modell schlägt, nach dem der Benchmark benannt ist.

• ToolACE — 94.52 für das 0.8B gegenüber 91.29 für Jev. ToolACE ist ein Function-Calling-Benchmark, und ein Decision Head, der Jev bei der Tool-Auswahl übertrifft, ist die substanziellste Behauptung in der Tabelle.

• AG News — 88,61 gegenüber Jevs 89,57. Effektiv auf Augenhöhe mit der Spitze dieser Kategorie bei der Vier-Klassen-Themenklassifikation.

• WildJailBreak — 64,48 gegenüber Jevs 96,29. Das ist der Zusammenbruch. Wohl die Spalte, die für ein Modell, das man auf nicht vertrauenswürdige Eingaben ansetzen würde, am wichtigsten ist, und diejenige, bei der das 0,8B am weitesten von der Referenz entfernt ist.

• Durchschnitt — 79,38 für das 0,8B, 84,68 für das eigene 2B-Geschwistermodell, 90,02 für das 4B. Die Modellfamilie steigt steil an, was genau dem entspricht, was man erwarten würde, und ist selbst ein mildes Argument dafür, dass die Tabelle nicht nachträglich konstruiert wurde, um dem Flaggschiff zu schmeicheln.

• Kalibrierung — Brier 0,530 und erwarteter Kalibrierungsfehler 0,066 für das 0.8B. Jev meldet 0,358 und 0,095. Liest man diese beiden zusammen, ergibt sich ein klareres Bild, als es eine der beiden Zahlen für sich allein liefert: Das 0.8B ist im ECE-Sinne besser kalibriert als Jev — seine angegebenen Konfidenzwerte folgen seiner Genauigkeit enger — während es insgesamt deutlich weniger genau ist. Das ist ein plausibles Profil für ein kleines Modell mit einer bewusst angepassten Temperatur, und es ist keine schmeichelhafte Kombination, die man versehentlich veröffentlicht.

Das Vergleichsset hat eine auffällige Eigenschaft: Es wird von Entscheidungsmodellen dominiert. Jev, Laya, SemIf, Kev und JevK5 sind alle vertreten; der Benchmark der Tabelle selbst stammt von TypeSafe. InternLM entschied sich, auf dem Terrain eines Wettbewerbers gemessen zu werden, mit der Testumgebung eines Wettbewerbers, und veröffentlichte dann die Spalten, in denen sein kleinstes Modell verliert. Es ist die Art von Entscheidung, die ein Team trifft, wenn es keine Marketingkampagne rund um die Veröffentlichung plant – was zu allem anderen darüber passt, wie dies ausgeliefert wurde.

Die Kalibrierungstemperatur ist die interessanteste Zahl

Intern-Decision-0.8B passt eine Standardtemperatur von 2,747760550703 an, indem die NLL über 1.728 designierte Kalibrierungsfälle mit 1.693 separaten Validierungsfällen minimiert wird. Die Modellkarte gibt ausdrücklich an, dass die Test-Suite-Labels nicht verwendet wurden, um sie auszuwählen. Die angewandte Transformation ist p = softmax(candidate_logits.float()), gefolgt von calibrated_p = softmax(log(p) / T).

Das ist eine Kalibrierung der Kandidatenwahrscheinlichkeit, keine Sampling-Temperatur, und der Unterschied ist keine Haarspalterei. Da die Transformation nach dem Softmax angewendet wird und die Reihenfolge beibehält, kann sie die Argmax-Entscheidung überhaupt nicht ändern. Sie verschiebt die Konfidenz, die noul-Ja-Wahrscheinlichkeit und den Erwartungswert einer Score-Frage – und lässt die Hauptentscheidung unverändert. Wenn Ihr Workflow das Label liest, ist die Temperatur ein No-Op. Wenn Ihr Workflow die Wahrscheinlichkeit liest – sie mit Schwellenwerten belegt, nach ihr sortiert oder sie in eine nachgelagerte Erwartungswertberechnung einspeist –, ist die Temperatur der Unterschied zwischen einer Zahl, die etwas bedeutet, und einer Zahl, die nichts bedeutet. Die Übergabe von temperature=1 liefert die unkalibrierte Verteilung zurück, was ein nützlicher Notausgang für alle ist, die ihre eigene Kalibrierung darauf anwenden möchten.

Die Temperatur wird pro Checkpoint angepasst und nicht gemeinsam verwendet. Das 4B-Modell verwendet einen anderen Wert, 1.99241824, und die Modellkarte weist Sie an, das Inferenzmodul zu verwenden, das mit der von Ihnen heruntergeladenen Größe ausgeliefert wird, damit dessen Standardkalibrierung dazu passt. Wer einen Inferenz-Wrapper von einem Geschwistermodell auf ein anderes kopiert, wendet stillschweigend die falsche Temperatur an.

Vierunddreißig Millisekunden, und ein Ergebnis, das nicht möglich sein sollte

InternLM maß die Ende-zu-Ende-Latenz pro Abfrage auf einer einzelnen RTX 4090 unter Verwendung des lokalen Hugging-Face-Pfads — eine echte Messung, aber auch die langsamste mögliche Serving-Konfiguration, da ein Produktionseinsatz eine kompilierte oder Batch-fähige Runtime verwenden würde. Jev wird mit 109,70 ms Mittelwert und 106,30 ms Median bei einem p95 von 146,70 ms angegeben. Intern-Decision-0.8B kommt auf 33,98 / 33,44 / 37,50 ms.

Die Zahl, bei der es sich lohnt, innezuhalten, ist das 2B-Geschwistermodell: 33,28 ms Mittelwert, 33,15 ms Median. Der 2B ist schneller als der 0.8B, und zwar mit einem Vorsprung, der klein genug ist, um Rauschen zu sein, aber nicht in die Richtung geht, die die Parameterzahlen nahelegen. Das ist kein Fehler in der Tabelle und es geht eigentlich nicht um die Modelle. Ein Entscheidungsmodell führt genau einen Vorwärtsdurchlauf über einen Prompt aus, dessen Länge durch den Zustand, das Schema und die Optionsbeschreibungen festgelegt wird – nicht durch irgendetwas, das das Modell schreibt, denn es schreibt nichts. Bei Prompts in diesem Regime dominiert die Prompt-Verarbeitung, und die Parameteranzahl ist ein Kostenfaktor zweiter Ordnung. Die praktische Konsequenz ist, dass der übliche Grund, zum kleinsten Checkpoint zu greifen – man zahlt pro Token –, hier nicht gilt. Der eigentliche Grund, den 0.8B statt des 2B zu wählen, ist der Speicherbedarf und die Tatsache, dass sein gesamtes Repository in 1,73 GB passt, nicht der Durchsatz.

Was noch nicht festgestellt werden kann

Das ist der Teil, den ein Launch-Post beantwortet hätte und ein Repository nicht.

Es gibt kein angegebenes Veröffentlichungsdatum, keine Ankündigung und nichts auf den öffentlichen Kanälen von InternLM, das die Modellfamilie beschreibt. Die auf der Modellkarte angegebene GitHub-URL lässt sich nicht auflösen. Der in der Karte referenzierte Demo-Space ist nicht öffentlich einsehbar. Es gibt keine Sammlung, die die drei Checkpoints zusammenführt, was bedeutet, dass die einzige Möglichkeit, die 2B- oder die 4B-Version zu finden, darin besteht, die Modellliste der Organisation anzusehen. Es gibt kein Paper, daher sind die Trainingsdaten, das Tuning-Rezept, die Anzahl der Trainingsschritte und das, was „Decision Tuning“ in den Gewichten verändert hat, allesamt nicht angegeben. Es gibt keine unabhängige Evaluierung, keine Latenz-Reproduktion durch Dritte und noch keine Belege dafür, dass jemand außerhalb von InternLM den Checkpoint ausgeführt hat.

Außerdem wirft die Modellkarte zwei Fragen auf, ohne sie zu beantworten. Die erste ist, was die WildJailBreak-Lücke in der Praxis bedeutet: Ein Defizit bei der Ablehnungsrobustheit dieser Größe ist eine Eigenschaft des Fine-Tunings, und ob es das Basismodell, das Decision-Tuning-Ziel oder die geringe Parameteranzahl widerspiegelt, verrät das Repository nicht. Die zweite ist, was an der Eingabeobergrenze passiert. Anfragen mit mehr als 8.192 Token werden abgelehnt statt gekürzt, was für ein Bewertungsmodell das richtige Verhalten ist, aber es bedeutet, dass das praktische Kontextfenster nicht die 262.144 Token beträgt, die die Konfiguration angibt – es ist so viel, wie in 8.192 Token für Zustand, Schema, Optionen und Bild-Patches passt. Bei langen Dokumenten mit reichhaltigen Schemas wird diese Obergrenze früher erreicht, als das Architekturdiagramm vermuten lässt.

Wo das einzuordnen ist und wie man es ausprobieren kann, ohne darauf zu wetten

Die ehrliche Einordnung ist, dass Intern-Decision-0.8B ein veröffentlichter Checkpoint mit ungeprüften Behauptungen und ohne unterstützende Dokumentation ist. Diese Kombination ist kein Grund, ihn zu ignorieren – eine Apache-2.0-Gewichtsveröffentlichung, die Sie herunterladen und an einem Nachmittag messen können, ist eine bessere Situation als eine API mit Warteliste –, aber sie bedeutet, dass die Last der Validierung bei Ihnen liegt. Die Engine lädt aus einem lokalen Verzeichnis, läuft auf einer GPU der 4090-Klasse oder kleiner, und die Modellkarte liefert eine ausgearbeitete Anfrage, die Sie einfügen können. Ein Tag Evaluation anhand Ihrer eigenen gelabelten Fälle wird Ihnen mehr über die WildJailBreak-Spalte sagen, als die Anbietertabelle kann.

Wenn die Entscheidungsebene der Teil ist, den Sie bewerten, ist ein gehostetes System das nützliche Vergleichsziel. TypeSafe's Jev 1.13 ist das Modell, gegen das InternLM gebenchmarkt hat, und es ist heute über einen einzigen OpenAI-kompatiblen Endpunkt zu 0,042 $ pro Million Eingabe-Tokens aufrufbar, wobei die Ausgabe mit null abgerechnet wird — zum selben Preis, den der Anbieter veröffentlicht, weil OrcaRouter den Listenpreis des Anbieters ohne Aufschlag durchreicht, anstatt eine Marge aufzuschlagen. Einen selbst gehosteten 0,8B-Entscheidungshead und eine gehostete Entscheidungs-API am selben Nachmittag auf denselben Schlüssel zu setzen, ist ein deutlich billigeres Experiment, als zwei getrennte Verträge aufzusetzen, um dieselbe Frage zu beantworten.

Was dieses Bild ändern würde, ist kein Benchmark. Es ist das Auftauchen des GitHub-Repositorys, oder dass InternLM das Tuning-Rezept veröffentlicht, oder ein erster unabhängiger Lauf des Checkpoints, der auf einem Leaderboard landet. Bis eines davon geschieht, ist die zutreffende Beschreibung von Intern-Decision-0.8B eng und wenig schmeichelhaft und fällt ganz zu seinen Gunsten aus: Die Gewichte sind echt, der Inferenz-Vertrag ist besser dokumentiert, als es die meisten gestarteten Modelle hinbekommen, und das Marketing hat noch nicht begonnen.