UserRepGen-4B vs. Intern-Decision-4B: Zwei Teams haben dieselbe 4B-Basis feinabgestimmt und waren sich in nichts einig

Zwei leise Veröffentlichungen, fünf Wochen auseinander, die vom selben Checkpoint abzweigen. microsoft/UserRepGen-4B wurde am 14. Oktober 2026 auf Hugging Face als ein 9,1 GB bfloat16-Repository ohne Ankündigung hochgeladen; internlm/Intern-Decision-4B erschien am 26. September 2026 um 05:36:37 UTC innerhalb eines vierzigsekündigen Fensters, das auch ein 0,8B- und ein 2B-Modell hervorbrachte, ebenso unangekündigt. Beide sind LoRA-Fine-Tunes von Qwen3.5-4B, beide sind text-only, obwohl sie einen Vision-Tower tragen, den sie nie nutzen, beide geben eine starre Struktur statt einer Antwort zurück — und sie könnten nicht unterschiedlicher darüber sein, wofür das Modell gedacht ist. Intern-Decision-4B schreibt kein einziges Token. UserRepGen-4B schreibt nichts als Token. Alles andere in diesem Vergleich folgt aus dieser einen Trennung.

Der eine ist ein Torschütze, der andere ein Schreiber

Die Model Card von InternLM ist ungewöhnlich unverblümt, was ihre eigene Mechanik angeht: „Diese API führt eine strukturierte Bewertung von Kandidaten durch. Sie ruft weder generate() auf noch sampelt sie Freitext.“ Man übergibt ihr einen Zustand, ein Schema benannter Fragen und eine Reihe von Kandidatenantworten. Sie bildet die Optionen auf Einzel-Token-Symbole ab, führt einen einzigen kausalen Vorwärtsdurchlauf aus, liest die Logits an der Position unmittelbar vor jedem Platzhalter aus, wendet eine angepasste Temperatur von 1,99241824 an und gibt eine kalibrierte Wahrscheinlichkeit pro Option zurück. Ein Durchlauf. Kein Sampling, keine Decodierungsschleife, kein Text.

UserRepGen-4B kehrt es um. Man übergibt ihm eine abgeschlossene Konversation. Es gibt bis zu 1.024 Token Prosa über zwei JSON-Felder aus — eine Aufgabenbeschreibung und eine user_behavior-Beschreibung — und die Karte ist in der anderen Richtung ebenso unverblümt: Das Modell „generiert Repräsentationen, keine simulierten Nutzer-Turns“, es führt die Aufgabe des Nutzers nicht aus, und es ist nicht der Simulator.

Stell die beiden nebeneinander, und die technischen Konsequenzen ergeben sich sofort.

• Was die Ausgabe wert ist — Intern-Decision-4B liefert eine Zahl, die sich mit einem Schwellenwert versehen, mitteln und auditieren lässt. UserRepGen-4B liefert einen Absatz, dessen Qualität nur ein LLM-Richter bewerten kann – und genau so hat Microsoft sie bewertet.

• Kosten pro Aufruf — ein einzelner Forward-Pass über einen festen Prompt gegenüber bis zu 1.024 generierten Tokens. Das ist der Unterschied zwischen ungefähr 44 Millisekunden und einem vollständigen Decoding-Durchlauf, und deshalb kann das Entscheidungsmodell in einer Schleife sitzen, in der das Repräsentationsmodell das nicht kann.

• Wo die Bedeutung lebt — InternLM entschied, dass die Antwort bereits im Prompt aufzählbar sein sollte, sodass das Modell nur noch eine Rangfolge bilden muss. Microsoft entschied, dass die Antwort latent in einer Konversation steckt, sodass das Modell schreiben, und zwar sie, muss. Das Ranking ist begrenzt und überprüfbar. Schreiben ist ergebnisoffen und braucht einen Richter.

Die Input-Obergrenzen, und was sie über die Wetten verraten

Beide Karten nennen ein hartes Limit, und sie zu vergleichen ist der schnellste Weg, um zu sehen, wie unterschiedlich die beiden Teams dasselbe Basismodell abgegrenzt haben.

Intern-Decision-4B verweigert Arbeit oberhalb von 8.192 Tokens. Das ist eine Verweigerung, keine Trunkierung – eine Designentscheidung, die besagt, dass das Modell für Entscheidungen gedacht ist, die kompakt genug sind, um sie vollständig in einem Prompt zu formulieren.

RepGen-4B wird auf einer Sequenz von 9.216 Tokens trainiert: bis zu 8.192 Prompt-Tokens, die die Konversation abdecken, plus 1.024 Completion-Tokens für die Repräsentation. Die Karte ergänzt, dass die Nutzung mit erweitertem Kontext über diese Länge hinaus „von dieser Version nicht unterstützt wird“ und dass die Leistung bei langem Kontext nie separat benchmarkiert wurde. So taucht dieselbe Obergrenze von 8.192 Tokens auf beiden Seiten auf, unabhängig voneinander erreicht, von zwei Teams, die vermutlich keine Einsicht in die Arbeit des jeweils anderen hatten.

Diese Konvergenz ist der nützliche Befund. Ein 4B-Fine-Tuning auf dieser Basis ist Mitte 2026 eine Komponente, die für einen einzelnen wohlgeformten Prompt ausgelegt ist – keine Long-Context-Engine. Beide Veröffentlichungen sind diesbezüglich ehrlich. Keine von ihnen versteckt es hinter einem größeren beworbenen Kontextfenster.

Beide veröffentlichten eine Kalibrierungsgeschichte, und sie sind nicht dieselbe Geschichte.

Hier wird die Beschaffung heikel, denn die beiden Bewertungen sind nicht vergleichbar, und keine von ihnen wurde außerhalb ihres eigenen Labors reproduziert.

Intern-Decision-4B veröffentlicht einen Benchmark mit sieben Suiten, in dem es durchschnittlich 90,02 erreicht – die beste Zeile in seiner eigenen Tabelle, vor Intern-Decision-2B mit 84,68 und Intern-Decision-0.8B mit 79,38, alle gemessen auf den Harnessen von InternLM. Es veröffentlicht außerdem Kalibrierung: einen Brier-Score von 0,347 und einen erwarteten Kalibrierungsfehler von 0,065. Ein separater Pilot mit 96 Fällen, der exakte Referenzverteilungen verwendet, geht von 0,628 Brier und 0,213 ECE auf 0,550 und 0,089 über, nachdem seine angepasste Temperatur angewendet wurde. Jede einzelne dieser Zahlen stammt vom Anbieter selbst, und niemand außerhalb von InternLM hat sie überprüft.

UserRepGen-4B veröffentlicht eine Fidelity-Tabelle auf einer Richter-Skala von 1 bis 10 — 4,95 best-of-1 und 6,02 best-of-3, gegenüber 3,90 und 4,90 für GPT-5.5, wie es unverändert eingesetzt wird, und 3,41 und 4,42 für die nicht abgestimmte Basis. Jede einzelne dieser Zahlen stammt von Microsoft selbst und wurde mit GPT-5.4 mini erzeugt, das gleichzeitig als Simulator, Assistent und Richter fungiert, und niemand außerhalb von Microsoft hat sie überprüft.

Die entscheidende Asymmetrie liegt nicht in den Scores – sie messen Unterschiedliches auf unterschiedlichen Skalen. Sie besteht darin, dass Intern-Decision-4B eine propere Scoring-Regel gegen bekannte Referenzverteilungen veröffentlicht, die konstruktionsbedingt falsifizierbar ist, während UserRepGen-4B einen LLM-Judge-Score veröffentlicht, der nur dadurch falsifizierbar ist, dass man einen anderen Judge laufen lässt. InternLM hat ein Modell gebaut, das sich mit Arithmetik auditieren lässt. Microsoft hat eines gebaut, das mit einem anderen Modell auditiert werden muss. Da beide behaupten, Baselines geschlagen zu haben, ist dieser Unterschied in der Auditierbarkeit ein realer Teil der Entscheidung, die Sie treffen.

Der Datenschutzbefund, den nur einer von ihnen druckt

Die Karte von Intern-Decision-4B enthält keinen nennenswerten Datenschutzabschnitt. Die von UserRepGen-4B enthält eine Zahl, die jedes Team innehalten lassen sollte: Bei über 147 Nutzern erzielt ein Selektor, der auswählen soll, welche der vier Konversationen von derselben Person stammt, 51,02 %, wenn er die Verhaltensbeschreibungen des Modells verwendet, gegenüber 44,22 % bei Verwendung der vollständigen Rohkonversationen und 25 % nach Zufallsprinzip. Die komprimierte Repräsentation identifiziert die Person besser als das Material, aus dem sie abgeleitet wurde.

Microsoft bezeichnet es als Verknüpfbarkeitsrisiko und erklärt unmissverständlich, dass Repräsentationen keine anonymisierten Daten sind. Das ist der korrekte Umgang damit, und es ist eine Warnung, die für die gesamte Modellklasse gilt – einschließlich des Entscheidungsmodells, dessen eigene Eingaben Gespräche über die Situationen von Menschen sind. Der Unterschied ist nur, dass die eine Karte es sagt und die andere nicht, was nicht gleichbedeutend damit ist, dass ein Modell sicher ist.

Keines von beiden ist eine API, aber die Basis, die sie gemeinsam haben, ist

Beides sind Downloads, keine Endpunkte. Intern-Decision-4B wird als Python-DecisionEngine-Klasse ausgeliefert, die einmal geladen und wiederverwendet wird, sein Demo-Space antwortet mit 401, und sein GitHub-Link liefert 404; UserRepGen-4B wird als einzelne unquantisierte safetensors-Datei und eine example.py ausgeliefert. OrcaRouter bietet keines von beiden. Wenn du sagst, eines von beiden sei heute über eine gehostete API verfügbar, beschreibst du einen Plan und keine Tatsache.

Was tatsächlich aufrufbar ist, ist der Checkpoint, von dem beide abgezweigt sind. Die Familie von Qwen3.5-4B ist in unserem Katalog — Qwen3.5-Flash mit einem Kontext von über einer Million Token bei 0,10 $ pro Million Eingabe-Token und 0,40 $ pro Million Ausgabe-Token, Qwen3.5-35B-A3B bei 0,057 $ und 0,459 $, Qwen3.5-27B bei 0,086 $ und 0,688 $ — alle mit demselben Schlüssel, alle zum Listenpreis des Anbieters, ohne Aufschlag. Das ist nützlich für den Teil der Pipeline, bei dem es nicht um diese beiden Modelle geht: Die Assistentenseite einer Simulation oder der Reasoning-Schritt rund um einen Entscheidungsaufruf kann über einen einzigen Endpunkt laufen, während Sie das Fine-Tuning lokal evaluieren.

Wie man wählt

Wenn Ihr Problem eine begrenzte Frage mit aufzählbaren Antworten ist und Sie zehntausend Mal pro Sekunde eine kalibrierte Zahl benötigen, ist Intern-Decision-4B das einzige Modell hier, das das leistet, und die Tatsache, dass es nie sampelt, ist das Feature und nicht die Einschränkung. Wenn Ihr Problem darin besteht, dass Sie einen Simulator möchten, der sich wie ein echter Nutzer verhält, ist UserRepGen-4B das einzige hier dafür trainierte Modell, und die Größe seines berichteten Vorsprungs gegenüber GPT-5.5 ist der Grund, sich dafür zu interessieren. Niemand sollte eines von beiden auf Grundlage der Zahlen des jeweils anderen auswählen, denn sie haben nie dasselbe gemessen. Was den Vergleich entscheiden würde, wäre eine einzige externe Überprüfung der einen oder anderen Karte — und bei zwei Releases, die in völliger Stille und mit Wochen Abstand veröffentlicht wurden, hat keine von beiden eine solche erhalten.

Zwei still und leise erfolgte Veröffentlichungen sind zugleich ein Hinweis darauf, wie viel von dieser Modellklasse ohne Dokumentation ausgeliefert wird, und die Fehler, die daraus folgen, werden in the OrcaRouter AI Incident Archive gesammelt, wo jeder Eintrag eigene Quellen, Schweregrad, Konfidenzstufe und eine Kennzeichnung als umstritten trägt.