Cloudflare liefert ein 27B-Entscheidungsmodell aus, das Jev bei dessen eigener Aufgabe schlägt

Cloudflare veröffentlichte Clef in den ersten Oktobertagen unter einer Apache-2.0-Lizenz. Es ist ein Modell mit 27 Milliarden Parametern, das auf Qwen3.8-27B basiert, und es schreibt keinen Fließtext. Es bewertet Optionen.

Die Kategorie ist klein und spezifisch. Ein Entscheidungsmodell nimmt eine Eingabe und eine Reihe möglicher Schema-Optionen entgegen und gibt dann eine Rangfolge statt eines generierten Satzes zurück. Jev von Typesafe AI etablierte den Ansatz und wurde zu dessen Referenzpunkt. Clef kommt als zweiter ernstzunehmender Anbieter, und gemessen an den von Cloudflare veröffentlichten Zahlen schlägt es den Platzhirsch sowohl bei der Genauigkeit als auch bei der Latenz.

Wie sich die Architektur unterscheidet

Clef verwendet ein Prefill-only-Design. Es liest die Eingabe und bewertet Schema-Optionen parallel, anstatt Token einzeln auszugeben. Diese eine Entscheidung erklärt den Großteil des Leistungsunterschieds, denn der teure Teil eines konventionellen Sprachmodell-Aufrufs ist die Decode-Schleife.

Bei BANKING77, einem Standard-Benchmark für Intent-Klassifizierung, erzielt Clef 94,20 Macro-F1 gegenüber 79,74 bei Jev. Cloudflare berichtet außerdem, dass Clef-flash, die kleinere Konfiguration, eine Median-Latenz von 38,8 Millisekunden hat, was das Unternehmen als etwa 13-mal schneller als Jevs Basiswert von 524,1 Millisekunden beschreibt.

Die Schnittstelle zählt genauso viel wie das Ergebnis. Clef ist Jev-API-kompatibel, sodass ein Team, das bereits an Jev angebunden ist, den Endpunkt austauschen kann, ohne Integrationscode neu zu schreiben. Clef akzeptiert außerdem multimodale Eingaben innerhalb eines Kontextfensters von 64.000 Token, während Jev nur Text verarbeitet und auf 32.000 begrenzt ist.

Cloudflares Formulierung ist unverblümt: Für Routing, Klassifizierung und strukturierte Auswahl ist das Generieren von Text verschwendete Arbeit. Wenn die benötigte Antwort eine von zwölf Kategorien ist, erledigt ein Modell, das einen Absatz schreibt und ihn anschließend nachbearbeitet, etwas Schwierigeres als die Aufgabe verlangt.

Wie sich das neben Embeddings einordnet

Es lohnt sich, Entscheidungsmodelle vom älteren Ansatz für dasselbe Problem zu trennen. Teams haben jahrelang mit Embeddings geroutet und klassifiziert: die Eingabe einbetten, sie mit gelabelten Beispielen vergleichen, das nächstgelegene auswählen. Das funktioniert und ist günstig, aber es braucht einen gelabelten Satz zum Vergleich und tut sich schwer, wenn die Entscheidung von Anweisungen statt von Ähnlichkeit abhängt.

Ein Entscheidungsmodell nimmt ein Schema und eine Reihe von Optionen als Teil der Anfrage entgegen. Es kann eine größere Bandbreite von Fragen beantworten, als ein Ähnlichkeitscheck zulässt: zu welcher Kategorie eine Nachricht gehört, welches von drei Tools aufgerufen werden soll, an welches Modell geroutet werden soll und welche von mehreren Richtlinien gilt. Die Anweisungen stecken in der Anfrage und nicht in einem gepflegten Index von Beispielen, was es einfacher macht, das Verhalten zu ändern, ohne irgendetwas neu zu labeln.

Der Kompromiss besteht darin, dass ein Entscheidungsmodell immer noch ein Sprachmodell ist, das die Bewertung vornimmt, und daher die Fehlermodi eines solchen erbt. Es kann mit hoher Zuversicht falschliegen, und seine Konfidenzwerte sind nicht auf eine Wahrscheinlichkeit kalibriert, der eine Routing-Richtlinie ohne Tests vertrauen kann. Das Prefill-only-Design beseitigt die Decode-Kosten, aber nicht das Problem zu wissen, wann das Modell rät.

Die Kostenrechnung ist ohnehin das, was die Kategorie interessant macht. Eine Anfrage durch ein generatives Modell zu routen kostet eine vollständige Generierung auf dem kritischen Pfad, oft mehrere hundert Millisekunden und ein paar hundert Token. Cloudflare gibt Clef mit unter 40 Millisekunden im Median für die Flash-Konfiguration an. Für einen Agenten, der pro Nutzer-Turn mehrere Routing-Entscheidungen trifft, summiert sich dieser Unterschied, und er summiert sich bei dem Schritt, den Nutzer tatsächlich spüren.

Die Kategorie standardisiert sich schnell

Was dies zu mehr als dem Launch eines einzelnen Anbieters macht, ist, wie schnell die Tooling-Landschaft rund um Entscheidungsmodelle dichter geworden ist.

Am 30. September fügte SGLang native Routen /v1/decisions und /v1/systemone hinzu, mit denen Sprach- und Vision-Modelle als Klassifikatoren und Scorer fungieren können, ohne Token-für-Token-Generierung. Das Framework demonstrierte die Fähigkeit, indem es Qwen3.8-27B als multimodales Entscheidungsmodell ausführte, und berichtete, Pokémon Feuerrot in einem Versuch mit einer Latenz unter 100 Millisekunden geschlagen zu haben.

Wenige Tage später fügte llama.cpp Unterstützung für Entscheidungsmodelle über einen neuen Endpunkt /v1/systemone hinzu, der offene Modelle wie Kev-4B und OpenJev abdeckt, mit geplantem Release in Version 0.6.0. Kleine Modelle laufen auf CPUs, und einige unterstützen Bildeingaben für die Klassifizierung.

Respan brachte mit Span-01 einen eigenen Beitrag auf den Markt, einen hyperparallelen Reasoning-Klassifikator zum Erkennen von Prompt-Injection, Halluzination und Tool-Missbrauch in Agenten-Traces. Er wird mit RLAIF trainiert und evaluiert mehrere ungesehene Verhaltensdefinitionen in einem einzigen Forward Pass. Respan bepreist ihn mit zwei Cent pro Million Eingabe-Token, mit einer kostenlosen Lite-Version.

Das sind vier separate Projekte, die Entscheidungsmodelle innerhalb von zwei Wochen als eine Schnittstelle behandeln, die es wert ist, nativ implementiert zu werden. Wenn ein Muster gleichzeitig in einem Inferenz-Framework, einer lokalen Laufzeitumgebung und der Produktpalette eines Start-ups auftaucht, ist es keine Kuriosität mehr.

Warum das für Agenten-Routing wichtig ist

Diejenigen, die zuerst profitieren dürften, sind diejenigen, die Agenten bauen, die andere Modelle aufrufen. Ein Agent muss entscheiden, welches Tool er verwendet, an welches Modell er routet, ob eine Anfrage ein Injection-Versuch ist und ob eine Antwort fundiert ist. Heute implementieren viele Teams diese Schritte, indem sie ein großes Modell bitten, in JSON zu antworten, und hoffen, dass das Format hält.

Ein Klassifikator, der eine Bewertung in wenigen Dutzend Millisekunden zurückgibt, verändert die Kosten dieser Entscheidung. Eine Anfrage durch ein Sprachmodell zu routen kostet eine vollständige Generierung, und zwar auf dem kritischen Pfad. Sie durch einen Prefill-only-Scorer zu routen kostet einen Bruchteil davon und ist früher fertig. Wenn die Genauigkeit standhält, ist der praktische Effekt, dass mehr vom Kontrollfluss eines Agenten mit Maschinengeschwindigkeit statt mit Token-Geschwindigkeit laufen kann.

Cloudflares eigenes Argument dreht sich um Infrastrukturökonomie. Das Unternehmen sagt, dass Open-Weight-Modelle mittlerweile für die meisten Produktions-Workloads 15 bis 90 Prozent günstiger laufen als geschlossene Äquivalente und dass die Ära, in der Open Weights aufholen mussten, vorbei ist. Clef wird als Beweis angeführt: ein herunterladbares, unter Apache 2.0 lizenziertes Modell, das einen proprietären Wettbewerber in dessen eigener Benchmark-Kategorie übertrifft und selbst gehostet werden kann.

Was man prüfen sollte, bevor man die Schlagzeile glaubt

Drei Einschränkungen sollte man sich bewusst halten.

Erstens sind die Benchmarks vom Anbieter ausgewählt. BANKING77 ist ein realer und weit verbreiteter Intent-Datensatz, aber eine einzelne Macro-F1-Zahl beschreibt nicht, wie sich ein Modell über eine Produktionsverteilung mit seltenen Klassen, mehrdeutigen Eingaben und adversarialen Formulierungen verhält. Eine unabhängige Evaluierung würde mehr klären, als ein Launch-Post kann.

Zweitens ist Jev-API-Kompatibilität eine Aussage über die Form der Anfrage, nicht über das Verhalten. Ein Drop-in-Endpunkt, der eine andere Konfidenzkalibrierung zurückgibt, kann eine Routing-Richtlinie, die auf das Original abgestimmt ist, trotzdem brechen.

Drittens wird der Vergleich gegen das veröffentlichte Jev gemessen. Typesafe AI hat eigene Releases in Arbeit, und der Abstand zwischen einem Herausforderer und einem Platzhirsch bleibt selten lange unverändert.

Nichts davon entkräftet den beständigeren Punkt. Entscheidungsmodelle existieren, weil Routing, Gating und Klassifizierung einen großen Teil dessen ausmachen, was Agenten-Infrastruktur tatsächlich tut, und sie mit einem Textgenerator zu erledigen, war immer ein unpassender Ansatz. Clef, Span-01 und die neuen Endpunkte in SGLang und llama.cpp konvergieren auf dieselbe Idee: Manche Modellaufrufe sollten eine Zahl statt eines Satzes zurückgeben. Die Frage ist jetzt, welche dieser Implementierungen unter dem Agenten-Loop aller anderen landet und wie lange die Kategorie umkämpft bleibt.