Google 的 Decisions API 回答 1,000 個問題，且不對輸出計費

最便宜的部分Gemini Decision 1就是根本不存在的那個部分。Google 讓這個模型透過全新的 Gemini Decisions API 於 2026 年 11 月 11 日推出，而定價頁面將輸出列為零——不是便宜、不是打折，而是不存在，因為 POST /v1beta/decisions 沒有散文可生成。你送出一整塊共用輸入，加上最多 1,000 個具型別的問題；你每個問題會取回一個校準過的答案，除此之外別無其他。排行榜上的數字在發表當天吸引了目光。真正會改變你建構方式的，是帳單那一行，而在你複製任何人的架構圖之前，值得先算一算。

你在過去兩年所做的其餘每一項模型決策，都受到兩種朝相反方向拉扯的成本所形塑：你希望只送出一次的輸入，以及你希望保持簡短的輸出。這個端點完全消除了第二種張力，並以另一種張力取而代之，而這種張力存在於單一請求內部。一旦你看清新張力所在的位置，API 設計的其餘部分——問題數量上限、共用上下文、沒有快取——就不再顯得任意。

零輸出 token 會對算術運算造成什麼影響

設想一個實際的文件評分工作：一份 40,000 個 token 的政策或合約，以及你想針對它取得答案的 1,000 個問題。向 Decisions API 發出一次請求，會一次性計費 40,000 個輸入 token，每百萬 token 收費 $0.10，也就是 0.4 美分——全部一千個答案只需 $0.004。

現在請用你一週前會問的方式，把同樣的 1,000 個問題當成 1,000 次個別的 generate-content 呼叫來問。每次呼叫都必須攜帶該文件，因為聊天端點無法在多次呼叫之間保留它。那是 4,000 萬個輸入 token，以相同的每 token 費率計算就是 $4.00；而一旦把你那些呼叫原本會產生的輸出 token 也算進去，差距還會擴大。封裝機制不是便利功能。同樣的工作量，成本相差一千倍，而這源自單一設計選擇：問題是在一次處理中對同一個共用上下文進行評估，而不是每個來回各評估一次。

那個算術也告訴你這個模型想要的工作負載形態。關於同一個大型物件的許多問題，一起回答。如果你的問題是關於 1,000 個不同的物件，你就會得到 1,000 個請求，而且完全沒有省到。

上限：262,144 個 token，共用，且最多 1,000 個問題

{{1}}上下文視窗涵蓋共用輸入與請求中的每個問題，合計 262,144 個 token。{{/1}} 在這個額度內，你可以提出 1 到 1,000 個問題。真正重要的是上限：{{2}}一次呼叫中提出 1,000 個問題，已不是分類器的範疇，而是把相當於規則引擎的判斷量壓縮進一次處理。{{/2}} 一張支援工單可以對照四十條政策條款檢查；一份貸款檔案可以同時套用所有核保規則測試。

請求結構有兩個特性很容易被忽略，而且日後發現時代價很高。問題是各自獨立評估的——某個問題的答案不會成為下一個問題的條件，因此你不能透過提出依賴先前回覆的後續問題來串接推理。而且模型永遠看不到你的問題鍵，只看得到你撰寫的指令文字，所以這些鍵是供你自己記錄管理之用，指令本身則必須能獨立成立。

三種提問形式，以及各自暗藏的陷阱

• 是/否 — noul type 會回傳介於 0.01 與 0.99 之間的機率，外加一個信心分數。此邊界在兩端都會被夾限，因此即使模型再確定，設在 0.995 的路由閾值也永遠不會觸發。請選擇落在 API 實際可回傳範圍內的閾值。

• Choice — 兩個至 255 個具名選項，傳回勝出選項、每個選項加總為一的機率，以及信心分數。評分前，API 會依 UTF-8 位元組順序將選項鍵按字母排序，這表示 JSON 鍵順序無關緊要，而完全平手時會偏向排序在前的鍵。Google 的指引由此而來：將你的萬用選項命名為 other，因為像 none_of_the_above 這樣的名稱會排在大多數真實類別之前，並贏得本不該贏的平手。

• 分數 — 兩到 255 個有序評分等級，建議使用兩到十個。傳回值是依機率加權的期望等級，而且由於期望值平均的是陣列索引而非標籤，若尺度寫成 1/10/100/1000，產生的數字不會落在你的尺度上。請讓評分標準在索引意義上等距，或自行將期望索引轉換回標籤。

文件所列為不可用的項目

這些缺口全都指向同一個方向：這是一個單次呼叫端點，外圍沒有任何包覆機制。它沒有內容快取，因此同一份政策文件若在多個請求中重複使用，每次都會再被全額計費。它沒有 Batch API，這排除了以半價在夜間批次掃描去年工單的做法。它沒有 Flex 或 Priority 層級。此模型僅提供於 Gemini Developer API，版本為 v1beta，且在 Google 提供的文件中並未列出 Vertex AI——這個細節對任何採購是透過雲端合約而非 API 金鑰進行的人來說都很重要。

媒體內容同時異常廣泛，又異常受限。文字、圖片、影片、音訊和 PDF 全都放在同一個請求中。限制為：內嵌 base64 上限 100 MB、PDF 上限 50 MB，以及每個外部 HTTPS URL 上限 15 MB。不接受 YouTube 連結，也不接受 gs:// URI；您可傳入已上傳檔案的參照、簽署 URL 或位元組。

免費方案的速率限制一開始為每分鐘 200 次請求和 50,000 個權杖，第 1 級提升至 1,500 次請求和 100 萬個權杖，第 2 級則達到每分鐘 5,000 次請求和 400 萬個權杖，且沒有每日請求上限。免費方案不收費，但文件記載其會被用來改善 Google 產品，因此不適用於任何受保密條款約束的用途。

比分，簡述

在 Artificial Analysis Decision Index v2.1 上，該模型得分為 66——未四捨五入為 65.98——在該評測委員會所排名的十八個決策模型中名列第九。它在六個組成部分中的兩個上單獨位居第一，即 AA-Omniscience-Decision v1.1 與 HLE-MultiChoice v1.1，兩者權重均為 15%；在權重 30% 的 AA-Paperclip 上則處於中游，而這是決定綜合分數大部分的組成部分。測得成本為每百萬項任務 345 美元，延遲為每項任務 211 毫秒，而同類中位數為 209。Google 在發布時並未隨附自家的基準測試表；此處每一項效能數據皆來自獨立評測委員會，使用其自有測試框架。66 分背後的算術是另一個問題，也是另一篇文章。

將它整合進你已經在路由的管線中

OrcaRouter 不提供 gemini-decision-1，而原因是結構性的，不是商業性的：僅輸出機率值的端點並不是 chat-completions 的目標，所以以我們這種形態的路由器而言，沒有東西可以放在單一金鑰後面。我們所針對的那一半管線，是另外那一半。決策服務幾乎總是兩次呼叫——一個負責起草候選答案、評分規準或候選清單，另一個負責對它評分——而真正會出現模型選擇競爭的，是起草那次呼叫。

該次呼叫可以跨單一端點上的 200 多個模型執行，價格為供應商定價原樣傳遞、零加成，因此當供應商降價時，新價格當天就會在我們這邊生效，而不是等到下一個計費週期。模型融合在此有其價值，這點在聊天介面中並不成立：兩個起草者產生互相競爭的候選答案，而 Decisions API 在單一請求中依同一套評分標準為兩者評分，把 A/B 測試變成逐筆記錄的決策。

容錯移轉也值得講究精確。自動容錯移轉保護的是生成式呼叫——如果你的起草模型背後的供應商回傳錯誤，請求就會改道，管線也能繼續運轉。它無法保護評分呼叫，因為那個呼叫只有一個地方可送。如果決策端點掛了，你的管線就掛了，再怎麼路由都改變不了這件事。把起草那一半設計得具韌性，並接受評分那一半就是一項相依性。

重點

Decisions API 值得采用只有一个原因，而且不是排行榜上的名次：它把上千次往返压缩成一次计费输入，而这会改变哪些问题问起来成本低廉。如果你的问题像是在单个大型对象上做许多判断——一份合同、一份理赔档案、一小时视频——那就基于它来构建，并预期把提示词都放在同一个请求里，因为让它变得廉价的一切都发生在单次调用的第一个和最后一个 token 之间。如果你的问题像是在上千个小对象上问一个问题，这套封装不会给你带来任何好处，而且输入费率就是更便宜的决策模型所收费用的三倍。