对于大多数大语言模型请求而言，联网搜索已是克服知识截止的基本门槛。各大实验室和搜索提供商正在快速演进，让搜索变得更高效、更省成本，这也给我们所有人留下了一系列棘手的选择：是用某些实验室自带的原生搜索，还是接入 Exa、Parallel 或 Perplexity 这类第三方引擎？一次搜索够不够？如果不够，我该让智能体持续搜索多久？更多的搜索轮次是否值得它们换来的质量提升？
我们构建了实时排行榜，用数据帮你决定最佳搜索配置。欢迎在我们的新 Benchmarks 页面查看数据。
我们对所有组合进行基准测试，找出各自的优势与短板。
设置一次搜索请求时，你有四个决策项：
- 模型。负责编写实际提交给搜索引擎的精确查询，并处理返回结果。
- 引擎。你可以选择特定引擎，也可以依赖某些实验室提供的捆绑引擎。在 OpenRouter 上，我们提供 Exa、Parallel 和 Perplexity，同时也有来自 OpenAI、Anthropic、Google 等实验室的原生引擎。
- 搜索方式。你既可以在调用模型之前先执行搜索、把结果作为上下文传入，也可以给模型配备一个联网搜索工具，由模型自行决定何时调用。
- 搜索预算。如果选择搜索工具方式，你还可以给模型设定一个允许执行的搜索次数预算。这样模型就能在不满意的结果时调整查询，或进行后续追问搜索。我们的测试运行使用 1、5 或 25 轮。
为了全面了解联网搜索的性能，我们定期在多个模型、引擎和搜索配置上运行四项基准测试：
- BrowseComp：需要真实浏览网页的硬核事实查找任务。
- DeepSearchQA：多跳研究型问题。
- WideSearch：广泛的“填满整张表”式信息收集任务。
- HLE：带搜索的专家级考试题目。
每个页面都会根据质量、价值和速度对配置进行排名，这样你就可以根据对自身工作负载最重要的因素来做决策。这些排行榜是实时更新的，因此随着新的运行结果落地、新模型和新引擎不断加入，数字也会随之变化。今天的榜首并不能保证明天依然领先。我们不会在这篇文章里花太多篇幅讨论今天的领先者，因为我们预计这种情况会随时间改变。相反，让我们来看看数据告诉了我们哪些关于如何为你的工作负载做决策的信息。
搜索预算比其他任何因素都更重要
将引擎预算从一轮提升到更多轮，比你能做的任何其他单一改动都能更有效地提升质量。为了说明这一点，以下是我们最初在 Perplexity 上以三种不同预算运行 BrowseComp 的结果：
| 模型，搭配 Perplexity | 1 轮 | 5 轮 | 25 轮 |
|---|---|---|---|
| Claude Opus 5，高 | 35.8%（$0.14） | 66.5%（$0.51） | 89.0%（$0.99） |
| GPT-5.6 Sol，高 | 46.3%（$0.20） | 65.2%（$0.29） | 82.4%（$0.50） |
| GPT-5.6 Luna，超高 | 33.7%（$0.02） | 57.0%（$0.04） | 74.0%（$0.10） |
这种规律在我们测过的所有提供商身上都成立：
这些运行只覆盖 BrowseComp，使用服务器工具、每次搜索返回十条结果，不进行页面抓取或代码执行，并且每个配置取最新一次符合资格的运行结果。
增加搜索深度是我们发现的提升质量最便宜的方式。从 1 轮增加到 25 轮，分数大约翻倍，而每道题的成本只增加 2.5 到 7 倍。
你可能会认为这普遍会拖慢响应时间，但情况并非总是如此。例如，Luna 在 1 轮时每道题耗时 140 秒，而在 25 轮时耗时 111 秒。在我们同时以 1 轮和 5 轮运行的 35 个配置中，超过三分之一在轮数更少时反而更慢。这些全都是 OpenAI 的模型。这些模型会用额外的推理来应对受限的搜索预算。
另一方面，在较简单的任务上，搜索深度可能会对成本产生不利影响。例如，在 HLE 上，GPT-5.6 Sol 搭配 Perplexity 在 1 轮和 25 轮之间得分相近，但成本却是三倍。如果你的搜索往往比较简单，那么把预算控制在有限范围内可能仍然是值得的。
你最坏情况下的成本场景是由你的失败率驱动的
另一种扩大预算反而有害的情况是模型无法找到答案时。我们发现，模型会耗尽预算去尝试寻找答案，尽管最终仍会失败。
| 测试套件（25 轮预算） | 答对时的平均搜索次数 | 答错时的平均搜索次数 |
|---|---|---|
| BrowseComp | 10.3 | 19.7 |
| DeepSearchQA | 11.7 | 20.1 |
| HLE | 5.2 | 7.5 |
| WideSearch | 17.6 | 23.4 |
我们记录到的最深尝试是在 WideSearch 表格上进行了 81 次搜索，结果仍被判为错误。如果你的工作负载失败率很高，那么降低搜索深度很可能是削减成本的有效途径。
引擎固然重要，但模型更重要
预算设定之后，下一个最重要的问题就是该用哪个模型。
| 模型 | Perplexity | Exa | Parallel |
|---|---|---|---|
| Claude Opus 5，高 | 89.0%（$0.99） | 82.2%（$1.29） | 88.8%（$2.42） |
| GPT-5.6 Sol，高 | 82.4%（$0.50） | 77.8%（$0.54） | 76.6%（$1.26） |
| DeepSeek V4 Flash，高 | 77.0%（$0.08） | 67.4%（$0.12） | 64.6%（$0.10） |
| GPT-5.6 Luna，超高 | 74.0%（$0.10） | 68.4%（$0.14） | 58.0%（$0.11） |
上表展示了 25 轮下的 BrowseComp 结果，对比了各搜索引擎上前沿模型与高性价比模型的表现。
在保持模型不变的情况下更换引擎，得分平均变化约 10 个百分点，而前沿模型与高性价比模型之间的平均差距更大，为 15 个百分点。在各引擎之间，前沿模型的成本差异最大，最贵的引擎是最便宜的 2.5 倍，而高性价比模型仅为 1.5 倍。
之所以能做这样的对比，是因为服务器工具位于提供商之上。更改请求中的模型，搜索行为会保持一致，包括那些提供商本身不提供搜索功能的模型。
当然，基准测试只是潜在性能的参考。它们能告诉你哪些配置值得尝试，以及大致成本。这些选择在你自己的实际任务中的成本和质量会有所不同，因此这些页面最有价值的用法是将其视为候选清单，然后把你自己的问题跑一遍排名靠前的几个配置。
在自己的工作负载上试试
以上所有内容都是你现在就可以在 OpenRouter 上设置的请求参数。
- 网页插件。该网页插件在模型开始写作前执行一次搜索，对于只需要最新事实的问题来说，这是快速且廉价的选择。
- 服务器工具。服务器工具将搜索工具交给模型，让其自行决定下一步查找什么，当答案需要分几步才能找到时，这正是你所需要的。
- 引擎。在 OpenRouter 上，你可以将引擎设置为 exa、parallel、perplexity 或 native；auto 模式会先尝试 native，再回退到第三方引擎。
- 搜索预算。顶层 `max_tool_calls` 请求字段限制了它可进行的智能体轮次数量，即它在必须作答前可进行的搜索轮数，而 `max_results` 则设置每次返回的结果数量。
一个合理的起点：选择最接近你任务的套件，在得分最高的几个配置中选取最便宜的方案，然后针对其上方两到三行的配置重新运行你自己的评估集，看看额外的花费是否体现在你的结果中。
基准测试方法
每次运行都通过公开的 OpenRouter API 针对生产环境端点进行，并使用我们的开源基准测试框架。
- 仅限于搜索性能。为确保我们只比较搜索配置，我们统一了每次搜索返回十条结果、不抓取页面、不执行代码。推理过程按模型固定，如表所示。
- 评分严格。每个评估答案根据官方答案键判定对错，在需要语义比较时使用 LLM 评判。WideSearch 还单独报告答案条目的准确率。
- 成本和速度按每个问题计算。成本是总支出（包括评分）除以评估的问题数。速度是每个评估问题的候选生成时间。
- 每个页面显示每个配置的最新合格运行结果。一次运行在完成最少问题数量后即视为合格，新的运行会取代旧的运行。
常见问题解答
这些分数与已发布的供应商智能体排行榜相比如何？
它们之间不具备直接可比性。大多数已发布的基准测试榜单衡量的是完整的智能体产品，这些产品结合了搜索、整页抓取和代码工具。而这些排行榜则隔离了搜索配置：模型仅读取搜索结果摘要，页面抓取和代码工具均处于关闭状态。这样可以实现配置之间的直接比较，但不会最大化基准测试分数。
我应该选择哪个搜索引擎？
这取决于模型和任务，这正是这些页面存在的原因。对于某些模型来说，不同引擎之间的差距很大，而对另一些模型则几乎可以忽略不计；并且，某个提供商自身的原生搜索并不自动就是其最佳选择。请查看与你工作负载最接近的套件的实时排行榜，将成本和延迟与分数一并阅读，并随时间推移反复查看，因为随着新运行的发布，排序会发生变化。
这些数字有多新？
排行榜始终显示每个配置的最新合格运行结果，这些结果是在 OpenRouter 的基准测试框架上针对生产环境端点执行的。新的运行结果会在页面上取代旧的结果。
在 Discord 的 #feedback 频道告诉我们，接下来我们应该对哪些引擎或模型进行基准测试。