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。

兩個名稱、同一個模型，而且兩者之間沒有別名。最後這一點才是反常之處。大多數 Google 模型家族會提供一個會變動的別名和一個固定 ID——給原型用的 -latest 形式，以及給正式環境用的帶日期或編號形式。這個家族只提供固定形式，因此任何建立在「模型家族有浮動最新版本」這個假設上的程式碼路徑，在這裡會直接失敗，而不是默默追蹤到新版本。

第二個名字不斷出現的地方

這種歧義之所以能持續存在，是因為有三個各自獨立的系統在描述這個模型，而它們之間沒有共用的命名慣例。

計價頁面把它列在模型本身的名稱底下，旁邊附上費率，以及一則「輸出並不適用」的註記。API 參考文件描述該端點，並在可用性說明句中提及該模型，而不是把它放在模型表格裡。對它進行基準測試的獨立排行榜，則在其資料列和圖表中使用可讀名稱。這些都沒有錯，但它們都不是模型 ID，因此從其中任何一處複製到請求主體中，都會產生相同的失敗。

還有第四個變異來源，隨著時間推移會越來越重要：其他人的寫法。發布報導、教學和論壇回答都會把名稱縮短，而其中一些會把它縮成看起來像 id 的東西——小寫、帶連字號、看似合理。解決辦法就是不要相信其中任何一個。去問端點。

如何檢查指定的金鑰實際上可以呼叫什麼

在撰寫請求之前，先列出這把金鑰有權使用的模型。對 Generative Language API 執行標準的 list-models 呼叫，會傳回你的專案可用的模型及其 ids，而執行一次就能為該把金鑰永久解決這個問題。

若出現 gemini-decision-1，表示你具有存取權，而請求中就必須填入這個完全相同的字串。若未出現，問題出在權益或地區，而不是拼寫，再怎麼改名也無濟於事。你不會在那份清單中找到名為 gemini-decision 的項目，因為根本沒有這個模型。

第二項檢查是針對回應。成功的決策回應會標明是哪個模型提供服務，因此，若管線將 model 欄位與自己的 request id 一併記錄，幾個月後就能回答「是哪個模型產生這個答案」，而不必重新讀取設定。這聽起來像是例行整理，直到第一次有人問起某個決策為何改變，而誠實的答案是某個別名遷移了。

這種模稜兩可實際上造成的三個錯誤

• 未知模型的 404。 最顯而易見的那個。請求內文中的 gemini-decision 會傳回一個讀起來像權限問題、但實際上不是的錯誤。如果錯誤訊息提到的是模型而不是專案，請先檢查該字串，再檢查帳單帳戶。

• 無聲的別名假設。更難察覺。一個已將 -latest 慣例內化的團隊，會用一個系列名稱和一個解析步驟來寫設定，而當別名不存在時，解析步驟會悄悄回傳字面上的系列名稱。於是失敗會出現在第一次真正的請求時，而不是在部署時——那是它最不可能被察覺的最糟時機。

• 錯誤端點的假設。 更隱晦的是，因為模型確實存在，名稱也正確：將 gemini-decision-1 送到一般的 generate-content 端點仍然會失敗。這個模型完全無法用那種方式呼叫。它是 decisions 端點上僅提供機率輸出的目標，而要求它產生散文的請求，等於在要求它不會產生的東西。任何預設使用 chat completions 的用戶端程式庫都需要明確指定路徑。

這說明了模型本身的什麼，而不只是它的名稱

命名只是表象，真正的設計決策在於：這不是一個僅有不同輸出格式的聊天模型。聊天模型回傳文字，因此它的 id 可以在提供者、代理與閘道之間自由替換，只要它們都採用同一套結構描述。一個針對你自己定義的型別化問題回傳校準機率的模型，並沒有這樣的共通結構描述，而它的 id 會綁定到單一端點與單一請求形狀。

這就是為什麼這個家族還沒有浮動別名，也還沒有第二個成員：目前沒有可與之相容的對象。這也說明了為什麼不能直接把這個模型加入通用路由器。OrcaRouter 並未收錄 gemini-decision-1，因為僅提供機率的端點不是 chat-completions 的目標，而把它放在一個採用該結構描述的金鑰後面，會是路由層無法兌現的承諾。我們在決策空間中確實收錄的是 TypeSafe 的 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、記錄回應所命名的模型，並把家族名稱當成一般文字。