pplx-embed-v2-late: API-Preise und Setup für PDF-Retrieval

Wer ein PDF-Suchsystem mit pplx-embed-v2-late kalkuliert, übersieht leicht den entscheidenden Punkt: Perplexity hat die Modellgewichte veröffentlicht, aber weder einen API-Preis für v2-late genannt noch die Modelle im öffentlichen Katalog der Embeddings API aufgeführt. Der praktikable Weg führt derzeit über selbst gehostetes multimodales Retrieval; die API-Preise der aktuellen v1-Modelle taugen lediglich als Vergleichswert.

Kein Tarif für v2-late in der öffentlichen Embeddings API

Stand 7. Oktober 2026 führt der offizielle Quickstart zur Embeddings API vier v1-Modelle auf. pplx-embed-v2-late-0.6b und pplx-embed-v2-late-9b fehlen dort. Eine belastbare API-Kostenschätzung pro Token für v2-late gibt es deshalb noch nicht.

Das sind nutzungsbasierte API-Tarife, keine Preise für die Late-Interaction-Familie. In der Ankündigung von Perplexity heißt es, dass Late-Interaction-, dichte und kontextualisierte Embeddings schrittweise auf der API Platform ausgerollt werden. Das beschreibt einen Rollout, nicht einen bereits verfügbaren v2-late-Endpunkt oder eine Preiszusage.

Für die Beschaffungsentscheidung sollte das Budget daher in zwei Positionen aufgeteilt werden:

1. Ausgaben für eine Managed API: für die oben genannten v1-Modelle verfügbar; ein Tarif für v2-late wurde nicht veröffentlicht.
2. Ausgaben fürs Self-Hosting: GPU-Zeit, Seiten-Rendering, Modellspeicher, Speicher für den Token-Vektorindex und Query Serving für v2-late.

Es wäre falsch, einen v1-Preis mit der Anzahl der PDF-Seiten zu multiplizieren und das Ergebnis als Angebot für v2-late auszugeben. Die Modelle verwenden unterschiedliche Repräsentationen, und die v1 API bettet Text ein – nicht den dokumentierten Workflow mit gerenderten Seiten.

Was mit pplx-embed-v2-late ausgeliefert wird

Perplexity veröffentlicht zwei Late-Interaction-Checkpoints: pplx-embed-v2-late-0.6b und pplx-embed-v2-late-9b. Laut Model Card des 9B-Modells hat das kleinere Modell 340M aktive Parameter, das größere 7.4B. Beide erzeugen pro Token Vektoren mit 128 Dimensionen und bewerten mit MaxSim, statt eine Seite auf einen einzelnen Vektor zu verdichten.

Die Benchmarkwerte stammen aus der Model Card und nicht aus einem unabhängigen PDF-Test: Das 9B-Modell liegt beim Image Retrieval um 2.9 Prozentpunkte und beim Markdown Retrieval um 3.5 Punkte vorne, bei rund 21.8-mal so vielen aktiven Parametern. Beide Checkpoints stehen auf Hugging Face unter der MIT-Lizenz.

Für die Bereitstellung ist vor allem der gemeinsame Embedding-Raum relevant: Laut Perplexity lässt sich ein mit 9B erstellter Index mit dem 0.6B-Modell abfragen. 9B kann also für die Offline-Kodierung von Dokumenten und 0.6B für Queries eingesetzt werden – allerdings erst nach einer Prüfung des Cross-Model-Recalls. Der Speicherbedarf des mit 9B erstellten Indexes entfällt dadurch nicht.

Ein praxistaugliches Setup für PDF-Retrieval

Der v2-late-Workflow behandelt jede gerenderte PDF-Seite als Bilddokument. Eine Textanfrage kann damit Wörter, Tabellenstruktur, Diagramme oder das Seitenlayout treffen, ohne dass OCR die primäre Retrieval-Repräsentation sein muss. Dieses Muster für visuelle Dokumente beschreibt auch die Dokumentation zum Visual Retrieval von Sentence Transformers.

„OCR-frei“ heißt dabei nicht, dass OCR verboten ist: Sie liefert nur nicht das eigentliche Retrieval-Signal. Extrahierter Text bleibt für Filter, Quellenangaben, Barrierefreiheit und eine Fallback-Suche nützlich.

1. Seiten rendern und Metadaten mitführen

Jede Seite sollte bei stabiler Auflösung als RGB-Bild gerendert werden. Daneben gehört ein Datensatz mit den zugehörigen Metadaten:

document_id und page_number gehören in den Retrieval-Datensatz und nicht ausschließlich in den Bilddateinamen. Wird eine relevante Seite gefunden, sollten auch die angrenzenden Seiten desselben Dokuments geladen werden: Tabellen, Fußnoten und Definitionen reichen oft über Seitenumbrüche hinweg.

2. Den passenden Encoder installieren

Die Model Card des 9B-Modells setzt aktuelle Bibliotheken voraus:

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

Das bereitgestellte Beispiel verwendet MultiVectorEncoder; für das Laden des 9B-Checkpoints wird CUDA ausgewählt:

from PIL import Image
from sentence_transformers import MultiVectorEncoder

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

Wenn der größere Checkpoint nicht auf die verfügbare Serving-Hardware passt, ist stattdessen die 0.6B-Kennung zu verwenden. Eine offizielle Mindestanforderung an VRAM, eine Durchsatztabelle oder eine Latenzgarantie nennt die Model Card nicht. Seitenauflösung, Batch-Größe und GPU sollten daher vor der Kapazitätsplanung gemessen werden.

3. Textanfragen und Seitenbilder getrennt kodieren

Das Modell erwartet asymmetrische Aufrufe: Textanfragen laufen über encode_query, gerenderte Seiten über 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)

Text- und Bilddokumente dürfen nicht gemeinsam in einem gemischten Encoding-Batch landen. Die Model Card weist ausdrücklich auf getrennte homogene Eingaben sowie die für diesen Checkpoint erwartete Marker-Konfiguration [Q] / [D] hin. model.similarity() wendet MaxSim auf die Repräsentationen auf Token-Ebene an.

Für eine echte Sammlung werden Seiten offline kodiert, die Multi-Vektor-Repräsentation in einem Late-Interaction-Index gespeichert und die Seitenmetadaten in einem separaten Store gehalten. Bei kleinen Beständen reicht vollständiges Scoring. In größerem Maßstab braucht es ein System mit MaxSim-Unterstützung oder einen dichten Retriever als erste Stufe, gefolgt von v2-late-Reranking für eine begrenzte Kandidatenmenge.

4. Trefferseiten abrufen und den Kontext erweitern

Ein Treffer auf Seitenebene sollte in der Regel Folgendes zurückgeben:

1. Die gefundene Seite samt Score.
2. Dokument-ID und Quell-Link.
3. Eine oder zwei Nachbarseiten aus demselben Dokument.
4. Das Seitenbild und gegebenenfalls extrahierten Text für die Quellenangabe.

So wird aus einem visuell präzisen Seitentreffer keine unvollständige Antwort, nur weil die Definition auf Seite 16 beginnt und sich die Tabelle auf Seite 17 fortsetzt. Zugleich bleibt das Ergebnis nachvollziehbar: Nutzer sehen das Diagramm oder die Tabelle, die zum Treffer geführt haben, statt einer unsichtbaren OCR-Umwandlung vertrauen zu müssen.

Das Kostenmodell jenseits von API-Tokens

Ein veröffentlichter API-Preis für v2-late, der sich mit den vier v1-Tarifen vergleichen ließe, existiert nicht. Die Betriebskosten werden daher vor allem von Bereitstellungsentscheidungen bestimmt, für die die Model Card keine Preise nennt.

Der Late-Interaction-Leitfaden von Hugging Face liefert einen nützlichen Größenvergleich anhand eines anderen Modells: Ein Beispiel mit 4,874 Passagen erzeugte 608,414 Token-Vektoren und benötigte 311.5 MB Rohspeicher als float32; ein komprimierter PLAID-Index kam auf 92 MB. Das ist keine Schätzung für v2-late, verdeutlicht aber, warum „128 Dimensionen“ nicht automatisch einen kleinen Index bedeuten. Entscheidend ist die Token-Anzahl.

Auch der Indexing-Durchsatz sollte auf der eigenen Hardware gemessen werden. In einem Praxisbericht auf LocalLLaMA benötigte pplx-embed-v1-4b auf einer A100 80GB rund 45 Minuten für 10,000 Vektoren, gegenüber 6 Minuten bei Qwen3-Embedding-4B. Der Bericht betrifft v1 und nicht v2-late. Er ist daher ein Hinweis darauf, den Embedding-Durchsatz von Perplexity selbst zu messen – keine Aussage zur v2-late-Performance.

„I think it might be because pplx embed uses bidirectional attention rather than standard masked attention.“ — u/Velocita84, r/LocalLLaMA

Welcher Bereitstellungsweg passt zu welchem Bedarf?

Meine Empfehlung: Den Cross-Model-Pfad mit 0.6B und 9B zunächst auf 100 bis 500 repräsentativen Seiten testen, bevor ein vollständiger Index entsteht. Dazu gehören gescannte Seiten, Tabellen, mehrspaltige Layouts und Seiten, deren Antwort über einen Umbruch hinweg reicht. Erfasst werden sollten Recall beim gewünschten k, Durchsatz beim Seiten-Encoding, rohe und komprimierte Indexgröße sowie Query-Latenz. Diese Daten sind aussagekräftiger, als einen v1-Tokenpreis auf ein Modell zu übertragen, das über diese API noch gar nicht verkauft wird.

FAQ: PDF-Retrieval mit pplx-embed-v2-late

Hat pplx-embed-v2-late einen API-Preis?

Nicht in der öffentlichen Dokumentation zur Perplexity Embeddings API, die für diesen Leitfaden geprüft wurde. Die veröffentlichten Preise von $0.004 bis $0.05 pro einer Million Tokens gelten für Standard- und kontextualisierte v1-Modelle.

Ist pplx-embed-v2-late offiziell veröffentlicht?

Ja. Perplexity stellt auf Hugging Face Open-Weight-Checkpoints mit 0.6B und 9B bereit. Die Veröffentlichung von Gewichten und die Verfügbarkeit als Managed API sind getrennte Meilensteine.

Braucht PDF-Retrieval OCR?

Nein, nicht für das visuelle Retrieval-Signal. Jede Seite wird als Bild gerendert und als Dokument kodiert. OCR oder extrahierter Text bleiben für Filter, Quellenangaben, Barrierefreiheit und die Fallback-Suche sinnvoll.

Kann das 0.6B-Modell einen mit 9B erstellten Index abfragen?

Laut Model Card von Perplexity teilen die beiden Modelle einen Embedding-Raum und unterstützen dieses Setup. Die Qualität sollte auf dem eigenen Korpus gemessen werden, denn die Card veröffentlicht keinen Retrieval-Unterschied für den Cross-Model-Betrieb.

Können Text und Seitenbilder gemeinsam in einen Batch?

Nein. Laut Model Card werden gemischte Text- und Bildeingaben nicht im selben Encoding-Batch unterstützt. Die Encoding-Aufrufe für Text und Bilder müssen homogen bleiben.

Brauche ich zusätzlich einen Reranker?

Nicht zwingend. MaxSim ist bereits das Late-Interaction-Scoring-Verfahren. Bei einem großen Korpus kann jedoch ein dichter Retriever als erste Stufe mit anschließendem v2-late-Reranking praktikabler sein, als jeden Seiten-Token-Vektor zu durchsuchen.

Wie hoch sind die exakten Speicherkosten pro PDF-Seite?

Perplexity veröffentlicht keinen v2-late-Rechner für Speicherbedarf pro Seite. Die Schätzung muss aus der Anzahl der beibehaltenen Seiten-Tokens, der Vektorpräzision, Metadaten und Indexkomprimierung abgeleitet und anschließend mit einem repräsentativen Sample validiert werden.

Sollte ich 0.6B oder 9B wählen?

9B ist die Wahl, wenn die Qualität beim Offline-Indexing Priorität hat und Modell sowie Indexing-Job finanzierbar sind. 0.6B eignet sich für kleinere Bereitstellungen oder als Query-Encoder, auch im dokumentierten Shared-Space-Setup gegen einen 9B-Index. Der Benchmark-Abstand ist messbar, doch die Model Card liefert keine universelle Regel für Qualität oder Latenz.

Die Go/No-Go-Prüfung ist kurz: Wer heute einen Managed Perplexity-Endpoint zu einem bekannten Preis braucht, kann diese Anforderung mit v2-late noch nicht erfüllen. Wer selbst hosten kann und PDFs verarbeitet, deren Informationsgehalt durch OCR oder Text-Chunking verloren geht, sollte eine repräsentative Seitenmenge rendern und die Late-Interaction-Pipeline messen, bevor sie skaliert wird.