pplx-decider vs Decider : le Silent 27B de Perplexity contre l'Open Ladder de Mapika

Deux modèles de décision sont actuellement hébergés sur Hugging Face et répondent aux questions de la même manière, tout en ne s'accordant sur presque rien d'autre. pplx-decider est un checkpoint 27B de Perplexity, apparu le 2026-10-01 sans annonce, sans article de blog, sans page de tarification et sans qu'aucun fournisseur d'inférence ne le propose ; une révision, pplx-decider-v1.1, a suivi le 2026-10-05 sur le même backbone. Decider est la famille de Mapika du même type de modèle — decider-0.8b à decider-35b-a3b, une reproduction ouverte dans la lignée System One, publiée avec des notes d'entraînement complètes. Les deux prennent un bloc de questions nommées ainsi qu'un document et renvoient une probabilité calibrée par réponse en une seule passe avant. Ni l'un ni l'autre n'écrit une phrase de prose. Ce qui suit est ce qui figure réellement au dossier pour chacun, avec un marqueur clair là où le dossier s'arrête.

D'abord, que fait « decision model » dans cette phrase ?

Ni l'un ni l'autre n'est un modèle de conversation auquel on a demandé d'être concis. Ce ne sont pas du tout des modèles de langue au sens habituel — il n'y a pas de boucle de décodage, pas d'échantillonnage, rien qui se fasse token par token. Une seule passe avant sur votre document renvoie une probabilité pour chaque option que vous avez fournie.

La forme de l’appel est ce qui rend la comparaison digne d’être écrite. Vous transmettez un état (un ticket, un enregistrement JSON, une capture d’écran, un contrat) et une liste de questions nommées. Chaque question nomme 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. Les réponses reviennent dans l’ordre dans lequel vous les avez posées, sous forme de nombres entre 0 et 1, et le nombre doit être lu comme une probabilité plutôt que comme une étiquette nette — 0,62 à « un remboursement est-il demandé ? » constitue toute la sortie, et c’est à l’appelant de décider du seuil.

Cette conception élimine la latence et le coût, car un document comportant soixante questions coûte une seule passe, pas soixante. Cela signifie aussi que les façons habituelles d’évaluer un modèle de langage ne s’appliquent pas : il n’y a pas de trace de raisonnement à lire, pas de chaîne de pensée à contester, aucun moyen de lui demander de s’expliquer. On obtient une masse de probabilité et rien d’autre. Les deux projets affirment explicitement que c’est là le compromis.

Ce qui a été livré, et ce que personne n'a dit

Le dépôt pplx-decider est étonnamment complet pour un modèle sans article de lancement derrière lui. Les poids sont sous Apache-2.0. La base est Qwen/Qwen3.8-27B, indiqué sur la fiche. Il y a une tête de lecture publiée en bf16 à [255, 5120], ce qui correspond exactement à la forme attendue pour 255 options sélectionnables sur un état caché de 5 120 de large. La fiche documente le budget d'entrée, le plafond d'options, les trois types de questions et la forme de l'endpoint — POST /v1/systemone.

Ce qui manque, c’est la phrase que porterait un post de lancement. Il n’y a pas de date de sortie sur la fiche, aucune annonce, aucun billet de benchmark de la part de Perplexity, aucun prix, et aucune plateforme tierce ne le sert. Les compteurs de téléchargement sont du niveau de ceux d’un dépôt qui a été trouvé plutôt que promu. Lisez les deux ensemble et la description honnête est : l’artefact est public, l’intention qui le sous-tend ne l’est pas. Tout ce qui suit à propos de pplx-decider provient du dépôt et de ses fiches. Rien de ce qui suit n’a été reproduit de façon indépendante, et personne en dehors du laboratoire n’a publié sa propre exécution.

L'entrée de la bibliothèque Ollama rend cet écart visible de manière modeste. Sa page indique le tag comme 27b à 17 GB avec une fenêtre de contexte de 256K — une build quantisée, bien en dessous des quelque 49 GiB qu'occupent les poids bf16 — tandis que le dépôt documente un budget d'entrée texte-et-images bien plus réduit et précise que les entrées surdimensionnées sont rejetées plutôt que tronquées. Ces deux affirmations ne décrivent manifestement pas la même limite, et rien de publié ne les concilie. Considérez le chiffre du runtime comme une affirmation du runtime.

La partie intéressante : deux inconnus, une interface

La famille Decider de Mapika et pplx-decider ont été développés indépendamment, à partir de bases différentes, pour des raisons différentes, et ils ont convergé vers le même format de transmission. Les modèles Decider parlent aussi la forme d'appel System One — questions nommées, choix parmi 2 à 255 options, aucune génération de texte, états acceptés jusqu'à environ 32k. Un client écrit pour l'un est, à peu de chose près, un client pour l'autre.

Cette convergence est le fait utile dans cette comparaison. Le choix que vous faites n'est pas une réécriture ; c'est un simple échange d'une URL de base et d'une chaîne de modèle. La question intéressante cesse d'être « quelle API dois-je intégrer » pour devenir « à quelle lecture dois-je me fier sur mes documents » — et les deux projets répondent à cette question de manières très différentes.

Un point de contrôle contre une échelle

La différence structurelle est la plus facile à voir. Perplexity a proposé une taille unique. Mapika a proposé une gamme et publié le tableau des tailles :

• Catalogue — pplx-decider : un checkpoint 27B, plus une révision v1.1 sur le même backbone. Decider : sept tailles publiées ou plus, de decider-0.8b à 1,4 Go jusqu’à decider-2b, decider-2b-vision, decider-4b, decider-12b et decider-35b-a3b à 65 Go en bf16 ou 19,6 Go en nvfp4.

• Bases — pplx-decider : Qwen/Qwen3.8-27B, une seule lignée. Decider : un mélange — Qwen3.5-0.8B, Qwen3.5-2B et Qwen3.5-4B pour les petites tailles, Qwen3.5-35B-A3B pour la grande, et gemma-4-12B-it et gemma-4-31B-it pour les variantes chat.

• Activation — pplx-decider : dense 27B, donc chaque paramètre est exécuté à chaque appel. Decider : decider-35b-a3b est un mélange — 34,7B au total avec environ 3B actifs répartis sur 256 experts routés, dont 8 actifs par token.

• Vision — pplx-decider : multimodale, et le dépôt l'indique ; texte, JSON et images, y compris captures d'écran, reçus et formulaires, les jetons de vision coûtant environ width × height / 1024. Decider : un point de contrôle decider-2b-vision distinct plutôt qu'un indicateur sur la ligne principale, de sorte que le travail sur les images relève d'un choix de modèle différent, et non d'un argument différent.

• Licence — Apache-2.0 des deux côtés, le seul point où cette comparaison est ennuyeuse.

• Divulgation d'entraînement — pplx-decider : un pipeline de données qui s'appuie sur Bespoke Nimble de Bespoke Labs, avec des sous-ensembles de benchmarks épinglés par ID d'enregistrement et somme de contrôle, et les gains de la v1.1 attribués à la suppression du masque causal et à l'ajout de données, notamment tasksource. Decider : des notes par version avec le nombre d'éléments, le matériel et le temps d'horloge — decider-35b-a3b entraîné sur 4× B300 pendant 394 minutes sur 1 543 567 éléments — plus des modes de défaillance nommés et la proportion de paramètres réellement entraînés, 2,45 B sur 34,7 B.

Ni l'une ni l'autre n'est un avantage décisif. Un checkpoint unique est plus simple à appréhender, plus facile à servir et impossible à réduire en taille. Une échelle de modèles vous permet de placer decider-0.8b derrière un pré-filtre peu coûteux et de ne dépenser le 35B que sur les éléments qui en ont besoin — mais seulement si vous êtes prêt à maintenir la logique de routage qui décide lequel est lequel.

Les chiffres, et qui les a produits

Les deux ensembles de chiffres phares sont déclarés par les fournisseurs, et aucun n’est accompagné d’une réplication indépendante. Cela compte davantage ici que d’ordinaire, car il n’existe aucun classement tiers de modèles décisionnels qui ait la notoriété des arènes d’image ou de langage.

Les chiffres de Perplexity pour pplx-decider le situent à 85,7 % sur 11 benchmarks publics, contre 84,5 % pour Jev et 74,8 % pour la base Qwen3.8-27B à partir de laquelle il a été entraîné. Les lignes individuelles rapportées incluent RAGTruth 88,8, FinancialPhraseBank 84,2, TabFact 90,6, JudgeBench 78,3 et WinoGrande 83,3, l’ensemble plus complet couvrant Circa, Belebele, TruthfulQA binary, BBH, ContractNLI et un split difficile public de JevBench. La révision v1.1 rapporte un score global pondéré par suite de 61,56 contre 56,4 pour la v1 et 57,9 pour Jev, avec le gain le plus important sur une seule catégorie dans les tâches linguistiques. La comparaison avec Jev est celle du fournisseur, calculée sur sa propre suite, et la pondération n’est pas publiée.

La communication de Mapika a une texture différente : les chiffres arrivent assortis de réserves qui les affaiblissent. decider-35b-a3b annonce 0,855 en tâche et 0,810 hors échantillon, contre une base zero-shot de 0,732, et 0,676 sur la partition difficile publique de JevBench — en dessous des 0,730 de Jev 1.13.0. La fiche indique aussi qu'il n'y a pas d'étape de renforcement, donc le jeu échantillonné se situe à 86,4 % contre les 93,2 % de decider-2b v10, et que le modèle est trop confiant sur les éléments les plus difficiles, avec une erreur de calibration attendue de 0,15 sur le niveau difficile. decider-2b v11 est annoncé à 0,802 en tâche et 0,752 hors échantillon, avec une ECE de 0,156 contre une ligne directrice de publication annoncée de 0,08 — un échec, imprimé par les auteurs.

Deux modes de défaillance documentés méritent d’être pris en compte dans toute évaluation que vous menez. Sélectionner un enregistrement par sa position dans un long tableau JSON est décrit comme la forme d’entrée la moins précise que gère cette famille, et le fait de regrouper plusieurs questions indépendantes dans un seul appel peut faire basculer jusqu’à 12 % des réponses lorsque l’indicateur independent est désactivé. Dans les deux cas, c’est le genre de détail qu’une fiche technique passe sous silence et qu’une carte ne mentionne qu’une fois.

Ce qu'il en coûte de faire fonctionner l'un ou l'autre

• Plus petit Decider exploitable — decider-0.8b fait 1,4 Go. pplx-decider n’a pas de variante réduite, donc son minimum est le 27B complet.

• Le plus grand Decider — decider-35b-a3b à 65 GB bf16 ou 19,6 GB nvfp4, avec seulement environ 3B de paramètres actifs par token.

• Latence, côté Decider — decider-2b tourne à 4 ms par requête avec les CUDA graphs sur un B300, contre 18,9 ms en mode eager, et environ 2 700 décisions par seconde avec un batch de 32. Le 35B, c'est un autre monde : environ 47 ms pour un ticket de 92 tokens comportant trois questions, 368 ms pour 64 tickets.

• Latence, côté pplx-decider — aucune publiée. Les fiches ne donnent aucun chiffre de débit ou de latence, ce qui est normal pour un dépôt qui n’a pas été lancé.

• Coût par décision — c’est ici que la conception porte ses fruits des deux côtés. Soixante questions sur un même document, c’est une seule passe avant dans un cas comme dans l’autre, donc le coût par décision s’effondre à mesure que vous posez davantage de questions sur le même document.

Voici le tableau honnête du routage. OrcaRouter ne dessert pas pplx-decider, et ne dessert pas non plus la famille Decider de Mapika — ni l'un ni l'autre n'apparaît au catalogue, et rien dans cet article ne doit être interprété comme affirmant le contraire. Ce que le catalogue propose effectivement dans cette catégorie aujourd'hui, c'est typesafe/jev-1.13, un modèle de décision de la même forme System One, avec une fenêtre de 65 536 tokens exposée via le même point de terminaison POST /v1/systemone, à 0,042 $ par million de tokens d'entrée, ce qui constitue un point de repère utile pour savoir ce que coûte un modèle de décision routé. Si vous évaluez un checkpoint non annoncé comme pplx-decider, la façon de procéder sans miser un chemin de production dessus est de l'exécuter vous-même aux côtés d'un modèle routé derrière une API unique pour plus de 200 modèles — le prix catalogue du fournisseur répercuté avec 0 % de marge, donc lorsque ces projets atteindront un fournisseur d'inférence, le prix catalogue sera le prix pratiqué ici le jour même. D'ici là, un pplx-decider auto-hébergé à côté d'un typesafe/jev-1.13 routé est la comparaison qui vous apprendra réellement quelque chose.

Lequel choisir

Si vous avez besoin d’un modèle de décision aujourd’hui, sur votre propre matériel, à la taille que vous choisissez, avec des notes d’entraînement que vous pouvez auditer et une licence qui ne vous demande rien, la réponse est un checkpoint Decider, et la seule vraie question est de savoir à quel échelon. Commencez par decider-2b ; les chiffres de la v11 montrent que la famille s’améliore par rapport à sa propre v10 précisément sur le split difficile qui vous intéresserait, et l’écart ECE documenté vous indique de réajuster une température avant de faire confiance aux probabilités en production.

Tournez-vous vers pplx-decider si vous voulez la même interface avec un modèle dense plus grand derrière, si les entrées d’images comptent et que vous préférez ne pas exécuter un second checkpoint, ou si vous êtes le genre d’équipe qui préfère évaluer elle-même la tête de lecture d’un laboratoire de pointe plutôt que d’attendre un post de lancement qui pourrait ne jamais venir. Ses avantages sont réels mais non vérifiés : un backbone plus grand, un tableau de benchmarks qui le flatte, et un pipeline d’entraînement documenté jusqu’aux sommes de contrôle au niveau des enregistrements.

Ce qu’il faut surveiller n’est pas un benchmark. C’est de savoir si pplx-decider parvient à un fournisseur d’inférence, tout court. Un dépôt avec des poids et sans annonce est un signal, pas un produit ; dès qu’il apparaît sur un point de terminaison hébergé, la question prix-latence à laquelle les cartes de Decider répondent déjà devient une véritable comparaison plutôt qu’une aspiration.

Exécutez un pplx-decider auto-hébergé à côté d’un modèle de décision routé adossé à le prix catalogue du fournisseur répercuté avec 0 % de marge , donc lorsque l’un ou l’autre projet atteint un fournisseur d’inférence, le prix affiché est celui pratiqué ici le jour même.

Un nouveau point de contrôle évalué par rapport à une échelle publiée est aussi un bon endroit pour vérifier l'historique : les incidents d'IA documentés et les défaillances d'agents concernant les modèles de cette classe 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.