Gemini Flash 系列怎麼選？3.5、3、2.5 實測對比

Google 的 Flash 系列模型承諾同一件事：在保持品質的前提下，降低延遲和成本。

但 Flash 系列現在選擇變多了。如果你在 2026 年要開發 AI 產品，可能會看到至少三個實用選項：

• gemini-3.5-flash
• gemini-3-flash
• gemini-2.5-flash

名字聽起來很接近，但實際表現完全不同。

為什麼 Flash 系列容易選錯

許多台灣開發團隊在選模型時，常犯的錯誤是：

1. 只看版本號：假設 3.5 一定比 3 好
2. 忽視延遲波動：平均延遲好看，但尖峰延遲會毀掉用戶體驗
3. 沒測試自己的 prompt：通用測試不代表你的業務場景

這篇文章透過實測三個模型，幫你找到適合自己的選擇。

TL;DR 結論

實務建議：

• 新專案優先用 gemini-3.5-flash
• 把 gemini-3-flash 當備用方案
• gemini-2.5-flash 只在已上線系統中保留

測試環境與重現方式

我們用四個真實開發場景測試這三個模型：

1. 格式化摘要 — 遵守規則，輸出恰好五點
2. 約束推理 — 解決雙工人排程問題
3. 程式碼除錯 — 修復 Python top_k 函數
4. 成本計算 — 計算月度代幣成本節省

每個模型跑每個任務兩次。

測試規模很小，不是學術級基準測試，但有實用價值——因為用的是同一個 API endpoint、同一套 prompt、同一份客戶端程式碼。

測試環境詳情

確認模型可用性：

GET https://cn.crazyrouter.com/v1/models

回應包含三個目標模型 ID。

延遲與穩定性比較

實測數據

品質分數：簡單的任務通過/失敗評分。1.0 表示完全符合要求，部分分數表示接近但不完美。

關鍵發現

Gemini 3.5 Flash 延遲最穩定

gemini-3.5-flash: 平均 4.99 秒
gemini-3-flash:   平均 7.80 秒
gemini-2.5-flash: 平均 7.52 秒

延遲差異主要來自尖峰：

• gemini-3-flash 有一次 29.79 秒 的慢請求
• gemini-2.5-flash 有一次 17.55 秒 的慢請求
• gemini-3.5-flash 始終在 3.69～5.97 秒 之間

重要提醒：API 延遲受路由、負載、地區、prompt 長度、上游可用性影響。這個測試不能保證 3.5 Flash 永遠最快，但在這次測試中最穩定。

對於台灣開發者來說，跨境 API 延遲波動會直接影響用戶體驗。如果你的用戶在台灣，尖峰延遲 29 秒 vs 6 秒，差別很大。

推理、程式碼、成本測試

推理任務：排程問題

題目：

工作 A 需要 2 分鐘，必須在 C 開始前完成。
工作 B 需要 3 分鐘，任何時間都可以。
工作 C 需要 4 分鐘。
有兩個相同的工人。最少需要多少時間？

正確答案：6 分鐘

最優排程：

• 工人 1：A (0-2 分鐘)，然後 C (2-6 分鐘)
• 工人 2：B (0-3 分鐘)
• 總時間：6 分鐘

這是測試中最明顯的差距。

在相同設定下，gemini-2.5-flash 在推理任務上容易被截斷。新版 Flash 模型處理得更好。

程式碼除錯任務

給定這個有 bug 的 Python 函數：

def top_k(items, k):
    scores = sorted(items, key=lambda x: x['score'])
    return scores[:k]

問題：應該回傳分數最高的 k 個項目。

正確修復：

def top_k(items, k):
    scores = sorted(items, key=lambda x: x['score'], reverse=True)
    return scores[:k]

結果：三個模型都通過了

對於簡單除錯，三者差異不大。更大的差異出現在程式碼 + 長上下文 + 工具呼叫 + 多步推理的組合場景。

成本計算任務

題目：

• 日均輸入：120 萬代幣
• 日均輸出：18 萬代幣
• 模型 X：$0.50 / 百萬輸入，$3.00 / 百萬輸出
• 模型 Y：$0.30 / 百萬輸入，$2.50 / 百萬輸出
• 計算 30 天節省

正確計算：

模型 X 日成本 = 1.2 × 0.50 + 0.18 × 3.00
            = 0.60 + 0.54
            = $1.14

模型 Y 日成本 = 1.2 × 0.30 + 0.18 × 2.50
            = 0.36 + 0.45
            = $0.81

日節省 = 1.14 - 0.81 = $0.33
月節省 = 0.33 × 30 = $9.90

所有完整回應都算出 $9.90。

但 gemini-3.5-flash 有一次回應因 finish_reason: length 沒有內容，被計為失敗。這就是為什麼它在最終表格的分數低於 gemini-3-flash。

這提醒我們：品質不只是智能。輸出控制、代幣設定、finish_reason 在生產環境很關鍵。

後端實務建議：Model Routing 與 Fallback

在實務上，不應該硬編碼一個模型。應該根據任務類型路由：

Python 實作範例

import requests
import time

API_KEY = "your-api-key"
BASE_URL = "https://cn.crazyrouter.com/v1"

models = [
    "gemini-3.5-flash",
    "gemini-3-flash",
    "gemini-2.5-flash",
]

prompt = """
仔細解決。一個開發者有三個工作：
A 需要 2 分鐘，必須在 C 開始前完成。
B 需要 3 分鐘，任何時間都可以。
C 需要 4 分鐘。有兩個相同的工人。
最少需要多少時間？
以「最終答案：X 分鐘」結尾。
"""

for model in models:
    start = time.perf_counter()

    response = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": model,
            "messages": [
                {"role": "user", "content": prompt}
            ],
            "temperature": 0,
            "max_tokens": 1024,
        },
        timeout=120,
    )

    latency = time.perf_counter() - start
    data = response.json()
    
    # 檢查 HTTP 200 不代表成功
    if response.status_code != 200:
        print(f"ERROR: {model} returned {response.status_code}")
        continue
    
    answer = data["choices"][0]["message"].get("content", "")
    finish_reason = data["choices"][0].get("finish_reason", "unknown")

    print(f"MODEL: {model}")
    print(f"LATENCY: {latency:.2f} 秒")
    print(f"FINISH_REASON: {finish_reason}")
    print(f"ANSWER: {answer}\n")

輸出範例：

MODEL: gemini-3.5-flash
LATENCY: 5.97 秒
FINISH_REASON: stop
ANSWER: ...最終答案：6 分鐘

MODEL: gemini-3-flash
LATENCY: 5.37 秒
FINISH_REASON: stop
ANSWER: ...最終答案：6 分鐘

MODEL: gemini-2.5-flash
LATENCY: 8.20 秒
FINISH_REASON: length
ANSWER: (不完整)

踩坑提醒

1. finish_reason 不是 "stop" 代表有問題

finish_reason = data["choices"][0].get("finish_reason")

if finish_reason == "length":
    print("WARNING: 回應被截斷，可能需要增加 max_tokens")
elif finish_reason == "stop":
    print("OK: 正常完成")
else:
    print(f"UNKNOWN: {finish_reason}")

在這次測試中，gemini-2.5-flash 的推理任務都以 finish_reason: length 結束。HTTP 200 不代表成功。

2. max_tokens 設定不當會影響結果

我們最終測試設 max_tokens: 1024。如果設太低（如 256），推理任務會更容易被截斷。

3. HTTP 200 不代表成功

檢查 response.status_code == 200 只是基本。還要檢查：

• data["choices"] 是否存在
• data["choices"][0]["message"]["content"] 是否為空
• finish_reason 是否異常

4. 溫度設定影響穩定性

推理和程式碼任務用 temperature: 0 最穩定。對話任務可以用 0.7。

成本與定價

Flash 模型通常被選中，因為它們在品質、速度、成本的三角形中間。

根據內部定價紀錄：

• gemini-3-flash：約 $0.50 / 百萬輸入代幣，$3.00 / 百萬輸出代幣
• gemini-2.5-flash：約 $0.30 / 百萬輸入代幣，$2.50 / 百萬輸出代幣
• gemini-3.5-flash：新模型，上線前務必確認最新定價

對台灣團隊的建議：

• 如果月度 API 成本 < $1000，選最新模型（3.5 Flash）
• 如果月度成本 $1000～$5000，做 A/B 測試，選最穩定的
• 如果月度成本 > $5000，建立 routing 層，按任務選模型

結論

gemini-3.5-flash 看起來是最新 Flash 系列的最佳首選——延遲低、穩定性好。

gemini-3-flash 在這次小規模測試中最可靠——所有任務都通過，但有一次大延遲尖峰。

gemini-2.5-flash 仍有用，特別是舊系統，但在相同設定下推理能力較弱。

對生產環境的最終建議：

不要永遠選一個模型。用最新 Flash 作主要路由，保留另一個 Flash 當備用，透過真實 API 流量測量任務結果。

建立 API routing 層的好處：

• 保持相同的客戶端程式碼
• 保持相同的 base URL
• 只改 model 欄位就能測試不同模型
• 監控延遲、成本、錯誤率、finish_reason、用戶結果
• 根據數據動態選擇最佳模型

這就是為什麼 OpenAI 相容的 API gateway 對團隊很有幫助。

延伸閱讀

• 原始英文實測文章
• AI API 定價比較
• OpenAI 相容 API 串接指南