pplx-decider sur Ollama : le modèle de décision silencieux 27B de Perplexity devient exécutable

Perplexity a publié les poids de pplx-decider-v1.1-27b le 2026-10-05, et le premier checkpoint qu'il a remplacé, pplx-decider (nom du dépôt pplx-decider-v1-27b), le 2026-10-01. Les deux sont des versions affinées de Qwen3.8-27B qui répondent en probabilités plutôt qu'en phrases, et les deux appartiennent à la même lignée System One que Jev 1.13 de TypeSafe. Ce qui est nouveau n'est pas le modèle : depuis aujourd'hui, pplx-decider figure dans la bibliothèque de modèles propre à Ollama, installable avec une seule commande. Avant l'apparition de cette entrée, exécuter ce checkpoint nécessitait un GPU CUDA disposant d'environ 49 GiB de poids bf16. Désormais, c'est un téléchargement quantifié de 17 GB sur un ordinateur portable. C'est ce seul changement qui fait l'objet de cette page, et le modèle qu'il rend exécutable a quatorze jours.

Qu’est-ce qui a changé, concrètement ?

L'entrée de la bibliothèque Ollama s'appelle pplx-decider, et la bibliothèque a régulièrement collecté des modèles de décision — Laya, Nimble, Kev, Clef, Strands Decider — tout au long de l'automne. Celui-ci est l'ajout le plus récent, et sur le registre maintenu, il expose trois tags (pplx-decider:latest, pplx-decider:27b et pplx-decider:27b-q4_K_M) qui correspondent au même digest de manifeste. Un seul artefact, pas une échelle de tailles.

• Format — GGUF servi par llama.cpp, par opposition aux fragments safetensors bf16 sur Hugging Face

• Taille du téléchargement — environ 17 Go en q4_K_M, contre environ 49 Gio de poids plus la mémoire de travail pour le checkpoint bf16

• Couche vision — le manifeste embarque un projecteur distinct d’environ 927 Mo aux côtés de la couche modèle, de sorte que l’entrée image est empaquetée avec les poids textuels

• Matériel — une machine grand public plutôt qu'une station CUDA

L'interface est le point de terminaison d'Ollama /v1/systemone, qu'Ollama a ajouté dans la v0.35.0 et étendu pour les modèles Clef dans la v0.35.1. Elle vient aussi de se doter d'une interface en ligne de commande : la v0.40.4, publiée le 2026-10-12, a ajouté les modèles de décision à ollama run, de sorte qu'une question oui/non, un choix de libellé ou une note de grille d'évaluation peut être demandé directement depuis un terminal avec --ask, --choice et --level. Cette version a trois jours ; le modèle qu'elle rend pratique en a deux semaines.

Ce que le dépôt documente réellement

Le checkpoint n'est pas un modèle de conversation avec un prompt concis. Sa fiche décrit une disposition de décision native : le backbone Qwen3.8-27B sous le nom de classe publié, plus un readout.safetensors distinct contenant une tête de décision bf16 [255, 5120] — une lecture à 255 voies sur les emplacements d'options, et non une tête de langage à vocabulaire complet. Il n'y a pas de boucle de décodage. Chaque option de chaque question est évaluée en une seule passe avant, c'est pourquoi la réponse indique zéro token de sortie.

Trois détails dans la carte comptent davantage que le tableau de benchmark, car ce sont eux qui font échouer une intégration naïve :

• Mode d'attention. Les couches à attention complète utilisent un mode non causal enregistré, et la fiche indique clairement que l'inférence causale par défaut ne reproduit pas la configuration évaluée. Lancez le checkpoint avec un chargeur causal standard et vous obtenez des chiffres qui ne sont pas ceux publiés.

• Température de calibration. Le DecisionModel.predict fourni applique une température enregistrée. Si vous lisez les logits directement, appliquez-la exactement une fois — l'appliquer deux fois, ou pas du tout, fausse l'échelle de chaque probabilité sur laquelle vous vous basez ensuite.

• Une véritable limite de décision. Le texte et toutes les images pour une décision doivent tenir dans un budget de 8 192 jetons, et les entrées dépassant la limite sont rejetées plutôt que tronquées. L'entraînement et l'évaluation rapportée plafonnaient les images à 512×512 ; relever ce plafond est désormais configurable via max_image_pixels, avec une valeur par défaut de 2048×2048, mais la fiche avertit que les résolutions plus élevées se situent en dehors de la distribution d'entraînement.

Le dépôt est par ailleurs inhabituellement complet pour un modèle que personne n’a annoncé : onze shards safetensors, un decision_config.json, un template de chat, et un release-manifest.json enregistrant les sommes de contrôle des fichiers et la provenance du checkpoint. La licence est Apache 2.0.

Deux parties de la documentation ont divergé. La fiche v1.1 vous demande encore de vous authentifier auprès de « ce dépôt privé » — le dépôt est public aujourd’hui. Et l’ancienne fiche v1 porte un pointeur new_version vers la v1.1, ce qui est le signal honnête que la v1 est supplantée.

La seule chose à vérifier avant de planifier en fonction de cela

La fiche Ollama annonce une fenêtre de contexte de 256K. Ce chiffre semble hérité du modèle de base — Qwen3.8-27B possède bien 262 144 positions — et il ne correspond pas au contrat que le point de contrôle de décision documente pour lui-même. Le point de contrôle rejette toute décision dont le texte et les images dépassent 8 192 tokens. Concevez un pipeline sur 256K, soumettez-lui un contrat de 40 000 tokens accompagné de quatre images de pages, et la requête échoue au lieu d’être tronquée. Le chiffre le plus élevé décrit l’architecture ; le plus petit décrit l’API que vous appelez réellement.

La prise en charge des images présente un cas limite similaire. La fiche de modèle Ollama pour pplx-decider montre une requête d’image vers /v1/systemone, mais la page des capacités d’Ollama pour ce point de terminaison indique que les images sont « réservées aux modèles Clef ». L’un de ces deux documents est obsolète. Considérez l’entrée multimodale sur ce chemin comme non vérifiée tant que vous ne l’avez pas exécutée vous-même — le checkpoint sous-jacent accepte clairement les images, et le manifeste embarque clairement un projecteur, mais la condition documentée du runtime est plus restrictive que ne le laisse entendre la fiche du modèle.

Un numéro de fournisseur, et un numéro différent

L’évaluation interne de Perplexity pour le checkpoint v1.1 rapporte un indice de décision de 61,56, contre 57,9 pour Jev sur la même suite et 56,4 pour le checkpoint qu’il remplaçait, avec les plus fortes progressions par catégorie en langue (69,45) et en récupération (61,26). Ces chiffres sont déclarés par le fournisseur et ont été produits du côté de Perplexity ; pour le checkpoint antérieur, la fiche va plus loin et indique que les résultats ont été mesurés via l’API Perplexity. C’est une chose légitime à publier, mais une base peu solide sur laquelle s’appuyer.

Le tableau indépendant est plus utile. Un classement communautaire ouvert pour cette classe de modèles, le Jev Decision Index, évalue pplx-decider-v1.1-27b sur son propre panel et sa publication de données du 2026-10-14 rapporte que le checkpoint a complété 110 179 des 110 201 cas évalués sur 42 benchmarks sur une seule RTX PRO 6000. Sur ce tableau, le modèle obtient un score de compétence équilibré de 62,75 et un rang de sixième, Jev étant douzième à 60,11. Deux choses que le tableau du fournisseur ne montre pas ressortent des mêmes données :

• Là où il excelle.ARC-Easy 99.3, ARC-Challenge 97.0, décisions oui/non d'appel de fonction (BFCL) 97.2, FinEntity 95.4, BPoMP 95.2, CLINC150 91.5. Les tâches classiques de classification et de recherche d'information sont là où ce checkpoint tire son épingle du jeu.

• Là où ce n'est pas le cas. Humanity's Last Exam 16,2, ChessBench 17,7, SATA-Bench 28,2, ACOS 28,2, l'ensemble de dialogues guidés par schéma 33,2, BRIGHT 50,9, GPQA Diamond 56,1. Le raisonnement complexe en plusieurs étapes n'est pas ce qu'une lecture en une seule passe vous apporte, et une pile qui achemine discrètement le travail de raisonnement vers un modèle de décision produira des branches erronées en toute confiance.

La calibration mérite sa propre ligne, car c'est tout l'intérêt d'un modèle qui renvoie des probabilités plutôt que des étiquettes. Sur 34 829 décisions notées indépendamment, le checkpoint a affiché en moyenne une exactitude de 76,1 % contre une confiance moyenne de 82,9 % — une erreur de calibration attendue de 0,071 et un score de Brier de 0,335, avec 2,0 % des cas situés au-dessus de 0,95 de confiance et pourtant erronés. C'est une surface de probabilité utilisable mais non parfaite, et elle est mesurablement mieux calibrée que l'ECE de 0,074 de Jev sur le même tableau. Si vous fixez un seuil de 0,9 et le traitez comme une quasi-certitude, ce chiffre de 2 % est celui autour duquel il faut concevoir.

La latence sur le même matériel s’est établie à une médiane de 104 ms et à un p95 de 835 ms sur 110 000 décisions, ce qui constitue l’argument pratique en faveur d’un modèle décisionnel plutôt que d’un petit modèle de langage en position de filtrage : le p95 est le budget, pas la moyenne.

Ce que coûte une décision

Perplexity exploite sa propre API Decisions hébergée pour ces checkpoints — POST https://api.perplexity.ai/v1/decisions, avec pplx-decider-v1.1-27b comme ID de modèle par défaut et le checkpoint antérieur toujours adressable. Cette page de tarification indique 0,02 $ par million de tokens d’entrée, les tokens de sortie gratuits, et aucun frais par requête, avec un plafond de 128 questions par requête, 262 144 tokens d’entrée et 10 requêtes par seconde par organisation.

En revanche, le chemin local ne coûte rien par décision une fois les 17 Go téléchargés. Pour une file de triage exécutant une poignée de questions typées par ticket, ce calcul s'impose de lui-même — et il est intéressant de noter que le plafond du service hébergé de 262 144 jetons d'entrée n'est pas la limite que votre copie locale appliquera, car le budget propre du checkpoint est de 8 192.

Là où la route locale n'est pas la solution, c'est le reste de la pile autour de la décision. Il s'agit d'un modèle 27B qui renvoie une probabilité par option ; il ne rédigera pas la réponse, ne résumera pas le ticket et n'appellera pas l'outil. Si vous voulez la décision et la rédaction derrière une seule clé, c'est ce à quoi sert OrcaRouter — une API unique sur plus de 200 modèles avec le prix catalogue du fournisseur répercuté sans majoration par token, ainsi que le DSL de routage lorsque vous voulez qu'un modèle de décision et un modèle de rédaction soient composés en un seul appel. Deux éléments de cette histoire précise sont déjà sur la plateforme : le checkpoint de base est servi en tant que Qwen3.8-27B, ce qui vous permet de comparer le fine-tune à sa propre base sur la même clé, et le modèle de référence auquel il est comparé est servi en tant que Jev 1.13 via la même forme de point de terminaison systemone. Le décideur de Perplexity n'est pas l'un de ceux que nous proposons — il est disponible via l'API propre à Perplexity et plusieurs plateformes tierces — donc si vous en avez spécifiquement besoin, la récupération locale ci-dessus et le point de terminaison de Perplexity sont vos routes.

Trois questions auxquelles le dépôt ne répond pas

Quel checkpoint se trouve dans l'artefact quantisé ? L'entrée de la bibliothèque Ollama est nommée d'après la famille, et non d'après une version, et son bloc de benchmarks renvoie vers le dépôt v1 — le tableau des 11 benchmarks indique 85,7 pour cent, ce qui correspond au chiffre global de la fiche v1 et non à la suite Decision Index de la v1.1. La v1.1 est le checkpoint le plus performant selon les propres calculs de Perplexity, et ce n'est pas forcément celui que vous téléchargez. Vérifiez le digest avant de fonder vos conclusions sur cette hypothèse.

Est-ce que Perplexity avait l'intention que tout cela soit public ? Aucune annonce, aucun article de blog, aucune entrée de journal des modifications ni avis de disponibilité de l'API pour ces poids n'a fait surface. Les checkpoints ont été consultés par des milliers de personnes — 2 740 téléchargements pour la v1 et 3 154 pour la v1.1 au moment de la rédaction —, mais l'attention portée à une fiche de modèle n'équivaut pas à un fournisseur qui déclare qu'il est pris en charge. Considérez le dépôt public comme l'artefact faisant autorité, et tout le reste comme une déduction.

Une version hébergée par le fournisseur et officiellement annoncée est-elle prévue ? Inconnu. L'existence, du côté de Perplexity, d'une API Decisions documentée et tarifée suggère que la voie de l'hébergement constitue le produit visé et que les poids se situent en amont de celui-ci. Mais il s'agit d'une conjecture sur les intentions, non d'un fait tiré d'un document, et elle est présentée comme telle.

Qui devrait bouger, et qui ne devrait pas

Si votre pipeline effectue déjà des branchements sur des décisions typées du fournisseur — routage des tickets, détection des remboursements, contrôle des étapes d'agent —, voici un checkpoint vieux de deux semaines avec des scores reproduits indépendamment, une licence Apache 2.0 et, depuis aujourd'hui, un chemin de 17 Go vers du matériel que vous possédez. L'évaluation suggère qu'il est mieux calibré que le modèle de référence et environ deux rangs au-dessus sur un classement public, et la copie locale supprime entièrement le coût par décision. Récupérez-le, exécutez-le sur vos propres exemples étiquetés et comparez-le à ce que vous utilisez aujourd'hui. Le budget de décision de 8 192 jetons est la contrainte à tester en premier, pas les 256K annoncés dans la fiche.

Si vous avez besoin de raisonnement plutôt que de classification, attendez. Le panel indépendant place ce checkpoint dans les 13-14 sur les benchmarks de connaissances difficiles, et une surface de probabilité qui est confiante sur une question à laquelle elle ne peut pas réellement répondre est pire en production qu'un modèle lent qui réfléchit d'abord. L'argument en faveur d'un modèle de décision, c'est la médiane de 104 ms et le fait que soixante questions coûtent une seule passe — et rien de tout cela n'aide là où les réponses sont fausses.

Exécuter l’étape de décision sur votre propre matériel est aussi l’occasion de regarder ce qui a déjà mal tourné dans cette catégorie : les incidents d’IA documentés et les défaillances d’agents impliquant des modèles de décision sont recensés dans l’OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, un niveau de gravité, une note de confiance et un indicateur de contestation.