pplx-decider vs Kev : deux modèles Two System One que vous pouvez déjà pull

L’accident utile dans cette confrontation, c’est que vous pouvez la régler sur votre propre matériel cet après-midi. pplx-decider, le modèle de décision 27B de Perplexity, est apparu le 2026-10-01 sans annonce, avec une révision v1.1 le 2026-10-05, et les deux sont sur la bibliothèque Ollama. Kev, la ligne de reproduction de Jared Palmer, est présent sur Ollama depuis la sortie de la v2 le 2026-09-30 et couvre de 0,5B à 27B. Ils parlent la même forme d’appel — un état plus une liste de questions nommées, une passe avant, une probabilité en retour, aucun texte généré — ce qui signifie que le même harnais peut exécuter les deux. Ce qui diffère, c’est tout ce qui se trouve en dessous : la manière dont la sortie est produite, ce que les auteurs ont documenté et la quantité de GPU nécessaire.

Commencez par ce qui rend un bake-off possible. Aucun des deux modèles n’écrit de texte. Vous remettez un document et posez des questions par nom, chaque question déclarant son type de réponse — un choix parmi 2 à 255 options étiquetées, une lecture oui/non/inconnu, ou un score sur 2 à 10 niveaux décrits. La réponse arrive sous forme de probabilité, dans l’ordre de vos questions. Un ticket de soixante questions est un seul passage sur le modèle, pas soixante appels.

Quelle part de chaque modèle prend réellement la décision ?

La fiche de Kev détaille sa construction avec une précision rare en dehors des documents internes, et ces détails valent la peine d’être lus avant de faire confiance à un chiffre qui en est issu. Le checkpoint 27B est un fine-tuning supervisé à poids complets sur Qwen/Qwen3.8-27B, puis une moyenne de poids — 0,85 du nouveau modèle mélangé à 0,15 de la v1 en fp32. Les tailles plus petites, de 0,8B à 9B, sont livrées sous forme d’adaptateurs LoRA sur des bases Qwen3.5 plutôt que sous forme de checkpoints complets.

La partie qui décide de la forme de la sortie est séparée du backbone linguistique. Kev porte une tête de pointeur — environ 2,6 M de paramètres en fp32, posée au-dessus d’un backbone de 25,6 B pour atteindre 26 B — qui transforme un état caché en une probabilité sur vos options nommées. pplx-decider fait le même travail avec une tête de lecture publiée de [255, 5120] : 255 options sur un état caché de largeur 5 120, en bf16.

Deux architectures, une même idée : le modèle de langage lit, une petite tête décide. C’est pourquoi ni l’une ni l’autre ne génère de la prose, et c’est aussi pourquoi le score d’un benchmark obtenu par l’une ne se transfère pas à l’autre, même lorsque les deux sont rapportés au même modèle de référence.

Le seul face-à-face au dossier, et pourquoi on ne peut pas le soustraire

Les deux projets sont évalués par rapport à Jev, ce qui donne envie de les aligner. Ne le faites pas.

La fiche de Kev elle-même comporte une ligne Decision Index 0.2 qui place Kev-27B v2 à 52,3 contre 50,2 pour v1, Jev à 54,0 et AutoJev-27B à 50,0. Il s'agit d'une comparaison propre, sur la même suite et la même version, et elle indique que Kev v2 s'est amélioré d'environ deux points et reste encore derrière Jev.

Les cartes de pplx-decider rapportent un score global pondéré par la suite de 61,56 pour la v1.1, contre 56,4 pour la v1 et 57,9 pour Jev. D’après leurs propres chiffres, cela représente un gain de plus de cinq points en une seule révision et une avance de plus de trois points et demi sur Jev.

Ces deux paragraphes ne peuvent pas être soustraits l'un de l'autre. Des suites différentes, des mélanges de tâches différents, une pondération différente — et aucun des deux projets ne publie la pondération. Ce que l'on peut dire est plus restreint et reste utile : les deux ont évolué dans la même direction sur la même fenêtre, tous deux y sont parvenus en modifiant la façon dont la tête de lecture est entraînée plutôt qu'en remplaçant le backbone, et la marge revendiquée par pplx-decider sur Jev est plus importante que le déficit mesuré de Kev. C'est une raison de tester pplx-decider, pas une raison d'y croire.

Un seul des deux comporte une réplication indépendante liée à l’un quelconque de ses chiffres. Les tags Ollama de Kev publient des décomptes de réussites JevBench par tag — 205 sur 231 pour kev:27b-nvfp4, dont 86 sur 111 sur le split difficile, jusqu’à 146 sur 231 pour kev:0.8b — avec une note explicite précisant que ceux-ci excluent 303 tâches indisponibles, scellées ou évaluées par un juge, et ne constituent pas un score officiel de classement. C’est une exécution personnelle, mais une exécution personnelle que l’on peut reproduire. Rien de comparable n’existe pour pplx-decider.

Ce que Kev documente que pplx-decider ne documente pas

• Température — Kev est livré avec T = 1,32, un intervalle à 90 % de [1,20 ; 1,45], appliqué au chargement, de sorte que les probabilités que vous obtenez en sortie sont déjà mises à l’échelle. Les fiches de pplx-decider ne publient aucune température du tout, ce qui signifie que, quelle que soit la calibration dont vous avez besoin, c’est à vous de l’ajuster.

• Fiche d'entraînement — Kev v2 représente 129 heures GPU sur 8× H200, une époque sur 145 840 enregistrements et 337 130 questions, des étiquettes produites par GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b et MiMo-V2.6-Pro sans qu'aucune sortie de Jev n'ait été utilisée, et un filtre de contamination qui a retiré 6 388 enregistrements répartis sur 102 partitions d'évaluation. pplx-decider documente un pipeline construit sur Bespoke Nimble de Bespoke Labs, avec des sous-ensembles de benchmark épinglés par identifiant d'enregistrement et somme de contrôle, et attribue les gains de la v1.1 à la suppression du masque causal ainsi qu'à l'ajout de données d'entraînement — mais ne publie ni nombre d'enregistrements, ni heures GPU, ni liste d'étiqueteurs.

• Rapports honnêtes des régressions — la fiche de Kev affiche ses propres ratés : transfer-v4 a verrouillé 0,8 point, CUAD en baisse de 1,6, erreur de calibration attendue sur breadth-v1 à 0,015 contre 0,053 sur CUAD, deux à quatre fois pire que la v1, et elle identifie l’optimisme de sélection dans sa propre évaluation. Le tableau v1.1 de pplx-decider montre les outils reculer de 79,3 à 78,88 alors que toutes les autres catégories progressent, et rien dans la fiche ne le mentionne.

• Modes de défaillance — La fiche de Kev liste la portée du dépistage des contaminations et les conditions dans lesquelles ses chiffres publiés ont été produits. La famille Decider, la gamme de Mapika, va plus loin et nomme des formes d’entrée précises qui le mettent en échec ; pplx-decider reste silencieux sur la question.

Rien de tout cela ne signifie que pplx-decider est moins bon. La documentation n’est pas une capacité — un laboratoire avec un article de lancement en brouillon a des incitations différentes de celles d’un particulier qui publie des notes sur Hugging Face. Mais lorsque deux modèles revendiquent le même type de résultat et qu’un seul d’entre eux vous indique sa température, celui qui vous l’indique est celui que vous pouvez mettre en production ce mois-ci.

La prise en compte du contexte, c'est là que les deux divergent le plus fort

• Kev — 65 536 jetons d'état, ainsi qu'au moins 8 192 jetons par question, avec un entraînement jusqu'à 32 768. À un état de 64k, l'empreinte résidente atteint environ 87,1 Go au pic, un temps de modèle de 9,4 secondes, 733 ms sur un succès de cache, et 21,1 requêtes par seconde pour un client unique contre 36,4 à soixante-quatre.

• pplx-decider — 8 192 tokens pour le texte et les images combinés, les entrées surdimensionnées étant rejetées plutôt que tronquées. La version Ollama indique une fenêtre de contexte de 256 K, que rien dans le dépôt n’explique et qui ne concorde pas avec la limite propre de la fiche.

Cet écart est la différence la plus déterminante entre les deux pour des charges de travail réelles. Kev est conçu pour de longs états et de nombreuses questions les concernant. pplx-decider est un modèle dense de 27B avec un budget d’entrée relativement faible, ce qui le pousse vers des documents courts, des images et des requêtes qui tiennent dans quelques milliers de tokens.

• Langue — anglais uniquement sur les deux, indiqué comme une limitation sur les deux.

• Vision — pplx-decider prend du texte, du JSON et des images, les tokens de vision coûtant environ largeur × hauteur / 1024 et une configuration d’évaluation plafonnée à 512×512. Kev n’a pas de vision dans la gamme 27B.

• Plancher de service — Kev-27B nécessite un GPU de classe 80 GB : 51,3 GB de poids bf16, environ 65,5 GB résidents, 87,1 GB pour un état 64k, et son serveur écoute ouvertement sauf si KEV_API_KEY est défini. Les poids bf16 de pplx-decider font environ 49 GiB, donc le plancher est similaire ; la version quantifiée d’Ollama se situe à 17 GB, ce qui correspond à une machine très différente.

• Échelons — Kev couvre 0,5B, 0,6B, 0,8B, 4B, 8B, 9B et 27B, avec les petites tailles comme adaptateurs LoRA. pplx-decider est d'une seule taille, révisé deux fois.

Organiser le bake-off sans parier dessus

Les deux modèles sont accessibles sous forme de poids locaux, ce qui correspond exactement à la situation où une couche de routage justifie son existence. OrcaRouter ne sert pas pplx-decider et ne sert pas Kev — ni l'un ni l'autre ne figure au catalogue, et rien ici ne doit être interprété comme une affirmation selon laquelle nous les hébergeons. Ce que nous proposons dans cette catégorie, c'est typesafe/jev-1.13, exposé via la même forme d'appel POST /v1/systemone à 0,042 $ par million de jetons d'entrée, et c'est le bras de contrôle naturel : même interface, mêmes types de questions, aucun GPU à vous.

Cela rend un comparatif à trois peu coûteux à mettre en place. Placez un pplx-decider local et un Kev local derrière le même harnais face à un typesafe/jev-1.13 routé, évaluez les trois sur vos propres documents, et laissez leur désaccord vous indiquer où se situent réellement vos seuils. Le basculement automatique compte plus que d’habitude dans cette configuration, car un 27B local sur une seule carte est le composant le moins fiable de la chaîne ; acheminer le repli via une API pour plus de 200 modèles — prix catalogue du fournisseur répercuté avec 0 % de marge — évite que l’expérience ne se transforme en panne. Et lorsqu’un modèle comme pplx-decider finit par être disponible sur un endpoint hébergé, la même clé qui exécute le bras de contrôle le fait tourner, sans second contrat ni modification du code.

Qu’est-ce qui changerait la réponse ?

Quatre choses, et toutes sont vérifiables plutôt qu'une question de goût.

Si pplx-decider atteint un fournisseur d’inférence, son tableau de benchmarks non vérifié devient une question d’arbitrage entre prix et latence, et la lacune documentaire cesse d’avoir de l’importance — vous paieriez pour un relevé hébergé, pas pour en maintenir un. Si un tiers indépendant reproduit les chiffres JevBench de l’un ou l’autre modèle sur un harnais publié, toute la comparaison se réduit à une seule suite plutôt qu’à deux suites incompatibles.

Si la faiblesse ECE documentée de Kev sur CUAD s’avère corrigeable par un réajustement plutôt qu’un réentraînement, l’argument de calibration à son encontre disparaît en grande partie, parce que Kev fournit déjà sa température et que ses modes de défaillance sont des grandeurs connues. Et si vous avez besoin d’un modèle de décision sur une seule carte plutôt que deux, la version quantisée de 17 Go de pplx-decider est la seule option ici — non pas parce qu’elle est meilleure, mais parce qu’elle tient là où un 27B en bf16 ne tient pas.

Jusqu’à ce que l’une de ces choses se produise, la lecture pratique est sans glamour. Kev est celui dont vous pouvez reproduire les chiffres dès aujourd’hui et dont vous pouvez croire que la calibration est documentée ; pplx-decider est celui dont le plafond revendiqué est meilleur et la traçabilité plus faible. Choisissez le premier si vous livrez ce mois-ci. Faites entrer le second dans le même banc d’essai si vous êtes le genre d’équipe qui préfère mesurer un lancement discret plutôt que d’attendre un article de lancement.

Faire passer le repli par le prix catalogue du fournisseur répercuté avec une marge de 0 % évite qu’un comparatif à trois se transforme en panne lorsque le point de contrôle local est le composant le moins fiable de la chaîne.

Un comparatif à trois est aussi un moment raisonnable pour se demander ce qui a déjà échoué dans cette catégorie : les incidents d'IA documentés et les défaillances d'agents impliquant des modèles de décision sont recueillis dans l'OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, son niveau de gravité, sa note de confiance et son indicateur de contestation.