pplx-embed-v2-lateのAPI料金とPDF検索環境の構築方法

pplx-embed-v2-lateを使ったPDF検索システムの予算を組むなら、まず押さえておきたい点があります。Perplexityはモデルの重みを公開していますが、v2-lateのAPI価格はまだ発表しておらず、公開中のEmbeddings APIのモデル一覧にも掲載していません。現時点で現実的なのは、マルチモーダル検索基盤を自前で運用する方法です。比較材料として、現行のv1 API料金を確認しておきましょう。

結論：v2-lateは公開中のEmbeddings API料金表に載っていない

2026年10月7日時点で、公式のEmbeddings APIクイックスタートに掲載されているのはv1モデル4種類です。pplx-embed-v2-late-0.6bとpplx-embed-v2-late-9bは含まれていないため、v2-lateについて信頼できるトークン単価を見積もることはまだできません。

ここで示したのは従量課金のAPI料金であり、late-interaction系モデルの価格ではありません。Perplexityのリリース発表では、late-interaction、dense、contextual embeddingsをAPI Platformに段階的に展開すると説明されています。ただし、これは展開方針の表明であって、v2-lateのエンドポイントや料金がすでに提供されているという意味ではありません。

導入費用を検討する際は、予算を次の2つに分けて考えるのが安全です。

1. マネージドAPIの利用料：上記のv1モデルでは利用可能。ただし、v2-lateの料金は未公開。
2. 自前運用の費用：GPU時間、ページのレンダリング、モデルの保存、トークンベクトルのインデックス保存、v2-lateによる検索処理。

v1の料金にPDFのページ数を掛けて、v2-lateの見積もりとして扱うのは避けてください。両者は表現形式が異なり、v1 APIはテキスト埋め込みです。一方、v2-lateで説明されているのはレンダリング済みページを使うワークフローです。

pplx-embed-v2-lateで利用できるモデルと特徴

Perplexityはlate-interactionモデルとして、pplx-embed-v2-late-0.6bとpplx-embed-v2-late-9bの2つのチェックポイントを公開しています。9Bのモデルカードによると、アクティブパラメータ数は小さいモデルが340M、大きいモデルが7.4Bです。どちらもトークンごとに128次元のベクトルを出力し、ページ全体を1本のベクトルにまとめるのではなく、MaxSimで照合します。

ベンチマーク値はモデルカードに記載された結果であり、独立したPDFテストの結果ではありません。9Bは画像検索で2.9ポイント、Markdown検索で3.5ポイント上回る一方、アクティブパラメータ数は約21.8倍です。どちらのチェックポイントもHugging Face上でMITライセンスが付与されています。

導入時に重要なのが、両モデルで共有される埋め込み空間です。Perplexityによれば、9Bで作成したインデックスを0.6Bで検索できます。ただし、モデル間での再現率を検証したうえで、オフラインの文書エンコードに9B、クエリ処理だけに0.6Bを使うようにしてください。この構成でも、9Bで作成したインデックスの保存領域が不要になるわけではありません。

実用的なPDF検索環境を構築する

v2-lateのワークフローでは、PDFの各ページを画像ドキュメントとして扱います。すると、テキストクエリからページ内の文字だけでなく、表の構造、グラフ、レイアウトまで検索できます。OCRを主要な検索表現にする必要はありません。これはSentence Transformersのビジュアル検索ドキュメントで説明されている、視覚的なドキュメント検索と同じ考え方です。

ここでいう「OCR不要」とは、OCR結果を検索シグナルにしなくてよいという意味です。抽出テキストは、絞り込み、引用、アクセシビリティ、フォールバック検索のために依然として役立ちます。

1. ページを画像化し、メタデータを保持する

まず、すべてのページを一定の解像度でRGB画像に変換し、各ページに対応するレコードを保存します。

document_idとpage_numberは、画像ファイル名だけに埋め込まず、検索レコードにも保持してください。関連ページが見つかったら、同じ文書の前後のページも取得します。表、脚注、定義がページをまたいで続くことは珍しくないためです。

2. 対応するエンコーダーをインストールする

9Bモデルのモデルカードでは、比較的新しいライブラリが必要とされています。

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

公式の例ではMultiVectorEncoderを使い、9Bチェックポイントの読み込み先としてCUDAを指定しています。

from PIL import Image
from sentence_transformers import MultiVectorEncoder

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

大きいチェックポイントを手元のサービング環境に載せられない場合は、0.6Bの識別子に置き換えてください。モデルカードには、必要なVRAMの最低値、スループット表、レイテンシー保証は記載されていません。ページ解像度、バッチサイズ、GPU構成を実環境で測定してから、必要なキャパシティを決めるべきです。

3. テキストクエリとページ画像を別々にエンコードする

このモデルでは、クエリとドキュメントで呼び出し方が異なります。クエリのテキストにはencode_queryを、レンダリングしたページには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)

テキストと画像のドキュメントを、1つの混在バッチにまとめないでください。モデルカードでも、入力は同種のものに分けること、そしてこのチェックポイントが想定する[Q] ／[D] マーカー設定が明記されています。model.similarity()は、トークン単位の表現に対してMaxSimを適用します。

実際の文書コレクションでは、ページのエンコードをオフラインで済ませ、マルチベクトル表現をlate-interaction対応のインデックスに保存します。ページのメタデータはサイドストアで管理します。小規模なコレクションなら全件スコアリングでも構いません。規模が大きくなったら、MaxSimに対応したシステムを使うか、dense検索を第1段階にして候補を絞り込み、その候補だけをv2-lateで再ランキングする構成が現実的です。

4. ページを検索し、前後の証拠範囲を広げる

ページ単位の検索ヒットでは、通常次の情報を返します。

1. 一致したページとスコア。
2. ドキュメントIDとソースリンク。
3. 同じ文書にある前後1〜2ページ。
4. 引用に使えるページ画像と、任意の抽出テキスト。

こうしておけば、ページ16で定義が始まり、ページ17で表が続くようなケースでも、視覚的には正しいページヒットが不完全な回答につながるのを防げます。検索結果の根拠をユーザーが確認できる点も重要です。見えないOCR変換を信頼するのではなく、ヒットの原因になったグラフや表を実際に確認できます。

APIトークン以外にかかるコスト

v2-lateのAPI価格は公開されていないため、4種類のv1料金と直接比較することはできません。したがって、実際の運用コストは、モデルカードでは価格が示されていないデプロイ構成に大きく左右されます。

Hugging Faceのlate-interactionガイドには、別モデルによる規模感の参考例があります。4,874パッセージの例では608,414個のトークンベクトルが生成され、float32の生データでは311.5 MB、圧縮したPLAIDインデックスでは92 MBになりました。これはv2-lateの見積もりではありませんが、「128次元だから小さなインデックスになる」とは限らないことが分かります。重要な倍率になるのは、トークン数です。

インデックス作成のスループットも、実際に使うハードウェアで測定してください。実ユーザーによるLocalLLaMAへの報告では、pplx-embed-v1-4bがA100 80GBで10,000ベクトルあたり約45分かかったのに対し、Qwen3-Embedding-4Bは6分でした。この報告はv1に関するもので、v2-lateの性能を示すものではありません。Perplexityの埋め込み処理を導入するなら、まずスループットを測定すべきだという注意材料です。

「pplx embedは、標準的なマスク付きアテンションではなく双方向アテンションを使っていることが原因かもしれません」— u/Velocita84、r/LocalLLaMA

どのデプロイ構成を選ぶべきか

私なら、いきなり全量のインデックスを作らず、まず100〜500ページの代表サンプルで0.6Bと9Bのクロスモデル構成を検証します。スキャンページ、表、複数段組み、ページをまたいで回答が続くページを必ず含めてください。目標とするkでの再現率、ページのエンコード速度、生および圧縮後のインデックスサイズ、クエリレイテンシーを記録します。まだこのAPIで販売されていないモデルに、v1のトークン単価をそのまま当てはめるより、こうした実測値のほうがはるかに有用です。

pplx-embed-v2-lateによるPDF検索：よくある質問

pplx-embed-v2-lateのAPI料金は公開されていますか？

このガイドで確認したPerplexityの公開Embeddings APIドキュメントには、掲載されていません。公開されている100万トークンあたり$0.004〜$0.05という料金は、v1の標準モデルとコンテキスト対応モデルに適用されます。

pplx-embed-v2-lateは正式にリリースされていますか？

はい。Perplexityは0.6Bと9BのオープンウェイトチェックポイントをHugging Faceで公開しています。ただし、重みの公開とマネージドAPIでの提供は別の段階です。

PDF検索にOCRは必要ですか？

視覚的な検索シグナルとしては必要ありません。各ページを画像としてレンダリングし、ドキュメントとしてエンコードします。OCRや抽出テキストは、絞り込み、引用、アクセシビリティ、フォールバック検索に引き続き利用できます。

0.6Bモデルで9Bが作成したインデックスを検索できますか？

Perplexityのモデルカードによれば、2つのモデルは埋め込み空間を共有しており、その構成に対応しています。ただし、モデルカードにはクロスモデル検索の差分が記載されていないため、自分のコーパスで品質を測定してください。

テキストと画像のページを同じバッチに入れられますか？

できません。モデルカードでは、同じエンコードバッチにテキストと画像の入力を混在させることはサポートされていないと説明されています。テキストと画像のエンコードは、同種の入力ごとに分けて実行してください。

それでも再ランキングモデルは必要ですか？

必ずしも必要ではありません。MaxSimがすでにlate-interactionのスコアリング方式だからです。ただし、大規模コーパスで全ページのトークンベクトルを調べるよりも、dense検索を第1段階に置き、v2-lateで候補を再ランキングする構成のほうが実用的な場合があります。

PDF 1ページあたりの正確な保存コストは分かりますか？

Perplexityは、v2-lateのページ単位の保存容量を計算するツールを公開していません。保持するページトークン数、ベクトルの精度、メタデータ、インデックス圧縮率から見積もり、代表的なサンプルで検証してください。

0.6Bと9Bのどちらを選ぶべきですか？

オフラインのインデックス品質を優先でき、モデルとインデックス作成処理のコストを負担できるなら9Bを選びます。小規模な構成やクエリエンコーダーには0.6Bが向いています。9Bのインデックスを0.6Bで検索する、モデルカードに記載された共有空間の構成も利用できます。ベンチマーク上の差は確認できますが、モデルカードには品質やレイテンシーについて一律に適用できる基準は示されていません。

導入可否の判断はシンプルです。料金が確定したマネージドPerplexityエンドポイントが今すぐ必要なら、v2-lateはその要件を満たせる段階にありません。一方、自前運用が可能で、PDFに含まれる情報をOCRやテキスト分割では取りこぼしそうなら、まず代表的なページをレンダリングし、late-interactionの検索パイプラインをベンチマークしてから規模を拡大してください。