Inception Labs 发布 Mercury 2 for Search，解码超 1000 tokens/秒

在过去两年里，“搜索”不再意味着一个排序好的链接列表，而是开始意味着一个智能体流水线。分类、改写、扇出、重排序、综合。每次搜索查询要调用五十到一百次 LLM，而且几乎全是串行的。

把自回归模型放在这个位置简直是地狱：一次 400ms 的改写会阻塞检索，检索又阻塞重排序，重排序又阻塞用户看到第一个词。于是团队不断削减流水线，直到它浅到足够快。

行业已经分裂成两个阵营：同步搜索运行着轻薄、廉价、几乎不思考的模型，以及需要三十分钟的深度研究智能体。没有人交付中间那个东西：一个既足够深以显得聪明、又足够快以真正有用的流水线。

Mercury 2 在标准 NVIDIA GPU 上每秒解码超过 1000 个 token。快到足以在你现有的延迟预算内运行每一步。

延迟就是质量预算

在大多数产品里，延迟和质量是两个独立的旋钮。你可以让用户多等一会儿来得到更好的答案。但在搜索里，它们是同一个旋钮，因为每一个让答案变好的步骤本身都是一次增加延迟的 LLM 调用：

• 查询改写能找到字面匹配漏掉的文档。

• 重排序把合并后的集合收窄到值得用来综合的段落。

• 片段摘要让综合上下文干净到足以引用。

每一步都是一次 LLM 调用。每一次要么在阻塞用户，要么在生成用户读到的输出。

那些运行六次改写而不是一次、重排一百条结果而不是十条、并对每个检索到的页面做摘要的智能体，不只是检索得更快，它们检索得更好。

为什么扩散模型不需要一次一个 token

自回归模型从左到右生成，每次前向传播一个 token。每个 token 都要等待它之前的所有 token。这种串行化就是结构性瓶颈，也正是为什么行业对搜索延迟的答案一直是“用更小的模型”。当解码顺序固定时，这是唯一可用的杠杆。

扩散语言模型没有固定的解码顺序。Mercury 2 并行生成，在少量、有界的步骤中细化一整段输出，而不是每次前向传播只吐出一个 token。每一步都是对整个片段的一次全上下文前向传播。模型整体地看到正在成形的答案，并在连续多次传播中收敛到最终输出。一段 300 token 的重排序理由和一段 500 token 的片段摘要能在极短时间内返回。而一个搜索流水线会生成数百个这样的东西。

每一步中最快的模型，实测

搜索流水线里的“快”不是一个数字。重要的是每一步耗时多久，因为每一步都会阻塞下一步。所以我们在 WideSearch 上直接测量了逐步延迟，这是一个需要数十次实时查询的穷尽式信息收集任务基准。相同的智能体框架、相同的 100 个任务、相同的实时检索、四个模型，每次 LLM 调用都计时。

可复现性：WideSearch 基准，100 个英文任务，实时 Exa 检索。延迟中位数基于每个模型 336–493 次调用，每个模型都在各自提供商的公共 API 上运行。框架和每次调用计时公开于： github.com/apoorvumang/retrieval-vs-recall

Mercury 2 在流水线的每一步都是最快的模型，在查询规划上比 Gemini 3.1 Flash Lite 快近 2 倍，比 Claude Haiku 4.5 快 4.7 倍，比 GPT-5 Mini 快 10 倍。正是这种每一步的差距，造就了下一节中的端到端数字：流水线的速度取决于其各跳之和。

对真实流水线算一笔账

以一个中等复杂度的答案引擎查询为例，首 token 预算为 2 秒。

传统流水线会把预算花在一次改写、单次检索、没有 LLM 重排，以及一个很晚才开始流式输出的合成步骤上。2 秒中的大部分是解码时间，而质量上限取决于检索器恰好返回了什么。

同样的预算用在 Mercury 2 上，可以换来四次并行改写、对所有改写进行检索扇出、对合并后的候选集进行 LLM 重排、逐文档片段摘要，以及一个还有余量就开始流式输出的合成步骤。同样的延迟范围。结构上更好的答案，因为流水线做了该做的工作。

按每百万输入 token 0.25 美元、每百万输出 token 0.75 美元计算，这条更深的流水线运行成本大约是在前沿速度优化模型上运行同样流水线的一半。

全速下的质量

速度只有在答案站得住脚时才有意义。因此我们在两个基于检索的基准上运行了成本效率生成层级：FRAMES（多跳检索与合成，每个问题 2–15 篇维基百科文章）和 DeepSearchQA（开放式智能体搜索，按答案集是否完整评分）。

每个基准 n=100，所有模型使用相同的问题集，全部采用中等推理强度。基于 Exa 的智能体工具调用循环；FRAMES 上 25 次调用预算，DSQA 上 30 次。使用每篇论文的官方提示和指定评判模型评分——FRAMES 用 GPT-5.4，DSQA 用 Gemini-2.5-flash。成本包括按标价计算的 Exa 检索费用，并按全价计入输入，没有提示缓存折扣。*Claude Haiku 4.5 通过 OpenRouter 路由（直接密钥已耗尽）；其延迟包含一次代理跳转，可能偏高几秒。

在 FRAMES 上，四个模型的得分彼此相差在三分以内——0.78、0.78、0.78、0.81。在 n=100 时，标准误差为四到五分，因此这一差距是噪声。在多跳基于检索的问答上，这一层级打成平手，GPT-5 Mini 名义上的最高分并不是真正的领先。

DeepSearchQA 将它们区分开来，而且并不利于 Mercury 2。GPT-5 Mini 得分为 0.44，而 Mercury 2 为 0.34——十分之差，比其他三者之间的差距更大，不过在此样本量下仍处于两个标准误差之内。DSQA 奖励广度：找到所有符合约束的条目，而不是通过一条链进行推理。一个果断规划并广泛阅读的模型在那里表现更好，GPT-5 Mini 正是如此。

在两个基准上都没有改变的是，一个正确答案要花多少钱，以及你要等多久。Mercury 2 在 10.8 秒内完成一次 FRAMES 查询，而 Gemini 3.5 Flash Lite 为 19.8 秒，Claude Haiku 4.5 为 21.0 秒，GPT-5 Mini 为 38.8 秒。而按正确答案计算（这个数字才会进入你的账单），Mercury 2 在两个基准上都是四者中最低的：FRAMES 上为 0.047 美元，而其他三者分别为 0.072、0.097 和 0.133 美元；DeepSearchQA 上为 0.432 美元，而其他三者分别为 0.457、0.676 和 0.938 美元。

所以 GPT-5 Mini 用 3.6 倍的延迟换来 DeepSearchQA 上十分的准确率提升，而且每个正确答案的成本仍略高于 Mercury 2。在一条每次查询要触发模型上百次的流水线中，这笔交易并不划算。

关于 DeepSearchQA 的一点坦诚说明：对每个模型来说，它的成本都是 FRAMES 的三到七倍，因为广度意味着更多轮次，而每一轮额外都会重新发送不断增长的对话记录。智能体流水线中的成本由轮次数量和输入量决定，而不是由输出长度或单价决定。换句话说，你能负担得起多少步骤，就决定了你的流水线运行成本是多少。

Mercury 2 如何在 WideSearch 上落败

上面每一个数字背后都藏着一个问题，包括我们自己的。我们是因为 Mercury 2 落败才发现它的。

Mercury 2 在 WideSearch 这个智能体搜索基准上的得分低于 Gemini 3.1 Flash Lite。一位客户问为什么。于是我们深入调查，最终在关闭检索的情况下运行了这个基准。如果一个基准衡量的是搜索，那么拔掉搜索应该会造成毁灭性打击。

除了 Gemini 之外，每个模型都从检索中获益，而 Gemini 在开启搜索时得分反而略低（−0.02）。它不是在搜索，而是在背诵。WideSearch 的任务由比所有模型知识截止日期都更早的事实构成（例如大学排名、产品规格、2022 年房价），因此模型可以忽略它检索到的每一个页面，直接从权重中作答。没人在作弊；这正是评分器所奖励的。分数看起来像搜索，实则是记忆。

对于一个搜索产品来说，这种区别就是全部胜负所在。一个凭记忆作答的模型会自信地反驳你的索引、你的目录、你刚抓取的页面，同时还能在基准上表现亮眼。

有一个任务能说明这一点。ws_en_034 要求提供英国月度房价，并指示模型引用政府网站上的每一项统计数据，从构造上就是检索任务。开启搜索时，智能体无法核实其来源中的数字，返回了一张空表：0.03。闭卷时，它凭记忆背诵出看似合理的数字：0.86。忠实输给了流畅，差了三十倍。

于是我们根据每个模型训练截止之后的事件重建了任务（例如 2026 年世界杯小组赛、法网、戛纳、欧洲歌唱大赛）。相同格式、相同官方评分器，没有任何可记忆的内容。闭卷得分对每个模型都跌至零，证实这些任务无法被回忆。开启检索后，Gemini 得分 0.929，Mercury 2 得分 0.923。

这是平局，我们就按平局来报告。在分数纯粹取决于检索与综合的数据上，一个每步运行速度快数倍的扩散模型，做出了与前沿自回归模型同等质量的工作。

SealQA 是一个每月刷新的抗污染基准，从另一个方向显示出同样的特征：Gemini 的闭卷优势完全存在于 2024 年之前的问题中，随着事实越来越新而逐渐消失，并在截止之后的 2026 年问题上翻转为 Mercury 领先。整个设置始终相同——唯一的变量是答案是否可被记忆。

在你为搜索评估一个模型之前，先做三项检查：

1. 关闭检索（如果分数保持不变，那你评估的是记忆）

2. 加入没有任何模型可能记住的截止后问题

3. 确认标准答案是可检索的，而不仅仅是正确的。 

以上一切都是可复现的。带上你自己的密钥，在任何模型上运行它，包括我们的： github.com/apoorvumang/retrieval-vs-recall

接下来是什么

搜索是并行生成最清晰的用例，因为它是每单位用户耐心下运行 LLM 次数最多的负载。任何需要反复调用模型的流水线都会呈现同样的形态。智能体研究是显而易见的下一步。将每步延迟降低 5 到 10 倍，就能把一项通宵的研究任务变成在合理等待时间内即可完成的工作。

试用 Mercury 2。API 已在

platform.inceptionlabs.ai 上线

.

正在对生产搜索流水线进行基准测试？我们将为你配置更高吞吐量的容量，以便你按自己的查询组合测量真实延迟，我们还会帮助你在自己的评估集上运行关闭检索的消融实验。

联系我们的工程师。