2026 年 11 月 11 日，Google DeepMind 上线了专为是非题、多项选择和量表打分设计的 Gemini Decisions API，底层模型为 Gemini Decision 1。它最扎眼的卖点是免收输出 token 费，输入定价每百万 token 0.10 美元（比 Gemini 3.5 Flash-Lite 便宜约 5 倍），单次请求最多可并发处理 1000 个独立问题。但在第三方机构 Artificial Analysis 的 Decision Index v2.1 榜单上，初创公司 TypeSafe 的 Jev 1.14 拿到了与 Google 相同的 66 分并列第一，速度比 Google 快一倍以上（92 毫秒对比 211 毫秒），输入单价（0.042 美元）还不到 Google 的一半。
把几个核心数字拆开看，就能摸清这次发布的真实水位：
- 能力与边界.支持文本、图像、音频、视频和 PDF 原生输入，已在 Google 内部的搜索安全检查、Gemini Notebook 动态路由和 Stitch 原型工具中跑通。
- 隐性限制.官方宣称的 150 至 250 毫秒端到端延迟，技术文档明确限定在 16K 上下文以内且仅限 1 至 100 个问题规模；1000 问满载时的真实延迟并未公布。
- 计费细节.单次请求的共享背景材料只收一次钱，但附带的每一道题及其评判标准，都要逐条累加输入 token。
五强混战与 Google 的真实护城河
过去几周，大模型厂商突然集体把做选择题从生成式模型里拆出来，独立成一个新品类。前 OpenAI 研究员创立的 TypeSafe 推出 Jev 后，OpenAI、Cloudflare 和 Microsoft 迅速跟进。
如果只看厂商自己的宣传，每家都是第一。Microsoft 宣称其 Decision-1 在 36 项基准测试中排名榜首且比第二名快 2.5 倍，Google 的官方图表也显示自己全面领先。但拉到 Artificial Analysis v2.1 的统一标尺下（该测试引入了私有文档任务和惩罚盲目自信的校准指标，满分并非准确率百分比），五家的长短板一目了然：
| 模型名称 | 综合得分 | 中位延迟 | 输入单价 (每百万) | 百万任务总成本 | 核心差异化能力 |
|---|---|---|---|---|---|
| TypeSafe Jev 1.14 | 66 分 | 92 ms | $0.042 | $156 | 极致速度与高性价比 |
| Google Gemini Decision 1 | 66 分 | 211 ms | $0.10 | $345 | 音视频/PDF 原生输入、1000 问并发 |
| Microsoft Decision-1 | 62 分 | 274 ms | $0.042 | $143 | 百万任务综合成本最低 |
| OpenAI GPT-6 Luna Decisions | 60 分 | 206 ms | $0.10 | 未公布 | 限 400 问并发、支持提示词缓存 |
| Cloudflare Clef | 60 分 | 354 ms | $0.24 | 未公布 | Apache 2.0 开源权重、支持自托管 |
数据摆在台面上，我不太买账的是 Google 把快和便宜当成主打歌的宣传口径。在纯文本和常规分类任务上，Google 的延迟是 Jev 1.14 的两倍多，跑完一百万次基准任务的账单（345 美元）更是 Microsoft（143 美元）和 Jev（156 美元）的两倍以上。
Google 真正能卡住企业客户咽喉的，是全模态输入与批处理上限。OpenAI 的同类接口只吃文本、图像和 JSON，单次最多问 400 题；而 Google 允许开发者直接塞进一段监控视频、一通客服录音或一份几十页的 PDF 合同，一次过筛 1000 个审核项。对于需要处理复杂多模态文档的团队来说，省去前置 OCR 和音视频转写管线的工程折腾，完全能抵消 API 账面上的溢价。
算力归位背后的工程暗礁
为什么巨头在 2026 年底扎堆造决策模型？因为过去两年，整个行业都在用最笨的办法干活。
在客服工单路由、Agent 工具选择、内容安全审核这些高频生产环节里，软件系统需要的只是一个明确的分支判断。过去开发者只能调用自回归生成式 LLM，逼着模型吐出一段 JSON 字符串，再写正则去解析。这就像十九世纪末工厂刚通电时，全车间几百台织布机依然共用一台巨大的蒸汽机改建的中央电机，哪怕只踩一脚踏板，整套传动轴都得跟着空转。按输出 token 计费的生成模型用来做分类，不仅为多余的废话买单，还得忍受逐字解码的高延迟和极不稳定的概率校准。
杀鸡焉用牛刀，把做选择题剥离出来是算力的各安其位。
专用决策模型砍掉了自回归生成环节，直接在前向传递中对预设选项打分，给出经过校准的概率分布（ECE）和置信度。系统看到置信度高于 0.95 就自动放行，低于阈值就转交人工或升级给大模型处理。
但这种封闭式机制藏着一个极易踩中的工程陷阱。早期外部开发者对 Gemini Decision 1 进行了 54 次 API 调用实测，在 30 个常规工单路由中准确率达 100%，中位延迟约 240 毫秒，且连续 5 次重复请求返回的概率分毫不差。然而，一旦输入偏离主题的野生内容，且开发者没有在选项列表里提供「其他（other）」兜底项时，模型的校准机制就会失灵，以极高的置信度强行归入错误分类。
生成式模型遇到不懂的问题还能胡言乱语露出马脚，封闭式决策模型却只能在你给的篮子里挑一个扔进去。如果工程师盲信 Google 宣传的「最低校准误差（Top-1 ECE）」，在写代码时漏掉了拒识兜底分支，这套每秒能跑几百次的自动化路由，瞬间就会变成高效率的故障分发器。
- 风险.切勿在生产环境中设计非黑即白的纯封闭选项；接入任何决策 API 时，必须在提示词选项中硬编码「无法判断 / 其他」作为逃生通道，并紧盯 100 问以上及超 16K 上下文时的 p99 长尾延迟衰减。