Gemini 3.5 Flash 讓你買速度

我到底該用哪個 Gemini 模型上線？

我把 BenchLM 的 Gemini 3.1 Pro 與 3.5 Flash 比較拆成一個可直接拿去選模型的版本。

我看模型比較頁看久了，最怕的就是那種表面很完整、實際很空的頁面。幾個大字告訴你誰贏了，幾個百分比看起來很硬，然後就要你自己吞下整包不完整證據。這次的 Gemini 3.1 Pro vs Gemini 3.5 Flash 比較，我第一眼就覺得有點怪，但不是因為它亂寫，而是因為它太誠實了：一個模型在 reasoning 比較強，另一個在整體分數、速度、價格上更好。這種結果最煩，因為它不會替你做決定，只會逼你面對產品現實。

我這次是從原始頁面 benchlm.ai/compare/gemini-3-1-pro-vs-gemini-3-5-flash 一條一條看下去。頁面寫得很清楚：它用了 28 筆 shared sourced results、BenchAlign v5，資料審查日是 2026 年 7 月 15 日。這種資訊我很吃，因為它至少讓我知道這不是在賣感覺。

先講結論，Flash 是預設，Pro 是升級

Pick Gemini 3.5 Flash if you want the stronger benchmark profile. Gemini 3.1 Pro only becomes the better choice if reasoning is the priority.

翻譯一下就是：如果你要的是一個能穩穩放進產品裡的模型，Gemini 3.5 Flash 比較像預設答案；Gemini 3.1 Pro 只有在你的工作真的很吃 reasoning 時，才值得多付成本和延遲。

我喜歡這種講法，因為它沒有假裝兩個模型是同一種東西。很多比較頁會把模型包成一坨，讓你自己猜差異在哪裡。BenchLM 反而很直接：你要先看整體，再看例外。

頁面給的 BenchAlign v5 分數是 Flash 63.88、Pro 54.66。這不是小差距，這是會影響預設路由的差距。它同時也標了估計排名：Pro 是 #87，Flash 是 #37。這些排名我只會當方向，不會當聖旨，因為頁面自己也說這是 estimated positions。

我以前犯過一個很常見的錯：看到某個模型在單一能力上比較強，就直接拿去當預設，結果每天都在付 latency 和成本的帳。後來我才學會，default model 不是看誰最會考試，是看誰最適合長期跑在產品裡。

實操寫法很簡單：先用整體分數當第一層篩選。你如果做的是一般 assistant、agent，或混合型工作流，先上 Flash。只有當你自己的 eval set 明顯偏向 reasoning，才考慮 Pro。

你要看 coverage，不要只看大字標題

BenchLM 說它有 28 個 shared benchmark results，分散在 7 個 evidence categories，但只有 3/8 類是兩個模型都能直接比的。這句話很重要，因為它直接告訴你：比較是成立的，但不是全覆蓋。很多人看到 leaderboard 就開始腦補完整答案，這真的很危險。

我自己看這種頁面時，最先問的不是誰第一，而是「哪些地方真的有交集」。因為 coverage 不完整時，分數很容易把你帶歪。你以為是在比模型，其實是在比兩份不一樣的考卷。

頁面上最明顯的反差之一，是 ARC-AGI-2。Gemini 3.1 Pro 在這個項目拿到 77.1%，Flash 是 72.1%。這種差距不會讓人驚呼，但它會讓人點頭：Pro 在某些需要更強推理的題型上，確實有它的價值。

但 Flash 也不是只會省錢。它在 CharXiv 是 84.2% 對 80.2%，multimodal average 是 83.8 對 82.6。這代表 Flash 不只是便宜，它在圖文混合、grounded 任務上也站得住腳。

• 先看 aggregate score，決定預設模型。
• 再看 category wins，決定哪些請求要升級路由。
• 不要拿單一 benchmark 當全部，除非你的產品本來就跟那個 benchmark 長得一模一樣。

實操寫法：如果你做的是混合型 assistant，先把 Flash 放在主路徑，再留一條 reasoning-heavy 的 fallback。若你做的是數學、邏輯或高約束工具，就別猜，直接用你自己的測試集去比兩個模型的失敗型態。

Pro 的價值集中在 reasoning，其他地方沒必要硬撐

BenchLM 的 category breakdown 裡，Gemini 3.1 Pro 在 reasoning 這欄拿到 77.1，Flash 是 74.7。這差距不算大，但夠用了。只要你的產品是靠多步推理、約束整合、或避免第一個直覺答案出錯，這種差距就會變成真金白銀的維護成本。

我之前做過類似的系統，用模型幫忙做規則整理、rubric-based grading，還有一些內部決策支援。那種場景下，模型不是要會聊天，是要能穩穩走完一串步驟。這時候 reasoning 多一點點，後面人工修正就少很多。

但我也不想把 Pro 神化。它在 reasoning 上比較強，不代表它就適合當全站預設。你如果把一個偏專門的模型硬塞去跑大量一般請求，最後通常會變成：成本更高、延遲更長、使用者還不一定感覺更好。

實操寫法：把 Gemini 3.1 Pro 限定在真正難的 prompt。像是多重限制、長依賴鏈、或需要跨步驟一致性的任務，才送去 Pro。其他都先留在 Flash，等你的內部 eval 證明要升級再說。

Flash 贏的是 production 會痛的地方

如果你只看產品現場，Flash 的優勢其實更直接。BenchLM 列的價格是 Flash 每 1M tokens input $1.5、output $9；Pro 則是 input $2、output $12。吞吐量也差很多：Flash 284.2 tok/s，Pro 109 tok/s。第一個答案延遲更明顯，Flash 是 18.55 秒，Pro 是 29.71 秒。

我很討厭那種在 demo 上看起來很聰明、實際上很慢的模型。因為使用者不會幫你補腦，他只會覺得系統卡住了。token 成本也是一樣，剛開始看起來小，流量一上來就會變成財務在問你是不是選錯路。

這頁還有一個我很在意的點：兩個模型都是 1M token context window。也就是說，context 不是決勝點，真正拉開差距的是價格、速度、以及工作型態適配度。從產品角度看，Flash 比較像那個能長期承受流量的選項。

• 較低的 input / output 價格，對短 prompt 和長輸出都比較友善。
• 較高的 tok/s，適合 batch job、agent loop、長篇生成。
• 較低的 first-token latency，使用者體感會差很多。

實操寫法：只要你的產品有任何 user-facing 介面，我都建議你先在自己的環境量 first-token latency。若是 batch-heavy，就直接模擬一天流量算帳單。通常便宜又快的那個，才是最後不會讓團隊吵架的那個。

category 的差距，才是你要拿來做 routing 的東西

BenchLM 把比較拆成 reasoning、multimodal、math、agentic、coding、knowledge、instruction following。這樣拆的好處是，你會很快看出兩個模型根本不是同一種用途。Flash 在 multimodal 和 grounded 類型上比較穩，Pro 在 reasoning 和某些 knowledge 題型上比較好。

我也注意到頁面一直出現「not measured」。這很正常，但也很煩。因為它提醒你：coverage 本來就不完整，沒有哪個 leaderboard 能替你把產品情境全部跑過一遍。BenchLM 至少沒有假裝自己什麼都知道，這點我給過。

如果你要我用產品語言翻譯這件事，我會說：Flash 比較適合 retrieval、summarization、multimodal grounding、一般 assistant 行為；Pro 比較適合高風險推理、複雜決策鏈、以及你已經知道它在你資料上表現更好的場景。

我以前也踩過一次坑，benchmark 贏家在乾淨 QA 很漂亮，一進產品就開始對 messy prompt 失常。那時我才真的學會，模型比較不能只看平均分，還要看它在哪些任務上有穩定性。

實操寫法：把內部 eval 按任務類型切開，不要混成一個總分。分別看 reasoning、multimodal、coding，再把 quality 和 cost per successful answer 一起算。你會少很多空轉會議。

這份比較最有價值的地方，是它承認自己不完整

BenchLM 有一句話我很買單：這是 partial-evidence comparison，結論是 directional，不是終局。很多模型頁面最愛裝作自己已經把答案算完了，實際上只是把資訊排得很漂亮。這一頁反而直接告訴你：先拿來當方向，不要當保證。

它還說 Gemini 3.1 Pro 的 BenchAlign 分數是估計值，而且有更寬的 uncertainty。這種 caveat 我希望每個模型比較頁都放在分數旁邊，而不是藏在角落。因為當你在做產品決策時，知道數字的邊界比知道數字本身更重要。

所以我的結論很乾脆：如果你要的是一個能直接上線的 default model，Flash 比較像今天的答案。它有更好的整體分數、更低的成本、也更快。如果你的產品核心就是 reasoning，那 Pro 值得測，但它比較像特定情境的升級，不是全站預設。

實操寫法：先寫下你產品不能出錯的那一件事。如果那件事是 reasoning，就測 Pro；如果那件事是 throughput、response time、或成本控制，就先測 Flash。最後再用自己的 traffic 驗證一次，因為 leaderboard confidence 跟 product confidence 不是同一件事。

可抄的模板

## Gemini 模型選擇 memo：3.1 Pro vs 3.5 Flash

### 預設選擇
- 預設用 **Gemini 3.5 Flash**。
- 原因：整體 benchmark 表現較好、token 價格較低、吞吐量較高。

### 什麼時候升級到 Gemini 3.1 Pro
只有在以下情況才把請求路由到 **Gemini 3.1 Pro**：
- 任務明顯吃 reasoning
- 有多步驟、強約束、長依賴鏈
- 你的內部 eval 已經證明 Pro 在核心任務上更穩

### 什麼時候留在 Gemini 3.5 Flash
以下情況維持 **Gemini 3.5 Flash**：
- 一般 assistant traffic
- multimodal / grounded 任務
- 高流量 batch 生成
- 對 latency 敏感的 user-facing 流程
- 成本敏感的工作負載

### 你可以直接記的數字
- BenchAlign v5：Flash 63.88，Pro 54.66
- 價格：Flash input $1.5 / output $9 per 1M tokens
- 價格：Pro input $2 / output $12 per 1M tokens
- 吞吐量：Flash 284.2 tok/s，Pro 109 tok/s
- first-token latency：Flash 18.55s，Pro 29.71s
- context window：兩者都是 1M tokens

### Routing policy
1. 所有請求先走 Flash。
2. 用簡單規則或 classifier 偵測 reasoning-heavy prompt。
3. 只有這類請求才升級到 Pro。
4. 記錄 quality、latency、cost per request。
5. 兩週後用真實流量重新檢查規則。

### 決策規則
除非你的內部 eval 顯示 Pro 在核心任務上明顯更好，否則就用 Flash。
如果 reasoning 品質真的比成本和延遲更重要，再把 Pro 拉進來。

這段我會直接貼進團隊 doc、launch checklist，或 model selection RFC。它故意寫得很平，因為平常能活下來的決策，通常都長這樣。

來源致謝：這篇是根據 BenchLM 的 Gemini 3.1 Pro vs Gemini 3.5 Flash 比較頁整理而來；我自己的部分是把頁面上的 benchmark、價格、延遲與 routing 邏輯翻成可執行模板。若你要回頭核對，直接看原始頁面最準。