Gemini Decision 1：7 胜 2 负，单次请求 0.6 美分

11 月 11 日，谷歌在 AI Studio 上线 Gemini Decisions API，背后的 gemini-decision-1 不生成文本，只在一次前向传播里给候选答案打分。官方给了 9 项基准，7 项第一。这篇不做能力综述，只算两笔账：一次请求 1000 个判断要花多少钱，以及那两次输掉的比赛说明了什么。

一、它把「写答案」换成了「给候选打分」

常规做法是让模型把答案写出来，再从文本里抠出结论。Gemini Decision 1 省掉了后半段：开发者提交输入、问题和候选集，模型直接返回胜出项、归一化概率，以及一个 0 到 1 的置信度。

三种判断可以混在同一次请求里执行。

单次请求最多 1000 个问题，多模态输入上限 256K token，文本、图像、音频、视频与 PDF 可以混在同一份输入里。图像与视频还能调分辨率，用来控制细节程度与 token 消耗。

0.6 美分是怎么算出来的

官方只给了单价：每百万输入 token 0.10 美元，输出不计费。计费规则里有一条关键设定——同一份共享输入在一次请求中只计费一次，每个问题只增加自己的指令与评分标准那点 token。

代入一个常见场景：共享上下文 1 万 token，1000 个问题各带 50 token 指令。总 token 是 6 万，成本 0.006 美元，即 0.6 美分，摊到每个判断约 0.0006 美分。需要说明的是，每问题 50 token 是本文的假设值，官方没有给典型指令长度。

官方称在共用基准套件上，它比通过 Interactions API 调用 Gemini 3.5 Flash-Lite 便宜近 5 倍。按这个倍数反推，同样的活交给 Flash-Lite 大约 3 美分。这是推出来的数，不是官方给的，只能当量级看。

真正的分界不在单价，在计费结构。生成式的账单随答案变长，决策式的账单只随输入变长，预算能提前封顶。这一点在 11 月的大模型 API 价格表 里也成立：输出单价往往比输入贵三到五倍，而这类模型干脆把输出那一段砍掉了。

二、9 项基准 7 项第一，输的两项很扎眼

官方挑的对手只有三个：OpenAI 的 GPT-6 Luna、专做分类决策的 TypeSafe Jev 1.14，以及自家的 Gemini 3.5 Flash-Lite。这份对比表有个值得注意的特征——赢的格子填满，输的格子也照实写。

领先幅度差别很大。New Yorker Caption 上甩开 GPT-6 Luna 11.3 个百分点，Global-MMLU-Lite 上 6.4 个点，PubMedQA 上 5.4 个点；到 JevBench 就只剩 1.3 个点。这说明「7 项第一」是平均数意义上的胜利，不是每一项都压倒。

输的那两项，正好在 Agent 的主场

Mind2Web Multimodal 差 0.6 个百分点，可以当噪声处理。When2Call 差 2.1 个点，就不太好解释了。

它考的正是「该不该在这个时候调用工具」，而工具选择与调用时机判断，是谷歌自己在发布稿里点名的核心场景。

两次都输给同一款模型。TypeSafe Jev 1.14 是专门做分类决策的小模型，不是通用大模型。这也给「首款决策模型」的说法打了个折扣：专用决策这条路此前已经有人走，谷歌是把通用模型的规模优势搬了过来。

另一处值得记下：JevBench 从命名看与 TypeSafe 的 Jev 系列同源。若它确为对方主推的基准，92.2 对 90.0 这 2.2 个点，就是在对手的主场拿到的。

三、校准误差 0.0250，这个数比准确率更该看

官方特别强调了 Top-1 ECE（预期校准误差）。它衡量的不是答对多少，而是「说出的把握」与「实际正确率」差多少——说九成有把握的那批判断，实际只对了七成，误差就很大。

0.0250 意味着说九成把握时，实际正确率大致落在 87.5% 到 92.5% 之间。换成 0.2104 的模型，同样一句「九成把握」可能只对应七成正确。官方口径下，它比 GPT-6 Luna 低约 65%，比 Flash-Lite 低约 88%。

阈值化自动执行的账

假设一个工单分流的场景：置信度高于 0.9 就自动派单，低于就转人工复核。模型越说越不准，这条阈值越不管用。

按每个复核单 2 元人力、自动派单近乎零成本估算，两成转人工意味着每 1000 单要付 400 元复核费。而 1000 次判断的模型调用费是 0.6 美分。两者差了约 9000 倍。

这个对比说明：这类模型省钱的地方不在 token，在「多大比例能放心交给机器」，而校准误差直接决定这个比例。评估供应商时，只看准确率会漏掉真正的成本项。

四、四个要打折的地方

第一个是状态。官方稿里没有 preview 或 GA 字样，只有 introducing 和 start building today。是否正式可用、哪些区域可用、限流多少，三样都没写。

第二个是可比性。9 行里有 4 行的对手分数是空的，官方只说高于 Flash-Lite，没给具体值。这不算造假，但「7 项第一」的含金量要按有数的格子算。

第三个是没有推理过程。输出里只有概率和置信度，没有解释、没有中间步骤。对需要留痕的合规场景，这反而是硬伤——你能拿到「0.93 的概率认为有风险」，拿不到「为什么」。

第四个是能力边界。0 输出 token 也意味着它不做链式思考。多步推理、需要拆解的任务，仍然要交给生成式模型。Gemini 4 Carbon 的评测 里那类多轮 Agent 任务，就不是它的战场。

用与不用

适合的活：模型路由、内容分类、检索相关性打分、安全判别、评分标准明确的审核。判断标准很简单——答案本来就在一个封闭集合里选。

不适合的活：开放式生成、需要解释的判断、选项不封闭的问题。

谷歌自己披露的四个内部案例都属于前者：Gemini Notebook 拿它做实时路由，日常查询延迟最多降 40%；Stitch 用它做线框图的快速迭代；Google Labs 的 CC 从 200 多个表情里选一个反应；Search 内部用它给 MCP 工具做安全检测层，识别对抗性行为。最后这个用法在 权重后门研究 里被反复强调过——上线前先判别，比上线后补救便宜。

顺带一句：那 40% 是路由省的，不是判断本身省的。判断本身的端到端延迟仍是 150 到 250 毫秒，这个数字的前提是上下文不超过 16K token、问题数在 1 到 100 之间。

一句话定位

把它当成系统里的一个零件，定位就清楚了：不是更聪明的模型，是更便宜、更可预测、自带置信度的判断器。

要不要用，取决于你的系统里「判断」和「生成」是不是被混在同一个调用里。如果是，拆开就能省下钱，还能顺带拿到一个可用的置信度阈值。如果本来就只有生成，它帮不上什么忙。