Perplexity 在 2026 年 9 月 24 日交出了一套自研的底层基建答卷：用 Rust 编写的内部检索与初精排引擎 Photon，正式全面替代此前基于开源代码魔改的旧检索系统，接管了全部生产流量。
根据官方披露的技术指标，内部检索与初排阶段的 p99 尾部延迟从约 800 毫秒压降至 65 毫秒。与此同时，他们还在搜索 API 中上线了 Fast Search 模式，单次调用报价 1 美元 / 1000 次，p50 延迟 160 毫秒，p95 延迟 230 毫秒。
很多技术讨论下意识地将功劳归于 Rust 的语言优势。然而在真实的分布式工业级搜索体系里，换语言从不是根治吞吐瓶颈的银弹。
架构的死穴从不在语法，而在内存与磁盘边缘的每一次无谓颠簸。
旧架构的内存墙与 I/O 悬崖
开源检索体系并不孱弱，但在互联网级超大规模实时索引面前，通用设计往往会迎头撞上一堵物理之墙。
随着索引体积急剧膨胀，数据量远远超出了物理 RAM 上限，mlock 无法常驻内存。依赖操作系统的原生虚拟内存映射（mmap）时，长尾查询会高频触发严重缺页中断与串行阻塞，旧系统的生产 p99 延迟常年卡在 800 毫秒 附近。
更致命的痛点是段合并（segment merge）。后台在执行磁盘索引融合时，p99 延迟会陡增至 1.2 秒 且持续 10 到 15 分钟之久。一旦集群发生故障需要扩容重建，部署与同步额外集群耗时动辄超过一周，还会显著推高查询的局部截断率。
这些不是靠调整几个 JVM 参数或者加机器就能抹平的毛病。Perplexity 意识到，继续维护魔改的分支系统，边际成本已经远远超过了从零重写一套专属系统。
异步调度与定制索引带来的物理收益
Photon 的核心技术演进，集中在底层存储格式与 I/O 调度路径的重组上。
在存储层，倒排索引不再采用单一的连续列表。短倒排链直接内联保存在单个内存页；长倒排链则被切分为固定文档 ID 范围的逻辑块。稀疏块使用有序偏移数组结合倍增跳转搜索，稠密块则直接换为位图，将成员存在性校验压到单 bit 查找级别。
文档记录结构采用 docblob 组织，包含词频、字段掩码与位置信息，并通过 Elias-Fano 进行紧凑编码。这意味着初排打分时只需解码命中的词项，单篇候选文档的打分仅对应一次底层查找。结合类 WAND 的剪枝策略，系统只对有希望突破分数阈值的文档读取精确词频。
最核心的系统级动作是全面接入 Linux 的 io_uring。由于文档记录偏移量在查询前期便已精确计算，落盘读取全量以批处理异步发出，彻底绕开由 OS Page Cache 引发的缺页卡顿。只读查询路径完全无锁，缓存淘汰摒弃了在多核竞争下极易出现热点锁的 LRU 链表，转用 CLOCK 算法。
在线与离线系统的物理拆分同样关键。离线端通过 Pillar 整理数据、YTsaurus 存储分片表，并在独立节点构建索引，使全网级别的数据更新在个位数小时内即可完成。在线端则由控制器按组平滑切流，并通过回放真实搜索日志预热缓存，彻底解决了版本切换引发的吞吐震荡。
在实际生产资源占用上，Photon 运行在减少约 20% 的服务节点上，每篇文档存储的信息量提升到了旧系统的 2.5 倍。推算显示，如果要用传统全量 mlock 达到相似吞吐，所需的物理驻留内存将是 Photon 现有内存占用的 4.6 倍。
剥离神话：指标范围与质量代价
面对 65 毫秒的成绩单，需要做一些清醒的技术解构。
这一延迟数字严格限定在 Photon 内部的召回与第一、二阶段精排，并不涵盖端到端大模型的内容理解、推理回答生成以及高层网络链路消耗。普通用户感知到的端到端应答时间，瓶颈仍然主要挂在模型推理与网页内容清洗阶段。
此外，Perplexity 并未披露其此前所分叉开源系统的真实版本号与配置基线。业界横向对照中，通用检索引擎在特定调优下的表现差异巨大：比如 Vinted 曾在百万级混合检索下测得 Vespa 达到 26 毫秒的 p99 延迟，吞吐约为 Elasticsearch 饱和态的 8 倍。而开源测评体系大多偏向温缓存的内存压测，与工业界必须直面冷读落盘的长尾环境不在同一语境。因此，这一演进属于其自身特定技术栈的成功迭代，而非对开源检索体系的绝对颠覆。
更值得关注的是其附带的产品化变现路径——基于 Photon 推出的 Fast Search 模式。该模式主要通过缩减精排算力来服务高频智能体调用。
| 检索服务方案 | 标称延迟指标 | 基础计费价格 | 召回数量限制 | 主要受限与边界 |
|---|---|---|---|---|
| Perplexity Fast Search | 160 ms (p50) / 230 ms (p95) | $1 / 1K 次 | 1 至 20 条自选 | 长尾检索相关度略有让步 |
| Parallel Search Turbo | ~200 ms | $1 / 1K 次 | 未公开单次上限 | 仅支持英日双语查询 |
| Exa Instant | ~250 ms 典型值 | $4 / 1K 次 | 基础档固定 10 条 | 额外结果加收 $1/1K 次 |
| Tavily ultra-fast | 厂商标为极速档（未标绝对值） | 约 $5 至 $8 / 1K 次 | 积分扣除折算 | 召回精度低于深度检索档 |
在涵盖 WideSearch、BrowseComp、DSQA、FRAMES、SEAL-0 和 SEAL-Hard 的 6 个 Agent 基准、3554 个评测任务中，Fast 模式综合得分为 64.3%，模型加检索的总预估成本为 59.73 美元；而默认模式得分为 64.0%，总成本为 187.60 美元。单任务总成本降幅接近 68%。
但天下没有免费的午餐。在内部长尾长句评测中，Fast 模式的相关性指标（DCG）从 2.45 下滑到 2.21，答案可用性从 0.596 降至 0.567，出现了 2.9 个百分点的实质损耗。
- 风险.极速剪枝在模糊长尾与高难度查询中的漏召率会直接传递给模型；高频工作流一旦命中错误或劣质的召回段，会放大后续链路的幻觉风险。
智能体基础设施的定价分水岭
古人云，兵贵神速。当大语言模型从单次直接问答演变为自动化拆解、多步工具调用的自主工作流时，检索 API 的使用逻辑正在被重写。
在传统网页搜索时代，工程目标是集中算力追求单次查询的最优解；而在智能体系统内，调用变成了一种容错率极高的探索机制。一个复杂的任务可能在数秒内连续发起十数次检索尝试，此时单次调用的时延与计费往往成为整个系统能否落地的决定性制约。
Perplexity 将 Fast Search 压低至 1 美元 / 1000 次，直接对标 Exa 与 Tavily 等垂直搜索 API。这表明底层闭源引擎 Photon 的商业诉求非常直接：自研并不是为了发布开源成果，而是要用极低的边际硬件成本，在即将爆发的智能体网络调用层立下价格壁垒。
- 结论.对于开发者而言，日常的高频子任务循环使用 Fast 档位能省下大笔开销；但对于边界模糊、容错空间极小的长尾任务，依然需要保留默认甚至更深度的检索配置。