Decision 3.0 vs. Intern-Decision-4B: Zwei Teams haben dasselbe Modell feinabgestimmt und waren sich über alles andere uneinig

Stell d3-mini, das 4B-Mitglied von Decision 3.0, neben Intern-Decision-4B und das Erste, was dir auffällt, ist kein Unterschied. Beide sind Fine-Tunes desselben Basis-Checkpoints, Qwen3.5-4B. Beide sind mit 4,54 Milliarden Parametern angegeben. Beide nehmen einen Zustand, ein Schema benannter Fragen und eine Menge von Kandidatenantworten entgegen und geben eine kalibrierte Wahrscheinlichkeit pro Kandidat zurück, ohne ein Token zu generieren. Beide sind Apache-2.0. Beide wurden ohne Ankündigung veröffentlicht — InternLM lud am 26. September 2026 drei Checkpoints in vierzig Sekunden hoch, und die Decision 3.0-Familie von vLLM-SR erschien am 10. Oktober 2026 auf Hugging Face, wobei die Neuigkeit nur über den X-Account des vLLM-Projekts verbreitet wurde.

Alles danach ist ein Streitpunkt. Sie sind sich uneinig darüber, wie man eine Wahrscheinlichkeit aus dem Modell herausliest, darüber, ob Video als Eingabe zählt, darüber, wie lang eine Anfrage sein darf, und – am schärfsten – darüber, ob das Team bereit ist, die Zahl zu veröffentlichen, die besagt, dass dem eigenen Vertrauen zu trauen ist. In diesem Beitrag geht es um diese vier Streitpunkte und darum, was jeder einzelne Sie kostet, nicht darum, welches Modell „besser“ ist, denn die beiden werden nicht auf derselben Skala gemessen und lassen sich nicht gegeneinander einordnen, ohne Arbeit zu leisten, die keiner der beiden Anbieter geleistet hat.

Der Zufall, den es zuerst zu verstehen gilt

Dass zwei Labore innerhalb von zwei Wochen dasselbe 4B-Backbone wählen, ist nicht völlig überraschend – Qwen3.5-4B ist eine vernünftige Basis für ein Modell mit strukturierter Ausgabe, und beide Teams haben offensichtlich darauf zurückgegriffen, weil es klein genug ist, um kostengünstig betrieben zu werden, und stark genug, um Anweisungen zu verstehen. Überraschend ist, dass sie bei der Parameterzahl auf vier signifikante Stellen genau denselben Wert erreicht haben. Das zeigt, dass das Fine-Tuning die Architektur erhalten hat und dass keiner einen separaten Vision-Tower hinzugefügt hat, der groß genug wäre, die Gesamtzahl zu verändern. Beide integrieren ihre multimodale Fähigkeit in dieselben Gewichte.

Der interessante Teil ist das Auslesen. Beide Modelle beantworten Fragen im Prinzip auf dieselbe Weise – sie bewerten Kandidatenantworten, statt sie zu generieren – und unterscheiden sich im Mechanismus vollständig:

• Intern-Decision-4B — ordnet jede Option einem einzelnen Token-Symbol zu (A–Z, dann a–z, dann 0–9), rendert ein JSON-Skelett in den Prompt mit einem Platzhalter pro Feld und führt einen kausalen Forward-Pass aus, wobei die Logits an der Position unmittelbar vor jedem Platzhalter ausgelesen werden. Der Mechanismus ist Schritt für Schritt auf seiner Modellkarte dokumentiert, einschließlich des exakten Softmax- und Temperatur-Schritts.

• d3-mini — liefert eine benutzerdefinierte Architektur in modeling_d3.py mit einem separaten Readout-Head in einer eigenen readout.safetensors, einer decision_config.json, die noncausal_full_attention und Last-Token-Pooling deklariert, sowie einem Token-zu-Code-Mapping, das in der Konfiguration definiert statt in Prosa beschrieben ist.

Keiner der beiden Ansätze ist offensichtlich besser. Der InternLM-Weg hat den Vorteil, dass er auf einer Standard-Hugging-Face-Modellklasse mit einer dokumentierten numerischen Sequenz läuft — man kann seine Arbeit überprüfen. Der vLLM-SR-Weg hat den Vorteil, dass der Readout ein trainierter Head statt einer Projektion eines vorhandenen Token-Embeddings ist, was eine freiere Anpassung ist, und der Preis dafür ist, dass man trust_remote_code=True setzen und ihren Code ausführen muss, um überhaupt irgendetwas tun zu können.

Die Limits, die jeder Einzelne veröffentlicht

Hier beginnt sich eine echte Präferenz herauszubilden, weil eine Karte viel genauer als die andere angibt, wo sie nicht mehr funktioniert.

• Eingabeobergrenze — Intern-Decision-4B: standardmäßig 8.192 Token, und Anfragen darüber werden sofort abgelehnt, nie gekürzt, wobei die Obergrenze durch ein Konstruktorargument festgelegt wird. d3-mini: max_length ist null in der ausgelieferten Konfiguration und auf der Karte erscheint nirgends ein Token-Budget.

• Fragen pro Anfrage — Intern-Decision-4B: 1 bis 16, mit einem angegebenen Maximum von 62 Optionen in einer einzelnen Frage. d3-mini: kein angegebenes Limit; die Karte besagt nur, dass Fragen gemeinsam beantwortet werden, jede aus ihrem eigenen Forward-Pass.

• Bilder — Intern-Decision-4B: bis zu acht pro Anfrage, geordnet nach einer von Ihnen angegebenen Liste, wobei der Checkpoint-Prozessor Größenänderung und Token-Erweiterung übernimmt. d3-mini: mehrere pro Anfrage als Pfade, URLs, PIL-Bilder oder Base64-Daten-URLs, jedes mit bis zu 1,6 Megapixeln eingelesen, wobei jede Frage jedes Bild sieht.

• Video — Intern-Decision-4B: keine. d3-mini: mehrere Videos, gelesen mit 2 Frames pro Sekunde, begrenzt auf 32 Frames, die über den Clip verteilt sind, und 0,2 Megapixel pro Frame.

Die Eingabe-Obergrenze ist der Punkt, der dies für die meisten den Ausschlag geben wird. Ein Budget von 8.192 Tokens, das zwischen Status, Frageanweisungen und Kandidatenbeschreibungen aufgeteilt wird, ist eine echte Einschränkung für die Dokumentbewertungs- und Long-Context-Routing-Arbeit, für die diese Modelle verkauft werden, und InternLM verdient Anerkennung dafür, dass es das so klar sagt, statt es der Entdeckung zu überlassen. Dass vLLM-SR es unerwähnt lässt, ist das Gegenteil: keine verborgene Grenze, sondern eine unbekannte, und kein noch so gründliches Lesen des Repositorys klärt das.

Kalibrierung ist die eigentliche Spaltung.

Jedes Entscheidungsmodell macht dasselbe Versprechen: Die Zahl, die es zurückgibt, ist eine Wahrscheinlichkeit, und Schwellenwerte, die daran ausgerichtet werden, haben eine Bedeutung. Fast keines von ihnen beweist es. An diesem Punkt gehen die beiden Releases am stärksten auseinander, und die Abweichung verläuft in die entgegengesetzte Richtung zu der, die man aufgrund der Veröffentlichungsdaten vermuten würde.

Intern-Decision-4B veröffentlicht auf seiner eigenen Modellkarte einen Brier-Score von 0,347 und einen erwarteten Kalibrierungsfehler von 0,065 im Durchschnitt seiner sieben Benchmarks, eine gefittete Temperatur von 1,99241824, abgeleitet durch NLL-Minimierung auf 1.728 designierten Kalibrierungsfällen mit 1.693 separaten Validierungsfällen, eine ausdrückliche Erklärung, dass Test-Suite-Labels nicht verwendet wurden, um diese Temperatur auszuwählen, und eine Diagnose mit 96 Fällen, die zeigt, dass sich seine Kalibrierung von 0,628 Brier / 0,213 ECE vor der Temperaturskalierung auf 0,550 / 0,089 danach verschiebt. Außerdem gibt es den Standardwert an und besagt, dass die Kalibrierung pro Checkpoint gilt, sodass die Verwendung einer anderen Größe mit diesem Modul nicht übereinstimmen wird.

Decision 3.0 veröffentlicht einen Genauigkeitsindex und eine Abdeckungsbehauptung – jede einzelne von 140.178 öffentlichen Anfragen beantwortet, keine ohne Belege – und überhaupt keinen Kalibrierungswert. Kein Brier-Score, kein ECE, keine angegebene Temperatur, bei keinem der sechs Checkpoints. Temperatur in der von d3 ausgelieferten decision_config.json ist 1,0, was die Identität ist und der angepasste Wert sein kann oder auch nicht; die Datei sagt es nicht.

Lesen Sie die beiden Index-Schlagzeilen nebeneinander, und die Asymmetrie wird schlimmer. Die Karte von d3-mini meldet einen Jev Decision Index 0.3 Public-Suite-Score von 54,90, beschrieben als mit dem offiziellen Kit auf den veröffentlichten Gewichten gemessen, während die Vergleichszeilen auf demselben Board als Live-Board-Daten beschrieben werden. Intern-Decision-4B meldet einen Durchschnitt von 90,02 über seine eigenen sieben Benchmarks. Diese beiden Zahlen liegen nicht auf derselben Skala, sie verwenden nicht dieselben Aufgaben, und sie in einem Satz als Vergleich zu nennen, wäre unehrlich. Vergleichbar ist die Offenlegung: Eine Karte sagt Ihnen, wie falsch ihre Konfidenzen sind, und die andere weiß es nicht oder will es nicht sagen.

Latenz, und warum die beiden Mengen von Millisekunden auch nicht vergleichbar sind

Beide Karten veröffentlichen die Latenz pro Anfrage, und sie für bare Münze zu nehmen, wäre aus demselben Grund ein Fehler, aus dem die Genauigkeitswerte nicht vergleichbar sind.

• Intern-Decision-4B — Mittelwert 44,16 ms, Median 44,03 ms, p95 44,60 ms, gemessen auf einer einzelnen RTX 4090 über den lokalen Pfad von Hugging Face, beschrieben als arbeitslast- und hardwareabhängig.

• d3-mini — Median 17,5 ms für Text, 96,2 ms mit einem Bild, 371,5 ms mit einem zehnsekündigen Video, auf einem AMD Instinct MI325X, eine Anfrage nach der anderen.

Zwei Dinge machen diese unvergleichbar. Das erste ist die Hardware und der Software-Pfad: eine 4090 gegen eine MI325X, ein Standard-Hugging-Face-Forward-Pass gegen eine benutzerdefinierte Attention-Implementierung mit Masked-Layer-Kernels, verfügbar über flash-linear-attention. Das zweite ist die Workload: InternLMs Zahl wird als End-to-End pro Query auf einer nicht genannten Mischung beschrieben, und die von vLLM-SR ist nach Eingabemodalität aufgeschlüsselt, sodass der rein textbasierte Vergleich die einzige direkt vergleichbare Zeile ist und selbst diese sich über zwei GPU-Hersteller erstreckt.

Die Zahl, die man aus beiden Karten mitnehmen sollte, ist nicht das Ranking, sondern die Form. Ein Entscheidungsmodell wird innerhalb eines Workflows wiederholt aufgerufen – ein Support-Datensatz braucht vielleicht ein Ziel, eine Rückerstattungsprüfung, eine Eskalationsentscheidung und einen Prioritätswert, vier Fragen, und ein Stapel von 128 Datensätzen macht daraus 512 Entscheidungen. Bei diesem Volumen verschwinden 17 ms und 44 ms beide neben dem, was das nachgelagerte generative Modell kostet. Die modalitätsabhängigen Werte sind die, die man im Auge behalten sollte, denn eine Bild- oder Videoanfrage kostet nach den eigenen Zahlen von d3-mini zwischen dem Fünf- und dem Zwanzigfachen einer Textanfrage, und wenn Ihre Entscheidung anhand eines Screenshots getroffen wird, haben Sie ein Kostenprofil importiert, das die meisten Entscheidungsmodell-Deployments nicht haben.

Welchen sollte man tatsächlich nehmen?

Wenn die Entscheidung, die Sie treffen müssen, von einem Video abhängt, gibt es keinen Wettbewerb und keine Analyse ist erforderlich: Decision 3.0 liest Video, und Intern-Decision-4B tut das nicht. Das ist die ganze Antwort für alles, was Bildschirmaufzeichnungen, Kameraclips oder Frame-Sequenzen betrifft, und es ist die Fähigkeitslücke, die die Existenz der neueren Familie für sich allein rechtfertigt.

Wenn es sich bei Ihren Eingaben um Text und gelegentlich Bilder handelt, hängt die Wahl von zwei Dingen ab, und keines davon ist die Bestenliste.

Nimm Intern-Decision-4B, wenn du über Schwellenwerte nachdenken musst. Es ist das einzige der beiden, das dir sagt, ob eine 0,9 neun von zehn Malen bedeutet, es nennt seine Temperatur, es sagt, auf welche Fälle diese Temperatur angepasst wurde, und es dokumentiert seine Inferenz als kurze nummerierte Prozedur, die du gegen eine Standard-Modellklasse neu implementieren kannst. Für einen Scorer, der vor einer automatisierten Aktion sitzt, ist das die Eigenschaft, auf die es ankommt, und sie ist seltener als Genauigkeitspunkte.

Nehmen Sie Decision 3.0, wenn Sie die Reichweite oder die Modalitäten benötigen. Sechs Checkpoints von 0,59B bis 26,09B bedeuten, dass dasselbe Anfrageformat von einem 6,7-ms-Edge-Modell und einem 27B-Modell bedient werden kann, und die Familie teilt eine Schnittstelle, sodass der Wechsel zwischen den Stufen eine Konfigurationsänderung und keine Neufassung ist. Der Haken ist, dass Sie einem nicht angegebenen Eingabebudget und einer nicht auditierten Kalibrierungsaussage vertrauen, und das größte Modell der Familie ist dasjenige, dessen Indexnummer der Anbieter auf seinem eigenen Prüfstand gemessen hat.

Keines von beiden ist heute eine sichere Standardeinstellung. Der meistheruntergeladene Checkpoint von d3 ist seit etwa einem Tag auf Hugging Face; Intern-Decision-4B ist seit zwei Wochen verfügbar und hat rund 3.200 Downloads und 83 Likes erhalten, was Aufmerksamkeit, aber keinen Produktionsverkehr bedeutet. Beide sind günstig genug für einen Test, und hinter keinem von beiden steht eine Evaluierung durch Dritte. Wenn Sie einen Scorer vor etwas setzen, das Geld ausgibt, sollten Sie beide mit Ihren eigenen gelabelten Fällen laufen lassen und die Kalibrierungskurven vergleichen, nicht die Indexzeilen.

Wo ein Router hingehört, ehrlich gesagt

OrcaRouter führt keines dieser beiden Modelle. Die Checkpoints von Decision 3.0 sind ein lokaler Python-Inferenzpfad in einem Hugging Face-Repository ohne veröffentlichten HTTP-Endpunkt, und Intern-Decision-4B wird als eine DecisionEngine-Klasse ausgeliefert, die Sie selbst instanziieren. Nichts davon könnten wir heute routen, und kein Teil dieses Artikels sollte als Verfügbarkeitsaussage gelesen werden.

Was wir führen, ist das gehostete Ende derselben Familie. typesafe/jev-1.13 ist in unserem Katalog, bereitgestellt über POST /v1/systemone — derselbe Vertrag aus Zustand und benannten Fragen, den beide offenen Modelle oben implementieren — zu $0.042 pro Million Eingabe-Tokens ohne Abrechnung für Completion, da es nie eine erzeugt. Es steht neben über 200 anderen Modellen, und das ist der praktische Punkt für alle, die diese beiden vergleichen: Der Scorer ist der günstige Teil der Schleife und das Modell, das auf die Entscheidung reagiert, der teure. Beide über einen Schlüssel zu routen, mit automatischem Failover, wenn ein Anbieter wackelt, und Anbieter-Listenpreis bei 0 % Aufschlag durchgereicht, bedeutet, dass die Evaluierung eines Entscheidungsmodells keinen zweiten Vertrag erfordert und auch kein Umschreiben der Aufrufstelle, wenn Sie Backends wechseln. Wenn Sie mitten in der Evaluierung sind — wo beide dieser Modelle heute stehen —, ist das der Teil, den es sich einzurichten lohnt, bevor Sie sich für eines von beiden entscheiden.

Die offene Frage

Die beiden Karten sind sich uneinig darüber, was ein Modellautor einem Leser schuldet, und diese Uneinigkeit ist interessanter als die Modelle. InternLM veröffentlichte eine Temperatur und die Fälle, auf die sie angepasst wurde, und veröffentlichte dann die Diagnose, die zeigte, wie stark die Kalibrierung sich verbesserte. vLLM-SR veröffentlichte Datei-Hashes, gepinnte Basisrevisionen, ein angegebenes Hardware-Ziel, eine Abdeckungsbehauptung – echte Provenienzarbeit – und überhaupt keine Kalibrierungszahl.

Der Test dafür, welches Release reift, ist nicht, welches ein Board gewinnt. Er besteht darin, ob der nächste Decision-Checkpoint mit einem Brier-Score darauf erscheint und ob der nächste Upload von InternLM Video erreicht. Beides ist von außen sichtbar, beides ist billig zu überprüfen, und keines von beidem ist bisher geschehen.