在 OrcaRouter 上對 Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview)（google）與 Google: Gemini 3.1 Pro Preview Custom Tools（google）進行正面對比——定價、脈絡窗口、延遲、吞吐與 benchmark 品質並排呈現，助你為工作負載挑選合適的模型。
| 指標 | Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) | Google: Gemini 3.1 Pro Preview Custom Tools | 結論 |
|---|---|---|---|
| 輸入 $/百萬 | — | $4.00 | — |
| 輸出 $/百萬 | — | $18.00 | — |
| 上下文 | 66K | 1M | Google: Gemini 3.1 Pro Preview Custom Tools 支援的脈絡窗口比 Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) 大 94%。 |
| p50 延遲 | 10000 ms | 5312 ms | 在中位數下，Google: Gemini 3.1 Pro Preview Custom Tools 的回應比 Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) 快 47%。 |
| 吞吐 | 2401 tok/s | 710 tok/s | Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) 的 tokens 串流輸出比 Google: Gemini 3.1 Pro Preview Custom Tools 快 70%。 |
| 品質 | 5.0 | 10.0 | 在綜合品質指數上，Google: Gemini 3.1 Pro Preview Custom Tools 比 Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) 高 50%。 |
對於延遲敏感的工作負載，Google: Gemini 3.1 Pro Preview Custom Tools 能更快回傳第一個 token。 在 benchmark 品質上，Google: Gemini 3.1 Pro Preview Custom Tools 在綜合指數上領先。
Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) 和 Google: Gemini 3.1 Pro Preview Custom Tools 都透過同一個 OrcaRouter 端點提供,依供應商成本計費、零 token 加價,因此在兩者之間切換只需改一行程式碼,下面的數字就是你實際支付的費用。本對比擷取了即時定價、官方公布的上下文視窗,以及 OrcaRouter 自己測得的延遲和吞吐資料,讓你能針對自己的具體工作負載權衡成本與效能,而不是依賴廠商標榜的 benchmark。正確的選擇幾乎總是取決於你流量的形狀——提示長度、你生成多少文字、你的使用者對延遲有多敏感,以及推理有多難——因此下面的章節會逐個維度拆解這個決策,並以一條具體建議收尾。凡是兩個模型中有一方缺少某項指標,該列會直接省略而不是猜測,所以這裡的每一條論斷都有真實數字支撐。
這兩個模型中有一個或兩個在此處未公開按 token 計費的價格(可能是免費層、按呼叫計費或尚未定價的模型),因此請將成本欄視為參考值,在據此編列預算前,先到各模型自己的頁面確認即時費率。
Google: Nano Banana 2 (Gemini 3.1 Flash Image Preview) 最多接受 66K 個 token 的上下文,Google: Gemini 3.1 Pro Preview Custom Tools 接受 1M。上下文視窗決定了單次請求中你能傳送多少源材料——文件、程式碼、先前的對話。更大的視窗讓你在處理長輸入時可以省去分塊和檢索的工程管線,但你傳送的所有內容仍按輸入 token 費率計費,所以更大的視窗是一種能力,而不是折扣。請讓視窗符合你的工作負載實際會產生的最長單次請求,而不是頁面上最大的那個數字。還要記住,在任何模型上,當上下文非常長時,末尾部分的質量都可能下降,因此大視窗最好被當作應對偶爾出現的長輸入的餘量,而不是把每個請求都塞到上限的許可證。
延遲和吞吐決定了模型在生產環境中的實際體感。中位數(p50)回應延遲是典型請求在第一個 token 出現前的等待時長;吞吐(每秒 token 數)決定回答開始後的串流速度。對於互動式對話和 agent 迴圈,低 p50 延遲最重要,因為使用者在等待第一個 token;對於批次生成和長文本輸出,吞吐主導整體耗時,因為回答很長。上方的 7 天趨勢圖顯示了每個模型的延遲是穩定還是漂移,這是單一標榜數字所掩蓋的——一個均值很好但尾部抖動的模型,仍可能達不到嚴格的 p95 SLA。如果你的產品有延遲預算,就要同時看中位數和曲線的形狀,並記住端到端延遲還包含你的網路跳轉,以及你圍繞模型所做的任何檢索或工具呼叫。
Benchmark 分數近似地反映能力,但不能取代在你自己的提示上進行測試。此處顯示的綜合質量指數彙整了多項公開評測,百分位則標出每個模型在目錄中所有可比模型裡的位置——這是一個有用的入圍訊號,而不是對你任務效果的保證。在通用智慧指數上領先的模型,在你的領域(編碼、抽取、多語言、長上下文推理)上仍可能落後,因此請用這些 benchmark 縮小範圍,再讓兩個模型在你流量的代表性切片上實際跑一跑。請關注與你用例相匹配的那個具體指數,而不是總榜數字:編碼密集的產品應看重編碼指數,研究助手則看重推理指數。Benchmark 也會隨著模型更新而過時,因此請把它們當作一個起始假設,再用你自己的評測集去確認。
如果成本是硬性約束,先按你真實的輸入/輸出比例選用更便宜的模型,只有在質量不達標時才升級。如果回應速度是優先項——面向使用者的對話、agent、任何有人在等待的情境——就把 p50 延遲和吞吐看得比小幅價差更重。如果你要做最吃力的推理、編碼或長上下文工作,就讓 benchmark 和上下文視窗的贏家領頭,並在物有所值處接受更高的費率。由於兩個模型都在同一套 API 之後,低風險的做法是把一小部分真實流量分別路由給兩者,在你自己的提示上對比成本、延遲和回答質量,再做最終決定。一種常見做法是分層(tier):把大量簡單、高頻的請求發給更便宜或更快的模型,把更強的模型留給真正需要它的請求,這樣能以一小部分成本拿到大部分的質量收益。無論選哪個,都要讓切換保持可逆——只需一行模型名稱的改動,一旦數字或你的需求發生變化,你就能立刻把流量切回去。
在過去 7 天裡，Google: Gemini 3.1 Pro Preview Custom Tools 維持較低的中位回應延遲。