pplx-decider-flash : le juge 4B discret de Perplexity, lu depuis le dépôt

Perplexity a téléversé pplx-decider-flash-v1.2 sur Hugging Face à 16:57 UTC le 15 octobre 2026, environ neuf heures après avoir téléversé pplx-decider-v1.2, le grand modèle de décision que le marketing appelle 27B et que la fiche du modèle appelle 26B. Nous n’avons trouvé aucun billet de lancement sur le blog de l’entreprise. Ce qui a suivi, c’était un fil du compte développeur sur X, une section dans la documentation de l’API Decisions, et une conversion GGUF trois jours plus tard. C’est l’intégralité des informations publiques, et cela suffit pour décrire précisément le modèle, mais pas pour vous dire s’il est performant sur vos données.

Ce qui suit distingue les trois choses que les gens confondent habituellement : ce que le dépôt prouve, ce que la documentation du fournisseur affirme, et ce que personne en dehors de Perplexity n'a vérifié. La dernière catégorie est plus vaste que les deux premières.

Qu’est-ce qui a réellement été livré, et quel jour

La chronologie du dépôt est sans ambiguïté. Perplexity a créé pplx-decider-v1-27b le 1er octobre 2026, pplx-decider-v1.1-27b le 5 octobre, les deux points de contrôle v1.2 le 15 octobre, et pplx-decider-flash-gguf-v1.2 le 18 octobre. Le point de contrôle Flash était le deuxième téléversement de la journée, ce qui correspond à la forme habituelle d’une publication appariée : le modèle phare d’abord, le petit frère distillé derrière lui afin que les deux soient annoncés ensemble.

Cet ordre des choses compte pour le cadrage. Il ne s’agit pas d’un modèle fuité ni d’un dépôt errant qui aurait devancé ses formalités. C’est une publication coordonnée, avec une empreinte publique volontairement discrète — un fil de développeur plutôt qu’un article de lancement, de la documentation plutôt qu’un hub de benchmarks. L’API {{1}}Hugging Face{{/1}} rapporte 4 667 téléchargements du checkpoint de base et 9 428 de la conversion GGUF au 4 novembre, ainsi que 63 likes. Les compteurs de téléchargements sur {{2}}Hugging Face{{/2}} sont un signal faible : ils comptent des requêtes, pas des utilisateurs distincts, et le trafic des miroirs les gonfle. Ils sont cohérents avec un public de modèles à poids ouverts réel mais modeste, pas avec une sortie virale.

Ce que le dépôt vous dit

La fiche modèle est inhabituellement technique pour une publication de fournisseur, et l’essentiel de ce qu’il est possible de savoir en provient.

• Backbone — Qwen3.5-4B, avec une tête de lecture BF16 distincte de forme [255, 2560] au lieu d'une tête de modèle de langage à vocabulaire complet. Il s'agit d'un point de contrôle décisionnel, et non d'un modèle de chat doté d'une enveloppe de classification.

• Taille — 25 fichiers totalisant environ 9 Gio en BF16, ce qu'il vous faut pour stocker les poids ; la mémoire de travail vient s'ajouter à cela.

• Nombre de paramètres — la documentation de l’API indique 4B, l’en-tête de la fiche du modèle indique 5B en BF16, et un index tiers répertorie 4,5B. Le backbone est un modèle 4B. Considérez « classe 4B » comme la description honnête et ne citez pas un chiffre unique comme s’il avait été mesuré.

• Attention — les couches d'attention complète s'exécutent de manière non causale sur l'ensemble de la requête, tandis que les couches d'attention linéaire restent causales. C'est le détail qui va vous poser problème : une pile de service causale standard produira des nombres différents, et les invites écrites pour la v1.1 ne sont pas transposables.

• Position de lecture — la tête s'active à chaque <|fim_suffix|> marqueur plutôt qu'au token final, ce qui permet à une seule passe avant d'évaluer plusieurs questions par rapport à un même état.

• Contexte — max_length est par défaut de 262 144 tokens, ce qui correspond au backbone. L'entraînement a utilisé des séquences allant jusqu'à environ 32 000 tokens, et la fiche précise explicitement que des entrées plus longues sont prises en charge mais moins validées.

• Images — plafonnées à 1,6 mégapixel (1 638 400 pixels), minimum 65 536 pixels, une image de 1,6 MP consommant environ 1 600 positions.

• Calibration — une température enregistrée de 1,554. Sur un ensemble de développement de 1 497 questions, la fiche indique une exactitude de 88,8 %, une erreur de calibration attendue de 0,021 et un score de Brier de 0,163 ; sans la température, l’erreur monte à 0,057. Un fournisseur qui publie ses propres chiffres de calibration et le coût de leur omission vous dit quelque chose de concret sur l’usage prévu.

Une ligne de la fiche ne résiste pas au contact de l’API. Elle indique que le dépôt est privé et nécessite un jeton avec accès. L’API Hugging Face renvoie gated: false et private: false, et les poids se téléchargent sans demande d’accès. Une ligne obsolète dans une fiche est une petite chose, mais c’est le genre de petite chose qui vous dit que la fiche a été écrite avant publication et n’a pas été relue ensuite.

Ce que la documentation de l’API ajoute

Le prix est le point de départ de l’argumentaire Flash. Sur l’API Decisions, pplx-decider-flash-v1.2 coûte $0.01 par million de jetons d’entrée. Les jetons de sortie sont gratuits et il n’y a pas de frais par requête, car il n’y a pas de jetons de sortie au sens habituel — le modèle renvoie des probabilités et un score attendu, et la documentation compte chaque question comme un jeton de sortie pour la comptabilité.

La même page définit l’enveloppe de fonctionnement :

• Alias — pplx-decider-flash-latest suit la version la plus récente, donc un seuil que vous avez ajusté la semaine dernière peut pointer silencieusement vers un autre modèle après une mise à jour. Figez l’identifiant versionné dans tout ce qui compte.

• Limites de débit — 4 000 000 de tokens par minute et 240 000 000 par heure, avec un plafond de 10 requêtes par seconde partagé entre les deux modèles de décision au niveau de l'organisation.

• Types de questions — noul renvoie P(oui) de 0 à 1, choice renvoie des probabilités pour jusqu’à 255 options, et score renvoie une distribution sur les niveaux du barème.

• Budget des questions — la documentation recommande une question par requête. Ce n’est pas une note de style ; c’est la différence entre le prix qui vous a été annoncé et le prix que vous payez.

La règle de facturation qui fait basculer la recommandation

Le modèle 27B répond à chaque question d’une requête en une seule passe groupée et facture l’état une seule fois. Flash répond à chaque question indépendamment, sans voir les autres, et facture à nouveau l’état pour chaque question. La documentation donne l’exemple détaillé : trois questions sur un état de 10 000 tokens coûtent environ 30 000 tokens d’entrée sur Flash.

Faites le calcul. Une question sur un état de 10 000 tokens coûte 0,0001 $ sur Flash et 0,0002 $ sur le 27B. Deux questions coûtent 0,0002 $ sur Flash et 0,0002 $ sur le modèle plus grand — égalité parfaite. Trois questions coûtent 0,0003 $ sur Flash et 0,0002 $ sur le 27B. Le point de bascule est de deux questions par état. La documentation de Perplexity elle-même indique que le modèle plus grand « coûte généralement moins cher que Flash » à partir de trois questions ; le point précis se situe une question plus tôt, et cela vaut pour tout prix catalogue où Flash représente exactement la moitié du tarif du 27B.

C’est la chose la plus utile de cette version, et il est facile de la manquer parce que l’annonce principale est une remise de 50 %. Un modèle 4B à moitié prix n’est moins cher que tant que vous ne lui demandez qu’une seule chose à la fois.

Le numéro dont il faut se méfier

Perplexity rapporte des scores de 0,3 à l'indice Decision pour les deux modèles. Flash obtient 60,05 avec une question par requête et 58,88 avec des requêtes conjointes ; le 27B obtient 68,09 en mode conjoint et 67,75 en mode une par requête. Sur l'indice Vision Decision, Flash est à 72,53 contre 77,43.

La répartition par catégorie est plus informative que le chiffre global, car elle montre où le 4B perd du terrain. Concernant les chiffres du run conjoint de Flash comparés à ceux du run conjoint du 27B :

• Connaissances — 42,0 vs 56,3. C'est l'écart le plus large, 14,3 points, et celui qui détermine si le modèle peut gérer des connaissances ouvertes sur le monde.

• Langue — 63,3 vs 72,8.

• Récupération — 64,8 contre 68,4. L’écart le plus faible, à 3,6 points, ce qui correspond à la tâche prévue : juger si un passage répond à une question est une tâche plus légère que de connaître la réponse.

• Outils — 76,7 contre 84,4.

• Arts — 46,8 contre 56,2.

• Global — 58,88 contre 68,09.

Chacun de ces chiffres provient d’un benchmark maintenu par Perplexity. La fiche du 27B — le modèle enseignant dans cette distillation — est inhabituellement franche sur le volet entraînement : une partie du travail, indique-t-elle, a rendu le modèle « dans le domaine » pour certaines tâches de Decision Index en incluant les splits d’entraînement officiels que plusieurs benchmarks fournissent, ces splits étant « décontaminés par rapport aux jeux de test » afin que la comparaison reste équitable. C’est une position plus prudente que ne le laissait entendre la couverture autour de la publication, et elle laisse encore le tableau des scores entre les mains du fournisseur. Aucun tiers n’a audité la discipline des splits, et personne n’a reproduit les chiffres.

Il y a une anomalie plus discrète dans les propres chiffres du fournisseur, qui va à l’encontre du discours marketing. Flash obtient des scores plus élevés lorsqu’il répond à une question à la fois — 60,05 contre 58,88. Le regroupement pénalise globalement le 4B, même s’il aide sur des tâches fortement couplées de type « sélectionnez toutes les réponses applicables », ce qui correspond exactement à ce que dit la documentation. Le modèle est vendu sur la vitesse des requêtes groupées et obtient de meilleures mesures sans elles.

Ce qui n’est pas encore connaissable

Les lacunes sont précises, et c’est la raison pour laquelle il s’agit d’un article sur ce que l’on sait plutôt que d’une critique.

• Aucun benchmark indépendant. Rien en dehors de Perplexity n’a publié de reproductions du Decision Index ni de comparaison directe sur un banc d’essai neutre.

• Aucun niveau de service de latence. Le seul chiffre de vitesse publié par le fournisseur provient d'un test de documentation daté du 19 octobre, dans lequel environ 248 000 jetons d'entrée ont pris 16 secondes sur Flash contre 53 secondes sur le 27B. Il s'agit d'une mesure côté fournisseur, sans matériel ni centile précisés.

• Aucune évaluation multilingue. La fiche et la documentation décrivent du texte et des images ; ni l’une ni l’autre ne rapporte de précision en dehors de l’anglais.

• Aucun volume de données d’entraînement publié. La fiche indique que Flash a été distillé à partir du 27B sur les requêtes d’entraînement du modèle plus grand, l’étudiant apprenant les distributions de probabilité complètes de l’enseignant plutôt que seulement ses réponses, et que plusieurs exécutions ont été combinées par moyennage des poids. Elle ne précise pas la quantité de données concernée, leur provenance, ni où se situe la date de coupure.

• Aucune analyse d'erreur publiée. Pour un modèle dont la sortie est une probabilité sur laquelle vous appliquerez un seuil, il n'existe aucune ventilation des endroits où il échoue — par type de question, par nombre d'options, par langue ou par contenu de l'image.

Où se situe un modèle comme celui-ci dans une stack

Il vaut la peine de préciser à quoi sert Flash, car son nom suscite une attente erronée. Il n’écrit rien. Vous lui fournissez un état — texte, JSON, images — et une ou plusieurs questions typées, et il renvoie une probabilité ou une distribution sur laquelle votre code applique un seuil. L’architecture naturelle est une porte peu coûteuse devant quelque chose de coûteux : classifier la requête, décider s’il faut récupérer des informations, choisir un outil, puis générer.

Cette passerelle ne remplace pas la couche de génération, et c'est là que le routage importe. OrcaRouter expose plus de 200 modèles de génération derrière une seule clé API sans marge sur les prix catalogue des fournisseurs, de sorte qu'une baisse de prix de n'importe quel fournisseur en amont est effective le jour même plutôt que d'attendre le tableur d'un revendeur. Si la passerelle classe mal, le basculement automatique empêche la requête d'échouer au saut suivant. Ce que nous ne faisons pas, c'est héberger pplx-decider-flash : il n'est pas dans notre catalogue, et la façon honnête de l'exécuter aujourd'hui est l'API du fournisseur lui-même ou les poids Apache-2.0 sur votre propre GPU.

Le calcul de l’auto-hébergement est raisonnable si vous disposez déjà du matériel. Environ 9 GiB de poids BF16 tiennent sur une carte grand public de 16 Go, et la couverture de la sortie a repris une affirmation du dirigeant de Perplexity selon laquelle Flash tourne sur un Mac M4 doté de 16 Go de mémoire. Aucun chiffre de débit publié ne l’étaye, et l’attention non causale signifie que vous ne pouvez pas simplement l’intégrer à un serveur d’inférence causal standard en espérant obtenir les scores de la carte.

Qu’est-ce qui changerait cette évaluation ?

Quatre choses, par ordre d’utilité. Une reproduction neutre de Decision Index 0.3 qui confirme soit le 60,05, soit explique l’écart. Une distribution de latence publiée par l’API plutôt qu’un unique test de documentation. Des preuves concernant les entrées multilingues, puisqu’un classifieur 4B est exactement le genre de modèle que les équipes pointeront vers du trafic non anglophone sans vérifier. Et un article technique de première main qui décrit les données d’entraînement derrière cette distillation.

D’ici là, la position défendable est étroite et utile : pplx-decider-flash-v1.2 est un véritable modèle de décision de classe 4B, téléchargeable, sous Apache-2.0, avec un prix publié, une température de calibration documentée et une règle de facturation qui le rend plus cher que son grand frère dès que vous traitez des questions par lots. Tout ce qui va au-delà relève du propre tableau de bord de Perplexity, et vous devriez le considérer comme une hypothèse à tester sur vos données étiquetées plutôt que comme un résultat.