$0.10 每百万输入 token，零输出 token 计费，150–250ms 返回最多 1000 个带置信度的多模态判断——Google 发布的 Gemini Decisions API 背后，是一个被生成式 AI 浪潮掩盖的事实：大量真实 AI 工作负载根本不需要模型「说话」。

一、一个不生成文本的大模型端点

过去 3 年，AI 产业几乎所有注意力都集中在生成式能力上——更长的上下文窗口、更流畅的对话、更精准的代码补全。但 Google 刚刚发布的 Gemini Decisions API 走向了另一个方向：据 Google 官方博客，其底层模型 Gemini Decision 1（模型 ID：gemini-decision-1）被设计为不进行逐 token 解码（token-by-token decoding），而是在单次前向传播（single forward pass）中对候选选项进行打分，输出的是概率和置信度分数，而非自然语言文本。

据 Google 官方博客，这个 API 的核心参数如下：

  • 输入能力：支持文本、图片、音频、视频和 PDF 的多模态输入，单次请求最大上下文为 256K token；
  • 决策容量：单次请求最多处理 1000 个独立决策问题；
  • 延迟：模型计算的中位延迟为 50–100ms，端到端延迟为 150–250ms；
  • 定价：$0.10 每百万输入 token，零输出 token 计费；
  • 性能稳定性：从 1 个问题到 100 个问题，延迟几乎保持平坦（nearly flat）。

这些数字全部来自 Google 官方博客。即便打上「厂商自报」的折扣，这组参数的组合仍然构成了一个清晰的产品声明：存在一类 AI 工作负载，它不需要生成能力，只需要判断能力——而这类负载的规模大到值得 Google 为它专门训练一个模型、设计一套 API、制定一种全新的计费逻辑。

二、产品解剖：3 种决策原语与零输出 token 的定价逻辑

3 种决策类型

Gemini Decisions API 提供 3 种结构化的决策原语（decision primitives），据 Google 官方博客描述：

第 1 种：bool（Yes/No）。估计某个 yes/no 条件成立的概率，可选地附带 true 和 false 的描述性标准。输出是一个 0 到 1 之间的置信度分数。典型场景：「这张图片是否包含违规内容？」「这段音频是否包含仇恨言论？」

第 2 种：choice（多选）。从 2 到 255 个候选项中选择，返回获胜者和所有候选项的归一化概率。典型场景：「这条用户查询应该路由到哪个模型？」「这封邮件属于哪个分类？」

第 3 种：score（有序评分量表）。按照一个有序量表（从 0 开始）对输入进行评分，返回一个连续的加权分数和每个等级的概率分布。典型场景：「这篇文章的质量是 1-5 分中的几分？」「这份保险索赔的风险等级是什么？」

这 3 种类型可以在单次请求中混合使用。据 Google 官方博客的示例，开发者可以把一张休息室台面的照片和一段文字备注作为同一个输入，在一个请求里同时跑这 3 种问题类型。

零输出 token 计费的经济学

$0.10 每百万输入 token、零输出 token 计费——这个定价结构本身就是一个架构声明。

传统的生成式 API 调用中，输出 token 通常是成本的主要来源，因为每个输出 token 都需要一次自回归解码步骤。据 Google 官方博客，Gemini Decision 1 跳过了整个自回归解码过程，直接在前向传播中对预定义选项进行打分，因此不产生输出 token。博客称，在共享基准测试套件上，使用 Decisions API 的 Gemini Decision 1 比使用 Interactions API 的 Gemini 3.5 Flash-Lite 便宜近 5 倍（nearly 5x cheaper）。

需要指出的是，Google 官方博客未详细说明这个「近 5 倍」对比的具体条件——是相同的 1000 个判断任务的端到端成本对比，还是单位 token 价格对比？Flash-Lite 完成同样数量的判断需要多少次独立调用、产生多少输出 token？在这些细节缺失的情况下，「5 倍」这个数字的可解读性有限，应被视为厂商在特定基准条件下的自报数据。

笔者尝试基于已披露数据做一个粗略的成本区间估算。假设一个 16K token 的输入上下文搭配 1000 个 bool 决策：仅计算共享上下文的输入成本为 $0.10 × 16K / 1M = $0.0016。但这个估算忽略了一个重要变量——每个决策问题描述本身的 token 消耗。如果每个问题描述平均消耗 50 个 token，1000 个问题就额外产生约 50K token，使总输入 token 从 16K 增加到约 66K，总成本上升到约 $0.0066。按此更保守的估算，每个决策的分摊成本约为 $0.0000066——仍然处于极低的数量级，但比仅计算共享上下文的理想情况高出约 4 倍。实际成本将取决于问题描述的复杂度和长度，开发者在评估时应以包含问题描述 token 的总输入量为基础。

概率校准度：被低估的核心指标

Google 官方博客特别强调了一个在生成式 AI 讨论中很少出现的指标：校准误差（calibration error）。据博客称，在覆盖 agent 路由、推理、排序和多模态理解的基准测试中，Gemini Decision 1 在整个测试套件中表现领先，且校准误差最低（lowest calibration error）。

校准度衡量的是模型输出的置信度分数与实际正确率之间的一致性——当模型说「我 80% 确定答案是 A」时，在所有它给出 80% 置信度的案例中，A 确实正确的比例应该接近 80%。对于需要基于模型输出进行自动化决策的系统来说，校准度直接决定了决策阈值的可靠性。一个校准度差的模型，即便准确率高，也无法被安全地用于自动化流水线，因为开发者无法信任它的置信度分数来设定路由阈值或人工复核触发点。

据 Google 官方博客，每个答案都包含一个 0 到 1 的置信度分数（confidence score），开发者的代码可以据此将模糊案例路由到备选方案或人工审核员。这意味着 Decisions API 的设计假设是：它将被嵌入自动化决策流水线，而非用于人工交互。

三、内部验证：Google 自己的产品已经在用

据 Google 官方博客，多个 Google 内部团队已经在使用 Decisions API 作为低延迟控制平面（low-latency control plane），通过定义选项而非训练自定义分类器或等待生成式调用来交付功能。博客列举了 4 个具体案例：

Gemini Notebook 的动态模型路由。Gemini Notebook 使用 Decisions API 作为实时路由器，将传入查询即时导向最优的模型层级和思考深度。据 Google 官方博客称，Decisions API 在毫秒级完成意图分类，使日常查询的延迟降低多达 40%（up to 40% lower latency），同时为复杂任务保留深度推理模型。

这个场景揭示了 Decisions API 的一个核心用例：模型路由（model routing）。在多模型架构中，一个轻量、快速的决策层决定每条查询应该由哪个模型处理，可以在不牺牲复杂任务质量的前提下大幅降低平均延迟和成本。笔者判断，随着 AI 系统从单模型架构向多模型编排架构演进，这类路由层的需求将持续增长。

Stitch 中的快速设计迭代。据 Google 官方博客，Stitch 中新的快速画布实验（rapid canvas experiment）使用 Decisions API 在数秒内生成可交互的产品流程线框图，并几乎即时应用语音或点击所做的编辑。

CC 的表情选择与 Google Search 的 MCP 工具安全层。据 Google 官方博客，Google Labs 的 CC 用 Decisions API 在 200 多个表情中瞬间挑出合适的表情回应；Google Search 则把它用作 MCP（Model Context Protocol）工具的安全层，用来检测对抗性行为和内容。

Google 选择先在内部大规模验证、再开放外部 API 的路径，在策略上有明确的合理性。内部产品提供了真实的规模化负载和反馈循环，而 Gemini Notebook 的模型路由场景尤其适合验证延迟和校准度的实际表现——如果路由层本身的延迟或判断失误导致用户体验下降，问题会在内部反馈中迅速暴露。

四、品类思考：为什么「决策型 AI」需要独立于生成式 AI

用通用 LLM 做判断的隐性成本

在 Decisions API 出现之前，开发者要用 AI 做分类、审核、路由等判断任务，通常有两条路径：调用通用 LLM（如 GPT-4o、Gemini Flash、Claude）通过 prompt 工程要求模型输出判断结果，或者训练专用的小型分类模型（如 fine-tuned BERT、DistilBERT 等）。

通用 LLM 路径有 3 个结构性问题：

第 1 个是延迟。通用 LLM 的自回归解码意味着即便只需要输出一个「是」字，模型仍然要完成至少一个解码步骤，而实际上模型往往会输出解释性文本，进一步增加延迟。对于需要在毫秒级完成的路由决策，这种延迟是不可接受的。

第 2 个是成本。输出 token 的单价通常是输入 token 的数倍，而生成式调用不可避免地产生输出 token。更重要的是，用通用 LLM 处理大量独立判断，要么逐个调用、重复传输和处理同一份输入上下文，要么把多个问题塞进一个 prompt，再生成更长的输出。

第 3 个是概率校准度。通用 LLM 输出的是自然语言，要获取置信度分数，开发者通常需要依赖 logprobs（对数概率）或要求模型自报置信度。前者在许多 API 中不可用或受限，后者的校准度通常很差——模型自报的「90% 确定」与实际 90% 的正确率之间可能存在显著偏差。

与专用小型分类模型的对比

专用小型分类模型（如 fine-tuned BERT）则走向另一个极端：在特定任务上，这类模型的推理延迟可能远低于 150ms，部署成本也可能更低，且在窄领域内的精度和校准度可能更优。但它们的局限同样明显：每个新任务通常需要收集标注数据并重新训练；不具备多模态能力（无法直接处理图片、音频、视频）；且模型的泛化能力受限于训练数据的覆盖范围。

Gemini Decisions API 试图占据这两者之间的位置：它继承了大模型的多模态理解能力和零训练成本的通用性（开发者只需定义选项和描述，无需标注数据），同时通过专用的决策架构将延迟和成本压缩到接近专用分类模型的水平。笔者判断，这种定位的核心权衡在于：对于需要极致延迟和极窄领域精度的场景，专用小型模型可能仍是更优选择；但对于需要多模态输入、频繁变更判断逻辑、或覆盖大量不同判断任务的场景，Decisions API 的零训练成本和通用性优势可能更为显著。

「决策层 + 生成层」的分层架构

笔者判断，Decisions API 的发布预示了一种正在成形的 AI 应用架构模式：将 AI 系统拆分为「决策层」和「生成层」。

决策层负责快速、廉价、高校准度的判断：这条查询该路由到哪个模型？这段内容是否违反政策？这个风险等级是什么？这些判断不需要自然语言输出，只需要结构化的概率分数。决策层的竞争维度是延迟（越低越好）、校准度（越准越好）和单位判断成本（越低越好）。

生成层负责需要创造性、流畅性和深度推理的任务：撰写回复、生成代码、进行多步推理。生成层的竞争维度是输出质量、上下文理解和推理深度。

这两层的需求特征截然不同，用同一个模型同时满足两者，在架构上是低效的。Gemini Notebook 的模型路由场景就是这种分层架构的典型实例：Decisions API 作为决策层在毫秒级完成路由判断，然后将查询分发给不同层级的生成模型。

与 Gemini 通用模型的关系

截至本文发布时，Google 官方博客未明确说明 Gemini Decision 1 与 Gemini 系列其他模型（如 Gemini 3.5 Flash、Gemini 3.5 Flash-Lite 等）在架构上的具体关系——是共享同一基础架构的专用微调版本，还是从头训练的独立模型。博客中的对比数据除前述的「近 5 倍」成本差异外，还在「Strong performance and calibration」章节给出了与其他 API 的基准性能与校准对比（称 Gemini Decision 1 在整套基准上领先且校准误差最低），但未详细说明 Gemini Decision 1 与 Gemini 系列其他模型在架构上的具体关系。

但从产品定位上看，Gemini Decision 1 与通用 Gemini 模型之间的关系显然是互补而非替代。据 Google 官方博客的表述，Decisions API 提供的是「purpose-built primitives for bounded choices」——为有界选择设计的专用原语。这个「有界」（bounded）一词精确地划定了它的能力边界：候选选项必须是预定义的，模型不创造新选项，只在给定选项中分配概率。

五、竞争格局与市场信号

Decisions API 的发布在独立媒体中获得了广泛报道。VentureBeat 以「Google’s Gemini Decision 1 model scores up to 1,000 questions in one API call」为题进行了报道；SiliconAngle 的标题是「Google enters the decision model market with Gemini Decisions API」；Unite.AI 和 Interesting Engineering 也分别发布了报道。SiliconAngle 的标题用的是「enters the decision model market」（进入决策模型市场）——在它看来，这个市场在 Google 入场之前就已经存在。

Google 不是第一个做决策 API 的厂商。据 SiliconANGLE，这类为简单问题生成简短答案的模型被称为决策模型（decision model），第一个是创业公司 TypeSafe AI 在 9 月中旬推出的 Jev，几天内获得 100 万用户，发布 3 周后以 75 亿美元估值融资 8.7 亿美元。据 Interesting Engineering，OpenAI 在 10 月推出了自己的 Decisions API，由 GPT-6 Luna 模型驱动，称比其 Responses API 快至多 10 倍、单次请求最多支持 400 个问题，同样提供概率判断、多选和评分量表，定价从每百万输入 token 0.10 美元起。据 SiliconANGLE，Google 把 Gemini Decision 1 与 Jev、OpenAI 的 Decisions API 做了对比，称在 9 项基准测试中有 7 项表现更好，但 Jev 的成本效率略高。

笔者判断，Google 入场意味着决策模型已经从创业公司的单点产品变成大厂之间的正面竞争：决策类工作负载遍布内容审核、风险评估、查询路由、政策合规检查等场景，而 Google 和 OpenAI 的起步定价都是每百万输入 token 0.10 美元，竞争会落在延迟、校准度和多模态覆盖上。

六、技术边界与待验证问题

尽管 Google 官方博客的描述令人印象深刻，但多个关键问题仍待外部独立验证：

延迟的真实分布。Google 声称端到端延迟为 150–250ms，模型计算中位延迟为 50–100ms，且从 1 个问题到 100 个问题延迟几乎平坦。但这些数字的测试条件（网络环境、输入上下文长度分布、问题复杂度）未在博客中详细说明。博客提到「across multimodal inputs and contexts up to 16K tokens」——注意这里的上限是 16K token，而非 API 支持的最大 256K token。在接近 256K token 的长上下文场景下，延迟表现是否仍然保持在 150–250ms 范围内，是一个需要外部基准测试验证的问题。

校准度的基准测试细节。Google 称 Gemini Decision 1 在基准测试中校准误差最低，但博客未公开基准测试的完整方法论、数据集构成和对比模型的具体版本。在没有第三方独立复现的情况下，这些性能声明应被视为厂商自报数据。

255 个候选项的实际表现。choice 类型支持最多 255 个候选项，但候选项数量增加时，概率分布的区分度和校准度是否会下降，博客未提供相关数据。在实际应用中，255 个候选项的多选场景（如从 255 个工具中选择最合适的一个）对模型的区分能力要求极高。

多模态输入的质量影响。博客提到可以调节图像和视频输入的分辨率（tune resolution on image and video inputs）以控制视觉细节和 token 成本，但未提供不同分辨率设置下决策准确率的对比数据。

这些问题并不意味着 Decisions API 的价值主张有问题，而是指出了从厂商发布到产品成熟之间必须经历的验证过程。据 Google 官方博客，Google AI Studio 已经开放了该 API 的访问，并提供 Python、JavaScript 和 REST 指南，外部开发者和独立评测机构的实测数据将在未来数周内逐步出现。

七、当判断与生成分离，AI 基础设施的下一步

Gemini Decisions API 的发布，从产品层面确认了一个在技术社区中已有讨论但尚未被主流 AI 产业叙事充分认知的趋势：AI 工作负载正在分化，而分化的方向之一是「判断」与「生成」的分离。

这种分离的驱动力来自经济学和工程学的双重压力。从经济学角度看，用一个每百万输出 token 收费数美元的通用模型来做一个 yes/no 判断，是对计算资源的浪费。从工程学角度看，将判断任务嵌入自动化流水线时，开发者需要的是结构化的概率输出和可靠的校准度，而非需要额外解析的自然语言文本。

Google 通过 Gemini Decision 1 和 Decisions API 给出了一个具体的产品化方案：专用模型 + 专用 API + 专用定价。这个方案是否会成为行业标准，取决于 3 个变量：第 1，外部开发者在真实场景中的采用速度和反馈；第 2，与 OpenAI Decisions API、TypeSafe AI 的 Jev 等已有产品竞争的结果；第 3，「决策层 + 生成层」的分层架构是否在实践中展现出相对于「通用模型做所有事」的显著优势。

若决策型 AI 确实成为一个独立品类，其竞争维度将与生成式 AI 截然不同。在生成式 AI 的竞争中，模型的创造力、推理深度和输出质量是核心差异化因素；在决策型 AI 的竞争中，延迟、校准度、单位判断成本和多模态覆盖范围将成为关键指标。Google 给出的数字是 150–250ms 延迟、$0.10/百万输入 token 和零输出 token 计费；面对已经在场的 Jev 和 OpenAI，它需要在这些维度上证明自己的优势。

AI 产业的叙事长期被「模型越大越好、生成越多越好」主导。Gemini Decisions API 提供了一个不同的视角：有时候，AI 最有价值的输出是一个带置信度的判断。当这种判断可以在 150ms 内完成、成本趋近于零、且校准度足够可靠时，它就不再是生成式 AI 的附属功能，而是一种独立的基础设施能力。

主题分类：技术突破

参考资料

  1. Gemini Decisions API: Fast, calibrated multimodal decisions — Google 官方博客, 2026-11-11
  2. Google’s Gemini Decision 1 model scores up to 1,000 questions in one API call — VentureBeat, 2026-11-11
  3. Google enters the decision model market with Gemini Decisions API — SiliconAngle, 2026-11-12
  4. Google Launches Gemini Decisions API for Multimodal AI Workflows — Unite.AI, 2026-11-11
  5. Google unveils Gemini Decisions API to handle 1,000 questions at once — Interesting Engineering, 2026-11-11