1000 个判断一次完成：Google Decisions API 能省下多少 AI 分类成本？

摘要：Google Decisions API 对固定选项直接打分，不生成文本。本文用公开价格测算它在分类、审核、路由任务中的成本，并结合官方与第三方数据说明它的适用边界。

结论先行：Google 于 2026 年 11 月 11 日发布 Gemini Decisions API（模型 ID gemini-decision-1）。它可以在一次请求中对同一份输入完成 1 到 1,000 个独立判断，输入价格为每百万 Token 0.10 美元，没有生成式输出 Token 费用。按公开价格测算，同一份 10K Token 文档检查 1,000 条规则时，费用约为 Gemini 3.5 Flash-Lite 的 1/20，理论节省 94.9%。1,000 条消息各分类一次，理论节省 73.1%。Google 官方测试给出的成本优势约为 4.7 倍。第三方单题实测中，这一优势约为 1.5 倍。只做分类、审核、路由，且答案能提前限定在固定选项内的任务，最适合用它降低成本。

后文先说明这个接口的工作机制和三种判断类型，再用可复算的公式测算三种典型业务的费用，并解释官方“约 5 倍”和第三方实测之间的差距。之后对照 Google 公布的速度数据和 Artificial Analysis 的独立评测，讨论准确率是否满足生产要求。最后给出最小调用示例、选型表和上线前的成本检查清单。

To Know：术语预备知识

1 Google 发布了什么：Gemini Decisions API 专门回答判断题

1.1 Gemini Decision 1 与传统生成式模型的区别

Gemini Decisions API 于 2026 年 11 月 11 日通过 Gemini Developer API v1beta 开放，REST 端点为 POST https://generativelanguage.googleapis.com/v1beta/decisions。它的核心功能是对预先定义的选项做概率判断，返回判断结果、各选项概率、置信度和 Token 用量。输入支持文本、图片、音频、视频和 PDF。

传统生成式模型处理分类任务的流程是：读入内容，理解指令，再逐 Token 生成一段回答，开发者还要解析这段回答。Decisions API 把流程改为读入共享内容，然后对每个问题的预设选项直接打分。分类、审核、路由这类任务只需要一个标签或一个“是/否”，生成长回答既占用输出费用，也拖慢响应。省掉这一步，就是它降低成本和延迟的来源。

1.2 Decisions API 三种判断方式覆盖哪些任务

以一条客服消息为例：“我上周买的耳机左耳没声音，申请退款三天了还没人理，再不处理我就投诉到平台。”针对这一条消息，可以在同一个请求里同时提出三个彼此独立的问题。

choice 支持 2–255 个选项，score 支持 2–255 个等级。score 返回的是根据各等级概率计算出的期望值，因此可以直接用于排序或设定阈值，无需从一段评价文字中提取分数。

2 Google Decisions API 成本究竟能省多少：三种业务场景算账

2.1 为什么共享输入可以降低 Token 消耗

Decisions API 的计费结构有三个特点：共享输入在一次请求中只计费一次，每个问题自身的指令仍按输入 Token 计费，判断结果不产生生成式输出费用。对比对象 Gemini 3.5 Flash-Lite 的官方标准价格为输入每百万 Token 0.30 美元、输出每百万 Token 2.50 美元（2026 年 11 月 13 日官方定价）。

设 S 为一份共享输入的 Token 数，Q 为针对这份输入的独立问题数，Tq 为每个问题的平均 Token 数，To 为生成式模型每个问题的平均输出 Token 数，N 为输入份数。在“两种接口可计费输入 Token 相同”的简化假设下：

Decisions API 成本  C_D = N × (S + Q×Tq) × 0.10 / 1,000,000
Flash-Lite 成本     C_F = N × [ (S + Q×Tq) × 0.30 + Q×To × 2.50 ] / 1,000,000
节省率              = (1 − C_D / C_F) × 100%

这是用于理解机制的计算模型，Google 并没有给出固定节省率。两个接口会有各自的指令编码和格式开销，实际费用以各自返回的计费 Token 为准。

2.2 从 1 次判断到 1,000 次判断，费用如何变化

下表是按公开价格推导的理论示例，没有经过实际压测。场景①中的 1,000 个判断全部针对同一份文档，是对一份输入提出的 1,000 个独立问题，与“1,000 份文档各分析一次”是两种完全不同的负载。

三个场景说明了两件事。场景②里每次请求只有一个问题，仍有 73.1% 的理论节省，来源是输入单价降为三分之一、输出费用归零。场景①和③的节省更高，是因为共享输入被多个问题摊薄，同时 Flash-Lite 需要为每个问题生成输出。

沿用场景③的参数扩大规模：处理 10 万条消息、共 100 万个判断时，Decisions API 的模型调用成本为 6 美元，Flash-Lite 为 43 美元，相差 37 美元。这一数字只包含模型调用费，未计入重试、误判后的人工审核、升级到更强模型、传输存储和工程改造成本。

如果想用自己的业务样本复算，可以先把同一批数据交给生成式模型跑一遍，记录实际的输入、输出 Token，再代入上面的公式。API易 apiyi.com 用一个 Key 即可调用 Gemini、GPT、Claude 等多款生成式模型，方便快速建立这条成本基线。

2.3 为什么 Google 的“约 5 倍”不是通用答案

Google 发布时公布，在官方测试中 Decision 1 的成本约为 Gemini 3.5 Flash-Lite 的 1/4.7。独立测试者 RanThis 在 2026 年 11 月 12 日用真实 API 调用给出了另一组数字：100 条英文消息、20 条越南语消息，每个请求只做一个二元判断。

• 准确率：100 条英文判断中，Decision 1 答对 99 条，Flash-Lite 答对 98 条。
• 成本：每千次英文判断推算成本分别为 $0.0113 和 $0.0166，Decision 1 约低 32%，约为 1.5 倍差距。
• 延迟：单次请求延迟中位数分别为 0.18 秒和 0.58 秒。
• Token 开销：Decision 1 每个请求平均计费约 113 个输入 Token，Flash-Lite 约为 47 个输入 Token 加 1 个输出 Token。

差距的原因很清楚：Decisions 接口自身的指令与格式开销让计费输入 Token 翻了一倍多，抵消了一部分单价优势。当输入很短、每次只问一题、生成式模型只需输出一个 Token 时，节省幅度最小。RanThis 把同一封邮件的 10 个问题合并进一个 Decision 1 请求、与 10 次单独的 Flash-Lite 请求对比时，差距扩大到约 5.4 倍；这组对照中 Flash-Lite 没有做同样的合并，属于不同请求方式之间的比较。

因此，影响实际节省的变量是：共享输入的长度、每份输入的问题数、生成式模型的输出长度、两边是否都做了请求合并，以及接口自身的固定开销。公式推导、官方基准和第三方实测来自不同条件，选型时应分别看待。

3 一次完成 1,000 个判断，Decisions API 实际适合什么工作？

3.1 文档审核：一份材料匹配多项规则

最能发挥共享输入优势的是“长材料 + 多条规则”。一份合同、招标文件或产品说明书，需要逐条对照合规清单：是否包含违约条款、是否约定数据出境、付款周期是否超过 60 天、是否缺少签署日期等。材料越长、规则越多，共享输入被摊薄得越充分，场景①的 94.9% 理论节省就是这种结构的结果。

这类任务的另一个优势是结果可直接落表。每条规则对应一个 noul 判断，返回概率和置信度，程序可以按阈值标记“通过 / 不通过 / 待复核”，审核人员只看需要复核的条目。

3.2 Agent 路由与内容分类

Agent 在每一步都要决定下一步动作：是否需要联网搜索、是否要运行代码、是否转交其他工具。这类判断选项固定、调用频繁、对延迟敏感，适合用 choice 一次完成。Google 披露的内部用法也集中在这里：Gemini Notebook 用它根据问题性质选择模型和思考层级，普通查询延迟最高降低 40%；Google Search 用它对 MCP 工具做安全检查，识别对抗性内容；CC 从 200 多个候选 Emoji 中快速选择反应。这些是 Google 自身的数据，外部开发者的实际效果取决于各自的负载。

内容生产工作流是另一个延伸场景。一条 AI 新闻收集完成后，系统需要判断它是否为新事件、是否与开发者相关、是否涉及 API 价格、是否有官方来源、是否适合写成教程，并给内容价值打分。这六个条件彼此独立，可以放进一个 Decisions 请求完成筛选，通过筛选的选题再交给生成式模型做研究、写作和润色。这是基于接口能力设计的方案示例。后半段的生成环节可以通过 API易 apiyi.com 按需切换不同模型，比较写作质量与成本。

3.3 1,000 个问题的三个边界

1. 问题必须相互独立。同一请求内的判断无法读取彼此的结果。“先判断是否投诉，再按投诉类型分级”这类有先后依赖的流程，需要由程序组合结果，必要时再发起下一次请求。
2. 1,000 个问题共享 262,144 Token 上下文。共享输入和全部问题共同占用这个窗口，每个问题的指令越长，能放下的材料就越短。
3. 官方低延迟数据只覆盖小规模请求。Google 测试中延迟近似平稳的范围是每次 1–100 个问题、上下文 16K Token 以内。1,000 个问题配合接近满载的上下文时，延迟需要自行实测。

4 便宜之外，Gemini Decisions API 的准确率和速度能否满足生产要求？

4.1 Google 公布的速度与内部应用数据

Google 公布的模型计算耗时中位数为 50–100 ms，端到端延迟为 150–250 ms，测试条件是每次 1–100 个问题、上下文不超过 16K Token。这组数据说明它适合放在实时链路中，例如 Agent 每一步的路由或用户消息的即时分流。RanThis 单题实测的 0.18 秒中位延迟也落在这个区间附近。

4.2 第三方测评告诉我们什么

Artificial Analysis 的 Decision Index v2.1 发布初期结果，按原始分数与实际任务混合计算。下表中的费用是该基准测试任务的混合成本，与“每百万 Token 单价”是两种口径。

两个信息值得注意。其一，Gemini Decision 1 的 Token 单价低，但在这套任务分布下，每百万任务的估算费用高于 Drex Max 和 Jev，说明请求方式和任务结构会改变最终的经济性。其二，在 AA-Paperclip 文档测试中，Decision 1 一次完成全部 15 项判断且全部正确的文档比例为 33%。多项判断一次完成节省了费用，每一项的准确率仍需单独验证。

4.3 用置信度防止错误被自动执行

置信度是模型对自身结果的概率估计，可以用来决定哪些结果自动执行、哪些交给人工。上线时建议配合三条做法：

• 设置置信度阈值：例如退款判断置信度低于 0.85 时转人工，高于阈值才自动打标签或派单。
• 为 choice 增加 other 选项：所有选项都不合适时，模型仍会选出其中一项，加入“其他 / 无法判断”能拦住一部分越界输入，也可以单独加一个 noul 做范围检查。
• 高风险操作保留代码约束：退款金额、账户封禁、合规拦截等动作，除模型判断外还应有硬编码规则和人工复核。

5 开发者应该如何使用与选型 Gemini Decisions API？

5.1 如何发出第一个请求

官方要求 Python google-genai SDK 3.2 或更新版本，同时支持 JavaScript SDK 和 REST，接入需要 Google AI Studio 的 API Key。下面的示例根据官方 SDK 结构整理，对同一条新闻同时做一个二元判断和一个分类判断，未在本文中实际调用验证，字段名请以官方开发者指南为准。

from google import genai

client = genai.Client(http_options={"api_version": "v1beta"})

result = client.decisions.create(
    model="gemini-decision-1",
    # input：所有问题共用的共享输入，只计费一次
    input="Google released a new AI API with official pricing and developer documentation.",
    # questions：相互独立的判断，键名即问题 ID
    questions={
        "has_api_pricing": {
            "type": "noul",
            "instructions": "Does this news mention API pricing?",
        },
        "category": {
            "type": "choice",
            "instructions": "Which news category fits best?",
            "criteria": {
                "model": "An AI model launch",
                "api": "An API or developer tool",
                "business": "Business or finance news",
            },
        },
    },
)

print(result.answers)  # 每题的判断结果、各选项概率与置信度
print(result.usage)    # 计费 Token 用量，成本核算以此为准

四个关键字段的作用如下：input 放共享内容，questions 放独立问题（score 类型的等级定义写法参见官方指南），answers 读取判断结果与概率，usage 读取计费 Token。成本测算时一定要用 usage 的实际值，第 2.3 节已经说明接口固定开销会显著影响单题成本。

要做成本对比，还需要一条生成式模型的基线。下面用 OpenAI 兼容接口通过 API易 调用 Flash-Lite 完成同样的分类，并记录 Token 用量：

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

resp = client.chat.completions.create(
    model="gemini-3.5-flash-lite",  # 以平台模型列表中的实际名称为准
    messages=[{
        "role": "user",
        "content": "News: Google released a new AI API with official pricing.\n"
                   "Q1 mentions API pricing? Answer yes/no.\n"
                   "Q2 category: model/api/business. Answer one word each line."
    }],
    max_tokens=10,
)
print(resp.choices[0].message.content)
print(resp.usage)  # 输入、输出 Token，用于代入 2.1 节公式

import openai

PRICE_IN, PRICE_OUT = 0.30, 2.50   # Flash-Lite 官方标准价，美元/百万 Token
DECISION_IN = 0.10                 # Decision 1 输入价，输出不计费

gen_client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

def flash_lite_cost(samples, questions, model="gemini-3.5-flash-lite"):
    """把每条样本的全部问题合并为一次生成式请求，累计实际计费成本"""
    total = 0.0
    for text in samples:
        prompt = text + "\n" + "\n".join(
            f"Q{i+1}: {q} Answer briefly." for i, q in enumerate(questions)
        )
        r = gen_client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": prompt}],
            max_tokens=10 * len(questions),
        )
        total += (r.usage.prompt_tokens * PRICE_IN
                  + r.usage.completion_tokens * PRICE_OUT) / 1_000_000
    return total

def decision_cost(usage_input_tokens_list):
    """传入 Decisions API 每次返回的 usage 输入 Token，计算总成本"""
    return sum(t * DECISION_IN for t in usage_input_tokens_list) / 1_000_000

🚀 快速上手建议：先挑 200–500 条真实业务样本，用生成式模型跑出基线准确率和 Token 用量，再与 Decisions API 的 usage 对比。API易 apiyi.com 提供 OpenAI 兼容接口和新用户免费测试额度，适合快速完成这一步基线测试。

5.2 什么时候选择 Decisions API，什么时候继续用生成式模型

生成式模型的结构化输出（JSON Schema）也能把答案约束成固定格式，但它仍然逐 Token 生成内容并按输出计费，概率需要额外处理才能获得。Decisions API 直接返回每个选项的概率和置信度，输出不计费，代价是只能回答事先限定选项的问题。

5.3 上线前还需计算什么成本

单价之外，下面几项会直接影响“每个正确决策的总成本”：

• 实际 Token 开销：以 usage 为准，短输入单题场景的固定开销占比最高。
• 请求限额：免费层为 200 RPM、50,000 TPM、10,000 RPD；付费 Tier 1 为 1,500 RPM、100 万 TPM、50,000 RPD。长上下文请求往往先触发 TPM 上限。
• 缺少缓存与批处理：不支持 Context Caching、Batch API、Flex/Priority 推理，重复使用同一长文档时无法享受缓存折扣。
• 功能约束：问题指令中不能放媒体内容，也不能直接传入完整对话历史、思考或工具调用块，多轮对话需要先整理成文本输入。
• 误判与人工复核：低置信度转人工的比例、误判后的返工费用，需要计入单位成本。
• 数据处理条件：免费层使用数据可能被用于 Google 产品改进，官方定价表显示付费层不用于此目的。处理客户文档前应确认所用层级。
• 工程改造：把生成式提示词改写为 noul / choice / score 问题、建立阈值和回退逻辑，都需要开发投入。

如果计划通过第三方 API 平台接入，需要确认平台是否支持 /v1beta/decisions 这一专用端点，仅支持 Chat Completions 的平台无法直接调用 Decisions API。在 API易 apiyi.com 使用前，可以先查阅文档中心的模型与端点列表，或联系平台确认支持情况。

6 结论：分类、审核、路由任务可以交给 Gemini Decisions API

回到标题的问题，结论有三点：

1. 固定选项任务值得优先考虑 Decisions API。按公开价格推导，单题分类理论节省约 73%，同一份长文档的千条规则审核理论节省约 95%；第三方单题实测的优势约为 32%。
2. “一份输入、多个独立问题”是成本潜力最大的结构。共享输入只计费一次，问题越多、输入越长、生成式模型输出越长，差距越大。
3. 最终衡量标准是生产环境中每个正确决策的总成本。Token 单价和 1,000 题上限是起点，准确率、置信度分流后的人工比例、限额和工程成本共同决定实际收益。

比较稳妥的路径是：先用真实样本跑出生成式模型的基线，再在 Decisions API 上对比 usage 和准确率，把判断层与生成层分开设计。生成层的模型选型与成本对比，可以通过 API易 apiyi.com 用统一接口完成。

📚 参考资料

1. Google Gemini Decisions API 开发者指南与定价表：接口能力、限制、限额与官方价格
2. 链接： ai.google.dev

3. 说明： 模型 ID、问题类型、上下文窗口、速率限额与 SDK 用法

4. Google 官方博客发布文章：发布日期、延迟数据与内部应用案例

5. 链接： blog.google

6. 说明： 50–100 ms 计算耗时、约 4.7 倍成本优势、Gemini Notebook 等案例

7. Gemini Decisions API REST 端点

8. 链接： generativelanguage.googleapis.com/v1beta/decisions

9. 说明： REST 方式调用的官方端点

10. Artificial Analysis Decision Index v2.1：第三方决策模型评测

11. 链接： artificialanalysis.ai

12. 说明： 综合分数、任务耗时、每百万任务费用与 AA-Paperclip 全对率

13. RanThis 独立实测（2026-11-12）：基于真实调用的小规模测试

14. 说明： 单题成本、延迟与 Token 开销对比，以及多题合并请求的结果

作者: APIYI 技术团队
技术交流: 欢迎在 API易 apiyi.com 首页联系我们，更多接入资料可访问 docs.apiyi.com 文档中心

延伸阅读

• Gemini Decision 不收输出费？API易还没有这个 ID:解读 Google Gemini Decisions API 与 gemini-decision-1 的计费规则：输出记 0、共享输入只计一次，并说明 API易 价目暂未收录该 ID 时路由与打分场景该如何选型