OpenRouter 上线实时网页搜索基准榜，对比引擎、搜索深度与模型组合

对于大多数 LLM 请求来说，网络搜索是克服知识截止时间的基本要求。实验室和搜索提供商正在快速演进，让搜索更有效、更高效，这也让我们所有人都面临一系列棘手的决策：是采用某些实验室内置的原生搜索，还是接入 Exa、Parallel 或 Perplexity 这样的第三方引擎？一次搜索够吗？如果不够，我该让智能体继续搜索多久？更多的搜索轮次是否值得它们所带来的质量提升？

我们构建了实时排行榜，帮助你用数据决定最佳的搜索配置。查看数据请访问我们全新的 Benchmarks 页面。

我们对所有组合进行基准测试，以找出各自的优势与劣势

在设置搜索请求时，你有四个决策：

• 模型。 编写提交给搜索引擎的确切查询，并处理结果。
• 引擎。 你可以选择特定引擎，也可以依赖某些实验室提供的捆绑引擎。在 OpenRouter 上，我们提供 Exa、Parallel 和 Perplexity，以及来自 OpenAI、Anthropic 和 Google 等实验室的原生引擎。
• 搜索方法。 你可以在调用模型之前执行搜索，并将结果作为上下文传入；也可以为模型配备一个网络搜索工具，由它自行决定何时调用。
• 搜索预算。 如果你选择搜索工具方法，还可以给模型设定允许执行多少次搜索的预算。这使模型能够在不喜欢结果时调整查询，或进行后续搜索。我们的运行使用 1、5 或 25 轮。

为了全面了解网络搜索性能，我们定期在多个模型、引擎和搜索配置上运行四项基准测试：

• BrowseComp：需要真实浏览的硬核事实查找
• DeepSearchQA：多跳研究问题
• WideSearch：广泛的“填满整张表”式信息收集
• HLE：带搜索的专家考试题

每个页面都按质量、性价比和速度对配置进行排名，因此你可以根据对自身工作负载最重要的因素做出决策。排行榜是实时的，因此随着新的运行结果落地以及新模型和引擎的加入，数字会不断变化。今天的领先者未必是明天的领先者。本文不会花太多时间讨论今天的领先者，因为我们预计这会随时间变化。相反，让我们看看数据告诉了我们什么，以便为你的工作负载做出决策。

搜索预算比其他任何因素都更重要

将引擎预算从一轮增加，对质量的提升超过你能做的任何其他单一改动。举例来说，这是我们在 Perplexity 上对 BrowseComp 进行的初始运行，涵盖三种不同预算：

这一模式在我们测量的所有提供商中都成立：

这些运行仅覆盖 BrowseComp，使用服务器工具，每次搜索十个结果，不进行页面抓取或代码执行，且每个配置采用最新的合格运行结果。

增加搜索深度是我们发现的提升质量最便宜的方式。从 1 轮增加到 25 轮，分数大约翻倍，而每个问题的成本仅增加 2.5 至 7 倍。

你可能会认为这普遍会拖慢响应时间，但事实并非总是如此。例如，Luna 在 1 轮时每题耗时 140 秒，在 25 轮时为 111 秒。在我们同时以 1 轮和 5 轮运行的 35 种配置中，超过三分之一在轮数更少时反而更慢。这些全都是 OpenAI 模型。这些模型通过额外的推理来应对受限的搜索预算。

另一方面，在较简单的任务上，搜索深度可能会损害成本。例如，在 HLE 上，使用 Perplexity 的 GPT-5.6 Sol 在 1 轮和 25 轮之间得分相近，但成本却是三倍。如果你的搜索往往比较简单，那么限制预算可能仍然值得。

你最坏情况的成本由失败率驱动

扩大预算会产生不利影响的另一种情况，是模型无法找到答案时。我们发现，即使模型最终会失败，它们也会耗尽预算去尝试寻找答案。

我们记录到的最深尝试是在 WideSearch 表格上进行了 81 次搜索，但最终仍被评为错误。如果你的工作负载失败率很高，那么减少搜索深度很可能是降低成本的有效途径。

虽然引擎很重要，但模型更重要

一旦预算设定好，下一个最重要的问题就是使用哪个模型。

上表显示了 25 轮时的 BrowseComp 结果，比较了不同搜索引擎下前沿模型与预算模型的表现。

在保持模型不变的情况下更换引擎，得分平均变化 10 分，而前沿模型与高性价比模型之间的平均差距更大，为 15 分。在各引擎之间，前沿模型的成本差异最大，最贵的引擎成本是最便宜引擎的 2.5 倍，而高性价比模型则为 1.5 倍。

之所以能进行这样的比较，是因为服务器工具位于提供商之上。在请求中更换模型，搜索行为保持一致，包括那些提供商自身不提供搜索的模型。

当然，基准测试只是可能性能的参考。它们告诉你哪些配置值得尝试，以及大致成本是多少。这些选择在你自己的真实任务中的成本和质量会有所不同，所以你能用这些页面做的最有价值的事，就是把它们当作一份候选清单，然后用你自己的问题去测试排名靠前的几个。

在你自己的工作负载上试一试

以上所有内容都是你今天就可以在 OpenRouter 上设置的请求参数。

• Web 插件。web 插件在模型开始写作前运行一次搜索，对于只需要最新事实的问题来说，这是快速、便宜的选择。
• 服务器工具。服务器工具把搜索工具交给模型，让它决定接下来查找什么，当答案需要多个步骤才能找到时，这正是你想要的。
• 引擎。在 OpenRouter 上，你可以将 engine 设置为 exa、parallel、perplexity 或 native；auto 会先尝试原生搜索，然后再回退到第三方。
• 搜索预算。顶层的 max_tool_calls 请求字段限制了它获得多少智能体轮次，也就是在必须回答之前可以进行多少轮搜索，而 max_results 设置每次返回多少个结果。

一个合理的起点：选择最接近你任务的套件，在得分与最高分相差几个点的范围内选最便宜的配置，然后用你自己的评估集重新测试它上面的两到三行，看看额外的花费是否体现在你的结果中。

基准测试方法

每次运行都通过公开的 OpenRouter API 针对生产端点进行，使用我们的开源基准测试工具。

• 仅限于搜索性能。为确保只比较搜索配置，我们统一设定每次搜索返回十条结果，不抓取页面，也不执行代码。推理能力按模型固定，如表中所反映。
• 评分是严格的。每个被评估的答案对照官方答案键判定对错，在需要语义比较时使用 LLM 评判。WideSearch 还单独报告答案项准确率。
• 成本和速度按问题计算。成本是总支出（包括评分）除以被评估的问题数。速度是每个被评估问题的候选生成时间。
• 每个页面显示每个配置的最新合格运行。一次运行在完成最少问题数后即合格，新运行会取代旧运行。

常见问题

这些分数与已发布的厂商智能体排行榜相比如何？

它们不能直接比较。这些基准的大多数已发布表格衡量的是结合搜索、完整页面抓取和代码工具的完整智能体产品。这些排行榜隔离了搜索配置：模型只读取搜索结果摘录，页面抓取和代码工具关闭。这允许在配置之间进行直接比较，但不会最大化基准分数。

我应该选择哪个搜索引擎？

这取决于模型和任务，这正是这些页面存在的原因。对于某些模型，引擎之间的差距很大，而对于其他模型则微不足道，而且提供商自己的原生搜索并不自动是其最佳选项。查看最接近你工作负载的套件的实时排行榜，结合分数阅读成本和延迟，并随时间重新检查，因为随着新运行的出现，排序会发生变化。

这些数字有多新？

排行榜始终显示每个配置的最新合格运行，这些运行在 OpenRouter 的基准测试工具上针对生产端点执行。新运行会取代页面上的旧运行。

在 Discord 的#feedback 中告诉我们接下来应该对哪些引擎或模型进行基准测试。