Entscheidungsmodelle werden klein: Qevi-2B, Liquid d1 und Jeeves drängen die Klassifikation auf das Gerät
Ein Vision-Modell mit 2B Parametern beantwortet Ja/Nein-Fragen, indem es seine eigenen Logits liest, statt Text zu erzeugen. Es wurde am 29. September auf Hugging Face veröffentlicht und beansprucht 0,977 Genauigkeit im eigenen Bereich sowie bis zu 21-mal schnellere Inferenz, wenn viele Fragen zu einem Bild gestellt werden.

Das Modell heißt Qevi-2B und ist ein vollständiges Fine-Tuning von Qwen3-VL-2B-Instruct. Seine Autoren beschreiben es als "kein Chat-Modell": Wer fragt, ob auf einem Foto eine Leiter zu sehen ist, bekommt P(Yes) = 0,97 statt eines Satzes. Die veröffentlichte Karte nennt 0,977 Genauigkeit im eigenen Bereich gegenüber 0,855 beim Basismodell, 0,889 auf zurückgehaltenen Bereichen gegenüber 0,745 und einen erwarteten Kalibrierungsfehler von 0,054 gegenüber 0,160 auf zurückgehaltenen Daten. Der Geschwindigkeitsanspruch stützt sich auf Question Packing: Mehrere Fragen teilen sich eine einzige Kodierung des Bildes, getrennt durch eine blockdiagonale Attention-Maske, bitweise geprüft gegen die separate Abfrage.
Das ist ein Artefakt in einer zwei Wochen alten Kategorie, die inzwischen SDKs, Benchmarks, eine konkurrierende Benchmark-Suite und mindestens einen Open-Source-Klon hat. TypeSafe lieferte Jev am 15. September aus, so Casco, das den Aufstieg des Modells zum Meme auf "innerhalb von achtundvierzig Stunden" datiert.
Liquid gibt den Primitiven einen Namen
Liquid AI veröffentlichte am 29. September die Dokumentation zu d1, das das Unternehmen sein erstes Entscheidungsmodell nennt. Die Dokumentation ist ungewöhnlich deutlich dazu, wofür diese Systeme gedacht sind: Statt Token für Token zu erzeugen, bewertet ein Entscheidungsmodell einen Zustand und liefert kalibrierte Wahrscheinlichkeiten über eine feste Menge von Ausgängen "in einem einzigen Aufruf mit null erzeugten Token".
Liquid definiert drei Fragetypen, die sich als De-facto-Schnittstelle durchgesetzt haben. Noul ist eine Ja/Nein-Frage und liefert eine Wahrscheinlichkeit zwischen 0 und 1; die Dokumentation nennt eine Spam-Prüfung mit 0,92 als Beispiel. Choice liefert eine Verteilung über benannte Optionen, etwa {"billing": 0.65, "technical": 0.30, "account": 0.05} für die Ticket-Weiterleitung. Score liefert eine wahrscheinlichkeitsgewichtete Position auf einer geordneten Skala, sodass "wie dringend ist das?" über drei Stufen als 1,85 zurückkommen kann, zwischen Medium und High. Liquids Empfehlung lautet, den Typ danach zu wählen, was der eigene Code als Nächstes tut: Verzweigung nach einer Kategorie, dann Choice; Vergleich gegen einen Schwellenwert, dann Score; Freigabe anhand eines Booleans, dann Noul.
Das Unternehmen warnt zudem vor einer häufigen Verwechslung. Ein Noul bei 0,5 bedeutet laut Dokumentation maximale Unsicherheit zwischen Ja und Nein und "sagt nichts über Grad oder Intensität". Um einen Grad zu messen, braucht es Score mit definierten Stufen.
Jeeves: Reasoning obendrauf und eine Rechnung von 3,3 Sekunden
Der interessanteste Widerspruch zur Kategorie kam von PostHog, das am 29. September Jeeves veröffentlichte: ein Jev-ähnliches Modell mit 9B Parametern auf Basis von Qwen3.5-9B mit LoRA und einem Pointer Head, trainiert mit SFT und CISPO, sodass es erst denkt und dann entscheidet. Das Repository ist unverblümt über den Kompromiss, den es korrigiert. "Jev-ähnliche Modelle liefern kalibrierte Entscheidungswahrscheinlichkeiten, aber bei geringer Genauigkeit", heißt es im README, weshalb viele Pipelines bereits auf ein Reasoning-Modell zurückfallen.
Jeeves meldet 0,889 auf einem zurückgehaltenen und bereichsfremden Testsplit von 2.962 Elementen, gegenüber 0,857 für Jev und 0,822 für Kev-9B. Einschränkend merkt das Repository an, dass die Kev- und Jev-Spalten Zahlen sind, die Kev veröffentlicht. Auf den 231 öffentlichen Elementen von JevBench beansprucht es 0,935 gegenüber 0,866 für Jev; auf der 111 Elemente umfassenden harten Stufe 0,865 gegenüber 0,730. Sein Kalibrierungsfehler auf öffentlichen JevBench-Elementen liegt bei 0,037. Derselbe Checkpoint erreicht 0,804 ohne Denken gegenüber 0,840 mit.
Dann die Kosten. PostHog misst etwa 0,3 Sekunden pro Anfrage ohne Denken und einen Median von 3,3 Sekunden mit, auf einer H100 bei FP8-Präzision, und merkt an, dass ein Kürzen der Kette das verkürzt. Die Inferenz läuft zudem auf Apple Silicon mit 48 GB oder mehr, was zählt, wenn der Sinn eines kleinen Entscheidungsmodells darin liegt, die Arbeit lokal zu halten.
Die Zahlen der Basismodelle in der Jeeves-Tabelle sind nicht alle vergleichbar: Das Repository versieht seinen Kev-9B-Wert bei JevBench mit einem Sternchen und merkt an, dass kein Kev-9B-Ergebnis für JevBench veröffentlicht ist und die gezeigten Zahlen Kev-8B auf Qwen3 sind.
Wer tatsächlich für einen Klassifikator zahlt
Das deutlichste Produktionsargument kommt von Evan Schwartz, der Scour betreibt, einen personalisierten Content-Feed. In einem Beitrag vom 29. September beschreibt er, wie er 54 Fragen an rund 1.100.000 Dokumente pro Monat stellt: 50 Nouls, 3 Choices und 1 Score, etwa 2.150 Token einschließlich rund 260 Token festen Overheads. Seine Fragen machen inzwischen etwa 88 Prozent der Eingabe-Token aus und werden bei jeder Anfrage wortgleich mitgeschickt. Seine Gesamtausgaben liegen unter 150 Dollar pro Monat, und er sagt, dieselben Inhalte durch auch nur das günstigste LLM zu schicken, wäre für ein bootstrapped Projekt unbezahlbar.
Seine Bitte ist konkret: Prompt-Caching oder die Möglichkeit, wiederverwendbare Fragensets zu registrieren.
Er merkt an, dass er mehrere Posts nicht in einer Anfrage bündelt, wegen der dokumentierten Warnung, dass die Genauigkeit sinkt, wenn der Zustand mit unrelated Inhalten wächst, und schlägt eine API vor, die viele Fragen und viele Eingaben entgegennimmt, als Alternative, die die Packing-Strafe vermeidet. Andere füllen die Lücken um TypeSafe bereits. Ein GitHub-Projekt namens Jeb, aktualisiert am 29. September, verwandelt jeden OpenAI-kompatiblen Endpunkt in ein Entscheidungsmodell, indem es Token-Logprobs liest und strukturiertes JSON unter POST /v1/systemone zurückgibt, mit demselben Anfrageformat über die CLI. Sein README ist offen über die Voraussetzung: Ein Endpunkt kann für gewöhnlichen Chat OpenAI-kompatibel sein und trotzdem die Log-Wahrscheinlichkeiten vermissen lassen, die Jeb braucht, also prüft diese Fähigkeit, bevor ihr einen Anbieter wählt.
Das Benchmark-Problem kommt früh
Casco, ein Sicherheitsunternehmen, schickte 2.449 Findings durch acht Modelle, darunter Jev, Claude und GPT, und verglich die Schweregradwerte nach CVSS 3.1 mit den eigenen veröffentlichten Referenzen. Jedes Modell überschätzte im Durchschnitt. Jev vergab 550 Critical-Werte an einen Datensatz mit 55 veröffentlichten Critical-Findings, wobei 500 dieser 550 in Cascos Referenz unter Critical lagen. GPT-6 Astra war insgesamt am genauesten, mit 1,92 Punkten mittlerem absolutem Fehler; Jev lag auf Platz sieben bei 3,40, vor Haiku mit 3,94.
Die vorzeichenbehafteten Fehler zeigen alle in dieselbe Richtung: Jev +3,30 Punkte, Haiku +3,89, Astra +1,18, auf einer Zehn-Punkte-Skala. Cascos Deutung ist, dass strukturierte, kalibrierte Ausgabe die Schweregradurteile gegenüber der eigenen Referenz nicht genauer machte und dass der daraus entstehende "security slop" Ingenieure Zeit kostet. Die Studie nutzte für jedes Modell dieselben Finding-Belege, ohne Cascos Bewertungsrichtlinie oder internen Anwendungskontext, misst also den Ermessensentscheid und nicht die Arithmetik.
Es gibt zudem eine Wartungsfrage, die niemand beantwortet hat. Jeeves ist ein Fine-Tuning auf Qwen3.5-9B mit einem Diffusion Drafter und einer Jev-kompatiblen API; Qevi-2B ist ein Fine-Tuning von Qwen3-VL-2B. Beide hängen von Basismodellen ab, die abgelöst werden. Das Versprechen der Kategorie lautet, dass man Fragen ohne Neutraining hinzufügen kann, was für die API-Oberfläche stimmt, nicht aber für die Gewichte.
Am 29. September veröffentlichte Sebastian Raschka eine lange technische Geschichte der Textklassifikation von Bag-of-Words über RNNs, CNNs und Transformer bis zu dem, was er Jev-ähnliche APIs nennt, ausdrücklich um den "Hype zu entzaubern". Seine Schlussfolgerung ist die langweiligste und wahrscheinlich nützlichste: Für ein enges, klar umrissenes Problem wird ein Jev-artiges Modell einen Spezialklassifikator weder bei Genauigkeit noch bei Geschwindigkeit oder Kosten schlagen. Sein Verkaufsargument ist die Allgemeinheit innerhalb des Klassifikationsplatzes, und das ist eine viel kleinere Behauptung, als die Reaktion nahelegt.
Quellen
12- 01Qevi-2B: A Jev-style finetuned model for image classificationEN
- 02d1: Liquid AI's First Decision ModelEN
- 03Jeeves. Reasoning improves Jev-like decision modelsEN
- 04Please add prompt caching to Jev-style modelsEN
- 05Jeb: Turn any OpenAI API into a decision modelEN
- 06Every model (incl. Jev) we tested inflates security finding severityEN
- 07Language Models for Text Classification: From Bag-of-Words to JevEN
- 08The System One models ecosystemEN
- 09AI models keep posting screenshots showing sensitive data from inside companiesEN
- 10AI Models Fail at Physics: Coding Harnesses Are to BlameEN
- 11How many tasks does it take to trust a cheaper model?EN
- 12Gates Foundation 5 Year Goal: Help 3B People to Use AI in Their LanguageEN
Alle Zahlen und Zitate in diesem Text stammen aus den unten genannten Quellen.
Die Materialien wurden vom Redaktionsteam mit Unterstützung von KI erstellt.
Kommentare
0- Noch keine Kommentare — seien Sie der Erste.