800ms到65ms，这刀怎么落下的

p99延迟从800毫秒砍到65毫秒，12倍的差距。Perplexity这次不是发个新模型刷榜，而是把AI搜索栈里最不起眼、却最要命的一层——检索排序——用Rust重写了一遍。新引擎叫Photon，已经承接全部生产流量，还顺手在Perplexity Search API里开了一个Fast Search模式。

我的判断很直接：这不是一次性能优化，这是AI搜索进入毫秒战争的分水岭。当大模型生成的延迟和成本压不动的时候，把前面每一层抠到极致，就成了唯一有确定性回报的活儿。

“注：本文关键数据与时间线以Perplexity官方披露为准；文中未注明出处的技术细节为作者基于公开资料的工程分析。

🚀 fork来的引擎，迟早要还的

先还原一下场景。几乎所有AI原生公司起步时都干过同一件事：找一个成熟的开源引擎，fork下来，往上堆自己的业务逻辑，快速把产品跑起来。这不是偷懒，是理性——验证PMF的阶段，每一行自研代码都是负债。

Perplexity也不例外。官方披露说得很明白：Photon替代的，正是它此前为自己的AI原生搜索栈fork的一个开源引擎。fork方案跑了一段时间，撑住了从零到一的阶段。但流量一上来，问题就藏不住了——上游社区的设计目标和你自己的业务形态越走越远，补丁越打越厚，每次想动检索逻辑都要先跟上游架构搏斗一番。

关键事实有三个：第一，Photon是彻底的in-house自研，检索和排序一手抓；第二，它现在承担Perplexity的全部生产流量，不是灰度、不是试点；第三，它同时对外输出了Fast Search能力。

产业逻辑在这里很清晰：核心链路自研，是AI公司跨过规模化门槛的必经之路。基础软件圈流传一句老话：fork一时爽，维护火葬场。Perplexity这刀砍下去，本质上是在为过去几年欠的技术债一次性结账。

⚙️ 为什么是Rust，为什么死盯p99

用户记住的从来不是平均延迟，是最卡的那一次。

先看数据。官方口径：Photon把检索层的p99延迟从800毫秒压到了65毫秒。p99是什么概念？100个请求里最慢的那1个。平均延迟好看不难，堆缓存、做预热就行；但p99考验的是系统在最坏情况下的表现——GC停顿、锁竞争、页错误，全都暴露在这条长尾上。

为什么选Rust？答案几乎写在语言特性里：无GC、内存安全、零成本抽象。检索排序是典型的延迟敏感型负载，任何一次几十毫秒的垃圾回收停顿，都可能把p99直接拖下水。落到工程层面，Rust的收益是具体可拆的：

• 异步运行时与调度：基于tokio这类工作窃取式调度器的异步运行时，可以把检索请求的I/O等待精细编排，避免线程阻塞导致的队头阻塞——这正是fork来的通用引擎在高并发下长尾失控的常见根源。
• 无GC的内存模型：索引常驻内存动辄数十GB，传统托管语言要么靠GC管理堆（停顿不可控），要么靠手动内存管理（易出事故）。Rust的所有权模型让索引生命周期在编译期确定，配合mmap映射倒排索引、Arena批量分配临时结构，热路径上基本没有运行时「惊喜」。
• 零成本抽象与无锁结构：倒排表的跳表遍历、近似最近邻（ANN）图搜索这类热点路径，可以用无锁读、ArcSwap做索引热切换，实现搜索在更换索引版本时零请求阻塞——灰度发布新索引时p99不抖动。

再看检索算法这一层。现代检索排序普遍是多阶段流水线，Photon自研后可以对每一阶段做端到端控制，这是fork方案做不到的：

fork方案的问题在于，这条流水线的每个环节都要服从上游的抽象边界——多一跳进程间通信、多一次序列化，p99就多一层长尾。自研后整条链路可以在一个进程内用零拷贝串起来，这也是65毫秒这个数字在架构上成立的前提。

最后看为什么12倍的优化值得这么大动干戈。AI搜索的完整链路是：查询进来，先检索，再排序，最后交给大模型生成带引用的答案。生成这一步又重又慢，且短期内压缩空间有限。那么整条链路的延迟预算怎么分？答案只能是——把检索层压到足够薄，给后面的生成留出空间。

这里有个容易被忽略的乘法效应：p99决定的是最差体验，而AI搜索的用户是高频使用者，一天几十次查询，撞上长尾的概率被次数放大。800毫秒的p99意味着每几十次就有一次明显的「转圈」，65毫秒则把这种体验破损基本抹平了。

📡 Fast Search：内功练出来，总要变现

底座练出来的肌肉，不能只自己用。

Photon第二个值得玩味的动作，是它直接催生了Perplexity Search API里的Fast Search模式——官方提到的单次调用延迟在160毫秒量级。注意这个产品逻辑：一个内部性能优化，被包装成了一个独立的对外接口。

按时间线捋一下这次发布：

• 阶段一：fork开源引擎，快速搭起AI原生搜索栈
• 阶段二：持续打补丁，检索层逐渐成为全链路性能瓶颈
• 2025年9月30日：Photon正式发布，p99降至65ms
• 同期：全量生产流量切换完成，Fast Search模式随Perplexity Search API推出

这个动作的产业含义，比65毫秒本身更值得琢磨。AI公司的第二增长曲线正在从「卖订阅」转向「卖能力」——模型能力API化、检索能力API化、工具链API化。Perplexity把检索层做成Fast Search模式，等于把自己最难复制的底层工程，变成了开发者可以直接采购的商品。

有意思的是定价逻辑的锚点也变了。过去API比拼的是模型智商，现在Fast Search比拼的是160毫秒的确定性——对做Agent和实时应用的开发者来说，延迟确定性有时比模型聪明程度更值钱。越来越多的Agent团队选型时，第一问不是「效果多好」，而是「p99多少」。

一句话总结这节的判断：基础设施能力产品化，是AI公司对冲模型层内卷的最务实路径。

🤖 检索层，AI栈里被低估的控制层

作为常年跟实时系统打交道的人，我看完Photon这事的感受特别直接：AI搜索栈的结构，和控制系统的技术栈是同构的。机器人圈有句话——控制器不行，机械臂就是废铁；AI搜索同理，大模型再强，如果检索层吐回来的语料慢半拍、差一截，最终答案照样又慢又不可靠。「感知—规划—控制」和「理解—检索—生成」，短板逻辑完全一样。

而被低估的恰恰是这一层。过去两年行业的注意力全在模型层——参数量、评测分、开源还是闭源，检索排序被视为「拿开源的凑合一下就行」的 commodity 环节。Perplexity用800毫秒到65毫秒的差距证明：在AI原生应用里，不存在可以凑合的层。每一层的性能上限，最终都会以乘法的形式落到底线体验上。

由此我给三个判断。第一，「核心链路自研、边缘环节开源」会成为AI公司的标准工程策略，全开源和全自研两个极端都不经济。第二，延迟会取代单点效果，成为AI基础设施竞争的主战场——用户对「快」的感知，远比对「聪明一点」的感知来得直接。第三，Rust在这波AI基础设施重写里的地位还会继续抬升，凡是贴着延迟敏感负载的模块，都在被重写的候选名单上。

结语

Photon这件事，表面上是一次12倍的延迟优化，底子里是AI搜索从「堆模型」转向「抠全栈」的信号。当生成层的延迟和成本进入平台期，检索层就成了最后一个确定性收益的大矿。先把延迟敏感的实时层做到极致，再谈上层智能——这是所有实时系统颠扑不破的次序。接下来值得盯的，是Fast Search这类能力型API能不能长出独立的收入曲线——那才是这场毫秒战争真正的胜负手。