Perplexity发布Photon检索引擎与Fast Search API
Perplexity Introduces Photon: A Rust-Based Retrieval Engine That Cuts p99 Latency From 800 ms to 65 ms
Agent开发者必看，Perplexity用Rust重写了检索底层，不仅把延迟砍到65ms，还推出了专门针对Agent的Fast Search API，成本直降68%，赶紧去压测你的搜索链路。
Perplexity has released Photon, an in-house retrieval and ranking engine written in Rust. It replaces an open-source engine Perplexity had forked for its AI-native search stack. Photon now handles retrieval and ranking for all production traffic. It also powers a new Fast Search mode in the Perplexity Search API. Perplexity reports single-call latency of 160 ms at p50 and 230 ms at p95.
Perplexity 发布了 Photon，这是一个用 Rust 编写的内部检索和排序引擎。它取代了 Perplexity 为其 AI 原生搜索栈而分叉的开源引擎。Photon 现在处理所有生产流量的检索和排序任务。它还支撑着 Perplexity Search API 中新推出的快速搜索模式。Perplexity 报告称，p50 单次调用延迟为 160 毫秒，p95 为 230 毫秒。
Is it deployable? Yes, as a hosted API. Set search_type: "fast" on POST /search and pay $1 per 1,000 requests. Photon itself is not open source, so the engine cannot be self-hosted.
它可以部署吗？可以，作为托管 API 使用。在 POST /search 上设置 search_type: "fast"，每 1,000 次请求收费 1 美元。Photon 本身并非开源，因此无法自行托管该引擎。
Why Perplexity Replaced its Old Engine
为什么 Perplexity 替换了其旧引擎
The old engine hit 3 limits as the index grew:
随着索引规模的增长，旧引擎遇到了三个限制：
- Tail latency: Production p99 sat near 800 ms. The dataset exceeded RAM, so mlock was not an option. Cold reads triggered major page faults that stalled queries.
- Merge spikes: During disk index fusion, p99 climbed to about 1.2 s for 10 to 15 minutes.
- Slow recovery: Deploying and syncing an extra cluster could take more than a week. Recovery also raised the share of partial responses.
- 尾部延迟：生产环境的 p99 接近 800 毫秒。数据集超出了 RAM 容量，因此 mlock 不可行。冷读取会引发严重的页面错误，导致查询停滞。
- 合并尖峰：在磁盘索引融合期间，p99 在 10 到 15 分钟内攀升至约 1.2 秒。
- 恢复缓慢：部署并同步额外集群可能需要超过一周的时间。恢复过程还会增加部分响应所占的比例。
Perplexity team concluded that building from scratch was simpler and cheaper than maintaining its fork.
Perplexity 团队得出结论，从头构建比维护其分叉版本更简单、成本更低。
How Photon Works
Photon 的工作原理
A load balancer routes each request to a Photon broker. The broker fans out to a shard group and watches for timeouts. Each shard runs retrieval, initial ranking, and second-stage ranking. The broker then merges candidates and fetches key document fields.
负载均衡器将每个请求路由到 Photon 代理。代理向分片组扇出请求并监控超时。每个分片执行检索、初始排序和第二阶段排序。随后，代理合并候选结果并获取关键文档字段。
- Adaptive posting lists: Short lists sit inline within a single page. Longer lists split into blocks of fixed document ID ranges. Sparse blocks store sorted offset arrays and use galloping search. Dense blocks use bitmaps, so membership becomes a single bit lookup.
- Budgeted traversal: A WAND-like algorithm splits lists into driving lists and probe lists. Cheap presence checks bound each candidate’s maximum score first. Exact term frequencies are read only when a candidate can clear the threshold.
- Docblob records: Each document gets a compact record of frequencies, field masks, and positions. Terms use Elias-Fano encoding, so ranking decodes only the matched terms. Ranking a candidate needs just 1 lookup per document.
- Batched async reads: Record offsets are known upfront, so disk reads go out in batches through io_uring. The cache checks the whole batch first. Readers take no locks, and eviction uses CLOCK instead of a shared LRU list.
- Separate build and serve: Indexers build versioned shard indexes from YTsaurus tables on dedicated nodes. A controller rotates serving groups one at a time and warms caches with replayed search-log queries.
- 自适应发布列表：短列表内联存储在同一页中。较长的列表被分割为固定文档 ID 范围的块。稀疏块存储排序后的偏移数组并使用跳跃搜索（galloping search）。密集块使用位图，因此成员资格检查只需一次位查找。
- 预算化遍历：类 WAND 算法将列表分为驱动列表和探测列表。廉价的成员资格检查首先限制每个候选项的最高得分。只有当候选项可能达到阈值时，才会读取确切的词频。
- Docblob 记录：每个文档都有一个包含频率、字段掩码和位置的紧凑记录。术语使用 Elias-Fano 编码，因此排序仅解码匹配的术语。对候选项进行排序时，每个文档仅需 1 次查找。
- 批量异步读取：记录偏移量是预先已知的，因此磁盘读取通过 io_uring 以批量方式发出。缓存首先检查整个批次。读取器不加锁，驱逐策略使用 CLOCK 算法而非共享 LRU 列表。
- 分离构建与服务：索引器在专用节点上从 YTsaurus 表构建版本化的分片索引。控制器一次轮换一个服务组，并通过重放搜索日志查询来预热缓存。
A full web index now builds in a single-digit number of hours.
完整网页索引的构建时间现已缩短至个位数小时。
Interactive Explainer: Inside Photon
交互式解释器：Photon 内部机制
Production Results
生产环境成果
- p99 retrieval and ranking latency fell from about 800 ms to about 65 ms. This covers Photon’s stages only.
- Photon runs on about 20% fewer serving machines than the old content nodes.
- It stores about 2.5x as much data per document, which Perplexity used to improve ranking quality.
- Pinning the same dataset with mlock would need an estimated 4.6x the resident memory Photon uses today.
- Index version switches no longer cause latency spikes.
- p99 检索和排序延迟从约 800 毫秒降至约 65 毫秒。这仅涵盖 Photon 的阶段。
- Photon 运行的服务机器数量比旧的内容节点少约 20%。
- 它每文档存储的数据量约为原来的 2.5 倍，Perplexity 借此提升了排序质量。
- 若使用 mlock 锁定相同数据集，预计需要占用当前 Photon 驻留内存约 4.6 倍的内存空间。
- 索引版本切换不再导致延迟尖峰。
Fast Search: Speed and Cost for Agents
快速搜索：代理的速度与成本
Fast Search pairs Photon with lighter ranking tuned for agentic workflows. Perplexity tested it on 6 benchmarks: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0, and SEAL-Hard. Across 3,554 tasks, Fast scored 64.3% at $59.73 in estimated model-plus-search cost. The default preset scored 64.0% at $187.60, so Fast was about 68% cheaper.
快速搜索将 Photon 与针对代理工作流优化的轻量级排序相结合。Perplexity 在 6 个基准测试中对其进行了测试：WideSearch、BrowseComp、DSQA、FRAMES、SEAL-0 和 SEAL-Hard。在 3,554 项任务中，Fast 方案以预估模型加搜索成本 59.73 美元取得了 64.3% 的得分。默认预设方案以 187.60 美元的成本取得 64.0% 的得分，因此 Fast 方案便宜了约 68%。
The trade-off shows up in broader search quality. On internal long-tail benchmarks, relevance (DCG) fell from 2.45 to 2.21. Answer availability dropped from 0.596 to 0.567, a loss of 2.9 percentage points. Perplexity recommends Fast for day-to-day agent loops and the default for hard, ambiguous queries.
这种权衡体现在更广泛的搜索质量上。在内部长尾基准测试中，相关性（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}'On Python SDK 0.43.4 and 0.43.5, pass extra_body={"search_type": "fast"} per the docs.
在 Python SDK 0.43.4 和 0.43.5 版本中，请按照文档传入 extra_body={"search_type": "fast"}。
Fast Search vs Closest Competitors
快速搜索 vs 最接近的竞争对手
| Feature | Perplexity Fast Search | Exa Instant | Parallel Search Turbo | Tavily ultra-fast |
|---|---|---|---|---|
| Request parameter | search_type: "fast" | type: "instant" | mode: "turbo" | search_depth: "ultra-fast" |
| Vendor-reported latency | 160 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 request | 1 to 20 | 10 in base price, $1 per 1K per extra result | Not specified | Not specified |
| Known limits | Lower relevance than default preset | Extra results billed separately | English and Japanese queries only | Lower relevance than other depths |
| Launched | Sep 24, 2026 | Feb 12, 2026 | Jul 13, 2026 (blog) | Jan 5, 2026 (blog) |
| 特性 | Perplexity 快速搜索 | Exa Instant | Parallel Search Turbo | Tavily ultra-fast |
|---|---|---|---|---|
| 请求参数 | search_type: "fast" | type: "instant" | mode: "turbo" | search_depth: "ultra-fast" |
| 供应商报告的延迟 | 160 毫秒 p50，230 毫秒 p95（博客） | 典型值约 250 毫秒（文档）；发布时低于 200 毫秒 | 约 200 毫秒（文档） | 未公布数据；最低延迟深度（文档） |
| 每 1K 次请求的标价 | $1（定价） | 最多 10 个结果包含在基础价格中，额外结果每 1K 个收费 $1（定价） | $1（文档） | 1 个积分：按用量付费 $8，套餐中为 $5 至 $7.50（积分） |
| 每次请求的结果数 | 1 到 20 | 基础价格包含 10 个，额外结果每 1K 个收费 $1 | 未指定 | 未指定 |
| 已知限制 | 相关性低于默认预设 | 额外结果单独计费 | 仅限英语和日语查询 | 相关性低于其他深度 |
| 发布日期 | 2026 年 9 月 24 日 | 2026 年 2 月 12 日 | 2026 年 7 月 13 日（博客） | 2026 年 1 月 5 日（博客） |
All latency figures are vendor-reported under different setups, so they are not like-for-like.
所有延迟数据均为各厂商在不同配置下报告的结果，因此不具备直接可比性。
Key Takeaways
核心要点
- Photon is Perplexity’s Rust retrieval and ranking engine, now serving all production traffic.
- Production p99 latency dropped from about 800 ms to about 65 ms.
- Fast Search reports 160 ms p50 and 230 ms p95 at $1 per 1,000 requests.
- Fast cut estimated agent task cost by about 68% at comparable task quality.
- It trades some retrieval relevance, so keep the default preset for hard queries.
- Photon 是 Perplexity 基于 Rust 构建的检索与排序引擎，现已服务于所有生产流量。
- 生产环境 p99 延迟从约 800 毫秒降至约 65 毫秒。
- Fast Search 在每千次请求 1 美元的定价下，p50 延迟为 160 毫秒，p95 延迟为 230 毫秒。
- Fast cut 在保持相当任务质量的前提下，将代理任务成本降低了约 68%。
- 此举牺牲了部分检索相关性，因此对于复杂查询请保留默认预设。
Check out the technical details and Fast Search docs. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
查看技术细节和 Fast Search 文档。本项目的所有功劳归于该研究员。此外，欢迎在 Twitter 上关注我们，别忘了加入我们拥有 15 万+成员的 ML SubReddit，并订阅我们的新闻通讯。等等！你在 Telegram 上吗？现在你也可以加入我们的 Telegram 群组。
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力