每任务成本：使用廉价分类器在 Gemini 模型和思考级别之间进行路由

2026年11月3日

每 token 的 API 价格持续下降，但自主编码智能体的工程账单却在不断攀升。每百万 token 的价格已不再是决定生产经济性的真正指标。如今占主导地位的指标是每个成功任务的成本：跨所有循环迭代、工具调用、重试和内部思考过程的总支出，除以通过验证的任务数量。

当智能体在其框架中为每个微决策都调用高思考推理配置时，你实际上是在为轻量级配置本就能准确回答的问题支付深度推理的价格。为避免这种不必要的开销，可以考虑添加一个轻量级路由层，在常规决策到达昂贵的推理模型之前就将其拦截。

这正是将 TypeSafe 的 Jev 分类器接入 Google Antigravity 模型调用之前的前提。Jev 是一种专为高吞吐量决策管道设计的结构化输出分类器，它不会逐 token 生成文本，而是在单次前向传播中评估结构化分类原语：从列表中选择一个 Choice、一个数值 Score，或一个 Noul——后者针对二元陈述返回 0 到 1 的概率。

需要完全披露的是，Google 与 TypeSafe 没有合作关系，本文也不构成对 TypeSafe 或其产品的背书。这里使用 Jev 只是作为轻量级分类器的一个示例，同样的路由模式也可以用其他分类器构建，包括 Google 原生的分类器。例如，判别式模型入门 codelab 就在你自己的 Google Cloud 项目中，使用 Google DeepMind 的开放权重模型 DiffusionGemma 运行同类分类器。

我们针对实时 Gemini 和 Jev API 运行了一项包含 50 个问题、自动评分的编码智能体基准测试，以检验一个近乎零成本的分类器能否将每个任务路由到仍能正确完成它的最便宜模型。以下是我们得到的结论：

1. 正则表达式和 token 长度框架路由器在未见过的智能体任务上会失效

让 Jev 路由编码任务的朴素方式是提出一个宽泛的 Choice 问题：simple 还是 complex。当我们首先在 16 个编码智能体任务上测试时，Jev 几乎将所有任务都路由到 simple，甚至包括需要 LRU 缓存追踪或模幂运算的任务。TypeSafe 的文档明确警告不要使用这种反模式。如果一个问题涉及多个因素或需要元判断，就应将其分解为原子级检查。

当我们用一个原子级 Noul 问题取代宽泛的 Choice 问题后，分离效果立刻得到修复。这个问题是：回答此问题是否需要执行超过一次的顺序计算、模拟步骤或逻辑推导，而不是单次直接查找、格式检查或一步分类？

def call_jev(question_text):
    body = {
        "state": question_text,
        "model": "jev-latest",
        "questions": {
            "multi_step": {
                "type": "noul",
                "instructions": (
                    "Answering this requires performing more than one "
                    "sequential calculation, simulation step, or logical "
                    "deduction, rather than a single direct lookup, format "
                    "check, or one-step classification."
                ),
            }
        },
    }
    # Send the request above to the classifier's API.
    # response.answers["multi_step"].noul is the probability used to route.

在最初的 16 个任务中，Jev 在第一轮运行中有 13 个任务的路由结果与我们手工标注的难度一致，第二轮则有 14 个。许多工程团队会问，既然可以用 Python 编写零成本的正则表达式和提示词长度启发式规则——匹配 sequence、modulo 和 race condition 等词语，或对超过 35 个词的任何提示词进行升级处理——他们是否还需要分类器 API。

在用于编写这些确切规则的 16 个开发问题上，本地启发式方法答对了 16 题中的 15 题，即 93.8%。为了检验该启发式方法在面对真实编码代理流量时是否依然有效，我们冻结了它的代码，一个字符都没有改动，并在七个编码代理类别中新增了 34 个未见过的留出任务：事实提取、模式验证、简短分类、单跳代码检查、状态模拟轨迹、数学或逻辑链以及微妙的语言语义缺陷。

在 34 个留出问题上，冻结的启发式方法下降了 23.2 个百分点，降至 70.6%。诸如从 Kubernetes YAML 清单中提取端口、从统一 git diff 头中提取文件路径或从 Python 回溯中提取行号之类的现实简单任务，超过了 35 个词，从而触发了错误的升级。相反，诸如跨调用的可变默认参数、Python 字典键在 {1: "a", True: "b", 1.0: "c"} 上的哈希以及 C 语言短路求值之类的简洁多步代码轨迹，缺少该启发式方法硬编码的谜题词，因而被错误地路由到了简单路径。Jev 对全部 34 个未见任务的分类一致率为 100.0%（34/34），在整个套件上达到 50 题中的 48 题，即 96.0%。

2. MaxOutputTokens 是上限，而不是思考预算旋钮

在构建快速路径路由器时，一个常见的错误是假设为推理模型设置较低的 maxOutputTokens 上限会让它在简单任务上花费更少。我们的 50 题数据说明了为什么这个假设不成立。

当我们比较 gemini-3.8-flash 与 maxOutputTokens=300，以及 gemini-3.8-flash 与 maxOutputTokens=4096，同时将 thinkingConfig 保持在 API 默认值时，两种配置在 Jev 标记为 SIMPLE 的 27 个任务上花费的思考 token 几乎完全相同：

注意： 图中数据反映的是在样本测试套件上单次运行的实验测量结果；实际延迟、token 数量和计费成本将因提示长度、上下文缓存和生产负载而异。

将模型的输出限制在 300 个 token 并没有在简单任务上省下任何钱。这个上限只是一个天花板，而简单的答案从未接近过它。在简单任务上，有限制的版本实际上比没有限制的版本花费略多。这个上限所做的唯一事情就是弄坏了 25 个困难任务中的 7 个。其中六个，模型在仍在推理时就耗尽了空间，从未给出答案。第七个，它压缩了推理以适应限制，按时完成但答错了。

因此，一个将简单任务发送给有限制模型、将困难任务发送给普通 Flash 的 Jev 路由器，50 题全对。它仍然比跳过路由器、全部使用普通 Flash 花费略多，而且更慢。如果你的廉价选项实际上并没有让模型在简单任务上思考得更少，那么任何路由器都无法为你省钱。即使是一个完美的、零成本的路由器也不行。

3. 将 Jev 与没有路由器的最强配置进行基准测试

减少思考开销最直接的方法就是让模型少思考。因此我们进行了第二轮测试，使用了两个更轻量的选项：默认完全不思考的 Flash-Lite，以及思考级别设为低的 Gemini 3.8 Flash。我们将这些结果添加到同一个结果文件中，逐题对应。

关于计时的说明。路由器在每个任务上的大部分时间都花在 Flash-Lite 和 Flash 调用上，我们在与纯 Flash 基线相同的运行和时间窗口内测量了这些调用，因此它们之间的速度比较是公平的。Jev 自身的决策只占总时间的一小部分，且来自第一轮。与默认 Flash 或 Pro 的速度比较混合了两轮，因此请将这些视为近似值。

注意：数据反映的是在样本测试套件上的单次实验测量结果；实际延迟、token 数量和计费成本会因提示长度、上下文缓存和生产负载而异。

7 桶细分展示了 gemini-3.5-flash-lite 和启发式路由器在哪些任务上失手，以及 Router Jev: Flash-Lite to 3.8 LOW 如何恢复 100% 准确率：

不使用路由器的最强配置是 Gemini 3.8 Flash 低思考模式。它解决了全部 50 个任务。这就是路由器必须超越的数字。

Jev 路由器超越了它。它先把每个任务发送给 Flash-Lite，只将 Jev 标记为复杂的任务升级处理。它同样解决了全部 50 个任务，而且与全部使用低思考模式相比，它还能帮助同时降低成本和响应时间。在如此短的提示下，每个任务的成本差异很小，因此对于交互式智能体来说，更短的等待时间是更大的收益。

它为何有效。单独使用时，Flash-Lite 在半秒内回答了每个简单任务，但在 25 个困难任务中失手了 6 个。Jev 以高置信度将这 6 个全部标记为复杂并进行了升级处理。这使其成本接近完美路由器所能达到的水平。

关键词启发式方法更便宜，但只是因为它出错了。它将 5 个困难任务发送给了 Flash-Lite，其中 2 个失败，最终得分为 50 个中的 48 个。

升级到更重的设置在这里并不划算。将困难任务路由到默认思考模式的 Flash，比在所有地方都使用默认思考模式更便宜。但它仍然比全部使用低思考模式更贵，而后者已经解决了全部 50 个任务。只有当低设置开始失败时，更重的升级目标才有意义。

局限性：每种配置仅运行一次，50 个提示，难度为人工指定，采用简单自动评分。

4. 每 token 价格并不能说明全部情况

我们结果中有两件事只有在超越这一点后才能看到。

路由和缓存的方向相反。我们的测试提示是简短、独立的任务，在这些任务上 Jev 路由器帮助降低了成本和响应时间。真实的编码智能体通常有所不同。它们每一轮都发送相同的大块上下文，例如仓库地图和工具定义。Agent Platform Context Caching 会存储该块，因此重新发送时可节省 75% 到 90% 的费用。问题在于缓存属于单个模型。如果你的智能体在每一轮之间在 Flash-Lite 和 Flash 之间切换，它要么保留两个缓存，要么失去折扣。实际的划分方式是：将日志解析或 schema 检查等简短、自包含的任务进行路由，而将长的、上下文密集的轮次保留在同一个模型上。

让模型与工作负载匹配。Gemini 3.1 Pro 专为深度、多步推理而构建，它会将同样的深度带入每个请求，包括不需要这种深度的简短查找。对于主要由快速检查和提取组成的工作负载，Flash 配置更合适，而 Pro 最好留给需要其推理深度的任务。模型配置还可以对安全相关提示应用不同的安全设置。在我们的运行中，Pro 配置拒绝了两个 Flash 回答过的简短代码安全审查提示。如果你的智能体执行安全审查，请在你计划使用的配置上测试这些提示。

每个成功任务的成本需要正确的分母

构建路由器的其他方式。 Jev 是获得快速分类器的一种方式，但并非唯一方式。判别式模型入门 codelab 在 DiffusionGemma（Google DeepMind 的开放权重模型，托管在 Compute Engine GPU 虚拟机或您自己 Google Cloud 项目中的 Cloud Run 上）上运行相同的 Choice、Score 和 Noul 问题。一个开源服务器在其前面暴露相同的 API，因此本文中的路由代码只需更换端点即可。我们的结果来自 Jev，所以在切换之前请在您自己的任务上测量准确率和延迟，并请记住自托管模型按 GPU 小时计费，而不是按 token 计费。

综合来看，这些结果给出了三条实用规则。

在构建路由器之前，先从 Flash 的低思考模式开始。 它解决了全部 50 个任务，且成本远低于默认设置。降低输出 token 上限并不能替代这一点，因为它不会减少模型在简单任务上的思考量。请直接设置思考级别：thinkingLevel: "LOW"。

使用 Jev 路由简短、独立的任务。 将简单任务发送给 Flash-Lite，将困难任务发送给低思考模式的 Flash。针对每个因素向 Jev 提出一个简单的是否问题。在我们的测试中，与全部使用低思考模式的 Flash 相比，这有助于降低成本和响应时间，并接近完美路由器所能达到的效果。将长的、上下文繁重的轮次保留在单个模型上，以便缓存继续生效。对于高吞吐量的仓库工作负载，Jeff Nelson 的 BigQuery 和 Cloud Run 级联模式应用了相同的思想。

测量您的智能体实际花费了什么。 将智能体的跟踪信息和思考 token 计数发送到 Cloud Logging 和 BigQuery，这样您就可以看到哪些任务驱动了您的支出，并发现导致支出膨胀的截断或重试。基准测试代码将在开源审查后发布。

总之，运行智能体最具成本效益的方式是将每个任务匹配到适合它的模型。 从一个快速模型的轻量设置开始。您通常会发现它已经能完成工作。然后添加一个小型、几乎免费的分类器（如 Jev），仅将困难任务发送给更强的模型，并提出简单的是否问题而不是一个宽泛的问题。根据每个正确完成的任务的成本（而不是每个 token）来评估每个选项。