pplx-decider vs Kev: Zwei System-1-Modelle, die du bereits pullen kannst

Der nützliche Zufall in diesem Vergleich ist, dass du ihn noch heute Nachmittag auf deiner eigenen Hardware klären kannst. pplx-decider, Perplexitys 27B-Entscheidungsmodell, erschien am 2026-10-01 ohne zugehörige Ankündigung und mit einer v1.1-Revision am 2026-10-05, und beide sind in der Ollama-Bibliothek. Kev, Jared Palmers Reproduktionslinie, ist seit dem Erscheinen von v2 am 2026-09-30 auf Ollama und deckt 0,5B bis 27B ab. Sie sprechen dieselbe Aufrufform — ein Zustand plus eine Liste benannter Fragen, ein Vorwärtsdurchlauf, eine Wahrscheinlichkeit zurück, kein generierter Text — was bedeutet, dass dieselbe Harness beide ausführen kann. Was sich unterscheidet, ist alles darunter: wie die Ausgabe erzeugt wird, was die Autoren dokumentiert haben und wie viel GPU es braucht.

Beginne mit dem, was einen Bake-off überhaupt erst möglich macht. Keines der beiden Modelle schreibt Text. Du übergibst ein Dokument und stellst Fragen anhand ihres Namens, wobei jede Frage ihren Antworttyp angibt – eine Auswahl aus 2 bis 255 beschrifteten Optionen, eine Ja/Nein/Unbekannt-Ausgabe oder eine Bewertung über 2 bis 10 beschriebene Stufen. Die Antwort kommt als Wahrscheinlichkeit an, und zwar in der Reihenfolge deiner Fragen. Ein Ticket mit sechzig Fragen ist ein einziger Durchlauf durch das Modell, nicht sechzig Aufrufe.

Wie viel von jedem Modell entscheidet tatsächlich?

Kevs Modellkarte gibt auf eine Weise explizit Auskunft über ihre Konstruktion, wie sie außerhalb interner Berichte selten ist, und es lohnt sich, die Details zu lesen, bevor man einer darin genannten Zahl vertraut. Der 27B-Checkpoint ist ein vollgewichtiges überwachtes Fine-Tuning auf Qwen/Qwen3.8-27B, danach ein Gewichtsmittel – 0,85 des neuen Modells vermischt mit 0,15 von v1 in fp32. Die kleineren Größen, 0,8B bis 9B, werden als LoRA-Adapter auf Qwen3.5-Basis ausgeliefert, nicht als vollständige Checkpoints.

Der Teil, der entscheidet, wie die Ausgabe geformt wird, ist vom Sprach-Backbone getrennt. Kev verfügt über einen Pointer-Head – etwa 2,6 Mio. Parameter in fp32, der auf einem 25,6B-Backbone sitzt und so 26B ergibt –, der einen Hidden State in eine Wahrscheinlichkeit über deine benannten Optionen umwandelt. pplx-decider erledigt dieselbe Aufgabe mit einem veröffentlichten Readout-Head von [255, 5120]: 255 Optionen über einen 5.120 breiten Hidden State, in bf16.

Zwei Architekturen, eine Idee: Das Sprachmodell liest, ein kleiner Kopf entscheidet. Deshalb erzeugt keine von beiden Prosa, und deshalb lässt sich ein Benchmark-Ergebnis der einen nicht auf die andere übertragen, selbst wenn beide gegen dasselbe Referenzmodell angegeben werden.

Das einzige direkte Duell in den Aufzeichnungen – und warum man es nicht abziehen kann

Beide Projekte berichten relativ zu Jev, was es verlockend macht, sie nebeneinanderzustellen. Tun Sie das nicht.

Auf Kevs eigener Karte gibt es eine Zeile im Decision Index 0.2, die Kev-27B v2 mit 52,3 gegenüber 50,2 für v1, Jev mit 54,0 und AutoJev-27B mit 50,0 aufführt. Das ist ein sauberer Vergleich mit derselben Suite und derselben Version, und er besagt, dass sich Kev v2 um etwa zwei Punkte verbessert hat und weiterhin hinter Jev zurückliegt.

Die Karten von pplx-decider melden für v1.1 einen suite-gewichteten Gesamtwert von 61,56 gegenüber 56,4 für v1 und 57,9 für Jev. Nach ihren eigenen Zahlen ist das ein Zuwachs von mehr als fünf Punkten in einer Revision und ein Vorsprung vor Jev von mehr als dreieinhalb.

Diese beiden Absätze lassen sich nicht voneinander subtrahieren. Unterschiedliche Suiten, unterschiedliche Aufgabenmischungen, unterschiedliche Gewichtung – und keines der Projekte veröffentlicht die Gewichtung. Was man sagen kann, ist enger gefasst und dennoch nützlich: Beide bewegten sich im selben Zeitfenster in dieselbe Richtung, beide erreichten dies, indem sie änderten, wie das Readout trainiert wird, statt den Backbone auszutauschen, und der von pplx-decider behauptete Vorsprung gegenüber Jev ist größer als Kevs gemessener Rückstand. Das ist ein Grund, pplx-decider zu testen, kein Grund, daran zu glauben.

Nur eine der beiden hat eine unabhängige Replikation, die an irgendeine ihrer Zahlen geknüpft ist. Kevs Ollama-Tags veröffentlichen JevBench-Pass-Zahlen für die einzelnen Tags – 205 von 231 für kev:27b-nvfp4, darunter 86 von 111 im schwierigen Split, bis hinunter zu 146 von 231 für kev:0.8b – mit einem ausdrücklichen Hinweis, dass diese 303 nicht verfügbare, versiegelte oder von Judges bewertete Aufgaben ausschließen und keine offizielle Leaderboard-Punktzahl sind. Es ist zwar ein selbst durchgeführter Lauf, aber einer, den man wiederholen kann. Für pplx-decider existiert nichts Vergleichbares.

Was Kev dokumentiert, was pplx-decider nicht dokumentiert.

• Temperatur — Kev wird mit T = 1.32 ausgeliefert, einem 90%-Intervall von [1.20, 1.45], angewendet beim Laden, sodass die Wahrscheinlichkeiten, die du erhältst, bereits skaliert sind. Die Karten von pplx-decider geben überhaupt keine Temperatur an, was bedeutet, dass du die Kalibrierung, die du benötigst, selbst vornehmen musst.

Trainingsprotokoll — Kev v2 umfasst 129 GPU-Stunden auf 8× H200, eine Epoche über 145.840 Datensätze und 337.130 Fragen, Labels erzeugt von GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b und MiMo-V2.6-Pro, wobei keine Jev-Ausgaben verwendet wurden, sowie einen Kontaminationsfilter, der 6.388 Datensätze über 102 Evaluierungspartitionen entfernte. pplx-decider dokumentiert eine Pipeline, die auf Bespoke Labs' Bespoke Nimble aufbaut, mit Benchmark-Teilmengen, die per Datensatz-ID und Prüfsumme fixiert sind, und schreibt die Verbesserungen von v1.1 dem Entfernen der kausalen Maske plus zusätzlichen Trainingsdaten zu — veröffentlicht aber weder eine Datensatzanzahl noch GPU-Stunden noch eine Liste der Labeler.

• Ehrliche Regressionsberichterstattung — Kevs Karte druckt ihre eigenen Fehlschläge ab: transfer-v4 fiel um 0,8 Punkte, CUAD um 1,6; der erwartete Kalibrierungsfehler bei breadth-v1 liegt bei 0,015 gegenüber 0,053 bei CUAD, zwei- bis viermal schlechter als v1, und sie benennt den Auswahloptimismus in ihrer eigenen Evaluierung. Die v1.1-Tabelle von pplx-decider zeigt, dass Tools von 79,3 auf 78,88 zurückgehen, während jede andere Kategorie steigt, und nichts in der Karte erwähnt das.

• Fehlermodi — Kevs Karte listet den Umfang des Kontaminations-Screenings und die Bedingungen auf, unter denen die veröffentlichten Zahlen erzeugt wurden. Die Decider-Familie, Mapikas Produktlinie, geht noch weiter und nennt bestimmte Eingabeformen, die es brechen; pplx-decider schweigt zu der Frage.

Nichts davon besagt, dass pplx-decider schlechter ist. Dokumentation ist keine Fähigkeit – ein Labor mit einem Startbeitrag im Entwurf hat andere Anreize als eine Einzelperson, die Notizen auf Hugging Face veröffentlicht. Aber wenn zwei Modelle dieselbe Klasse von Ergebnis beanspruchen und nur eines von ihnen dir seine Temperatur mitteilt, dann ist dasjenige, das es dir mitteilt, dasjenige, das du diesen Monat in Produktion bringen kannst.

Kontextabrechnung, was der Punkt ist, an dem die beiden am stärksten auseinandergehen.

• Kev — 65.536 Tokens Zustand, plus mindestens 8.192 Tokens pro Frage, mit Training bei bis zu 32.768. Bei einem 64k-Zustand erreicht die residente Speicherbelegung im Spitzenfall etwa 87,1 GB, Modellzeit 9,4 Sekunden, 733 ms bei einem Cache-Treffer und 21,1 Anfragen pro Sekunde bei einem einzelnen Client gegenüber 36,4 bei vierundsechzig.

• pplx-decider — 8.192 Tokens für Text und Bilder zusammen, wobei zu große Eingaben abgelehnt statt gekürzt werden. Der Ollama-Build gibt ein Kontextfenster von 256K an, wofür es im Repository keine Erklärung gibt und was sich nicht mit dem eigenen Limit der Karte vereinbaren lässt.

Diese Lücke ist der mit Abstand folgenreichste Unterschied zwischen den beiden bei realen Arbeitslasten. Kev ist für lange Zustände und viele Fragen dazu ausgelegt. pplx-decider ist ein dichtes 27B-Modell mit einem vergleichsweise kleinen Eingabebudget, was es in Richtung kurzer Dokumente, Bilder und Anfragen drängt, die in ein paar tausend Tokens passen.

• Sprache — bei beiden nur Englisch, bei beiden als Einschränkung angegeben.

• Vision — pplx-decider nimmt Text, JSON und Bilder entgegen, wobei Vision-Tokens ungefähr Breite × Höhe / 1024 kosten und ein Evaluierungs-Setup auf 512×512 begrenzt ist. Kev hat in der 27B-Reihe keine Vision.

• Serving-Mindestanforderung — Kev-27B braucht eine GPU der 80-GB-Klasse: 51,3 GB bf16-Gewichte, etwa 65,5 GB resident, 87,1 GB bei einem 64k-Zustand, und sein Server bindet offen, sofern KEV_API_KEY nicht gesetzt ist. Die bf16-Gewichte von pplx-decider liegen bei rund 49 GiB, die Mindestanforderung ist also ähnlich; der quantisierte Ollama-Build landet bei 17 GB, was eine ganz andere Maschine ist.

• Stufen — Kev umfasst 0,5B, 0,6B, 0,8B, 4B, 8B, 9B und 27B, wobei die kleinen Größen als LoRA-Adapter dienen. pplx-decider ist eine Größe, zweimal überarbeitet.

Den Bake-off durchführen, ohne darauf zu wetten

Beide Modelle sind als lokale Gewichte erreichbar, und genau das ist die Situation, in der sich eine Routing-Schicht bezahlt macht. OrcaRouter bedient pplx-decider nicht und bedient Kev nicht – keines von beiden steht im Katalog, und nichts hier sollte als Behauptung gelesen werden, dass wir sie hosten. Was wir in dieser Klasse tatsächlich führen, ist typesafe/jev-1.13, verfügbar über dieselbe Aufrufform POST /v1/systemone zu 0,042 $ pro Million Eingabe-Tokens, und es ist der natürliche Kontrollarm: dieselbe Schnittstelle, dieselben Fragetypen, keine eigene GPU.

Dadurch lässt sich ein Drei-Wege-Bake-off günstig aufsetzen. Setzen Sie einen lokalen pplx-decider und einen lokalen Kev hinter denselben Harness gegen einen gerouteten typesafe/jev-1.13, bewerten Sie alle drei anhand Ihrer eigenen Dokumente und lassen Sie sich von der Uneinigkeit zwischen ihnen zeigen, wo Ihre Schwellenwerte tatsächlich liegen. Automatisches Failover ist in dieser Anordnung wichtiger als sonst, denn ein lokales 27B auf einer einzelnen Karte ist die unzuverlässigste Komponente in der Kette; das Fallback über eine API für 200+ Modelle zu routen – Listenpreis des Anbieters mit 0 % Aufschlag durchgereicht – verhindert, dass das Experiment zu einem Ausfall wird. Und wenn ein Modell wie pplx-decider irgendwann einen gehosteten Endpoint erreicht, läuft es mit demselben Schlüssel, der den Kontrollarm betreibt, ohne zweiten Vertrag und ohne Codeänderung.

Was würde die Antwort ändern?

Vier Dinge, und alle davon sind überprüfbar und nicht Geschmackssache.

Wenn pplx-decider einen Inferenzanbieter erreicht, wird seine unbestätigte Benchmark-Tabelle zu einer Frage von Preis versus Latenz, und die Dokumentationslücke ist nicht mehr relevant — man würde für eine gehostete Auslesung bezahlen, nicht für deren Pflege. Wenn eine unabhängige Partei die JevBench-Zahlen eines der beiden Modelle auf einer veröffentlichten Harness reproduziert, verengt sich der ganze Vergleich auf eine einzige Suite statt auf zwei inkompatible.

Wenn sich Kevs dokumentierte ECE-Schwäche bei CUAD mit einem Refit statt einem Retrain beheben lässt, verschwindet das Kalibrierungsargument dagegen weitgehend, denn Kev liefert seine Temperatur bereits mit und seine Fehlermodi sind bekannte Größen. Und wenn Sie ein Entscheidungsmodell auf einer Karte statt auf zwei benötigen, ist der quantisierte 17-GB-Build von pplx-decider hier die einzige Option – nicht weil er besser ist, sondern weil er passt, wo ein 27B-Modell bei bf16 nicht passt.

Bis eines davon eintritt, ist die praktische Einschätzung wenig glamourös. Kev ist derjenige, dessen Zahlen man heute reproduzieren kann und dessen Kalibrierung man getrost als dokumentiert voraussetzen kann; pplx-decider ist derjenige mit der besseren behaupteten Obergrenze und der schwächeren Dokumentationsspur. Nimm den ersten, wenn du diesen Monat auslieferst. Zieh den zweiten in dasselbe Harness, wenn du zu der Art Team gehörst, die lieber ein stilles Release misst, als auf einen Launch-Post zu warten.

Das Leiten des Fallbacks über den mit 0 % Aufschlag durchgereichten Listenpreis des Anbieters verhindert, dass ein dreiseitiger Vergleichstest zu einem Ausfall wird, wenn der lokale Checkpoint die unzuverlässigste Komponente in der Kette ist.

Ein dreifacher Bake-off ist ebenfalls ein passender Moment, um zu fragen, was in dieser Klasse bereits fehlgeschlagen ist: Die dokumentierten KI-Vorfälle und Agenten-Ausfälle im Zusammenhang mit Entscheidungsmodellen sind gesammelt im OrcaRouter AI Incident Archive, wo jeder Eintrag seine eigenen Quellen, den Schweregrad, die Konfidenzstufe und eine Kennzeichnung als umstritten trägt.