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 模型，並未包含 pplx-embed-v2-late-0.6b 或 pplx-embed-v2-late-9b。因此，目前沒有足夠依據替 v2-late 估算每 token 的 API 費用。

上述是隨用隨付的 API 費率，不是 late-interaction 系列的價格。Perplexity 的發布公告表示，late-interaction、dense 與 contextual embeddings 將逐步在 API Platform 上推出。但這只是發布規畫，並不代表 v2-late 已經有可用端點，更不是價格承諾。

如果是為了採購或預算規畫，建議把成本拆成兩條線：

1. 託管 API 費用：目前適用於上列 v1 模型；v2-late 尚未公布費率。
2. 自架成本：包括 GPU 運算時間、頁面渲染、模型儲存、token-vector 索引儲存，以及查詢服務。

不要直接拿 v1 價格乘上 PDF 頁數，就當成 v2-late 的報價。兩者採用不同的表示方式，而且 v1 API 做的是文字 embedding，並不是文件中描述的渲染頁面工作流程。

pplx-embed-v2-late 實際提供了什麼

Perplexity 目前公開兩個 late-interaction checkpoint：pplx-embed-v2-late-0.6b 與 pplx-embed-v2-late-9b。9B 模型卡指出，較小模型有 340M 個 active parameters，較大模型則為 7.4B。兩者都會為每個 token 輸出 128 維向量，並使用 MaxSim，而不是把整頁壓縮成一個向量。

這些 benchmark 數據來自模型卡，並不是獨立進行的 PDF 測試：9B 在影像檢索上領先 2.9 個百分點，在 Markdown 檢索上領先 3.5 個百分點，但 active parameters 約是 0.6B 的 21.8 倍。兩個 checkpoint 都以 MIT 授權發布於 Hugging Face。

部署時最重要的細節，是兩者共用同一個 embedding 空間。Perplexity 表示，用 9B 建立的索引可以交給 0.6B 查詢。實務上可以用 9B 離線編碼文件，再只用 0.6B 處理查詢，但前提是先驗證跨模型的 recall；這種做法並不會減少 9B 索引本身的儲存需求。

一套可落地的 PDF 檢索架構

v2-late 的工作流程，是把 PDF 每一頁渲染成影像文件。這樣一來，文字查詢不只能對應頁面上的文字，也能匹配表格結構、圖表與版面配置，而不必把 OCR 當成主要檢索表示。這正是 Sentence Transformers 視覺檢索文件所描述的視覺文件檢索模式。

所謂「免 OCR」，指的是 OCR 不負責提供主要的檢索訊號；抽取出的文字仍然很適合用於篩選、引用、無障礙功能，以及備援搜尋。

1. 渲染頁面並保留中繼資料

先把每一頁渲染成固定解析度的 RGB 影像，再為每頁建立一筆對應記錄：

請把 document_id 與 page_number 存在檢索記錄中，不要只依賴影像檔名。找到相關頁面後，也要從同一份文件抓取前後相鄰頁面，因為表格、註腳或定義經常會跨頁。

2. 安裝相容的 encoder

9B 模型卡要求使用較新的函式庫：

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

官方範例使用 MultiVectorEncoder，而模型卡在載入 9B checkpoint 時選擇 CUDA：

from PIL import Image
from sentence_transformers import MultiVectorEncoder

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

如果現有服務硬體無法容納較大的 checkpoint，就改用 0.6B。模型卡沒有提供正式的最低 VRAM 要求、吞吐量表或延遲保證，因此在決定容量前，應先用實際頁面解析度、batch size 與 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)

不要把文字與影像文件放進同一個混合編碼 batch。模型卡特別說明，這個 checkpoint 預期使用分開且同質的輸入，以及 [Q] ／[D] 標記設定。model.similarity()會對 token 層級的表示套用 MaxSim。

面對真實文件集合時，應該離線編碼所有頁面，把多向量表示存進 late-interaction 索引，並在旁邊的儲存層保留頁面中繼資料。小型集合可以直接做 exhaustive scoring；規模放大後，則應使用支援 MaxSim 的系統，或先用 dense retriever 找出受控數量的候選，再交給 v2-late 重排。

4. 找到頁面後，再擴大證據範圍

頁面層級的命中結果通常應包含：

1. 命中的頁面與分數。
2. 文件 ID 與來源連結。
3. 同一份文件的一到兩頁相鄰頁面。
4. 頁面影像，以及可選的抽取文字供引用使用。

如此一來，即使定義從第 16 頁開始、表格延續到第 17 頁，也不會因為只命中單頁而產生不完整的答案。同時，整個結果也更容易檢查：使用者可以直接看到產生匹配的圖表或表格，而不是只能相信一段看不見的 OCR 轉換結果。

不要只看 API token：完整成本模型

目前沒有公開的 v2-late API 價格可與四種 v1 費率比較。因此，實際營運成本主要取決於模型卡沒有定價的部署選擇。

Hugging Face 的 late-interaction 指南提供了另一個模型的規模參考：一個包含 4,874 個 passage 的範例，產生 608,414 個 token vectors，原始 float32 儲存空間為 311.5 MB；壓縮後的 PLAID 索引則使用 92 MB。這些數字不是 v2-late 的估算，但足以說明「128 維」不等於「索引很小」，真正重要的放大因素是 token 數量。

索引建立速度也應該在自己的硬體上實測。一份使用者發布於 LocalLLaMA 的報告指出，在 A100 80GB 上，pplx-embed-v1-4b 每 10,000 個向量約需 45 分鐘，Qwen3-Embedding-4B 則需 6 分鐘。這份報告測的是 v1，不是 v2-late；它能提醒你的，是 Perplexity embedding 的吞吐量必須實測，而不是替 v2-late 做效能宣稱。

「我認為這可能是因為 pplx embed 使用雙向注意力，而不是標準的 masked attention。」— u/Velocita84，r/LocalLLaMA

該選哪一種部署路線？

我的建議是，先用 100 到 500 個具代表性的頁面，測試 0.6B 與 9B 的跨模型流程，再決定是否建立完整索引。測試樣本應包含掃描頁面、表格、多欄版面，以及答案跨越頁面邊界的情況。同時記錄目標 k 下的 recall、頁面編碼吞吐量、原始與壓縮後的索引大小，以及查詢延遲。這些資料比把 v1 token 價格套到一個尚未透過該 API 販售的模型上，更能支援實際決策。

pplx-embed-v2-late PDF 檢索常見問題

pplx-embed-v2-late 有 API 價格嗎？

在本文查閱的 Perplexity 公開 Embeddings API 文件中，還沒有。已公布的每百萬 token $0.004 至 $0.05 價格，適用的是 v1 標準模型與 contextualized 模型。

pplx-embed-v2-late 已經正式發布了嗎？

是。Perplexity 已在 Hugging Face 公開 0.6B 與 9B 的 open-weight checkpoint。但釋出模型權重，與提供託管 API，是兩個不同階段。

PDF 檢索一定需要 OCR 嗎？

不需要，至少主要的視覺檢索訊號不需要。把每一頁渲染成影像，再將其編碼為文件即可。OCR 或抽取文字仍可用於篩選、引用、無障礙功能與備援搜尋。

0.6B 可以查詢由 9B 建立的索引嗎？

Perplexity 的模型卡表示，兩個模型共用 embedding 空間，支援這種部署方式。不過仍應在自己的語料庫上測量品質，因為模型卡沒有公布跨模型檢索差異。

文字與影像頁面可以放在同一個 batch 嗎？

不行。模型卡指出，同一個編碼 batch 不支援混合文字與影像輸入。文字與影像的編碼呼叫必須各自保持同質。

還需要另外使用 reranker 嗎？

不一定。MaxSim 本身就是 late-interaction 的評分方式；但在大型語料庫中，先用 dense retriever 找出候選，再用 v2-late 重排，可能比逐一掃描所有頁面 token 向量更實際。

每頁 PDF 的確切儲存成本是多少？

Perplexity 沒有公布 v2-late 的頁面層級儲存計算器。應根據保留的頁面 token 數量、向量精度、中繼資料與索引壓縮方式進行估算，再用具代表性的樣本驗證。

該選 0.6B 還是 9B？

如果優先考量離線索引品質，且負擔得起模型與索引工作，就選 9B。如果需要較小型的部署或查詢 encoder，則可選 0.6B，包括以 9B 索引搭配共用空間的文件化部署方式。兩者 benchmark 的差距確實可量化，但模型卡沒有提供適用所有情境的品質或延遲規則。

最後的 go／no-go 判斷其實很簡單：如果你今天就需要一個價格明確的 Perplexity 託管端點，v2-late 還無法滿足這項要求。如果你能自行部署，而且 PDF 內容包含 OCR 或文字切分容易遺失的資訊，就先渲染一批具代表性的頁面，在擴大規模前完成 late-interaction 流程的 benchmark。