Google 实测用轻量分类器在 Gemini 模型和 thinking 级别间路由以降低每任务成本

2026年11月3日

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

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

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

特此说明，Google与TypeSafe并无合作关系，本文也不构成对TypeSafe或其产品的背书。此处仅将Jev作为轻量级分类器的一个示例，同样的路由模式也可以用其他分类器构建，包括Google原生的分类器。例如，判别式模型入门代码实验室就在你自己的Google Cloud项目中，对Google DeepMind的开源权重模型DiffusionGemma运行同类分类器。

我们针对实时Gemini和Jev API运行了一个50道题、自动评分的编码代理基准测试，以检验一个近乎免费的分类器能否将每个任务路由到仍能正确完成它的最便宜模型。以下是我们得到的发现：

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

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

当我们把宽泛的Choice问题替换为一个原子Noul问题后，区分度立刻得到修复。问题是：回答这个问题是否需要执行多于一次的连续计算、模拟步骤或逻辑推演，而非单次直接查找、格式检查或一步分类？

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.

Python

已复制

table_1_task_routing_sample

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

在用于编写这些确切规则的16道开发问题上，本地启发式方法在16道中答对了15道，即93.8%。为了测试该启发式方法在接触真实编码智能体流量后是否仍然有效，我们将其代码原封不动地冻结，并新增了34道未见过的留出任务，涵盖七个编码智能体类别：事实提取、模式验证、短分类、单跳代码检查、状态模拟轨迹、数学或逻辑链以及细微的语言语义错误。

table_2_benchmark_split_agreement

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

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

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

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

table_3_easy_task_configuration

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

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

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

3. 将Jev与不使用路由器的最强设置进行基准比较

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

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

table_4_strategy_performance_comparison

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

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

table_5_task_bucket_breakdown (1)

不使用路由器时最强的配置是低思考模式下的 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 上运行同样的 Choice、Score 和 Noul 问题，DiffusionGemma 是 Google DeepMind 的开放权重模型，托管在 Compute Engine GPU 虚拟机或你自己 Google Cloud 项目中的 Cloud Run 上。一个开源服务器在其前面暴露相同的 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 的成本。