Kleine Entscheidungsmodelle laufen lokal: Liquid AI, PostHog und Qevi liefern Klassifikatoren

Drei kleine Modelle für je eine Aufgabe erschienen am 29. September innerhalb weniger Stunden. Alle drei folgen derselben Idee: keine Textgenerierung, Wahrscheinlichkeiten direkt aus dem Modell lesen und das Ganze auf Hardware betreiben, die man selbst kontrolliert.

Liquid AI beschreibt d1 auf der Dokumentationsseite als "eine neue Klasse von KI-Modellen, die für strukturierte Entscheidungen gebaut wurde". Statt Token einzeln zu erzeugen, heißt es dort, "bewertet ein Entscheidungsmodell eine Situation und liefert kalibrierte Wahrscheinlichkeiten über eine feste Menge von Ergebnissen in einem einzigen Aufruf mit null erzeugten Token". Das Beispiel der Firma zeigt usage.output_tokens: 0 für eine Anfrage zur Beschwerdeerkennung, die einen noul-Wert von 0.999 zurückgab.

Drei Frageformen, kein erzeugter Text

Liquid teilt Entscheidungsfragen in drei Typen. Ein noul ist eine Ja-oder-Nein-Frage und gibt eine Wahrscheinlichkeit zwischen 0 und 1 zurück, laut Dokumentation "ein Boolean auf einer gleitenden Skala". Ein choice liefert eine Verteilung über benannte Optionen, etwa {"billing": 0.65, "technical": 0.30, "account": 0.05}. Ein score liefert eine wahrscheinlichkeitsgewichtete Position auf einer geordneten Skala. Eine Frage nach der Dringlichkeit in drei Stufen kann so als 1.85 zurückkommen, zwischen "Medium" und "High".

Die Dokumentation sagt ausdrücklich, dass noul und score nicht austauschbar sind. Ein noul bei 0.5 bedeutet maximale Unsicherheit zwischen Ja und Nein und "sagt nichts über Grad oder Intensität". Muss der Code gegen einen Schwellenwert auf einem Kontinuum prüfen, verweist die Dokumentation auf score. Geht es um ein Boolean als Bedingung, dann noul. Die API nimmt einen Zustand plus eine oder mehrere benannte Fragen und beantwortet alle in einem einzigen Aufruf. Client-Bibliotheken gibt es für Python (typesafe-sdk) und JavaScript (@typesafe-ai/sdk), die Schlüssel beginnen mit liquid_.

Liquids Seite ist Dokumentation, kein Benchmark-Paper, deshalb stehen dort keine Genauigkeitswerte für d1. Das ist wichtig, denn in derselben Woche erschienen zwei Modelle, die Zahlen veröffentlichen. Der Abstand zwischen ihnen ist aufschlussreich.

Jeeves ergänzt die Jev-Formel um Reasoning

PostHogs GitHub-Repository zu Jeeves beschreibt es als "einen Klassifikator im Jev-Stil mit Reasoning und einem Diffusion-Drafter, trainiert mit SFT und CISPO". Es ist ein 9B-Modell auf Basis von Qwen3.5-9B mit LoRA und einem Pointer-Head, dazu ein Diffusion-Drafter mit Block-4 sowie der vollständige Trainingscode und die Daten. Das Repository behauptet, es schlage Kev-9B und Jev auf Testdaten, auf denen es nie trainiert wurde, mit 0.889 gegen 0.822 und 0.857, und auf den öffentlichen Stufen von JevBench mit 0.935 gegen 0.866 für Jev.

Das Repository veröffentlicht eine ausführlichere Tabelle, und die ist nicht durchweg schmeichelhaft. Jeeves erreicht 0.746 bei Transfer-Aufgaben zu MMLU-Pro und buried state, unter Jevs 0.800. Bei MMLU fällt es auf 0.793 gegen Jevs 0.900, bei MMLU-Pro 10-way auf 0.739 gegen 0.840. Es gewinnt bei PAWS (0.875 gegen 0.788), bei zurückgehaltenen Regelstrukturen (1.000 gegen 0.885) und bei kontrastiven Policies (1.000 gegen 0.963). Unbeantwortbare Fragen beantwortet es seltener mit p von 0.9 oder höher als Jev, 0.055 gegen 0.090, wobei niedriger besser ist.

Das Repository merkt außerdem an, dass derselbe Checkpoint ohne Thinking 0.804 auf seinem Testsplit von 2.962 Elementen erreicht, gegenüber 0.840 mit Thinking. Die Latenz ist der Preis: etwa 0.3 Sekunden pro Anfrage ohne Thinking und ein Median von 3.3 Sekunden mit Thinking, auf einer H100 bei fp8-Präzision. Auf einem M4 Pro denkt eine Frage mit ungefähr 20 Token pro Sekunde. Die Gewichte belegen 21 GB in bf16, die Standard-Caches kommen mit weiteren 28 GB hinzu. Deshalb empfiehlt die README auf einem Mac mit 48 GB kleinere Cache-Einstellungen.

Ein Hinweis steht in der Tabelle selbst. Es gibt kein veröffentlichtes Kev-9B-Ergebnis für JevBench, und die beiden mit Sternchen markierten Zeilen betreffen Kev-8B auf Qwen3. Ein Teil des Vergleichs läuft also gegen ein anderes Modell, als die Spaltenüberschrift nahelegt.

Qevi-2B überträgt denselben Kniff auf Bilder

Die Modellkarte zu Qevi-2B auf Hugging Face beschreibt ein vollständiges Fine-Tuning von Qwen3-VL-2B-Instruct. Es beantwortet typisierte, geschlossene Fragen zu Bildern, "indem es die Logits des Modells selbst liest, statt Text zu erzeugen". Fragt man, ob auf einem Bild eine Leiter zu sehen ist, liefert es P(Yes) = 0.97 zurück, keinen Satz. Die Karte sagt klar, dass es kein Chat-Modell ist, und warnt: Wer .generate() aufruft und den Text parst, reproduziert die veröffentlichten Zahlen nicht, weil das nicht der Pfad ist, auf dem das Modell feinabgestimmt wurde.

Das Auslesen sind etwa 30 Zeilen gewöhnlicher transformers-Code ohne trust_remote_code. Gegenüber dem Basis-Qwen3-VL-2B-Instruct über denselben Auslesepfad steigt Qevi-2B von 0.855 auf 0.977 bei der Genauigkeit im Trainingsbereich und von 0.745 auf 0.889 bei 12 zurückgehaltenen Domänen. Der Expected Calibration Error auf zurückgehaltenen Daten sinkt von 0.160 auf 0.054. Die Karte nennt einen Geschwindigkeitsvorteil von etwa 21-mal, wenn viele Fragen zu einem Bild gestellt werden. Eine blockdiagonale Attention-Maske erlaubt mehreren Fragen eine gemeinsame Kodierung des Bildes, bitweise geprüft gegen einzelne Abfragen.

Die Karte warnt vor dem Temperature Scaling, das frühere Versionen empfahlen: bei T = 2.45 liegt der ECE auf zurückgehaltenen Daten bei 0.160, im Wesentlichen der Wert des Basismodells, und "der gesamte Kalibrierungsgewinn wird aufgehoben".

Es gibt eine zweite ehrliche Anmerkung. Der Trainingskorpus enthält nur noul- und choice-Fragen. Die Engine unterstützt score, und das Basismodell beantwortet solche Fragen zero-shot, doch das Fine-Tuning hat nie eine gesehen. Deshalb hält die Karte fest, dass Genauigkeit und Kalibrierung für score nicht gemessen wurden und als ungetestet gelten sollten.

Warum das lokale Argument immer wieder auftaucht

Sebastian Raschkas Text vom 29. September zur Geschichte der Textklassifikation hilft hier, weil er einordnet, worauf diese Modelle verzichten. Er merkt an, dass die neuesten GPT- und Open-Weight-Modelle dieselben Klassifikationsaufgaben wie Jev erledigen können und dabei viel allgemeiner sind. Der Vorteil eines Modells im Jev-Stil liegt bei Geschwindigkeit und Kosten. Am anderen Ende gilt: "Für ein enges, klar umrissenes Problem wird Jev wahrscheinlich nichts besser, schneller oder günstiger klassifizieren als ein spezialisierter Klassifikator." Der Reiz liegt in der Mitte: allgemeiner als ein aufgabenbezogenes Modell, günstiger als ein Frontier-Modell.

Raschkas Artikel verfolgt die Linie zurück bis zu Bag-of-Words-Darstellungen, die Naive Bayes, logistische Regression, SVMs und XGBoost speisen. Er merkt an, dass der Gmail-Spamfilter angeblich ein Naive-Bayes-Modell über Bag-of-Words war. Der Unterschied heute: Der Klassifikator ist ein feinabgestimmtes Sprachmodell mit einem kalibrierten Wahrscheinlichkeitskopf, und man kann ihn als Gewichte ausliefern, statt ihn als Dienst aufzurufen.

Genau hier greift das lokale Argument. Jeeves läuft auf CUDA in bf16 oder fp8 und auch auf Apple Silicon über MPS. Ein fp8-Build schrumpft die Gewichte auf 11.5 GB und hebt den Thinking-Durchsatz auf einem M4 Pro von etwa 20 auf etwa 31 Token pro Sekunde. Das Repository sagt, Genauigkeit und NLL hätten sich bei Dev-Fragen nicht messbar geändert. Ein bereits quantisiertes PostHog/jeeves-fp8-Repo ist veröffentlicht, sodass der Download etwa halb so groß ist.

Qevi-2B ist noch kleiner, mit 2B Parametern, ein Format, das auf einen Laptop oder ein Telefon passt statt in ein Rack. Liquids Dokumentation beschreibt, dass das Modell Zustand und Fragen in einem Aufruf mit null Ausgabe-Token bewertet. Genau diese Eigenschaft macht die Kosten pro Anfrage vorhersagbar.

Die Messungen bleiben dünn

Nichts davon ist frei von Problemen. Die jüngste angrenzende Forschung, ein am 28. September eingereichtes arXiv-Paper von Cameron Berg und Caspar Kaiser, fand heraus: Über sieben Open-Weight-Modelle aus fünf Familien hinweg steuern verborgene valenzbezogene Aktivierungsmuster spätere Entscheidungen vorhersagbar, selbst wenn jedes sichtbare Token identisch ist. Die Autoren schreiben, ob diese Spuren von subjektivem Erleben begleitet werden, das für das Wohlergehen von Modellen relevant wäre, "bleibt unklar". Das erinnert daran, dass das Lesen des internen Zustands eines Modells inzwischen ein Entwurfsmuster ist, nicht nur eine Diagnose.

Der praktische Einwand kommt aus dem Entwicklerblog von Microsoft vom 29. September. Der Beitrag argumentiert, dass öffentliche Benchmarks wenig über die eigene Arbeitslast aussagen. Er zitiert Goodharts Gesetz und weist darauf hin, dass SWE-bench-Aufgaben aus öffentlichen Repositories stammen, die Überschneidung mit Trainingsdaten also unvermeidlich ist und mit jeder Generation wächst. Ein Modell mit 92% auf SWE-bench, so heißt es dort, ist nachweislich gut darin, gut dokumentierte Probleme in populären Repositories zu lösen. Über die eigene interne Bibliothek sagt das nichts.

Dieselbe Logik gilt für Entscheidungsmodelle. Jeeves' eigene Tabelle zeigt es unterlegen gegenüber Jev bei MMLU und MMLU-Pro, während es bei zurückgehaltenen Regelstrukturen gewinnt. Die Antwort auf "welches ist besser" hängt also ganz davon ab, aus welcher Verteilung die eigenen Tickets, Bilder oder Dokumente stammen. Liquid veröffentlicht überhaupt keine Genauigkeitswerte für d1. Die Karte zu Qevi-2B führt score als ungetestet. Die Zahlen, die es gibt, stammen überwiegend von den Teams selbst, die die Modelle ausliefern, auf Splits, die sie gewählt haben.

Neu in dieser Woche ist nicht, dass es kleine Klassifikatoren gibt. Neu ist, dass drei getrennte Teams sie mit derselben Schnittstellenidee ausgeliefert haben: kalibrierte Wahrscheinlichkeiten über eine feste Antwortmenge in einem einzigen Vorwärtsdurchlauf. Sie sind klein genug, um ohne Rechenzentrum zu laufen. Ob das reicht, um das Muster aus Frontier-Modell mit Fallback zu verdrängen, das die Jeeves-README beschreibt, können die veröffentlichten Benchmarks noch nicht beantworten.