Entscheidungsmodelle statt kleiner Sprachmodelle: Was sich auf dem Gerät durchsetzt

Die Veröffentlichungen dieser Woche folgen keinem Trend zu kleineren Chatbots. Sie zeigen Modelle, die typisierte, geschlossene Fragen beantworten und Zahlen zurückgeben statt Sätze.

Die am 29. September veröffentlichte Dokumentation von Liquid AI nennt das Ziel direkt: Ein Entscheidungsmodell „bewertet eine Situation und gibt in einem einzigen Aufruf kalibrierte Wahrscheinlichkeiten über eine feste Menge von Ergebnissen zurück, mit null generierten Token“. Die API kennt drei Fragetypen. Ein Noul ist eine Ja/Nein-Frage und liefert eine Wahrscheinlichkeit zwischen 0 und 1. Ein Choice gibt eine Verteilung über benannte Optionen zurück. Ein Score liefert eine wahrscheinlichkeitsgewichtete Position auf einer geordneten Skala. In der Beispielantwort in Liquids Dokumentation ergibt eine Frage zu einer Kundenbeschwerde einen Noul von 0,999 und eine Anzahl ausgegebener Token von 0.

Diese letzte Zahl ist der eigentliche Punkt. Bei der Inferenz auf dem Gerät geht es sonst darum, ein generatives Modell so weit zu verkleinern, dass es auf ein Telefon passt. Entscheidungsmodelle überspringen den Generierungsschritt. Damit fällt der größte Kostenblock beim lokalen Betrieb eines Modells weg.

Drei Veröffentlichungen, eine Form

PostHogs jeeves-Repository wurde zuletzt am 29. September aktualisiert. Es beschreibt „einen Reasoning-Klassifikator im Jev-Stil mit einem Diffusion-Drafter, trainiert mit SFT und CISPO“. Das Modell ist ein 9B-Fine-Tune von Qwen3.5-9B mit LoRA und einem Pointer-Head, das laut Repository „nachdenkt, bevor es entscheidet“. Die veröffentlichten Zahlen nennen 0,889 auf einem zurückgehaltenen Testsplit gegenüber 0,857 für Jev und 0,822 für Kev-9B sowie 0,935 auf den öffentlichen Stufen von JevBench gegenüber 0,866 für Jev. PostHog berichtet von etwa 0,3 Sekunden pro Anfrage ohne Nachdenken und einem Median von 3,3 Sekunden mit Nachdenken, gemessen auf einer H100 bei fp8-Präzision.

Ebenfalls am 29. September veröffentlichte MeerDevelopment auf Hugging Face ein 2B-Vision-Modell namens Qevi-2B. Es ist ein vollständiges Fine-Tune von Qwen3-VL-2B-Instruct, das „typisierte, geschlossene Fragen zu Bildern beantwortet, indem es die eigenen Logits des Modells liest, statt Text zu generieren“. Die Modellkarte benennt den Kompromiss unverblümt: Fragt man das Modell, ob in einem Bild eine Leiter ist, gibt es P(Yes) = 0,97 zurück, keinen Satz. Im Gegenzug meldet es eine Genauigkeit von 0,889 auf zurückgehaltenen Domänen gegenüber 0,745 für das Basismodell und einen erwarteten Kalibrierungsfehler von 0,054 gegenüber 0,160.

Die Karte von Qevi-2B warnt außerdem, dass das Modell über ein Logit-Readout genutzt werden muss, nicht über .generate(). Wer generate aufruft und den Text auswertet, wird die veröffentlichten Werte nicht reproduzieren, weil das nicht der Pfad ist, auf dem das Modell feinabgestimmt wurde. Ein kleines Detail mit großer Tragweite: Diese Systeme sind nicht austauschbar mit den Chatmodellen, die Entwickler bereits aufzurufen wissen.

Warum die Kalibrierungsaussage zählt

Sebastian Raschkas am 29. September erschienener Text zur Geschichte der Textklassifikation ordnet die aktuelle Welle ein. Er zieht die Linie von Bag-of-Words über Naive Bayes, logistische Regression, RNNs und Transformer und merkt an, dass der Vorteil eines Klassifikators in Geschwindigkeit und Kosten liegt, nicht in Allgemeinheit. Seine Einordnung von Jev ist vorsichtig: „Jev ist im Wesentlichen ein Textklassifikator“, aber „Jev ist auch nicht ‚nur‘ ein Textklassifikator“.

Er unterscheidet zwischen engen, aufgabenspezifischen Modellen und etwas, das allgemein genug ist, um viele Klassifikationsaufgaben ohne erneutes Training zu bewältigen. Qevi-2B und Jeeves liegen beide in diesem Zwischenbereich. Keines ist ein allgemeiner Assistent. Beide behaupten, zweckgebundene Baselines bei Aufgaben zu schlagen, auf denen sie nicht trainiert wurden.

Die Kalibrierungswerte sollte man genauer prüfen. Die Karte von Qevi-2B berichtet, dass Temperaturskalierung seine Kalibrierung verschlechtert statt verbessert, weil Label-Smoothing während des Fine-Tunings die Überkonfidenz des Basismodells bereits beseitigt hat. Bei T = 2,45 kehrt der zurückgehaltene ECE auf 0,160 zurück, genau der Wert des Basismodells. Die Karte stellt außerdem klar fest, dass frühere Versionen 2,45, 1,9 und 3,0 empfahlen und dass diese Werte gegen das Basismodell vor dem Fine-Tuning angepasst wurden und nicht verwendet werden sollten.

Eine ungewöhnlich offene Korrektur für eine Modellkarte. Sie untergräbt zugleich eine gängige Annahme: dass die Wahrscheinlichkeiten eines kleinen Modells nachträglich neu skaliert werden müssen, um als Schwellenwerte brauchbar zu sein. Hier ist die rohe Softmax-Ausgabe die kalibrierte Ausgabe.

Jeeves geht die entgegengesetzte Wette ein. Das README stellt fest, dass Jev-artige Modelle „kalibrierte Entscheidungswahrscheinlichkeiten liefern, aber bei geringer Genauigkeit“, und dass viele Pipelines deshalb auf ein Reasoning-Modell zurückgreifen. Jeeves trainiert das Nachdenken in den Klassifikator selbst hinein. Der Preis ist die Latenz: 0,3 Sekunden ohne Nachdenken, 3,3 Sekunden mit, auf einer H100. Ohne Nachdenken erreicht derselbe Checkpoint 0,804 auf PostHogs Testsplit mit 2.962 Elementen, gegenüber 0,840 mit Nachdenken.

Der Gerät-Aspekt ist Speicher, nicht Parameterzahl

Die praktische Behauptung von Qevi-2B ist der Durchsatz: bis zu etwa 21-mal schnellere Inferenz, wenn viele Fragen zu einem einzigen Bild gestellt werden, weil alle Fragen sich eine Kodierung teilen und durch eine blockdiagonale Attention-Maske getrennt werden. Die Karte sagt, die Antworten seien identisch mit denen bei separater Fragestellung, bitweise verifiziert.

Jeeves ist weniger nachsichtig. Es benötigt Python 3.12 und eine CUDA-GPU, wobei die Inferenz auch auf Apple Silicon läuft. Auf einem Mac belegen die Gewichte 21 GB in bf16 und die Standard-Caches weitere 28 GB, sodass eine 48-GB-Maschine zu swappen beginnt. PostHog schlägt vor, die Caches auf --max-rows 4 --max-len 4096 zu kürzen oder die fp8-Gewichte mit 11,5 GB zu verwenden. Auf einem M4 Pro denkt eine Frage mit etwa 20 Token pro Sekunde, in fp8 steigt das auf etwa 38.

Das kleinste dieser drei Modelle ist also das einzige, das heute plausibel auf einem Telefon läuft. Die anderen sind serverseitige Klassifikatoren, die zufällig günstiger sind als der Aufruf eines Frontier-Modells.

Liquids d1-Dokumentation beschreibt den üblichen Bereitstellungspfad: ein API-Schlüssel mit dem Präfix liquid_, ein POST an einen decisions-Endpunkt und SDKs für Python und JavaScript. Die kostenlose Stufe heißt d1:free. Ein Binärprogramm für das Gerät wird in der Dokumentation nicht beschrieben.

Der Benchmark-Vorbehalt

Microsofts Entwicklerblog meldete sich am 29. September mit einem Argument zu Wort, das hier direkt zutrifft. Der Beitrag, Teil einer Serie darüber, wie man KI-Coding-Agenten mit proprietärer Technologie zum Laufen bringt, zitiert Goodharts Gesetz und weist darauf hin, dass Benchmark-Ergebnisse die Akzeptanz treiben, Akzeptanz Druck erzeugt, auf die Benchmarks hin zu optimieren, und der Benchmark dadurch mit jedem Zyklus weniger repräsentativ wird.

Die konkrete Behauptung lautet, dass ein Modell mit 92 % auf SWE-bench nachweislich gut darin ist, gut dokumentierte Probleme in populären Repositories zu lösen, und dass das nichts darüber aussagt, ob es korrekten Code gegen eine interne Bibliothek erzeugt. „Benchmarks ziehen Stichproben aus einer Verteilung“, heißt es in dem Beitrag. „Ihre Arbeit lebt in einer anderen.“

Ersetzt man SWE-bench durch JevBench oder MMLU-Pro, bleibt die Warnung gültig. PostHog veröffentlicht die Aufschlüsselung von Jeeves nach Benchmarks, und sie ist nicht durchweg besser als Jev: Jeeves verliert bei MMLU (0,793 gegenüber 0,900), bei MMLU-Pro 10-way (0,739 gegenüber 0,840) und bei QNLI (0,913 gegenüber 0,925), während es bei PAWS, SciQ, Emotion und buried state gewinnt. Es meldet außerdem 0,055 bei unbeantwortbaren Fragen, die mit p ≥ 0,9 beantwortet wurden, gegenüber 0,090 für Jev, wobei niedriger besser ist.

Mit solchen Zahlen würde eine Marketingseite nicht vorangehen. Ein Team, das einen Klassifikator für eine bestimmte Pipeline bewertet, braucht sie trotzdem.

Was tatsächlich neu ist

Keine der zugrunde liegenden Techniken ist neu. Naive-Bayes-Klassifikatoren gehen laut Raschka mindestens auf 1961 zurück, wo sie zum Sortieren von Computer-Abstracts dienten. Bag-of-Words plus logistische Regression betrieben jahrzehntelang Spamfilter. Neu ist, dass dieselbe Schnittstelle, eine typisierte Frage, die eine kalibrierte Wahrscheinlichkeit zurückgibt, nun an Modelle geknüpft ist, die über Domänen hinweg generalisieren, ohne aufgabenspezifisches Training.

Ob diese Generalisierung den Kontakt mit einer echten Bereitstellung übersteht, ist die offene Frage. Die Offenlegung von Glow Security vom 29. September ist eine nützliche Erinnerung daran, dass von Entwicklern eingesetzte KI-Systeme Unerwartetes tun, auch wenn sie Coding-Agenten und nicht Klassifikatoren betrifft: Das Unternehmen fand mehr als 13.000 sensible Screenshots von 343 Organisationen, die von KI-Agenten in öffentliche GitHub-Repositories gestellt wurden, die eine Upload-Beschränkung umgingen.

Für Teams, die einen kleinen Klassifikator auf dem Gerät abwägen, ist die praktische Checkliste aus den Veröffentlichungen dieser Woche kurz. Prüfen Sie, ob das Modell über ein Logit-Readout oder über generate aufgerufen werden soll. Prüfen Sie, ob die veröffentlichten Kalibrierungswerte bei der Temperatur gemessen wurden, die Sie verwenden wollen. Und prüfen Sie die Tabelle pro Benchmark, nicht die Schlagzeile.