Tarification de l’API pplx-embed-v2-late et mise en place de la recherche dans les PDF

Si vous préparez le budget d’un moteur de recherche dans des PDF basé sur pplx-embed-v2-late, attention au point qui passe facilement inaperçu : Perplexity a bien publié les poids des modèles, mais aucun tarif API pour v2-late et aucun modèle de cette famille n’apparaît dans son catalogue public Embeddings API. À l’heure actuelle, la voie concrète consiste donc à mettre en place une recherche multimodale auto-hébergée, en prenant les tarifs de l’API v1 comme simple point de comparaison.

Tarifs : v2-late n’apparaît pas dans la grille publique de l’Embeddings API

Au 7 octobre 2026, le guide de démarrage officiel de l’Embeddings API liste quatre modèles v1. Il ne mentionne ni pplx-embed-v2-late-0.6b ni pplx-embed-v2-late-9b. Il est donc impossible de donner aujourd’hui une estimation sérieuse du coût par token pour v2-late.

Ces montants correspondent aux tarifs à l’usage de l’API, pas à ceux de la famille late-interaction. Dans son annonce de lancement, Perplexity indique que les embeddings late-interaction, denses et contextuels seront progressivement déployés sur l’API Platform. Cela décrit une feuille de route, pas un endpoint v2-late actuellement disponible ni un engagement tarifaire.

Pour établir votre budget, séparez clairement deux postes :

1. Coût de l’API managée : disponible pour les modèles v1 ci-dessus ; aucun tarif v2-late n’est publié.
2. Coût de l’auto-hébergement : temps GPU, rendu des pages, stockage des modèles, stockage de l’index de vecteurs par token et service des requêtes pour v2-late.

Ne multipliez pas le tarif v1 par le nombre de pages d’un PDF pour obtenir un prétendu devis v2-late. Les modèles utilisent des représentations différentes, et l’API v1 fournit des embeddings de texte, pas le workflow documenté fondé sur des pages rendues.

Ce que fournit réellement pplx-embed-v2-late

Perplexity publie deux checkpoints late-interaction : pplx-embed-v2-late-0.6b et pplx-embed-v2-late-9b. La fiche du modèle 9B indique 340M de paramètres actifs pour le plus petit modèle et 7.4B pour le plus grand. Tous deux produisent des vecteurs de 128 dimensions par token et utilisent MaxSim, au lieu de réduire chaque page à un unique vecteur.

Ces chiffres proviennent de la fiche du modèle et non d’un test indépendant sur des PDF : le 9B devance le 0.6B de 2.9 points de pourcentage en recherche d’images et de 3.5 points en recherche Markdown, avec environ 21.8 fois plus de paramètres actifs. Les deux checkpoints sont distribués sous licence MIT sur Hugging Face.

Le détail déterminant pour le déploiement est l’espace d’embedding partagé : Perplexity indique qu’un index construit avec le 9B peut être interrogé avec le modèle 0.6B. Vous pouvez donc réserver le 9B à l’encodage hors ligne des documents et utiliser le 0.6B pour les requêtes, mais seulement après avoir validé le rappel entre les deux modèles. Cette approche ne réduit pas le stockage nécessaire pour l’index 9B.

Une architecture concrète pour rechercher dans des PDF

Avec v2-late, chaque page rendue du PDF est traitée comme un document image. Une requête textuelle peut ainsi retrouver les mots présents sur la page, la structure d’un tableau, un graphique ou une mise en page, sans faire de l’OCR le signal principal de recherche. C’est le même principe de recherche visuelle de documents présenté dans la documentation de Sentence Transformers.

« Sans OCR » signifie que l’OCR n’est pas utilisé comme représentation principale pour la recherche. Le texte extrait reste toutefois utile pour filtrer les résultats, générer des citations, améliorer l’accessibilité et fournir une recherche de secours.

1. Rendre les pages et conserver leurs métadonnées

Convertissez chaque page en image RGB avec une résolution stable, puis stockez à côté un enregistrement de ce type :

Conservez document_id et page_number dans l’enregistrement de recherche, plutôt que de les déduire du seul nom de fichier image. Lorsqu’une page pertinente est trouvée, récupérez aussi les pages adjacentes du même document : un tableau, une note de bas de page ou une définition peut très bien se poursuivre à la page suivante.

2. Installer l’encodeur compatible

La fiche du modèle 9B demande des bibliothèques récentes :

pip install "sentence-transformers>=6.0.0" "transformers>=5.4.0" pillow

L’exemple fourni utilise MultiVectorEncoder, et la fiche du modèle sélectionne CUDA pour charger le checkpoint 9B :

from PIL import Image
from sentence_transformers import MultiVectorEncoder

model = MultiVectorEncoder(
    "perplexity-ai/pplx-embed-v2-late-9b",
    device="cuda",
)

Utilisez l’identifiant du modèle 0.6B si le checkpoint le plus volumineux ne tient pas sur le matériel disponible. La fiche du modèle ne fournit ni minimum officiel de VRAM, ni tableau de débit, ni garantie de latence. Mesurez donc les performances avec votre résolution de page, votre taille de lot et votre GPU avant de dimensionner l’infrastructure.

3. Encoder séparément les requêtes texte et les images de pages

Le modèle impose des appels asymétriques. Le texte des requêtes passe par encode_query, tandis que les pages rendues passent par encode_document :

query_embeddings = model.encode_query([
    "Which clause governs termination after a material breach?"
])

page = Image.open("pages/contract-2026-04/017.png").convert("RGB")
page_embeddings = model.encode_document([page])

scores = model.similarity(query_embeddings, page_embeddings)
print(scores)

Ne mélangez pas textes et documents image dans un même lot d’encodage. La fiche du modèle précise que les entrées doivent rester homogènes et utiliser la configuration attendue avec les marqueurs [Q] et [D] . model.similarity() applique MaxSim aux représentations produites au niveau des tokens.

Pour une collection réelle, encodez les pages hors ligne, enregistrez leur représentation multi-vecteur dans un index late-interaction et conservez les métadonnées dans un stockage séparé. Sur une petite collection, un score exhaustif peut suffire. À plus grande échelle, utilisez un système compatible avec MaxSim ou mettez en place un premier filtrage dense, suivi d’un reranking v2-late sur un ensemble contrôlé de candidats.

4. Retrouver les pages, puis élargir le contexte

Un résultat au niveau de la page devrait généralement renvoyer :

1. La page correspondante et son score.
2. L’identifiant du document et le lien source.
3. Une ou deux pages voisines du même document.
4. L’image de la page et, si disponible, le texte extrait pour les citations.

Vous évitez ainsi qu’une correspondance visuelle pertinente débouche sur une réponse incomplète lorsque la définition commence à la page 16 et que le tableau se poursuit à la page 17. Le résultat reste aussi vérifiable : l’utilisateur peut voir le graphique ou le tableau à l’origine de la correspondance, plutôt que de devoir faire confiance à une transformation OCR invisible.

Le coût réel ne se limite pas aux tokens de l’API

Aucun tarif API v2-late n’est publié pour le comparer aux quatre tarifs v1. Les coûts opérationnels dépendent donc principalement de choix de déploiement que la fiche du modèle ne chiffre pas.

Le guide Hugging Face consacré à la late interaction fournit un ordre de grandeur utile avec un autre modèle : un exemple de 4,874 passages a produit 608,414 vecteurs de tokens et 311.5 MB de stockage float32 brut, tandis qu’un index PLAID compressé occupait 92 MB. Ces chiffres ne constituent pas une estimation pour v2-late, mais ils montrent pourquoi « 128 dimensions » ne signifie pas « petit index ». Le nombre de tokens est le véritable multiplicateur.

Le débit d’indexation doit lui aussi être mesuré sur votre matériel. Dans un retour d’expérience publié par un utilisateur de LocalLLaMA, pplx-embed-v1-4b a mis environ 45 minutes pour traiter 10,000 vecteurs, contre 6 minutes pour Qwen3-Embedding-4B sur une A100 80GB. Ce retour concerne v1, pas v2-late : il invite donc à mesurer le débit des embeddings Perplexity, sans constituer une affirmation de performance sur v2-late.

« Je pense que cela vient peut-être du fait que pplx embed utilise une attention bidirectionnelle plutôt qu’une attention masquée standard. » — u/Velocita84, r/LocalLLaMA

Quelle architecture choisir ?

Je recommande de tester le fonctionnement croisé 0.6B/9B sur 100 à 500 pages représentatives avant de construire un index complet. Incluez des pages numérisées, des tableaux, des mises en page sur plusieurs colonnes ainsi que des cas où la réponse s’étend sur deux pages. Mesurez le rappel au k visé, le débit d’encodage des pages, la taille brute et compressée de l’index, ainsi que la latence des requêtes. Ces données seront bien plus utiles que l’application du tarif par token v1 à un modèle qui n’est pas encore vendu via cette API.

FAQ sur la recherche dans les PDF avec pplx-embed-v2-late

pplx-embed-v2-late a-t-il un tarif API ?

Pas dans la documentation publique de l’Embeddings API Perplexity consultée pour ce guide. Les tarifs publiés, de $0.004 à $0.05 par million de tokens, concernent les modèles v1 standard et contextualisés.

pplx-embed-v2-late est-il officiellement disponible ?

Oui. Perplexity publie sur Hugging Face des checkpoints open-weight 0.6B et 9B. La publication des poids et la disponibilité d’une API managée sont deux étapes distinctes.

La recherche dans des PDF nécessite-t-elle un OCR ?

Non, pas pour le signal de recherche visuelle. Rendez chaque page sous forme d’image et encodez-la comme un document. L’OCR ou le texte extrait reste utile pour le filtrage, les citations, l’accessibilité et la recherche de secours.

Le modèle 0.6B peut-il interroger un index construit avec le 9B ?

La fiche du modèle Perplexity indique que les deux modèles partagent un espace d’embedding et prennent en charge cette configuration. Mesurez néanmoins la qualité sur votre corpus, car la fiche ne publie pas l’écart de rappel entre les modèles.

Peut-on mélanger les textes et les pages image dans un même lot ?

Non. La fiche du modèle précise que les entrées texte et image mixtes ne sont pas prises en charge dans un même lot d’encodage. Gardez des appels d’encodage homogènes pour les textes et les images.

Faut-il encore utiliser un reranker ?

Pas systématiquement. MaxSim est déjà la méthode de scoring de la late interaction, mais un premier étage dense suivi d’un reranking v2-late peut être plus pratique que l’analyse de chaque vecteur de token de chaque page dans un corpus volumineux.

Quel est le coût exact du stockage par page PDF ?

Perplexity ne publie pas de calculateur de stockage v2-late au niveau de la page. Estimez-le à partir du nombre de tokens conservés par page, de la précision des vecteurs, des métadonnées et de la compression de l’index, puis validez le résultat sur un échantillon représentatif.

Faut-il choisir le 0.6B ou le 9B ?

Choisissez le 9B si la qualité de l’indexation hors ligne est prioritaire et que vous pouvez absorber le coût du modèle et de la tâche d’indexation. Le 0.6B convient à un déploiement plus léger ou à l’encodage des requêtes, notamment dans la configuration documentée avec un index 9B. L’écart entre les benchmarks est mesurable, mais la fiche du modèle ne donne aucune règle universelle en matière de qualité ou de latence.

La décision tient en quelques mots : si vous avez besoin aujourd’hui d’un endpoint Perplexity managé avec un tarif connu, v2-late ne répond pas encore à ce besoin. Si vous pouvez auto-héberger le modèle et que vos PDF contiennent des informations que l’OCR ou le découpage textuel perdent, rendez un jeu de pages représentatif et mesurez le pipeline late-interaction avant de le déployer à grande échelle.