Gemini Decisions API 拆解：不生成 token 的决策模型，怎么把路由延迟压到 150ms 还省 5 倍成本？

笔名：小六 / 上海 / 1995 女 / 某互联网公司工程师

先说结论

11 月 11 日，Google DeepMind 在官方博客发布 Gemini Decisions API 与配套模型 gemini-decision-1：一次请求最多塞 1000 个独立问题，覆盖文本、图像、音频、视频、PDF，输入上限 256K token；模型不做逐 token 生成，而是在一次前向里给候选答案打分，返回概率与置信度，端到端 150-250 ms，价格 0.10 美元 / 百万输入 token、输出 token 计费为 0。

我的结论：这条发布真正的价值不是”又一个 Gemini 端点”，而是它把”决策”从”生成文本再解析”里拆了出来——答案空间由调用方给定，模型只负责打分。对 Agent 工程来说，这意味着路由、工具选择、策略校验这三类高频判断可以从”调一次大模型 + 解析 JSON”降级成”一次前向 + 直接读概率”，延迟和成本都降一个量级。但要注意：它解决的是”闭集选择”，不是”开放式推理”，凡是需要模型自己发现选项的场景，它依然无能为力。

发生了什么

官方事实一：发布主体、时间与位置。 主来源是 Google 官方博客《Gemini Decisions API: Fast, calibrated multimodal decisions》，页面标注发布日期 2026 年 11 月 11 日，作者是 Google DeepMind 的产品经理 Min Choi 与首席科学家 Felix Yu，归属栏目为 Developer tools。原始 URL 见文末 Q1。文章不是研究论文，而是一篇”端点说明书 + 早期采用者清单”，同时给出了 API 形态、计价、基准结论和生态接入。

官方事实二：它是什么。 官方定义得很窄：一个面向”闭集决策”的端点，用来做工具选择、策略检查、模型路由、上下文分级这四类有界判断。调用方把一段多模态输入（文本、图像、音频、视频、PDF 混合，上限 256K token）和最多 1000 个互相独立的问题一起发过去，模型一次性返回每个问题的概率分布与置信度。官方强调”不再逐 token 生成答案文本，而是在一次前向里给候选打分”——这句话是整个产品的立足点。

官方事实三：已经有内部采用者，不是纸面功能。 官方列了四个在跑的场景：Gemini Notebook 用它做实时路由，把进来的查询分到合适的模型档位与思考深度，官方称日常查询延迟最多降 40%；Stitch 的 rapid canvas 实验用它生成可播放的原型流程；Google Labs 的 CC 用它从 200 多个 emoji 里挑反应；Google Search 用它给 MCP 工具加一层安全判定，检测对抗性行为与内容。这四个场景有个共同点：都是”从一堆已知选项里挑一个”，而不是”写一段话”。

相关事件（前一天，同一技术线）。 11 月 10 日，Hugging Face 博客发布《Decision Models in Hugging Face》（作者 Aritra Roy Gosthipaty、Lysandre、Pedro Cuenca、Tom Aarsen），把这类模型正式命名为 “decision model”，给出统一接口契约：状态 + 问题 + 允许答案 → 决策 + 概率分布，并把三种原语（choice / score / noul）写成了可复用的规范。两篇相隔一天，一篇是闭源商业端点，一篇是开源生态的接口标准化——合起来才是”决策模型”这条线在 2026 年 11 月的完整形状。

技术细节

1. 三个原语，覆盖三类判断

Gemini 侧给出三种问题类型，和 Hugging Face 那篇的规范几乎一一对应：

• noul（是/否）：估计某个条件成立的概率，可以附带”真”与”假”的描述性判据；
• choice（多选）：从 2 到 255 个候选里选一个，返回获胜项与全部候选的归一化概率；
• score（有序评分）：按从 0 开始的有序量表打分，返回连续的加权分数与每一档的概率。

每个答案都带一个 0 到 1 的置信度。官方给的理由很实用：置信度低的时候，代码可以把模糊样本路由到兜底模型或人工复核——这相当于把”模型不确定”变成程序可消费的信号，而不是让下游去猜。

2. 延迟与计价的账

官方给的数字：端到端 150-250 ms，其中模型计算中位数 50-100 ms；在 16K token 以内的上下文里，从 1 个问题加到 100 个问题，延迟”几乎持平”。计价是 0.10 美元 / 百万输入 token，输出 token 计费为 0；共享输入按请求计费一次，不管里面塞了多少个问题，每个问题只额外增加自己的指令与判据 token。

官方还给了横向对照：在同一套共享基准上，Gemini Decision 1 配 Decisions API 比 Gemini 3.5 Flash-Lite 配 Interactions API 便宜近 5 倍。注意这个”5 倍”的口径是”共享基准套件上的综合成本”，不是所有场景通用——但它至少说明省钱的来源是结构性的（没有输出 token、没有思考 token、没有单独的音频转写与 OCR 账单），不是一次性折扣。

3. 多模态是一次前向，不是拼接流水线

官方强调”原生多模态”：文本、图像、音频、视频、PDF 在同一次前向里处理，可以把一段通话录音和账户元数据放进同一个共享输入，或者把扫描的 PDF 索赔单和损坏照片配对。图像与视频还可以调分辨率，用来控制视觉细节与 token 成本。

这一点对工程的意义比分数更大：传统做法是”先 OCR 或转写，再喂给模型”，中间有两段额外计费和两段额外延迟；这里是”一段输入、一次打分”。官方明确把”没有单独的音频转写与 OCR 费用”写进了计价段落。

4. Hugging Face 那侧的接口规范

HF 那篇的价值在于把接口写成了可移植的契约，而不是某家厂商的私有形状：

• 输入分两部分：state（要评估的信息，可以是字符串、结构化对象，或支持的全模态输入）与 questions（一组带名字的问题）；
• 三种原语与 Gemini 侧同名：choice（对选项的概率分布）、score（有序分布的期望值）、noul（伯努利参数）；
• confidence 有明确公式：对 K 个选项的选择题，置信度 = (最大概率 − 1/K) / (1 − 1/K)，均匀分布时置信度为 0；
• 服务侧已经落地：Transformers 提供 DecisionPipeline、AutoModelForDecision、DecisionConfig 和统一的 /v1/systemone 端点；llama.cpp 用同一个端点路径，llama serve -hf ... 起本地服务即可；
• Hub 上加了 decision-model 标签用于发现模型；训练侧可以走 Trainer，TRL 的一等支持还在 PR 阶段（写作时仍 open），Unsloth 给了把生成式模型改造成决策模型的 LoRA 配方。

HF 那篇还明确区分了三种相邻方案：传统分类（输出类别烘死在分类头里，加一个新部门就要重训）、零样本分类（推理时给候选标签，但只有”归到某类”这一种形态）、决策模型（多个带类型的命名问题 + 有序评分 + 是/否概率 + 原生概率输出）。这张对比表是整篇最值得抄的部分——它说清楚了”决策模型不是新发明的分类”，而是”把已有的概率能力组织成一个统一接口”。

5. 一个被低估的细节：兼容自回归模型

HF 那篇提到，/v1/systemone 这套接口也能跑普通的自回归语言模型：Transformers 会自己构造决策提示、在一次批量前向里取答案标签的 logits、再做 softmax，全程不生成文本。这意味着不用先训一个新模型就能试这套接口——对想快速验证”我的路由场景适不适合闭集决策”的团队，这是一条零成本的试验路径。

6. 生态接入清单

Gemini 侧给出的接入方：OpenRouter、LangChain、Vercel、LiteLLM、Pydantic AI、Pipecat、LiveKit、OpenCode，外加官方 SDK；Gemini in Google Cloud 的支持”即将到来”。HF 侧给出的是 Transformers、llama.cpp、Hub 标签、Trainer/TRL/Unsloth。两边合起来说明一件事：这条线不是单厂商的实验，而是正在被两套生态同时吸收。

对 Agent / 工程的影响

立刻能用上的三类场景。 一是模型路由：把”这句话该给哪个档位的模型、要不要开深度思考”交给一次打分，官方自己在 Gemini Notebook 上就是这么用的，报的是日常查询延迟最多降 40%。二是工具选择与参数前置判断：工具集是已知的闭集，让决策模型挑一个再交给主模型执行，省掉一次大模型往返。三是策略校验：对 Agent 输出做”是否违反规则”的是/否判定，带概率比带布尔值更有用——0.62 和 0.98 应该走不同的处理路径。

需要进一步验证的两类。 一是校准：概率是模型给的，不是天然校准过的。HF 那篇的评论区里就有人指出生产环境的真实痛点——把 0.83 变成动作需要一个阈值，而阈值会悄悄过期，因为原始概率很少校准，正确阈值取决于犯错的代价，而”这次判断对不对”的证据往往几天后才到。二是多问题一致性：一次请求塞 1000 个问题听起来很省，但如果这些问题之间语义相关，模型是否会把它们当成互相独立的判断，官方没给这方面的评测。

短期不要碰的两类。 一是开放式推理：决策模型的前提是”答案空间由你给定”，需要模型自己发现选项的场景（比如”这份日志里有哪些异常”）它接不住。二是高代价的强安全判定：Search 用它给 MCP 工具做对抗检测是加分项，但不能当成唯一防线——概率输出适合做”分级”，不适合做”终审”。

一个立刻可做的组合。 把决策模型放在 Agent 的最前面做意图路由与工具选择，把主模型留给真正需要知识与多步推理的那一段；再用置信度做三级分流（高置信直接执行、中置信走主模型复核、低置信进人工队列）。这套结构的成本曲线比”每次都调大模型”平滑得多，而且每一级的阈值都可以单独调。

我的判断

该用，但只用在”闭集”上。 路由、工具选择、规则校验这三类判断本来就只需要从已知选项里挑一个，用生成式模型去做等于先写一段解释再把解释解析回来——多付了输出 token，还多背了 JSON 不合法的风险。决策模型把这段冗余删掉了。

开源侧的接口规范比闭源端点更重要。 HF 那篇把 state + questions + 三种原语 + /v1/systemone 端点写成跨引擎契约（Transformers 与 llama.cpp 同一个端点路径），这意味着今天写在这套接口上的代码，明天可以换模型、换引擎而不改调用方。闭源端点给的是性能和价格，开源规范给的是可移植性，两者互补。

真正的门槛在阈值，不在模型。 概率输出把”模型不确定”暴露给了程序，代价是程序必须自己决定”多少概率才算过”。这条线会不会被工程团队真的采纳，取决于有没有人把校准与阈值管理做成常规工序——而不是取决于基准分数再高几分。

Q&A

Q1：来源/出处？
A：主源为 Google 官方博客《Gemini Decisions API: Fast, calibrated multimodal decisions》，作者 Min Choi（产品经理）与 Felix Yu（首席科学家），均属 Google DeepMind，发布日期 2026 年 11 月 11 日，原始 URL：https://blog.google/innovation-and-ai/technology/developers-tools/gemini-decisions-api/ 。相关源为 Hugging Face 博客《Decision Models in Hugging Face》，发布日期 2026 年 11 月 10 日，原始 URL：https://huggingface.co/blog/decision 。模型标识为 gemini-decision-1，通过 Gemini API 在 Google AI Studio 提供。

Q2：能不能复现/怎么验证？
A：两条路径。闭源侧：在 Google AI Studio 拿 API key，用官方 Python / JavaScript / REST 指南发一次请求，构造一个”三问题共享输入”的例子（是/否 + 多选 + 有序评分），看返回里是否同时带概率分布与置信度，再对比同一输入走生成式端点时的延迟与账单。开源侧：llama serve -hf <decision-model> 起本地服务（默认端口 9931），向 /v1/systemone 发同样的 state 与 questions 结构；或者用 Transformers 的 pipeline("decision", ...) 直接在本地跑，不需要训练新模型。

Q3：适用边界是什么？
A：闭集判断。答案空间必须由调用方给定：路由目标、工具清单、规则条目、评分档位。不适合开放式发现（”找出所有异常”）、不适合长链推理（需要多步推导才能得出结论）、不适合作为强安全场景的唯一防线（概率适合分级，不适合终审）。另外多模态输入上限 256K token、单请求问题上限 1000 个，超了要拆请求。

Q4：和其他方案对比？
A：和”生成式模型 + JSON 输出”比：少了输出 token 计费、少了 schema 不合法的风险、延迟从数百毫秒到秒级降到 150-250 ms。和传统分类器比：分类器的输出类别烘死在分类头里，加一个新选项要重训；决策模型的选项在推理时给定。和零样本分类比：零样本只有”归到某类”一种形态，决策模型支持多个带类型的命名问题、有序评分与是/否概率。和约束解码（语法约束库）比：约束解码仍然要逐 token 生成，只是限制了可选 token 集合，计算开销还在。

Q5：风险/坑？
A：三个。一是把概率当校准过的概率用——原始概率很少天然校准，阈值要按”犯错的代价”来定，还要随模型版本更新重新校准。二是把”延迟几乎持平”误读成”问题数量免费”——共享输入计费一次，但每个问题自己的指令与判据 token 仍然计费，1000 个问题不等于 1 个问题的账单。三是把闭集端点用成开放问答——一旦答案空间没被穷举，模型只能在给定选项里挑”最不坏”的那个，错误会以”看起来很自信”的形式出现。

字数自检：≥1500 个中文字符（不含 frontmatter）
隐私自检：无内网 IP、无真实机器名、无凭据、无本地路径协议前缀、无占位域名
文件名：2026-11-12-gemini-decisions-api-closed-set-probabilities.md（唯一）
封面 seed 含日期 + 主题 slug，未复用