Google 的 Decisions API 回答 1,000 个问题，且不对输出计费

最便宜的部分并不存在于Gemini Decision 1 之中。Google 于 2026 年 11 月 11 日将该模型置于新的 Gemini Decisions API 之下，而定价页面将输出价格列为零——不是便宜，不是打折，而是根本不存在，因为 POST /v1beta/decisions 没有可供生成的文本。你发送一个共享输入块，外加最多 1,000 个带类型的问题；每道问题返回一个经过校准的答案，除此之外别无其他。发布当天吸引注意力的是排行榜上的数字。真正改变你所构建之物的，是那条计费项；在照搬任何人的架构图之前，值得先把这笔账算清楚。

过去两年里，你做出的其他每一个模型决策，都受到两种方向相反的成本影响：输入，你想只发送一次；输出，你想保持简短。这个端点完全消除了第二种矛盾，并用另一种矛盾取而代之，后者存在于单个请求内部。一旦你看出新的矛盾在哪里，API 设计的其余部分——问题数量上限、共享上下文、没有缓存——就不再显得随意了。

零输出 token 对算术运算的影响

设想一个真实的文档评分任务：一份 40,000 token 的政策或合同，以及你想就它获得答案的 1,000 个问题。向 Decisions API 发起一次请求只会对 40,000 个输入 token 计费一次，按每百万 $0.10 计算，也就是十分之四美分——全部一千个答案只需 $0.004。

现在，以 1,000 次单独的 generate-content 调用，按你一周前会采用的方式提出同样的 1,000 个问题。每次调用都必须携带该文档，因为聊天端点无法在多次调用之间保留它。这就是 4,000 万个输入 token，按相同的每 token 费率计算为 4.00 美元；而且一旦把每次调用原本会产生的输出 token 也算进去，差距还会进一步扩大。封装并不是一项便利功能。对于同样的工作，它带来的是上千倍的成本差异，而这源于一个单一的设计选择：问题是在单次处理中针对一个共享上下文进行评估，而不是每次往返评估一次。

这套算术也告诉你这个模型所期望的工作负载形态：关于同一个大对象的许多问题，一起得到回答。如果你的问题是关于 1,000 个不同的对象，你就会得到 1,000 个请求，一点节省都没有。

信封：262,144 个 token，共享，且上限为 1,000 个问题

上下文窗口将共享输入和请求中的每个问题一并覆盖，共 262,144 个 token。在该预算内，你可以提出 1 到 1,000 个问题。真正重要的是上限：一次调用中提出 1,000 个问题并不属于分类器的范畴，而是相当于把规则引擎级别的判断力压缩进一次处理中。一张支持工单可以对照四十条政策条款进行检查；一份贷款文件可以一次性对照所有核保规则进行检验。

请求形态有两个属性很容易被忽略，而日后发现时代价很高。问题会被独立评估——一个问题的答案不会影响下一个问题，因此你不能通过提出依赖先前回复的后续问题来串联推理。而且模型从不会看到你的问题键，只会看到你写的指令文本，所以这些键只是供你自己记录使用，指令必须能够独立成立。

三种提问形态，以及每种形态中的陷阱

• 是/否 —— noul 类型会返回一个介于 0.01 和 0.99 之间的概率，以及一个置信度分数。该边界在两端都会被钳制，因此无论模型有多确定，设置为 0.995 的路由阈值都永远不会触发。请选择落在 API 实际可返回范围内的阈值。

• Choice — 2 到 255 个命名选项，返回获胜选项、每个选项的概率（总和为 1）以及置信度。评分之前，API 会按 UTF-8 字节顺序对选项键进行字母排序，这意味着 JSON 键的顺序无关紧要，并且完全平局时会判定给排序最靠前的键。Google 的建议由此而来：将你的兜底选项命名为 other，因为像 none_of_the_above 这样的名称会排在大多数真实类别之前，并会赢下本不该赢的平局。

• 评分 — 2 到 255 个有序评分等级，建议使用 2 到 10 个。返回值是按概率加权的预期等级；由于期望值平均的是数组索引而不是标签，因此若刻度写成 1/10/100/1000，产生的数字不会落在你的刻度上。请让评分等级在索引意义上均匀间隔，或者自行将预期索引转换回标签。

文档中列为不可用的内容

这些缺口都指向同一个方向：这是一个单次调用的端点，周围没有任何封装。没有上下文缓存，因此跨请求复用的策略文档每次都会被重新全额计费。没有 Batch API，这就排除了对去年工单进行半价夜间批处理的可能性。没有 Flex 或 Priority 层级。该模型仅位于 Gemini Developer API 上，版本为 v1beta，Google 随附的文档中没有 Vertex AI 上的条目——对于采购流程走云合同而非 API 密钥的人来说，这个细节很重要。

媒体支持异常广泛，同时又异常受限。文本、图像、视频、音频和 PDF 都可以放在同一个请求中。限制为：内联 base64 为 100 MB，PDF 为 50 MB，每个外部 HTTPS URL 为 15 MB。不接受 YouTube 链接，也不接受 gs:// URI；你需要传入已上传文件引用、签名 URL 或字节数据。

速率限制从免费层级的每分钟 200 次请求和 50,000 个令牌开始，在第 1 层级提升至每分钟 1,500 次请求和 100 万个令牌，并在第 2 层级达到每分钟 5,000 次请求和 400 万个令牌，且没有每日请求上限。免费层级不收费，但文档说明其会被用于改进 Google 产品，这使其无法用于任何受保密条款约束的用途。

简要说一下比分

在 Artificial Analysis Decision Index v2.1 上，该模型得分为 66——未取整为 65.98——在榜单所排名的十八个决策模型中位列第九。它在六个分项中的两个上单独排名第一，即 AA-Omniscience-Decision v1.1 和 HLE-MultiChoice v1.1，两项权重均为 15%；在权重为 30% 的 AA-Paperclip 上处于中游，而该分项决定了综合得分的大部分。实测成本为每百万任务 345 美元，延迟为每任务 211 毫秒，而同类中位数为 209。Google 在发布时未公布自己的基准测试表；这里的每项性能数据都来自独立榜单，基于其自有测试框架。66 分背后的算术是另一个问题，也是另一篇文章。

将其融入你已经在路由的流水线中

OrcaRouter 不承载 gemini-decision-1，原因在于结构而非商业：仅返回概率的端点并不是聊天补全的目标，因此在我们这种形态的路由器里，没有什么东西可以放在一个密钥后面。我们所面向的那半条流水线，是另一半。决策服务几乎总是两次调用——一个负责起草候选答案、评分标准或候选名单，另一个负责给它打分——而真正存在模型选择之争的，是起草那次调用。

该调用可以运行在单一端点上的 200 多个模型上，按供应商目录价原样透传、0% 加价，因此当厂商下调价格时，新价格当天就会在我们这边生效，而不必等到下一个计费周期。模型融合在此处有其用武之地，而在聊天界面中则不然：两个起草器会生成相互竞争的候选答案，Decisions API 在单次请求中依据同一套评分标准对两者打分，从而把 A/B 测试转化为逐条记录的决策。

故障转移也值得精确说明。自动故障转移保护的是生成调用——如果起草模型背后的提供商返回错误，请求会重新路由，流水线继续运行。它无法保护评分调用，因为该调用只有一个可发送的位置。如果决策端点宕机，你的流水线就会中断，再多的路由也无法改变这一点。把起草部分设计得具备韧性，并接受评分部分是依赖项。

底线

采用 Decisions API 有一个值得的理由，而且不是排行榜排名：它把一千次往返请求压缩成一次计费输入，这改变了哪些问题问起来便宜。如果你的问题看起来是对一个大对象做许多判断——一份合同、一份索赔文件、一小时视频——那就基于它来构建，并预期要把提示词保持在一个请求内，因为让它变得便宜的一切都发生在单次调用的第一个和最后一个 token 之间。如果你的问题看起来是对一千个小对象问一个问题，这层封装不会给你带来任何好处，输入费率就是一个更便宜的决策模型收费的三倍。