pplx-embed-v2-late API 定价与 PDF 检索配置指南

如果你正在围绕 pplx-embed-v2-late 规划 PDF 搜索系统，最关键的信息其实很容易被忽略：Perplexity 已经发布了模型权重，但尚未公布 v2-late 的 API 价格，也没有将它列入公开的 Embeddings API 模型目录。目前真正可用的路径是自托管多模态检索，而现有 v1 API 价格只能作为对照，不能当作 v2-late 的报价。

先说结论：v2-late 尚未出现在公开 Embeddings API 价目表中

截至 2026 年 10 月 7 日，官方 Embeddings API 快速入门文档列出了 4 个 v1 模型，但没有 pplx-embed-v2-late-0.6b 或 pplx-embed-v2-late-9b。因此，目前无法为 v2-late 给出有依据的按 token API 价格估算。

当前 API 文档中列出的 Perplexity 模型	每 100 万 token 的价格	适用输入
`pplx-embed-v1-0.6b`	$0.004	独立文本、查询、句子
`pplx-embed-v1-4b`	$0.030	独立文本、查询、句子
`pplx-embed-context-v1-0.6b`	$0.008	相关文档片段
`pplx-embed-context-v1-4b`	$0.050	相关文档片段

上表是按量付费的 API 费率，不是 late-interaction 系列模型的价格。Perplexity 的发布公告表示，late-interaction、dense 和 contextual embeddings 将逐步登陆 API Platform。但这只是发布路线说明，并不代表 v2-late 已经拥有可调用的 API 端点，也不构成价格承诺。

做采购和预算时，最好把成本拆成两部分：

托管 API 支出：目前适用于上面列出的 v1 模型；v2-late 尚未公布费率。
自托管支出：包括 GPU 运行时间、页面渲染、模型存储、token 向量索引存储，以及 v2-late 的查询服务。

不要把 v1 价格乘以 PDF 页数，再把结果当成 v2-late 报价。两者使用的表示方式不同，而且 v1 API 针对的是文本 embedding，并不是文档中所描述的渲染页面工作流。

pplx-embed-v2-late 到底提供了什么

Perplexity 发布了两个 late-interaction 检查点：pplx-embed-v2-late-0.6b 和 pplx-embed-v2-late-9b。9B 模型卡显示，较小模型有 340M 个活跃参数，较大模型有 7.4B 个活跃参数。两个模型都会为每个 token 输出 128 维向量，并使用 MaxSim，而不是把整页压缩成一个向量。

模型	活跃参数	ViDoRe v3 图像 nDCG@10	ViDoRe v3 Markdown nDCG@10	实际定位
`pplx-embed-v2-late-0.6b`	340M	62.3%	61.2%	更轻量的查询模型或小型部署
`pplx-embed-v2-late-9b`	7.4B	65.2%	64.7%	更高质量的索引与检索模型

这些 benchmark 数据来自模型卡，并不是独立的 PDF 测试结果：在图像检索上，9B 领先 2.9 个百分点；在 Markdown 检索上领先 3.5 个百分点，同时活跃参数约为 0.6B 模型的 21.8 倍。两个检查点都以 MIT 许可证发布在 Hugging Face 上。

部署时最值得注意的是两者共享 embedding 空间：Perplexity 表示，可以使用 0.6B 模型查询由 9B 模型构建的索引。你可以用 9B 离线编码文档，再仅用 0.6B 处理查询，但应先验证跨模型召回率；这种做法并不会减少 9B 索引本身的存储需求。

一套可落地的 PDF 检索方案

v2-late 的工作流会把 PDF 的每一页渲染成图像文档。这样，文本查询就可以直接匹配页面中的文字、表格结构、图表或版式，不必把 OCR 作为主要检索表示。这与 Sentence Transformers 视觉检索文档介绍的视觉文档检索模式一致。

“无需 OCR”指的是 OCR 不作为检索信号，并不意味着完全不需要提取文本。提取文本仍然适合用于过滤、引用、无障碍访问和兜底搜索。

1. 渲染页面，并保留元数据

将每一页渲染为 RGB 图像，并保持稳定的分辨率，同时为每页保存一条记录：

字段	示例
`document_id`	`contract-2026-04`
`page_number`	`17`
`image_path`	`pages/contract-2026-04/017.png`
`source_uri`	内部 PDF 对象 URL
`text_fallback`	可选的提取文本

请把 document_id 和 page_number 放在检索记录中，不要只编码进图片文件名。找到相关页面后，还应从同一文档中取回相邻页面，因为表格、脚注或定义经常会跨页出现。

2. 安装兼容的 encoder

9B 模型卡要求使用较新的库：

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

官方示例使用 MultiVectorEncoder，模型卡则选择 CUDA 来加载 9B 检查点：

from PIL import Image
from sentence_transformers import MultiVectorEncoder

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

如果现有服务硬件无法容纳更大的检查点，可以改用 0.6B 标识符。模型卡没有提供官方最低显存要求、吞吐量表或延迟保证，因此在确定容量之前，应针对实际页面分辨率、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。模型卡明确要求使用分别的同质输入，以及该检查点预期的 [Q] / [D] 标记配置。model.similarity() 会基于 token 级表示执行 MaxSim。

在真实文档集合中，应离线编码页面，将多向量表示持久化到 late-interaction 索引中，并把页面元数据保存在旁路存储中。小型集合可以直接进行穷举打分；规模更大时，应使用支持 MaxSim 的系统，或者先用 dense 检索器进行第一阶段召回，再对受控候选集使用 v2-late 重排。

4. 先检索页面，再扩展证据窗口

一个页面级命中结果通常应包含：

匹配页面及其分数。
文档 ID 和来源链接。
同一文档中的一到两个相邻页面。
页面图像，以及用于引用的可选提取文本。

这样可以避免页面匹配很准确，但最终答案不完整——例如定义从第 16 页开始，表格却延续到第 17 页。同时，结果也更容易检查：用户可以直接看到产生匹配的图表或表格，而不是只能相信某个隐藏的 OCR 转换结果。

别只盯着 API token：完整成本模型

目前没有公开的 v2-late API 价格可与 4 个 v1 费率进行比较。因此，实际运营成本主要取决于模型卡没有定价的部署环节。

成本因素	已确认信息	规划时的含义
模型权重	Hugging Face 上的 9B 仓库显示约 33.6 GB，使用 F32 张量	在开始建立索引之前，权重存储和加载就已经是重要成本
表示方式	每个 token 生成一个 128 维向量，并通过 MaxSim 打分	每页会产生多个向量，而不是一个 dense 向量
索引构建	9B 可以构建由 0.6B 查询	如果查询量较高，应把更多计算放进离线任务
检索	Late interaction 会比较查询 token 与文档 token	使用支持 MaxSim 的索引，或者在重打分前限制候选数量
API 计费	尚未公布 v2-late 费率	目前不要预测托管 API 支出

Hugging Face 的 late-interaction 指南提供了一个来自其他模型的规模参考：在一个包含 4,874 个 passage 的示例中，模型生成了 608,414 个 token 向量，原始 float32 存储空间为 311.5 MB；经过压缩的 PLAID 索引则使用了 92 MB。这些数字不能直接当作 v2-late 的估算，但足以说明“128 维”并不等于“小索引”。真正重要的放大因素是 token 数量。

索引吞吐量也必须在自己的硬件上进行测试。在一份真实用户发布的 LocalLLaMA 报告中，pplx-embed-v1-4b 在 A100 80GB 上处理 10,000 个向量大约需要 45 分钟，而 Qwen3-Embedding-4B 需要 6 分钟。这份报告针对的是 v1，不是 v2-late，因此它只能说明需要测量 Perplexity embedding 的吞吐量，不能视为 v2-late 的性能结论。

“我觉得这可能是因为 pplx embed 使用了双向注意力，而不是标准的 masked attention。”——u/Velocita84，r/LocalLLaMA

应该选择哪条部署路线？

需求	当前最合适的路径	原因
使用托管端点，低成本处理纯文本 RAG	Perplexity v1 API	公开价格为每 100 万 token $0.004 至 $0.05
图表、表格、扫描页面和版式都很重要	自托管 `pplx-embed-v2-late`	文档描述的工作流可以直接检索渲染页面
大规模语料库，且查询频繁	9B 离线索引加 0.6B 查询 encoder，或 dense-first 加 v2-late 重排	将索引质量与查询时计算分开
小型原型或硬件受限的测试	在具有代表性的页面样本上使用 0.6B 检查点	活跃参数更少，但仍需测试页面编码速度和存储占用
硬性要求是使用托管的 v2-late 端点	等待官方 API 模型 ID 和价目表	当前公开 embedding 文档中两者都不存在

我的建议是：先在 100 到 500 个具有代表性的页面上验证 0.6B 与 9B 的跨模型方案，再决定是否建立完整索引。样本中应包含扫描页面、表格、多栏版式，以及答案跨越页面边界的页面。记录目标 k 下的召回率、页面编码吞吐量、原始和压缩后的索引大小，以及查询延迟。这些实测数据，比把 v1 token 价格套用到一个尚未通过该 API 售卖的模型上更有价值。

pplx-embed-v2-late PDF 检索常见问题

pplx-embed-v2-late 有 API 价格吗？

在本指南查阅的 Perplexity 公开 Embeddings API 文档中，还没有。已公布的每百万 token $0.004 至 $0.05 价格，适用于 v1 标准模型和上下文模型。

pplx-embed-v2-late 已正式发布吗？

是的。Perplexity 已在 Hugging Face 上发布 0.6B 和 9B 开放权重检查点。但模型权重发布与托管 API 可用是两个不同阶段。

PDF 检索需要 OCR 吗？

如果只看视觉检索信号，不需要。将每页渲染成图像，再作为文档进行编码即可。OCR 或提取文本仍然适合用于过滤、引用、无障碍访问和兜底搜索。

0.6B 模型能查询由 9B 构建的索引吗？

Perplexity 的模型卡表示，两个模型共享 embedding 空间，并支持这种组合方式。不过仍应在自己的语料库上测试效果，因为模型卡没有公布跨模型检索的性能差异。

文本页面和图像页面可以放在同一个 batch 中吗？

不可以。模型卡表示，同一个编码 batch 不支持混合文本和图像输入。文本编码和图像编码应分别使用同质输入。

还需要额外的 reranker 吗？

不一定。MaxSim 本身已经是 late-interaction 打分方式，但在大规模语料库中，使用 dense 第一阶段检索器，再通过 v2-late 重排，通常比扫描所有页面 token 向量更实际。

每页 PDF 的确切存储成本是多少？

Perplexity 没有公布 v2-late 的页面级存储计算器。应根据保留的页面 token 数量、向量精度、元数据和索引压缩方式进行估算，然后使用具有代表性的样本验证。

应该选 0.6B 还是 9B？

如果优先考虑离线索引质量，并且能够承担模型与索引任务的成本，就使用 9B。如果需要更小的部署，或者只想使用查询 encoder，可以选择 0.6B；它也适用于文档中介绍的共享空间方案，用来查询 9B 索引。两者的 benchmark 差距是可以测量的，但模型卡没有给出适用于所有场景的质量或延迟规则。

最终的判断其实很简单：如果你今天就需要一个价格明确的托管 Perplexity 端点，v2-late 还无法满足这一要求。如果你可以自托管，而且 PDF 中包含 OCR 或文本切块容易丢失的信息，就先渲染一组具有代表性的页面，在扩大规模之前完成 late-interaction 流程的 benchmark。