pplx-decider vs Kev: Twee System One-modellen die je al kunt pullen

De nuttige toevalligheid in deze vergelijking is dat je het vanmiddag op je eigen hardware kunt beslechten. pplx-decider, Perplexity's 27B-beslissingsmodel, verscheen op 2026-10-01 zonder aankondiging, met een v1.1-revisie op 2026-10-05, en beide staan in de Ollama-bibliotheek. Kev, Jared Palmers reproductielijn, staat op Ollama sinds v2 op 2026-09-30 uitkwam en bestrijkt 0,5B tot en met 27B. Ze hebben dezelfde aanroepvorm — een toestand plus een lijst met benoemde vragen, één forward pass, een waarschijnlijkheid terug, geen gegenereerde tekst — wat betekent dat dezelfde harness beide kan draaien. Wat verschilt, is alles eronder: hoe de output wordt geproduceerd, wat de auteurs gedocumenteerd hebben, en hoeveel GPU het vergt.

Begin met hetgeen een bake-off überhaupt mogelijk maakt. Geen van beide modellen schrijft tekst. Je overhandigt een document en stelt vragen op naam, waarbij elke vraag zijn antwoordtype aangeeft — een keuze uit 2 tot 255 gelabelde opties, een ja/nee/onbekend-uitlezing, of een score over 2 tot 10 beschreven niveaus. Het antwoord komt binnen als een waarschijnlijkheid, in de volgorde waarin je ze hebt gevraagd. Een ticket met zestig vragen is één enkele doorgang door het model, niet zestig aanroepen.

Hoeveel van elk model neemt eigenlijk de beslissingen

De modelkaart van Kev is expliciet over de constructie ervan, op een manier die zeldzaam is buiten interne documentatie, en de details zijn het lezen waard voordat je een getal uit die kaart vertrouwt. Het 27B-checkpoint is een supervised fine-tune met volledige gewichten op Qwen/Qwen3.8-27B, en vervolgens een gewichtsgemiddelde — 0,85 van het nieuwe model gemengd met 0,15 van v1 in fp32. De kleinere formaten, 0,8B tot en met 9B, worden geleverd als LoRA-adapters op Qwen3.5-bases in plaats van volledige checkpoints.

Het deel dat bepaalt hoe de uitvoer wordt gevormd, staat los van de taal-backbone. Kev heeft een pointer-head — ongeveer 2,6M parameters in fp32, bovenop een 25,6B-backbone om 26B te vormen — die een verborgen toestand omzet in een waarschijnlijkheid over de door jou benoemde opties. pplx-decider doet hetzelfde met een vrijgegeven readout-head van [255, 5120]: 255 opties over een 5.120-brede verborgen toestand, in bf16.

Twee architecturen, één idee: het taalmodel leest, een klein hoofd beslist. Daarom genereert geen van beide proza, en daarom draagt een benchmarkscore van de ene ook niet over naar de andere, zelfs niet wanneer beide tegen hetzelfde referentiemodel worden afgezet.

De enige rechtstreekse confrontatie die is vastgelegd, en waarom je die niet kunt wegstrepen.

Beide projecten rapporteren aan Jev, wat het verleidelijk maakt om ze naast elkaar te leggen. Doe dat niet.

Kevs eigen kaart bevat een rij voor Decision Index 0.2 die Kev-27B v2 op 52,3 zet tegenover 50,2 voor v1, Jev op 54,0 en AutoJev-27B op 50,0. Dat is een zuivere vergelijking binnen dezelfde suite en dezelfde versie, en die zegt dat Kev v2 met ongeveer twee punten is verbeterd en nog steeds achterloopt op Jev.

De kaarten van pplx-decider rapporteren een suite-gewogen totaalscore van 61,56 voor v1.1, tegenover 56,4 voor v1 en 57,9 voor Jev. Op basis van hun eigen cijfers is dat een winst van meer dan vijf punten in één revisie en een voorsprong op Jev van meer dan drie en een half.

Die twee paragrafen kunnen niet van elkaar worden afgetrokken. Verschillende suites, verschillende taakmixen, verschillende weging — en geen van beide projecten publiceert de weging. Wat je kunt zeggen is smaller en toch nuttig: beide bewogen in dezelfde richting in hetzelfde venster, beide deden dat door te veranderen hoe de readout wordt getraind in plaats van door de backbone te verwisselen, en de beweerde voorsprong van pplx-decider op Jev is groter dan het gemeten tekort van Kev. Dat is een reden om pplx-decider te testen, niet een reden om het te geloven.

Slechts één van de twee heeft een onafhankelijke replicatie gekoppeld aan een van zijn cijfers. Kevs Ollama-tags publiceren JevBench-passaantallen per tag — 205 van 231 voor kev:27b-nvfp4, waaronder 86 van 111 op de harde split, tot 146 van 231 voor kev:0.8b — met een expliciete opmerking dat deze 303 niet-beschikbare verzegelde of door een judge beoordeelde taken uitsluiten en geen officiële leaderboardscore zijn. Het is een self-run, maar het is een self-run die je kunt herhalen. Voor pplx-decider bestaat niets vergelijkbaars.

Wat Kev documenteert dat pplx-decider niet doet

• Temperatuur — Kev wordt geleverd met T = 1,32, een 90%-interval van [1,20, 1,45], toegepast bij het laden, dus de waarschijnlijkheden die je eruit krijgt, zijn al geschaald. De kaarten van pplx-decider publiceren helemaal geen temperatuur, wat betekent dat je de kalibratie die je nodig hebt, zelf moet fitten.

• Trainingsrecord — Kev v2 is 129 GPU-uren op 8× H200, één epoch over 145.840 records en 337.130 vragen, labels geproduceerd door GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b en MiMo-V2.6-Pro waarbij geen Jev-uitvoer is gebruikt, en een contaminatiescreening die 6.388 records in 102 evaluatiepartities verwijderde. pplx-decider documenteert een pijplijn gebouwd op Bespoke Labs' Bespoke Nimble met benchmarksubsets die zijn vastgepind op record-ID en checksum, en schrijft de winst van v1.1 toe aan het verwijderen van het causale masker plus toegevoegde trainingsdata — maar publiceert geen recordaantal, geen GPU-uren en geen lijst van labelaars.

• Eerlijke regressierapportage — Kevs kaart toont zijn eigen missers: transfer-v4 daalde met 0,8 punten, CUAD daalde met 1,6, verwachte kalibratiefout op breadth-v1 van 0,015 tegen 0,053 op CUAD, twee tot vier keer slechter dan v1, en het benoemt het selectieoptimisme in zijn eigen evaluatie. De v1.1-tabel van pplx-decider toont dat tools dalen van 79,3 naar 78,88 terwijl elke andere categorie stijgt, en niets in de kaart maakt er een opmerking over.

• Faalmodi — Kevs kaart vermeldt de reikwijdte van de contaminatiescreening en de omstandigheden waaronder de gepubliceerde cijfers tot stand zijn gekomen. De Decider-familie, Mapika's lijn, gaat verder en noemt specifieke invoervormen die hem breken; pplx-decider zwijgt over de kwestie.

Niets hiervan zegt dat pplx-decider slechter is. Documentatie is geen capaciteit — een lab met een lanceerbericht in concept heeft andere prikkels dan een individu dat notities op Hugging Face publiceert. Maar wanneer twee modellen hetzelfde soort resultaat claimen en slechts één ervan je zijn temperatuur vertelt, is degene die het je vertelt degene die je deze maand in productie kunt nemen.

Contextverantwoording, waar de twee het sterkst uiteenlopen.

• Kev — 65.536 tokens aan toestand, plus minstens 8.192 tokens per vraag, met training tot maximaal 32.768. Bij een toestand van 64k bereikt de residente voetafdruk op het hoogtepunt ongeveer 87,1 GB, is de modeltijd 9,4 seconden, 733 ms bij een cachehit, en 21,1 verzoeken per seconde bij één client tegenover 36,4 bij vierenzestig.

• pplx-decider — 8.192 tokens voor tekst en afbeeldingen samen, waarbij te grote inputs worden geweigerd in plaats van afgekapt. De Ollama-build vermeldt een contextvenster van 256K, wat door niets in de repository wordt verklaard en wat niet strookt met de eigen limiet van de kaart.

Dat verschil is het meest bepalende onderscheid tussen de twee voor echte workloads. Kev is gebouwd voor lange states en veel vragen daarover. pplx-decider is een dense 27B met een naar verhouding klein inputbudget, waardoor het richting korte documenten, afbeeldingen en vragen gaat die binnen een paar duizend tokens passen.

• Taal — alleen Engels op beide, op beide als beperking vermeld.

• Vision — pplx-decider accepteert tekst, JSON en afbeeldingen, waarbij vision-tokens ongeveer breedte × hoogte / 1024 kosten en de evaluatieopzet beperkt is tot 512×512. Kev heeft geen vision in de 27B-lijn.

• Ondergrens voor serveren — Kev-27B heeft een GPU van de 80 GB-klasse nodig: 51,3 GB aan bf16-gewichten, ongeveer 65,5 GB resident, 87,1 GB bij een 64k-status, en de server bindt openlijk tenzij KEV_API_KEY is ingesteld. De bf16-gewichten van pplx-decider zijn ongeveer 49 GiB, dus de ondergrens is vergelijkbaar; de gekwantiseerde Ollama-build komt uit op 17 GB, wat een heel andere machine is.

• Treden — Kev bestrijkt 0,5B, 0,6B, 0,8B, 4B, 8B, 9B en 27B, waarbij de kleine formaten als LoRA-adapters dienen. pplx-decider is één formaat, tweemaal herzien.

De bake-off runnen zonder erop te wedden

Beide modellen zijn beschikbaar als lokale gewichten, precies de situatie waarin een routeringslaag zijn plek verdient. OrcaRouter bedient pplx-decider niet en bedient Kev niet — geen van beide staat in de catalogus, en niets hier mag worden opgevat als een bewering dat wij ze hosten. Wat we in deze klasse wél aanbieden, is typesafe/jev-1.13, ontsloten via dezelfde POST /v1/systemone-aanroepvorm tegen $0,042 per miljoen inputtokens, en het is de natuurlijke controlegroep: dezelfde interface, dezelfde vraagtypen, geen eigen GPU.

Dat maakt een drievoudige bake-off goedkoop op te zetten. Zet een lokale pplx-decider en een lokale Kev achter dezelfde harness tegen een gerouteerde typesafe/jev-1.13, scoor alle drie op je eigen documenten, en laat de onenigheid tussen hen je vertellen waar je drempels daadwerkelijk liggen. Automatische failover is in die opzet belangrijker dan gewoonlijk, omdat een lokale 27B op één kaart het minst betrouwbare onderdeel in de keten is; het routeren van de fallback via één API voor 200+ modellen — providerlijstprijs doorgegeven met 0% opslag — voorkomt dat het experiment in een storing verandert. En wanneer een model als pplx-decider uiteindelijk een gehost endpoint bereikt, wordt het gedraaid door dezelfde key die de controlearm draait, zonder tweede contract en zonder codewijziging.

Wat zou het antwoord veranderen

Vier dingen, en ze zijn allemaal controleerbaar in plaats van een kwestie van smaak.

Als pplx-decider een inferentieprovider bereikt, wordt zijn niet-geverifieerde benchmarktabel een kwestie van prijs versus latentie, en doet de documentatiekloof er niet meer toe — je zou betalen voor een gehoste uitlezing, niet voor het onderhouden daarvan. Als een onafhankelijke partij de JevBench-cijfers van een van beide modellen reproduceert op een gepubliceerde harness, beperkt de hele vergelijking zich tot één suite in plaats van twee incompatibele suites.

Als Kevs gedocumenteerde ECE-zwakte op CUAD met een refit in plaats van een retrain verhelpbaar blijkt, verdwijnt het calibratieargument ertegen grotendeels, omdat Kev zijn temperatuur al meelevert en zijn faalmodi bekende grootheden zijn. En als je een beslissingsmodel op één kaart in plaats van twee nodig hebt, is de 17 GB gekwantiseerde build van pplx-decider hier de enige optie — niet omdat die beter is, maar omdat die past waar een 27B op bf16 dat niet doet.

Totdat een van die dingen gebeurt, is de praktische inschatting weinig glamoureus. Kev is degene wiens cijfers je vandaag kunt reproduceren en van wie je erop kunt vertrouwen dat de kalibratie gedocumenteerd is; pplx-decider is degene met het hogere geclaimde plafond en het zwakkere papieren spoor. Kies de eerste als je deze maand uitbrengt. Neem de tweede op in hetzelfde testharnas als je het soort team bent dat liever een stille release meet dan op een lanceringsbericht wacht.

Het routeren van de fallback via de lijstprijs van de provider doorgegeven met 0% opslag voorkomt dat een drievoudige bake-off in een storing verandert wanneer de lokale checkpoint het minst betrouwbare onderdeel in de keten is.

Een bake-off met drie deelnemers is ook een goed moment om te vragen wat er in deze categorie al is misgegaan: de gedocumenteerde AI-incidenten en agentfouten waarbij beslissingsmodellen betrokken zijn, zijn verzameld in het OrcaRouter AI Incident Archive, waarbij elke vermelding zijn eigen bronnen, ernst, betrouwbaarheidsgraad en markering voor betwisting bevat.