pplx-decider-flash: Perplexitys stiller 4B-Richter, aus dem Repo gelesen

Perplexity lud pplx-decider-flash-v1.2 am 15. Oktober 2026 um 16:57 UTC auf Hugging Face hoch, rund neun Stunden nachdem es pplx-decider-v1.2 hochgeladen hatte, das große Entscheidungsmodell, das das Marketing 27B nennt und die Modellkarte 26B. Wir konnten keinen Veröffentlichungsbeitrag im Firmenblog finden. Was folgte, war ein Thread vom Entwicklerkonto auf X, ein Abschnitt in der Dokumentation der Decisions API und drei Tage später eine GGUF-Konvertierung. Das ist der gesamte öffentliche Nachweis, und er reicht aus, um das Modell präzise zu beschreiben, aber nicht, um Ihnen zu sagen, ob es mit Ihren Daten gut funktioniert.

Im Folgenden werden die drei Dinge getrennt, die Menschen üblicherweise miteinander vermischen: was das Repository beweist, was in der Dokumentation des Anbieters steht und was niemand außerhalb von Perplexity verifiziert hat. Die letzte Kategorie ist größer als die ersten beiden.

Was tatsächlich ausgeliefert wurde und an welchem Tag

Die Zeitachse des Repositories ist eindeutig. Perplexity erstellte pplx-decider-v1-27b am 1. Oktober 2026, pplx-decider-v1.1-27b am 5. Oktober, beide v1.2-Checkpoints am 15. Oktober und pplx-decider-flash-gguf-v1.2 am 18. Oktober. Der Flash-Checkpoint war der zweite Upload an diesem Tag, was die übliche Form einer gekoppelten Veröffentlichung ist: zuerst das Flaggschiff, dahinter das destillierte kleine Geschwistermodell, sodass beide unter derselben Ankündigung erscheinen.

Diese Reihenfolge ist für die Einordnung wichtig. Dies ist kein geleaktes Modell und kein verirrtes Repository, das seiner Formalitäten vorausgeeilt ist. Es ist eine koordinierte Veröffentlichung mit bewusst geringer öffentlicher Präsenz – ein Entwickler-Thread statt eines Launch-Essays, Dokumentation statt eines Benchmark-Hubs. Die Hugging-Face-API meldet mit Stand 4. November 4.667 Downloads für den Basis-Checkpoint und 9.428 für die GGUF-Konvertierung sowie 63 Likes. Download-Zahlen auf Hugging Face sind ein schwaches Signal: Sie zählen Anfragen, nicht einzelne Nutzer, und Mirror-Traffic bläht sie auf. Sie passen zu einem echten, aber bescheidenen Open-Weights-Publikum, nicht zu einem viralen Drop.

Was das Repository Ihnen verrät

Die Modellkarte ist für eine Anbieterveröffentlichung ungewöhnlich technisch, und das meiste, was sich daraus erfahren lässt, stammt aus ihr.

• Backbone — Qwen3.5-4B, mit einem separaten BF16-Readout-Head der Form [255, 2560] statt eines Language-Model-Head über das gesamte Vokabular. Dies ist ein Entscheidungs-Checkpoint, kein Chat-Modell mit einem Klassifikations-Wrapper.

• Größe — 25 Dateien mit insgesamt etwa 9 GiB in BF16, was Sie benötigen, um die Gewichte zu halten; der Arbeitsspeicher kommt noch obendrauf.

• Parameteranzahl — Die API-Dokumentation nennt 4B, die Kopfzeile der Modellkarte gibt 5B in BF16 an, und ein Drittanbieter-Index führt 4,5B auf. Das Backbone ist ein 4B-Modell. Betrachten Sie „4B-Klasse“ als die ehrliche Beschreibung und zitieren Sie keine einzelne Zahl, als wäre sie gemessen worden.

• Attention — Full-Attention-Schichten laufen nicht kausal über die gesamte Anfrage, während Linear-Attention-Schichten kausal bleiben. Das ist das Detail, das Ihnen zum Verhängnis wird: Ein standardmäßiger kausaler Serving-Stack erzeugt andere Zahlen, und für v1.1 geschriebene Prompts lassen sich nicht übernehmen.

• Ausleseposition — der Head feuert bei jedem <|fim_suffix|>-Marker ab statt beim letzten Token; so kann ein einzelner Forward-Pass mehrere Fragen gegen einen Zustand bewerten.

• Kontext — max_length beträgt standardmäßig 262.144 Token, passend zum Backbone. Beim Training wurden Sequenzen von bis zu etwa 32.000 Token verwendet, und in der Model Card wird ausdrücklich darauf hingewiesen, dass längere Eingaben unterstützt, aber weniger validiert sind.

• Bilder — begrenzt auf 1,6 Megapixel (1.638.400 Pixel), mindestens 65.536 Pixel, wobei ein 1,6-MP-Bild etwa 1.600 Positionen beansprucht.

• Kalibrierung — eine gespeicherte Temperatur von 1,554. Auf einem Entwicklungsdatensatz mit 1.497 Fragen meldet die Karte 88,8 % Genauigkeit, einen erwarteten Kalibrierungsfehler von 0,021 und einen Brier-Score von 0,163; ohne die Temperatur steigt der Fehler auf 0,057. Ein Anbieter, der seine eigenen Kalibrierungswerte veröffentlicht und die Kosten für deren Nichtbeachtung nennt, teilt damit etwas Reales über den vorgesehenen Einsatzzweck mit.

Eine Zeile in der Karte übersteht den Kontakt mit der API nicht. Sie besagt, dass das Repository privat sei und ein Token mit Zugriff benötige. Die Hugging Face API gibt gated: false und private: false zurück, und die Gewichte lassen sich ohne Zugriffsanfrage herunterladen. Eine veraltete Zeile in einer Karte ist eine Kleinigkeit, aber es ist die Art von Kleinigkeit, die einem sagt, dass die Karte vor der Veröffentlichung geschrieben und danach nicht noch einmal gelesen wurde.

Was die API-Dokumentation ergänzt

Die Preisgestaltung ist der Punkt, an dem das Flash-Argument beginnt. In der Decisions API pplx-decider-flash-v1.2 kostet 0,01 $ pro Million Eingabe-Tokens. Ausgabe-Tokens sind kostenlos, und es gibt keine Gebühr pro Anfrage, da es keine Ausgabe-Tokens im üblichen Sinne gibt – das Modell liefert Wahrscheinlichkeiten und einen erwarteten Score, und die Dokumentation zählt jede Frage für die Abrechnung als ein Ausgabe-Token.

Dieselbe Seite legt den Betriebsbereich fest:

• Alias — pplx-decider-flash-latest folgt der neuesten Version, daher kann ein Schwellenwert, den du letzte Woche angepasst hast, nach einem Update stillschweigend auf ein anderes Modell verweisen. Fixiere die versionierte ID überall dort, wo es darauf ankommt.

• Ratenlimits — 4.000.000 Token pro Minute und 240.000.000 pro Stunde, mit einer Obergrenze von 10 Anfragen pro Sekunde, die auf Organisationsebene von beiden Entscheidungsmodellen gemeinsam genutzt wird.

• Fragetypen — noul gibt P(yes) von 0 bis 1 zurück, choice gibt Wahrscheinlichkeiten über bis zu 255 Optionen zurück, und score gibt eine Verteilung über Rubrikstufen zurück.

• Fragenbudget — die Dokumentation empfiehlt eine Frage pro Anfrage. Das ist kein Stilhinweis; es ist der Unterschied zwischen dem Preis, der Ihnen genannt wurde, und dem Preis, den Sie zahlen.

Die Abrechnungsregel, die die Empfehlung umkehrt

Das 27B-Modell beantwortet jede Frage in einer Anfrage in einem einzigen gruppierten Durchlauf und berechnet den Zustand nur einmal. Flash beantwortet jede Frage unabhängig, ohne die anderen zu sehen, und berechnet den Zustand für jede Frage erneut. Die Dokumentation enthält das durchgerechnete Beispiel: Drei Fragen gegen einen Zustand mit 10.000 Token kosten auf Flash etwa 30.000 Eingabe-Token.

Rechnen wir nach. Eine Frage auf einem Zustand mit 10.000 Tokens kostet 0,0001 $ bei Flash und 0,0002 $ beim 27B. Zwei Fragen kosten 0,0002 $ bei Flash und 0,0002 $ beim größeren Modell — ein totes Rennen. Drei Fragen kosten 0,0003 $ bei Flash und 0,0002 $ beim 27B. Der Schnittpunkt liegt bei zwei Fragen pro Zustand. Perplexitys eigene Dokumentation sagt, dass das größere Modell bei drei oder mehr Fragen „üblicherweise weniger als Flash kostet“; der genaue Punkt liegt eine Frage früher, und er gilt bei jedem Listenpreis, bei dem Flash genau die Hälfte des 27B-Tarifs beträgt.

Das ist die mit Abstand nützlichste Sache in diesem Release, und sie ist leicht zu übersehen, weil die Schlagzeile ein Rabatt von 50 % ist. Ein 4B-Modell zum halben Preis ist nur günstiger, solange man ihm jeweils nur eine Sache auf einmal abfragt.

Die Zahl, der man misstrauen sollte

Perplexity meldet für beide Modelle Werte im Decision Index 0.3. Flash erzielt 60,05 bei einer Frage pro Anfrage und 58,88 bei gemeinsamen Anfragen; das 27B-Modell erzielt 68,09 bei gemeinsamen Anfragen und 67,75 bei einer Frage pro Anfrage. Im Vision Decision Index liegt Flash bei 72,53 gegen 77,43.

Die Aufteilung nach Kategorien ist aussagekräftiger als die Schlagzeile, weil sie zeigt, wo das 4B nachgibt. Bei den Joint-Run-Zahlen von Flash gegenüber den Joint-Run-Zahlen des 27B:

• Wissen — 42,0 vs. 56,3. Dies ist die größte Lücke, 14,3 Punkte, und diejenige, die entscheidet, ob das Modell überhaupt mit offenem Weltwissen umgehen kann.

• Sprache — 63,3 vs. 72,8.

• Abruf — 64,8 vs. 68,4. Die geringste Differenz mit 3,6 Punkten, was zur beabsichtigten Aufgabe passt: Zu beurteilen, ob eine Passage eine Frage beantwortet, ist eine leichtere Aufgabe, als die Antwort zu kennen.

• Werkzeuge — 76,7 vs. 84,4.

• Künste — 46,8 vs. 56,2.

• Gesamt — 58.88 vs 68.09.

Jede einzelne dieser Zahlen stammt aus einem Benchmark, den Perplexity pflegt. Die 27B-Karte – der Teacher in dieser Destillation – ist ungewöhnlich offen über die Trainingsseite: Ein Teil der Arbeit, heißt es, brachte das Modell „in domain“ für einige Decision-Index-Aufgaben, indem die offiziellen Trainings-Splits einbezogen wurden, die mehrere Benchmarks mitliefern, wobei die Splits „gegen die Testsätze decontaminiert“ wurden, damit der Vergleich fair bleibt. Das ist eine sorgfältigere Position, als die Berichterstattung rund um die Veröffentlichung nahelegte, und sie lässt die Rangliste weiterhin in den Händen des Anbieters. Kein Dritter hat die Split-Disziplin geprüft, und niemand hat die Zahlen reproduziert.

Es gibt eine kleinere Merkwürdigkeit in den eigenen Zahlen des Anbieters, die gegen das Marketing spricht. Flash schneidet besser ab, wenn es eine Frage nach der anderen beantwortet – 60,05 gegenüber 58,88. Die Gruppierung schadet dem 4B insgesamt, obwohl sie bei eng gekoppelten Aufgaben vom Typ „Alle zutreffenden auswählen“ hilft, was genau der Dokumentation entspricht. Das Modell wird mit der Geschwindigkeit bei gebündelten Anfragen beworben und schneidet ohne diese besser ab.

Was noch nicht zu wissen ist

Die Lücken sind konkret, und sie sind der Grund dafür, dass dies ein Was-wir-wissen-Beitrag ist und keine Rezension.

• Kein unabhängiger Benchmark. Außerhalb von Perplexity hat niemand Reproduktionen des Decision Index oder einen Direktvergleich auf einer neutralen Testumgebung veröffentlicht.

• Kein Service-Level für Latenz. Die einzige Geschwindigkeitsangabe, die der Anbieter veröffentlicht, ist ein Dokumentationstest vom 19. Oktober, bei dem rund 248.000 Eingabe-Tokens auf Flash 16 Sekunden gegenüber 53 Sekunden auf dem 27B dauerten. Das ist eine anbieterseitige Messung ohne Angabe von Hardware oder Perzentil.

• Keine mehrsprachige Evaluierung. Die Karte und die Dokumentation beschreiben Text und Bilder; keine von beiden gibt Genauigkeit außerhalb des Englischen an.

• Kein veröffentlichtes Trainingsdatenvolumen. Die Modellkarte besagt, dass Flash aus dem 27B-Modell anhand der Trainingsanfragen des größeren Modells destilliert wurde, wobei der Student die vollständigen Wahrscheinlichkeitsverteilungen des Lehrers und nicht nur dessen Antworten lernte, und dass mehrere Läufe durch Gewichtsmittelung kombiniert wurden. Es wird nicht angegeben, wie viele Daten dafür verwendet wurden, woher sie stammten oder wo der Cutoff liegt.

• Keine veröffentlichte Fehleranalyse. Für ein Modell, dessen Ausgabe eine Wahrscheinlichkeit ist, auf die Sie einen Schwellenwert anwenden, gibt es keine Aufschlüsselung darüber, wo es fehlschlägt – nach Fragetyp, nach Optionsanzahl, nach Sprache oder nach Bildinhalt.

Wo ein solches Modell im Stack einzuordnen ist

Es lohnt sich, klarzustellen, wofür Flash gedacht ist, denn der Name weckt eine falsche Erwartung. Es schreibt nichts. Man übergibt ihm einen Zustand – Text, JSON, Bilder – und eine oder mehrere typisierte Fragen, und es gibt eine Wahrscheinlichkeit oder eine Verteilung zurück, auf die Ihr Code Schwellenwerte anwendet. Die natürliche Architektur ist ein günstiges Gate vor etwas Teurem: die Anfrage klassifizieren, entscheiden, ob abgerufen werden soll, ein Tool auswählen und dann generieren.

Dieses Gate ersetzt nicht die Generierungsschicht, und hier ist Routing entscheidend. OrcaRouter stellt über 200 Generierungsmodelle hinter einem einzigen API-Schlüssel bereit – ohne Aufschlag auf die Listenpreise der Anbieter, sodass eine Preissenkung eines vorgelagerten Anbieters noch am selben Tag live ist, statt auf die Tabellenkalkulation eines Wiederverkäufers zu warten. Wenn das Gate falsch klassifiziert, verhindert automatisches Failover, dass die Anfrage am nächsten Hop scheitert. Was wir nicht tun, ist, pplx-decider-flash zu hosten: Es ist nicht in unserem Katalog, und der ehrliche Weg, es heute zu betreiben, ist die API des Anbieters selbst oder die Apache-2.0-Gewichte auf der eigenen GPU.

Die Self-Hosting-Rechnung ist plausibel, wenn man die Hardware bereits hat. Rund 9 GiB BF16-Gewichte passen auf eine 16-GB-Consumer-Karte, und die Berichterstattung über das Release wiederholte eine Aussage des CEO von Perplexity, dass Flash auf einem M4 Mac mit 16 GB Arbeitsspeicher läuft. Keine veröffentlichten Durchsatzahlen stützen das, und die nichtkausale Attention bedeutet, dass man es nicht einfach in einen standardmäßigen kausalen Inferenzserver stecken und die Leistungswerte der Karte erwarten kann.

Was würde diese Einschätzung ändern?

Vier Dinge, nach Nützlichkeit geordnet. Eine neutrale Reproduktion des Decision Index 0.3, die entweder die 60,05 bestätigt oder die Abweichung erklärt. Eine veröffentlichte Latenzverteilung aus der API statt eines einzelnen Dokumentationstests. Belege zu mehrsprachigen Eingaben, denn ein 4B-Klassifikator ist genau die Art von Modell, auf das Teams nicht-englischen Traffic ohne Prüfung lenken werden. Und ein technischer Beitrag aus erster Hand, der die Trainingsdaten hinter dieser Destillation beschreibt.

Bis dahin ist die verteidigbare Position eng und nützlich: pplx-decider-flash-v1.2 ist ein echtes, herunterladbares Entscheidungsmodell der 4B-Klasse unter Apache-2.0 mit einem veröffentlichten Preis, einer dokumentierten Kalibrierungstemperatur und einer Abrechnungsregel, die es in dem Moment teurer macht als sein großes Geschwistermodell, in dem du Fragen bündelst. Alles darüber hinaus ist Perplexitys eigene Rangliste, und du solltest es als Hypothese betrachten, die an deinen gelabelten Daten zu testen ist, statt als Ergebnis.