OpenRouter 上线 Auto Exacto 自适应质量路由，工具调用请求默认开启

10 月，我们上线了 Exacto：经过人工精选的端点，凭借经过审核的提供商子集，具备更好的工具调用准确率。与默认路由相比，Exacto 在 Tau2Bench 和 LiveMCPBench 上的得分提升了 10-20%。

但我们从社区听到，他们期望更多。你必须在模型 slug 后追加 :exacto，而且仅适用于受支持的模型。并且提供商列表是静态的，需要手动更新，并且在我们重新运行分析之前一直冻结。

Auto Exacto 旨在解决所有这些反馈。它大约每 5 分钟根据三个信号重新评估提供商：吞吐量、工具调用遥测和基准分数。对于包含工具的请求，它默认开启。

{
  "model": "moonshotai/kimi-k2.5",
  "messages": [
    {"role": "user", "content": "Find me a flight to Denver."}
  ],
  "tools": [...]
}

如果你希望对非工具调用请求也使用同样的质量加权路由，可以像以前一样，通过在任何模型 slug 后追加 :exacto 来选择启用。这适用于所有模型和所有请求类型，类似于用于吞吐量排序的 :nitro 和用于价格排序的 :floor。

第一周问题

提供商差异在模型刚发布时达到峰值，而这恰恰也是最多人尝试使用它的时候。

推理引擎需要为新聊天模板、新格式、新参数打补丁。Moonshot 发布 Kimi K2 时，vLLM 和 SGLang 的提交在第一天就已准备好。即便如此，仍然花了数周发布后的工作才把一切做对。

Artificial Analysis 用 gpt-oss-120b 展示了这一点：第 1 周差异巨大，一个月后收窄成很窄的区间。

Auto Exacto 在这个窗口期帮助最大。尚未稳定的提供商会自动被降级。随着它们改进，它们会重新上升。无需人工更新列表。

我们一直在测量什么

自 2025 年 8 月以来，我们一直在对 OpenRouter 上所有 tool_call 响应进行评分。我们测量了三件事：

tool_call 是否是有效的 JSON？
工具名称是否确实在用户提供的工具中？
schema 是否匹配？

我们以这种方式在数月内测量了数十亿次工具调用，并对这一信号有很高的信心。

不过，生产流量也有局限——某个提供商主要被 Kilo Code 用户使用，另一个则看到演示工具调用应用的流量。schema 可能差异极大，尤其是在复杂度、提供的工具数量方面，当然，用例也各不相同。仅凭真实世界数据无法得出干净的对比，所以我们也构建了受控基准。

TauBench Verified 和 GPQA-Diamond

我们正在按周期在提供商之间运行两个基准：

TauBench Verified Airline（来自 τ²-Bench 套件，并使用 AWS-AGI Verified 数据集）。智能体工具调用评估，航空公司客服领域。它足够小，可以频繁运行而不至于烧掉一大笔钱，但又足够复杂，能够暴露真实的提供商差异。请注意，该数据集与经常发布的数据集不同，因此我们的 TauBench Airline 分数与你可能在网上找到的分数并不等同。该数据集可在此处找到

GPQA-Diamond，一个大多数人都熟悉的基准，是一个知识密集型推理基准，为我们提供了第二个维度。我们此前曾与 Florian Brand 和 Epoch 团队合作，使用该基准进行提供商差异分析。他们的发现是：对于成熟模型，GPQA-Diamond 上的提供商中位数紧密聚集——差异主要是噪声。但当差异真实存在时，它就很明显。

我们的发现

我们已经在生产环境中测试这一路由变更数周，仅影响一个内部账户，通过该账户微调行为并运行基准测试。过去几天，我们为精选的一批顶级工具调用模型全局启用了 auto exacto—— notably GLM-4.7、GLM-5、DeepSeek V3.2 和 gpt-oss-120b。

以下是自美国东部时间 3 月 10 日周二下午 5 点以来，我们的默认路由在各模型上的改进情况，对比了之前的按价格加权算法与新的 auto exacto 算法：

GLM-5 和 GLM-4.7 的工具调用错误率分别下降了 88% 和 80%。这是代理可靠性的巨大提升。此前我们看到的错误率约为 8%，现在平均接近 1%。在 20 次运行中，Tau Bench Verified Airline 分数与 Z.AI 官方端点保持一致。
gpt-oss-120b 的错误率下降了 36%，从 5.6% 降至 3.5%，其 TauBench 分数从 53% 提升了 2% 至 55%，与我们各提供商 55% 的平均分持平。
DeepSeek V3.2 的工具调用错误率下降了 16%。我们在此看到的主要改进是 TauBench 分数从 69% 升至 74%，提升了 5 个百分点，远超噪声范围且具有统计显著性。

GPQA Diamond 结果仍在运行中，我们旨在收集具有统计显著性的数据。我们将在未来几天内用这些结果更新本博客。

路由如何工作

Auto Exacto 使用三类信号对提供商进行分类：

吞吐量。每秒生成的 token 速度，从生产流量中持续测量。
工具调用遥测。我们自 8 月以来一直在收集的生产数据：JSON 有效性、模式合规性、工具名称准确性。
基准分数。TauBench Airline 和 GPQA-Diamond，通过我们的内部基础设施按周期运行，使用 Groq 的 OpenBench。

这三类信号输入到一个按模型自适应的阈值系统中。系统使用所有服务该模型的提供商的中位数和中位数绝对偏差，计算出每个模型的“好”与“坏”标准。只有当某个提供商在特定模型上相对于同类是统计异常值时，才会被标记。

提供商分为三个层级：

验证良好。数据充足，且三类信号均无异常。
数据不足。请求量尚不足以判断——这些处于中间位置，不被视为一等，但也不受惩罚。
降级。在一个或多个信号上属于统计异常值，会被推到队列末尾。

在每个层级内，原始路由顺序（价格、延迟、你的偏好）保持不变。本次发布中，我们选择不尝试构建一个将吞吐量、基准和工具调用数据混成一个数字的综合评分。我们只是将表现最差的提供商推到后面。这更容易理解，也更容易调试。

未来，可能会有一个综合评分，纳入更多信号，包括定价，为所有请求（无论是否工具调用）构建类似的质量加权路由。我们欢迎任何反馈或想法，关于你最关心哪些能泛化到你所有用例的东西。

OpenRouter 大约每 5 分钟重新计算一次所有评分。每次计算时，每个模型和信号的参考统计数据（中位数、偏差、计算出的阈值）都会被持久化保存，并附带完整的审计追踪。如果我们需要调试为什么某个提供商上周二下午 3 点被降级，我们可以做到。

我们观察到但（目前）不用于路由的指标

偶尔，我们会注意到某个提供商在相同的基准任务上消耗的 token 比中位数多 30%。这可能意味着循环、填充或推理引擎的怪癖，尤其是对于较新的模型。我们目前不对此采取行动，但会调查并向相关提供商标记该问题。

我们还注意到其他信号，这些信号对所有提供商都会出现，包括队列时间和吞吐量方差。我们将评估这些信号能提供多少价值，并考虑在未来纳入它们。

基础设施

我们在 Groq 的 OpenBench 之上构建了内部工具（Mission Control），它封装了英国 AI 安全研究所的 Inspect 框架。Temporal 处理长时间运行的工作流。GCP 上的 GKE 容器运行基准测试，超额配置到 16GB RAM，因为 agent 评估会消耗大量内存。

相同的基准测试、相同的环境、相同的配置，按固定计划重复运行。运行之间没有人工调整变量。每个提供商每个模型取多次运行的平均值。

关于量化和工具调用解析器

人们将提供商差异归咎于量化。我们尚未发现仅量化本身对工具调用质量有可测量的影响。

真正的罪魁祸首，往往不是量化，而是工具调用解析器。这通常是推理引擎的问题，而不是提供商偷工减料。即使模型实验室在发布前直接与推理引擎团队（vLLM、SGLang）合作，他们也不总能一次就做对。每个人都需要时间来弄清楚模型希望如何使用工具，以及如何成功解析这些调用。

Florian Brand 的 GPQA-Diamond 分析显示，尽管量化水平差异很大，各提供商的中位数几乎相同。DeepInfra 运行激进的量化，但表现一直不错。Novita 在 FP4 下击败了 FP8 提供商。Kimi K2 的官方权重以原生 int4 发布。

推出

Auto Exacto 现已上线。其工作原理如下：

工具调用请求：对于任何有足够多提供商可供测量方差的模型，默认开启。
所有其他请求：在任何模型 slug 后附加 :exacto。适用于所有模型。
新提供商：在处理足够多的流量之前，处于中间层级。我们不会将您推向未经测试的端点。

关于定价：质量加权路由可能会偏向比绝对最便宜选项稍贵一些的提供商。如果您无论如何都想要最便宜的推理，可以使用 :floor 快捷方式，或直接固定提供商。

{
  "model": "moonshotai/kimi-k2:floor"
  // OR, use this:
  "provider": { "order": ["fireworks"] }
}

我们将发布的内容

我们正在努力公开这些数据：

每个模型提供商的工具调用准确率随时间变化，现已在性能标签页中实时显示
TauBench 和 GPQA-Diamond 结果，定期更新

我们将首先提供摘要。我们希望在发布完整数据集之前，让提供商有机会查看数据并做出回应。当我们发现问题时，我们始终看到聪明的团队会迅速修复。

结语

问题、反馈、投诉：我们在 X 和 Discord 上。