Perplexity 已发布 pplx-embed-v2-late，这是一对 ColBERT 风格的多模态嵌入模型。它们有 2 种规格：0.6B 用于快速、低成本的查询，9B 用于最高质量。两个模型都能检索文本、图像和渲染后的 PDF 页面，并且共享同一个嵌入空间。
它是否可部署？ 可以，如果你自己托管。两个模型都已上线 Hugging Face ，采用 MIT 许可证。托管的 Perplexity API 端点已在计划中，但尚未上线。
简而言之
最好的方面
- 0.6B 模型在处理图像时使用约 340M 激活参数，且性能接近 8B 竞品。
- 9B 索引可以用 0.6B 查询进行搜索，在 0.6B 查询成本下可恢复文本上约一半的 9B 质量差距。
- 其 128 维词元向量比 2,048 到 4,096 维的竞品窄 16 倍到 32 倍。
- MIT 许可证，允许商业使用。
最差的方面
- 它为每个词元存储 1 个向量，因此索引大小随文档长度增长。
- 它在 ViDoRe v3 图像检索上并非第 1 名；腾讯的 EVIE 得分更高。
- 单个输入不能混合文本和图像。
- 所有分数均为自报数据，技术报告尚未发布。
模型规模及其运行环境
| 指标 | pplx-embed-v2-late-0.6b | pplx-embed-v2-late-9b |
|---|---|---|
| 总参数量 | 594M | 9B（Hugging Face 列为 8B） |
| 激活参数量 | 文本约 240M，图像 340M | 7.4B |
| Base 模型 | Qwen3.5-0.8B,剪枝至 12 个文本层 | Qwen3.5 |
| 输出 | 每个 token 128 维 | 每个 token 128 维 |
| 内存中的权重（bf16，我们的估计） | ~1.2 GB | ~16 到 18 GB |
| 预期使用的机器 | 笔记本、边缘设备或小型 GPU | 数据中心或大内存 GPU |
| Perplexity 建议的角色 | 实时查询编码器，100% 本地运行 | 构建文档索引 |
Perplexity 将 0.6B 模型设计为可在边缘设备上运行的轻量级查询编码器。两个 模型卡片 都显示了 CUDA GPU 的使用。它们需要 sentence-transformers >= 6.0.0 和 transformers >= 5.4.0。内存数字是我们按每参数 2 字节估算的，仅指权重。已发布的检查点以 F32 存储，这使下载大小翻倍。
性能表现如何：最好与最差成绩
以下所有数字均来自 Perplexity 的 公告:
| 基准测试 | 0.6B | 9B | 所处位置 |
|---|---|---|---|
| MADQA（代理式 PDF 问答，准确率） | 90.1% | 92.4%（最佳） | 超过 Mixedbread 的检索器（88.9%）；落后于 Mixedbread Agentic Search（93.4%） |
| 领域特定文本（72 项任务，nDCG@10） | 78.0% | 81.3% | 9B 在所有受测模型中领先 1.6pp；0.6B 落后 gemini-embedding-2 0.3pp |
| Q2D-Web （Recall@1000） | 73.6% | 74.8% | 两者均超过此前最佳的 69.3% |
| ViDoRe v3 图像（nDCG@10） | 62.3% | 65.2% | 0.6B 与 nemotron-colembed-v2-8b 相差在 1.2pp 以内；EVIE 领先 |
| ViDoRe v3 Markdown（nDCG@10） | 61.2%（最差） | 64.7% | 两者均优于测试的每一个外部模型 |
| BrowseComp+ （准确率） | 未提供 | 64.0%（最低） | 仍比下一个ColBERT模型高出4.9个百分点 |
最强结果： 在 MADQA 上达到 92.4%，由 9B 模型创下。最大优势在 BrowseComp+ 上，比最佳稠密模型高出 8.7 个百分点。
最弱结果： 在 ViDoRe v3 Markdown 上为 61.2%，来自 0.6B 模型。这仍是该基准上的第 2 好成绩。真正的差距在图像搜索：Gemini Embedding 2 在 MIRACL-Vision 上击败了 9B 模型，在 PPLX-Q2I 上领先 2 个百分点。
混合尺寸： 由 0.6B 模型查询的 9B 索引在 ViDoRe v3 图像检索上得分为 63.5%。这超过了两侧都用 0.6B 时的 62.3%，且查询成本相同。
工作原理
稠密模型将一个文档压缩为 1 个向量。pplx-embed-v2-late 则为每个 token 保留一个 128 维向量。它使用 MaxSim 打分：每个查询 token 找到其最佳文档 token，然后对这些最大值求和。页面以图像形式编码，因此无需 OCR 步骤。Perplexity 使用一个 18B 的教师模型对这两个模型进行了蒸馏，训练过程中 LEAF风格的 token 级训练，从 18B 教师模型蒸馏出这两个模型。正是这种训练创造了共享空间。
最佳使用场景
- 最适合对 PDF、幻灯片和扫描报告进行视觉文档搜索。
- 低延迟搜索：在云端用 9B 建立索引，然后在设备上用 0.6B 查询。
- 针对大型 PDF 或网页集合的 Agentic RAG。
交互式讲解
对比情况
| 特性 | pplx-embed-v2-late | NVIDIA nemotron-colembed-vl-8b-v2 | TopK topk-embed-v1 | Google Gemini Embedding 2 |
|---|---|---|---|---|
| 规模 | 0.6B, 9B | ~8.8B | 0.8B, 2B 开源 | 未公开 |
| 向量宽度 | 每个 token 128 | 每个 token 4,096 | 每个 token 2,048（small) | 128 至 3,072，1 个向量 |
| 输入 | 文本、图像、页面渲染 | 文本查询、页面图像 | 文本、页面图像 | 文本、图像、视频、音频、PDF |
| 运行于 | 你的GPU；0.6B边缘端 | NVIDIA A100/H100，Linux | CUDA GPU（Ampere及更高） | Google API |
| 跨型号共享空间 | 是 | 未说明 | 未说明 | 不适用 |
| 许可证 | MIT | CC-BY-NC-4.0 | Apache 2.0（小型） | 专有 |
核心要点
- 0.6B模型适用于边缘设备；9B模型则专为索引期质量而构建。
- 最佳成绩：MADQA上的92.4%。最弱：ViDoRe v3 Markdown上的61.2%。
- 用0.6B查询9B索引的效果优于两侧都用0.6B。
- 存储增长和自报分数是主要的注意事项。
请查看 HF上的模型权重 以及 技术细节。所有功劳归于该项目的研究者。另外，欢迎在 Twitter 上关注我们，别忘了加入我们的 150k+ML SubReddit 并订阅 我们的Newsletter。等等！你用Telegram吗？ 现在你也可以在Telegram上加入我们了。
这篇文章 Perplexity AI发布pplx-embed-v2-late:一款0.6B边缘模型和一款在MADQA上得分92.4%的9B模型 首发于 MarkTechPost.