Perplexity 发布了 Photon，一个用 Rust 编写的内部检索与排序引擎。它取代了 Perplexity 为其 AI 原生搜索栈所分叉的开源引擎。Photon 现在处理所有生产流量的检索与排序。它还为 Perplexity Search API 中新的 Fast Search 模式提供支持。Perplexity 报告单次调用延迟为 p50 160 ms、p95 230 ms。
它可部署吗？可以，作为托管 API。在 POST /search 上设置 search_type: "fast"，每 1,000 次请求支付 $1。Photon 本身并非开源，因此该引擎无法自托管。
Perplexity 为何替换其旧引擎
随着索引增长，旧引擎触及了 3 个极限：
尾部延迟：生产环境 p99 接近 800 ms。数据集超出 RAM，因此 mlock 不是选项。冷读取触发主缺页，导致查询停滞。
合并尖峰：在磁盘索引融合期间，p99 攀升至约 1.2 s，持续 10 到 15 分钟。
恢复缓慢：部署并同步一个额外集群可能需要超过一周。恢复还提高了部分响应的比例。
Perplexity 团队得出结论：从零构建比维护其分叉更简单也更便宜。
Photon 如何工作
负载均衡器将每个请求路由到一个 Photon broker。broker 扇出到一个分片组并监视超时。每个分片运行检索、初始排序和第二阶段排序。broker 随后合并候选并获取关键文档字段。
自适应倒排列表：短列表内联在单个页面内。较长的列表拆分为固定文档 ID 范围的块。稀疏块存储排序的偏移数组并使用跳跃搜索。稠密块使用位图，因此成员判断变成单次位查找。
预算化遍历：一种类似 WAND 的算法将列表拆分为驱动列表和探测列表。廉价的存在性检查先为每个候选的最大分数设定上界。只有当候选能越过阈值时，才读取精确的词频。
Docblob 记录：每个文档获得一条紧凑记录，包含词频、字段掩码和位置。词项使用 Elias-Fano 编码，因此排序只解码匹配的词项。对一个候选排序，每个文档只需 1 次查找。
批量异步读取：记录偏移量提前已知，因此磁盘读取通过 io_uring 批量发出。缓存首先检查整个批次。读取器不加锁，淘汰使用 CLOCK 而非共享的 LRU 列表。
构建与服务分离：索引器在专用节点上从 YTsaurus 表构建带版本的 shard 索引。控制器一次轮换一个服务组，并通过重放搜索日志查询来预热缓存。
完整的网页索引现在可在个位数小时内构建完成。
交互式讲解：深入 Photon
生产结果
p99 检索和排序延迟从约 800 ms 降至约 65 ms。这仅涵盖 Photon 的各阶段。
Photon 运行所需的服务机器比旧的内容节点少约 20%。
它每篇文档存储的数据量约为原来的 2.5 倍，Perplexity 借此提升了排序质量。
若用 mlock 固定相同数据集，估计需要 Photon 当前常驻内存的 4.6 倍。
索引版本切换不再导致延迟尖峰。
Fast Search：为智能体提供的速度与成本
Fast Search 将 Photon 与为智能体工作流调优的轻量级排序相结合。Perplexity 在 6 个基准测试上进行了测试：WideSearch、BrowseComp、DSQA、FRAMES、SEAL-0 和 SEAL-Hard。在 3,554 个任务中，Fast 得分为 64.3%，估计的模型加搜索成本为 $59.73。默认预设得分为 64.0%，成本为 $187.60，因此 Fast 便宜约 68%。
这种权衡体现在更广泛的搜索质量上。在内部长尾基准测试中，相关性（DCG）从 2.45 降至 2.21。答案可用性从 0.596 降至 0.567，损失 2.9 个百分点。Perplexity 建议将 Fast 用于日常智能体循环，将默认预设用于困难、模糊的查询。
复制代码已复制使用其他浏览器
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 与最接近的竞品对比
FeaturePerplexity Fast SearchExa InstantParallel Search TurboTavily ultra-fastRequest parametersearch_type: "fast"type: "instant"mode: "turbo"search_depth: "ultra-fast"Vendor-reported latency160 ms p50, 230 ms p95 (blog)~250 ms typical (docs); sub-200 ms at launch~200 ms (docs)No figure published; lowest-latency depth (docs)List price per 1K requests$1 (pricing)$4 for up to 10 results (pricing)$1 (docs)1 credit: $8 pay-as-you-go, $5 to $7.50 on plans (credits)Results per request1 to 2010 in base price, $1 per 1K per extra resultNot specifiedNot specifiedKnown limitsLower relevance than default presetExtra results billed separatelyEnglish and Japanese queries onlyLower relevance than other depthsLaunchedSep 24, 2026Feb 12, 2026Jul 13, 2026 (blog)Jan 5, 2026 (blog)
所有延迟数据均为厂商在不同环境下自行报告，因此并非同类可比。
关键要点
Photon 是 Perplexity 的 Rust 检索与排序引擎，现已承载全部生产流量。
生产环境 p99 延迟从约 800 ms 降至约 65 ms。
Fast Search 报告 p50 为 160 ms、p95 为 230 ms，价格为每 1,000 次请求 $1。
在任务质量相当的情况下，Fast 将估计的智能体任务成本降低了约 68%。
它牺牲了一部分检索相关性，因此对于困难查询请保留默认预设。
查看技术细节和 Fast Search 文档。所有功劳归于该项目的研究者。另外，欢迎在 Twitter 上关注我们，别忘了加入我们的 150k+ ML SubReddit 并订阅我们的 Newsletter。等等！你在 Telegram 上吗？现在你也可以在 Telegram 上加入我们了。
需要与我们合作推广你的 GitHub Repo 或 Hugging Face Page 或产品发布或网络研讨会等？联系我们
文章 Perplexity Introduces Photon: A Rust-Based Retrieval Engine That Cuts p99 Latency From 800 ms to 65 ms 首发于 MarkTechPost。