Perplexity自研Rust检索引擎Photon，P99延迟从800ms降至65ms

Perplexity 发布 Photon：一款基于 Rust 的检索引擎，将 p99 延迟从 800ms 降至 65ms

Perplexity 发布了一款名为 Photon 的自研检索与排序引擎，完全使用 Rust 编写。它取代了此前 Perplexity 在 AI 原生搜索技术栈中所基于的一个开源引擎分支。Photon 现已承接全部生产流量，同时驱动着 Perplexity Search API 中全新的 Fast Search 模式。Perplexity 公布的单次调用延迟为：p50 160ms，p95 230ms。

是否可部署？可以通过托管 API 方式使用。在 POST /search 时设置 search_type: "fast"，价格为每 1000 次请求 1 美元。Photon 本身并非开源，因此不支持自托管。

Perplexity 为何替换旧引擎

旧引擎在索引规模增长后遇到了三个瓶颈：

尾部延迟：生产环境 p99 延迟接近 800ms。数据集体量超出 RAM，无法使用 mlock，冷读取触发了大量主缺页错误，导致查询阻塞。

合并突刺：在磁盘索引合并期间，p99 在 10 到 15 分钟内攀升至约 1.2 秒。

恢复缓慢：部署和同步一个额外的集群需要超过一周时间，且恢复过程还会导致部分响应的比例上升。

Perplexity 团队最终得出结论：从头构建比维护自己的分支更简单、成本更低。

负载均衡器将每个请求路由至 Photon Broker。Broker 再将请求下发到一个分片组并监控超时。每个分片负责检索、初排和二排。Broker 最后合并候选结果并获取文档的关键字段。

自适应倒排表：短表直接内联在单个页面内。较长的表按固定文档 ID 范围拆分为块。稀疏块存储排序后的偏移数组并使用跃进搜索（galloping search）。稠密块使用位图，成员查询变为一次位运算查找。

预算遍历：一种类似 WAND 的算法将列表划分为驱动列表（driving list）和探测列表（probe list）。廉价的 presence 检查先行为每个候选确定最大分数上界。只有当候选可能越过阈值时才读取精确的词频。

Docblob 记录：每个文档拥有一条紧凑记录，包含词频、字段掩码和位置信息。词项采用 Elias-Fano 编码，排序时仅解码命中的词项。排序一个候选文档只需每次查找一条记录。

批量异步读取：记录偏移量提前已知，因此通过 io_uring 批量发出磁盘读取。缓存层先检查整个批次。读取进程不加锁，淘汰策略使用 CLOCK 而非共享的 LRU 列表。

构建与服务分离：索引构建器在专用节点上从 YTsaurus 表构建版本化的分片索引。控制器逐组轮换服务节点，并用重放的搜索日志查询预热缓存。

完整 Web 索引现可在个位数小时数内构建完成。

交互式解读：Photon 内部架构

p99 检索与排序延迟从约 800ms 降至约 65ms。该数据仅覆盖 Photon 自身阶段。

Photon 运行的服务器数量比旧内容节点减少约 20%。

每个文档存储的数据量约为原来的 2.5 倍，Perplexity 用这部分额外数据提升了排序质量。

若使用 mlock 固定相同数据集，预计需要当前 Photon 实际使用量的 4.6 倍驻留内存。

索引版本切换不再引发延迟尖峰。

Fast Search：为 Agent 打造的速度与成本方案

Fast Search 将 Photon 与针对 Agent 工作流优化的轻量排序相结合。Perplexity 在 6 个基准测试上进行了评估：WideSearch、BrowseComp、DSQA、FRAMES、SEAL-0 和 SEAL-Hard。在 3554 个任务中，Fast 模式以约 59.73 美元的估算模型+搜索成本达到 64.3% 的得分。默认预设模式的得分为 64.0%，成本为 187.60 美元，因此 Fast 模式成本降低约 68%。

权衡体现在更广泛的搜索质量上。在内部长尾查询基准测试中，相关性（DCG）从 2.45 降至 2.21。答案可用率从 0.596 降至 0.567，下降了 2.9 个百分点。Perplexity 建议将 Fast 用于日常 Agent 循环，默认预设用于困难且模糊的查询。

curl -X POST 'https://api.perplexity.ai/search' \
  -H "Authorization: Bearer $PERPLEXITY_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"query": "latest stable Rust release", "search_type": "fast", "max_results": 5}'

在 Python SDK 0.43.4 和 0.43.5 中，根据文档需传递 extra_body={"search_type": "fast"}。

Fast Search 与主要竞品对比

特性	Perplexity Fast Search	Exa Instant	Parallel Search Turbo	Tavily ultra-fast
请求参数	search_type: "fast"	type: "instant"	mode: "turbo"	search_depth: "ultra-fast"
厂商报告延迟	160ms p50, 230ms p95（博客）	约 250ms 典型（文档）；上线时 <200ms	约 200ms（文档）	未公布数字；为最低延迟深度（文档）
每 1K 请求价格	1 美元（定价页）	最多 10 结果 4 美元（定价页）	1 美元（文档）	1 credit：8 美元按量付费，套餐 5-7.5 美元
每次请求结果数	1-20	基础包含 10 条，额外结果每 1K 1 美元	未明确	未明确
已知限制	相关性低于默认预设	额外结果单独计费	仅支持英文和日文查询	相关性低于其他深度
上线时间	2026 年 9 月 24 日	2026 年 2 月 12 日	2026 年 7 月 13 日（博客）	2026 年 1 月 5 日（博客）

所有延迟数据均为各厂商在不同环境下自行报告，不可直接横向对比。

Photon 是 Perplexity 的 Rust 检索与排序引擎，现已承接全部生产流量。

生产环境 p99 延迟从约 800ms 降至约 65ms。

Fast Search 报告的延迟为 p50 160ms、p95 230ms，价格为每 1000 次请求 1 美元。

Fast 模式在任务质量相当的情况下将估算的 Agent 任务成本降低了约 68%。

它在检索相关性上有所取舍，因此困难查询请保留使用默认预设。