Le 24 septembre 2026, Perplexity a présenté Photon, le moteur interne qui récupère et classe les pages candidates dans son système de recherche. L’entreprise affirme que Photon traite le trafic de recherche en production et annonce un p99 d’environ 65 ms pour ses propres étapes, contre environ 800 ms avec le système précédent.
Photon, moteur interne de Perplexity
Photon n’est pas un moteur de recherche grand public autonome : Perplexity le décrit comme une brique de son infrastructure, chargée de sélectionner et de classer des pages web pour Perplexity Search. Le service de recherche s’appuie ensuite sur ces pages pour produire une réponse étayée.
Perplexity présente aussi Photon comme une étape de sa transition vers une infrastructure de recherche développée en interne autour de Rust. L’entreprise explique avoir conçu ce moteur pour remplacer un système adapté à partir d’un moteur open source.
Le parcours d’une requête dans Photon
Une requête passe par un répartiteur de charge, puis par un broker, qui choisit un groupe de shards — des partitions de l’index. Les shards récupèrent les pages candidates et les classent. Le broker rassemble ensuite les résultats et récupère certains champs des documents retenus avant de renvoyer les résultats à Perplexity Search.
Un index construit à part des requêtes
Perplexity sépare la construction de l’index du traitement des requêtes en direct. Pillar prépare les données sources dans des tables YTsaurus, puis des indexeurs construisent les structures des shards. Un contrôleur déploie les nouvelles versions de l’index sur les groupes de serveurs qui répondent aux requêtes.
Cette séparation accompagne plusieurs changements que Perplexity attribue à Photon : environ 20 % de machines de service équivalentes en moins et 2,5 fois plus de données stockées par document que dans le système précédent. L’entreprise indique également que son index web complet peut être construit en moins de dix heures.
Ce que mesure le p99 annoncé
Le p99 correspond au seuil sous lequel se situent 99 % des mesures considérées. Pour son système de récupération et de classement en production, Perplexity rapporte un p99 d’environ 800 ms avant Photon, contre environ 65 ms pour Photon. Cette dernière valeur couvre les étapes internes du moteur ; elle n’inclut pas les étapes ultérieures du système de recherche de plus haut niveau.
| Système | Latence p99 de production annoncée | Périmètre |
| Système précédent | Environ 800 ms | Récupération et classement |
| Photon | Environ 65 ms | Étapes internes de Photon |
Fast Search : benchmarks et accès à l’API
Fast Search est un mode de l’API Perplexity Search fondé sur Photon, avec un classement allégé pour les traitements par agents. Perplexity rapporte une latence de 160 ms au p50 et de 230 ms au p95 pour un appel unique à l’API. Ces chiffres portent sur cet appel, tandis que le p99 de 65 ms concerne les étapes internes de Photon.
Dans six benchmarks couvrant 3 554 tâches sélectionnées, Perplexity rapporte un score de 64,3 % pour Fast Search, contre 64,0 % pour son réglage par défaut. Les coûts estimés pour ces tâches — calculés pour le modèle et la recherche — sont respectivement de 59,73 $ US et 187,60 $ US. Dans des tests internes distincts portant sur des requêtes de longue traîne, Fast Search obtient un score DCG de 2,21, contre 2,45 pour le réglage par défaut ; la disponibilité des réponses est de 0,567 contre 0,596.
| Mesure | Fast Search | Réglage par défaut | Contexte |
| Score pondéré par tâche | 64,3 % | 64,0 % | Six benchmarks, 3 554 tâches sélectionnées |
| Coût estimé modèle et recherche | 59,73 $ US | 187,60 $ US | Même ensemble de benchmarks |
| Pertinence DCG | 2,21 | 2,45 | Tests internes sur les requêtes de longue traîne |
| Disponibilité des réponses | 0,567 | 0,596 | Tests internes sur les requêtes de longue traîne |
La documentation de l’API fixe le tarif de Fast Search à 1 $ US pour 1 000 requêtes réussies, contre 5 $ US pour 1 000 requêtes réussies de recherche web standard. Pour appeler Fast Search, il faut envoyer search_type: "fast" à POST /search. Le paramètre max_results accepte une valeur comprise entre 1 et 20.