一張為 Gemini Decision 1 與 Drex Max v1.1 之間遷移比較所產生的標題卡,標籤顯示每 100 萬輸入 token 為 $0.10 對比 $0.03、每題共享 token 為 262,144 對比 131,072、文件通過率為 63% 對比 33%,頁腳則註明這兩項數字皆為截至 2026 年 11 月 13 日的價目表與指數值。
Engineering & Research

將決策工作負載從 Drex Max 移轉至 Gemini Decision 1

作者

Gideon Frost

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

這次移植看起來像是改個 URL,但實際上並不是。 Drex Max v1.1 與 Gemini Decision 1兩者都接收一段上下文和一組具型別的問題,並回傳機率,所以移轉的第一個下午進展順利:重新命名欄位、把用戶端指向不同的基礎路徑、執行測試套件。真正出問題的是第二週,當用量湧入時,才發現兩套計費模式對於你究竟在買什麼的定義並不一致。本文說明實際上必須改變哪些地方,寫給已經有一套可運作的 Drex Max v1.1 整合、並且想知道較新模型的主打評分是否足以證明這次移轉值得的人。

先從這筆取捨最誠實的版本說起。在 Artificial Analysis Decision Index v2.1 上,Drex Max v1.1 得分 73,Gemini Decision 1 得分 66。較舊的模型勝出,而且領先 6.6 分,其中大部分來自佔總合指標 30% 的那個組成部分。如果你的工作負載是文件分流,這次遷移就是包裝成升級的降級。如果是其他用途,請繼續讀下去,因為這兩個端點並不像它們的請求形態所暗示的那麼相似。

不在任何排行榜上的差異

Drex Max v1.1 為每個問題提供各自 131,072 個 token 的預算。Gemini Decision 1 則為整個請求提供 262,144 個 token,並由輸入與其中的每個問題共享。這兩句話描述的是同一種產品類別,卻給出相反的工程建議。

在 Drex 上,問 200 個問題會耗用 200 個各自獨立的預算,而單一請求的實際上限取決於你的速率限制,而不是上下文。在 Gemini Decision 1 上,200 個問題和一份 200,000 個 token 的合約無法容納於同一個請求中:200,000 個 token 的輸入會留下 62,144 個給問題與指示,這還算寬裕,但 250,000 個 token 的輸入只剩 12,144 個,請求就會失敗。這個上限是真實存在的,它是共用的,而且會隨著你送出多少內容而變動。

這是所有單一變更中最可能弄壞原本運作正常的 Drex 整合的一項,因為它的失效模式在低量時並不會以錯誤的形式顯現。一套在 30,000 個 token 的文件上跑 20 道問題的測試套件,在兩套系統中都游刃有餘。生產環境則是 180,000 個 token 的紀錄搭配 900 道問題,只放得進其中一套,另一套則不行。

Screenshot of the Gemini Decision 1 documentation page in the Google AI Studio docs, headed gemini-decision-1, stating that a single request can evaluate up to 1,000 independent questions over shared input up to 262,144 tokens, listing the yes/no, single-select and rubric rating question types with their return values, and showing a Python sample that sends a yes/no question and a routing choice over the same customer message in one call.

每個 token 的價格隱藏了什麼

Drex Max v1.1 以每百萬輸入 token $0.03 的推出價列出,對比 $0.06 的定價,而 Gemini Decision 1 是 $0.10。兩者都不對輸出收費。單看那一欄,Drex 便宜 1.7 到 3.3 倍,這足以讓高用量團隊直接結束討論。

以每項任務衡量,差距會縮小。Artificial Analysis 將 Drex Max v1.1 定為每百萬個決策任務 103 美元,Gemini Decision 1 為 345 美元,比率約 3.3——這是牌價比較,不是上市價。原因是 Gemini Decision 1 為了得出答案會讀取更多 token。其共用上下文規模是兩倍,且其元件分數顯示,它在每個問題中送入更多輸入,而非更少。以每項任務計,誠實的差距大約是 3 比 1,對 Drex 有利;而上市折扣是暫時情況,不會撐過你的第二次合約續約。

這意味著,定價問題不是「哪個比較便宜」,而是「你願意為多大比例的任务支付 3 倍費用來換取正確結果」。一條將支援工單路由到佇列的規則,如果比替代方案多出 5% 的錯誤率,就毫無價值。一條將合約條款標記出來供法務審查的規則,其價值立刻就能顯現出差異。

文件處理正是分數的來源

6.6 分的綜合差距並非平均分布,而遷移論證取決於了解它究竟存在於何處。

• AA-Paperclip,權重 30% — Drex Max v1.1 得分 72.8,且在全部或全無測試中直接通過 63% 的文件;Gemini Decision 1 得分 56.8,通過 33%。這一項組成部分就占了綜合差異的大部分。

• When2Call, 10% — Drex 以 95.3 對上 Gemini 的 80.5,在工具呼叫判斷上差距達 14.8 分,這是 Drex 在任何地方按比例計最大的領先幅度。

• EvalSafe-O*NET-AA,15% — 88.3 對 87.1。只是個四捨五入誤差,也是這組測試中唯一與安全相關的測試。

• AA-Omniscience-Decision v1.1, 15% — Drex 60.3、Gemini 66.3。Gemini 的領先,也是其發布報導以知識為主打的原因。

• HLE-MultiChoice v1.1,15% — Drex 46.6,Gemini 48.7。差距很窄,而且兩個模型拒答而非猜測的頻率都高到讓原始準確率遠低於這些數字。

• AA-Symmetry v1.1,15% — Drex 79.8 對 70.5。答案是否能在此問題被重新排序、重新標記與否定後依然成立,而這是排行榜上最接近穩定性測試的項目。

A generated two-row comparison of Drex Max v1.1 against Gemini Decision 1 on the Artificial Analysis Decision Index and on document pass rate, with Drex Max ahead on both: an index score of 73 against 66, and a document pass rate of 63% against 33%.

在您下決定前,那幾列中有兩列值得再看一眼。在文件擷取上,Drex 在嚴格指標下的可靠性幾乎是兩倍;在對稱性上,它的穩定度則高出九個百分點——這意味著以 Drex 為基礎的管線,對於同一個問題換個問法時,產生答案翻轉的情況較少。如果您的產品向使用者呈現的是單一答案,不穩定就是一個錯誤回報。如果它是要饋入下游分數,不穩定則是可以透過取平均消除的變異。

速度,以及保留兩者的理由

Drex Max v1.1 執行一項任務的中位數時間為 283 毫秒。Gemini Decision 1 執行相同任務則為 211 毫秒。較新的模型儘管處理更多工作,速度卻更快,這是遷移唯一無條件帶來助益的地方。對於使用者操作前的同步檢查而言,70 毫秒並非微不足道。

速度、價格與準確度很少能如此整齊地朝同一個方向對齊,而在這裡情況並非如此:Gemini 更快但更差,Drex 更慢但更好,而且成本比是跟著品質比走,而不是跟著延遲比走。這正是兩個設計確實不同的模型所具備的特徵,而不是其中一個只是另一個的嚴格升級版。

哪個才是實際的建議。只有一個評分模型的決策服務,只有一個故障點和一種觀點。同時運行兩者要付出第二次整合的成本,換來的是分歧訊號:當兩個模型都以高信心度回傳不同答案時,該案例確實模稜兩可,而且可能不應該自動化。這種模式很老、很無聊,而且能抓到任何單一模型信心分數都抓不到的錯誤。

移植呼叫本身

機械部分比會計部分小,但有三個陷阱值得在開始前先說明。

首先,Drex 是透過 /v1/systemone 呼叫,並將模型 ID 固定為 drex-max;快速入門中的 drex-latest 別名並不是這個固定 ID,使用它意味著模型會在你未部署的情況下於底層變更。Gemini Decision 1 則有相反的問題:完全沒有別名,只有 gemini-decision-1,而指定 gemini-decision 的請求將無法解析。兩邊都要固定,並將模型 ID 視為設定中的版本號,而非原始碼中的常數。

其次,媒體限制無法直接對應。Drex Max v1.1 每次請求最多接受 8 張圖片。Gemini Decision 1 接受文字、圖片、音訊、影片與 PDF,限制為內嵌 base64 上限 100 MB、每個 PDF 上限 50 MB、每個 HTTPS URL 上限 15 MB,並且直接拒絕 YouTube 連結與 gs:// URI。原本每次請求批次處理八頁掃描的 Drex 流程,到了 Gemini 流程就變成要麼把這些頁面當成單一 PDF 送出,要麼拆分批次。

第三,題型相近,但界線並不完全相同。兩者都支援是/否、選項與分數。Gemini 將選項與分數的上限設為 2–255 個選項或等級,並將是/否機率限制在 0.01–0.99,因此你在 Drex 程式碼中設定高於 0.99 的任何閾值,在移植後都會靜默地永遠不會觸發。請檢查程式碼庫中的每一個閾值常數,而不只是設定檔裡的那些。

Screenshot of the Decisions API overview page in the Google AI Studio documentation, showing the sentence that the API generates zero text tokens so output token usage is always 0, a diagram of shared multimodal input being scored by Gemini Decision 1, and a table of the yes/no, choice and score question types with the values each returns.

路由器適用之處,以及不適用之處

OrcaRouter 既不承載 gemini-decision-1,也不承載 drex-max。兩者都是僅提供機率(probabilities-only)的端點,而像我們這種形態的路由器,前端對接的是 chat-completions 目標;若聲稱 otherwise,那就是一種可用性宣稱,會在第一次請求時就失敗。在這次遷移中,路由器的用途是管線中不屬於評分器(scorer)的那一部分。

幾乎每個決策服務在評分之前都會先草擬:生成式模型會擷取候選條款、提出評分規準,或將紀錄摘要成決策模型隨後讀取的共用脈絡。那個草擬呼叫正是供應商選擇真正重要之處,也是第二份合約造成痛點之處,而且它可跨單一端點上的超過 200 個模型,並以 0% 加價轉嫁供應商定價。路由 DSL 在這裡比在聊天產品中更重要,因為草擬呼叫具有異質性——便宜模型用於初步分流,長脈絡模型用於 180,000 個 token 的紀錄——而將此表達為規則,勝過表達為三個 SDK。

老實說,限制在於:容錯移轉保護的是草擬呼叫,而不是評分呼叫。決策請求只有一個傳送位置,一旦該位置無法使用,你的服務就無法使用。如果這種相依性不可接受,上述的雙模型模式就不只是準確度措施——它是唯一真正可用的備援,因為它是擁有兩個獨立評分端點的唯一方式。

重點

如果你的決策是知識型的、如果速度很重要,或者你想要一個大到能一次容納整份紀錄的共享上下文,就改用 Gemini Decision 1。如果你的決策是文件型的,就留在 Drex Max v1.1——而通過率顯示它們多半是,因為仔細一看,大多數決策工作負載其實就是文件擷取。如果答錯的代價高昂,就兩者並行,並在向任何人承諾節省成本之前,先為三比一的成本比例做好預算。移轉是一天的工作,外加一季的重新調校;該不該做這個決定,取決於你的工作負載實際上比較像索引中的哪個組成部分。