Gemini Decision 与 Gemini Decision 1：一个是名称，一个是模型 ID

搜索 Gemini Decision，你会发现发布报道、排行榜条目、定价行和 API 参考，它们对同一事物的用词略有不同。再搜索 Gemini Decision 1，你会找到真正可用的模型 ID。这两个字符串只差一个字符，在代码中的行为却完全不同：一个是人们称呼该产品的方式，另一个是 POST /v1beta/decisions 唯一会接受的值。如果你曾花一下午对着 404 发愁，不明白一个明明存在的模型为什么找不到，那么这篇文章本可以帮你省下这些时间。

这种混淆并不是某个人特定的错误。G​oogle 在 2026 年 11 月 11 日的同一次发布中推出了一个模型、一个端点和一个系列名称，而写到这三者时，自然的做法就是把它们缩写。这种缩写在行文里行得通，在请求体里却行不通，而这两个事实之间的落差，正是未来一个月里此类支持工单的主要来源。

这两个名称解析成什么

从映射开始，因为其他一切都由它而来。

• Gemini Decision — 一个产品名称。它指代该决策模型产品线，在 Google 自己的文档中，它会作为系列标签出现在正文、模型卡标题，以及诸如“仅可通过 Gemini Decision 获得”这样的句子里。它不是模型 ID，背后也没有别名；将其作为模型参数传入会返回未知模型错误，而不会回退到该系列的最新成员。

• Gemini Decision 1 — 模型，以及 id gemini-decision-1。这是可用的值。它是 Decisions API 唯一提供的模型，文档也明确说明了这一点：该端点仅支持 G​emini Decision 1。

两个名称，同一个模型，二者之间没有别名。最后这一点才是不同寻常之处。大多数 G​oogle 模型家族都会提供一个可移动的别名和一个固定 ID——供原型使用的 -latest 形式，以及供生产使用的带日期或编号的形式。这一个只提供固定形式，因此任何基于“模型家族都有浮动头”这一假设构建的代码路径都会在这里失败，而不是悄悄跟踪到一个新版本。

第二个名称不断出现的位置

这种歧义之所以能够持续存在，是因为有三个彼此独立的系统都在描述这个模型，而它们都没有采用统一的命名规范。

定价页面在模型自己的名称下列出它，旁边还有费率和一条“输出不适用”的说明。API 参考描述了该端点，并在可用性说明中写出模型名称，而不是在模型表中列出。对其进行基准测试的独立排行榜在其行和图表中使用的是可读名称。这些都没有错，而且它们都不是模型 ID，因此从其中任何一个复制到请求体中都会导致同样的失败。

还有第四个变异来源，随着时间推移会变得更重要：其他人的写法。上线报道、教程和论坛回答都会缩短这个名称，其中一些会把它缩短成看起来像 id 的东西——小写、带连字符、貌似合理。解决办法就是不要相信其中任何一个。去问端点。

如何检查给定的密钥实际可以调用什么

在编写请求之前，先列出该密钥有权使用的模型。对 Generative Language API 执行标准的 list-models 调用，会返回你的项目可用的模型及其 ID，运行一次即可为该密钥永久解决这个问题。

如果出现 gemini-decision-1，说明你有访问权限，并且请求中要填的就是这个确切字符串。如果没有出现，那么问题在于权限或区域，而不是拼写，无论怎么改名都无济于事。你在那个列表里找不到名为 gemini-decision 的条目，因为不存在这样的模型。

第二项检查针对响应。一次成功的决策响应会标明是哪个模型提供了该响应，因此，如果流水线将模型字段与自己的请求 ID 一并记录到日志中，几个月后也能回答“这个答案是由哪个模型生成的”，而无需重新读取配置。这听起来像是例行维护，直到第一次有人问为什么某个决策发生了变化，而诚实的答案是某个别名发生了迁移。

这种歧义实际导致的三个错误

• 未知模型 404。 最明显的一个。请求体中的 gemini-decision 会返回一个看起来像权限问题、但实际上并不是权限问题的错误。如果错误提到的是模型而不是项目，请先检查该字符串，再检查结算账户。

• 静默别名假设。更难发现。一个已经内化了 -latest 约定的团队，用家族名和解析步骤编写配置，而当别名不存在时，解析步骤会悄悄返回字面上的家族名。于是故障会在第一次真实请求时才出现，而不是在部署时——这是最糟糕的时机。

• 错误的端点假设。更微妙的是，因为模型确实存在，名字也没错：把 gemini-decision-1 发送到普通的 generate-content 端点仍然会失败。这个模型根本不能以那种方式调用。它是 decisions 端点上一个仅输出概率的目标，向它请求散文式文本，就是在要求它产出它并不会产出的东西。任何默认使用聊天补全的客户端库都需要一条显式路径。

这说明了模型本身的哪些情况，而不只是它的名称

命名只是真正设计决策的一个表征；真正的设计决策是：这并不是一个只是输出格式不同的聊天模型。聊天模型返回文本，因此只要提供商、代理和网关都遵循相同的 schema，它的 id 就可以在它们之间自由替换。而一个针对你自己带类型的问题返回校准概率的模型，并没有这种通用 schema，它的 id 绑定到只有一个请求形态的单个端点。

这就是为什么该系列目前既没有浮动别名，也没有第二个成员：因为还没有任何可供兼容的对象。这也解释了为什么不能简单地把该模型加入通用路由器。OrcaRouter 不承载 gemini-decision-1，因为仅提供概率的端点并不是 chat-completions 目标，而把它放在一个遵循该 schema 的密钥之后，会成为路由层无法兑现的承诺。我们在决策空间中确实承载的是 TypeSafe's typesafe/jev-1.14，这是一个可通过与目录中其他所有模型相同的接口调用的决策模型。

路由器在决策流水线中确实承担的那部分，是起草环节——即生成候选答案、或生成评分器随后评估的评分标准的生成式调用。该调用在单一端点上覆盖 200 多个模型，并按提供商目录价以 0% 加价透传，而且正是在这个调用上，更换供应商只是改一下配置，而非重写。相比之下，评分调用在设计上就绑定于单一端点，诚实的架构会把它当作固定依赖，而不是需要绕开路由的东西。

如果你要在表单上的两个字符串之间进行选择

这个问题有一个完全不涉及标识符的版本，而且值得直接回答，因为这种措辞会引导人这样理解：有人在比较“G​emini Decision”和“G​emini Decision 1”时，可能会以为自己看到的是两个产品，一个较旧、一个较新，并想知道该采用哪一个。其实只有一个。在 G​emini Decision 1 之前，从未发布过任何名为 G​emini Decision 的东西，而较短的那个名字是一个目前只有一个成员的系列的名称。

实际后果是，你找到的任何比较表、评测或基准测试，只要把两者列为单独的条目，其实都是在把同一个型号描述了两遍。两行、一个型号、一个价格。如果这两行在某个数字上不一致，那么其中一行是过时了，而不是在衡量不同的东西。

底线

在每个请求体、端点路径和配置值中都使用 gemini-decision-1，并且只在供人阅读的地方使用“G​emini Decision”。没有可回退的别名，没有隐藏在较短名称背后的第二个模型，也没有通往较长名称的 chat-completions 路径。弄错这一点的代价很小——一次 404、一个困惑的下午——但假设存在别名的代价更大，因为这种错误能通过评审，却会在生产环境中失败。固定这个 id，记录响应中给出的模型名称，并把系列名称当作普通文字对待。