為什麼用 Gemini Pro 回答「你好！」？
用 Gemma-2b 回答「你好！」，品質幾乎一樣，成本低 20 倍。
問題不是「要不要用小模型」，而是「如何設計一個系統，讓正確的問題找到正確的模型」。
面試情境
面試官： 「客戶希望設計一個 Hybrid Model Routing 系統：70% 的簡單日常問候和格式轉換自動路由到 GKE 部署的 Gemma-7b；複雜推理和多步驟 Tool-calling 才路由到 Gemini 1.5 Pro。你如何設計這個路由器？如何用統計評估確保路由器不會因為誤判讓整體品質下滑？」
一、核心問題：路由器要解決什麼問題
不路由的世界（所有請求 → Gemini Pro）：
成本：$1.25/1M input tokens（Gemini 1.5 Pro）
延遲：平均 2~5 秒
路由後的世界：
70% 簡單請求 → Gemma-7b（自托管 GKE）
成本：近乎零（只有 GKE 運算成本，約 $0.05/1M tokens 等效）
延遲：0.2~0.5 秒（本地推理）
30% 複雜請求 → Gemini Pro
成本：$1.25/1M tokens
延遲：2~5 秒
整體節省：70% × 95% cost reduction = ~66% 成本降低
代價（路由器的風險）：
如果路由器誤判，把複雜問題送給 Gemma-7b
→ Gemma-7b 無法回答 → 錯誤答案 → 業務影響
→ 品質下滑的代價 > 成本節省的收益
結論：路由器的設計核心是「確保誤判率在可接受範圍內」
二、路由器設計的三種方案
方案比較：
Embedding-based LLM-based Router Rule-based
Semantic Router (Gemini Flash)
──────────────────────────────────────────────────────────────────────────
決策速度 ~50ms ~300ms < 1ms
準確性 中等（依賴相似度） 高（LLM 理解語意） 低（規則有限）
維護成本 中（需要更新範例向量） 低（Few-shot 更新） 高（規則越來越多）
對新場景適應 差（未見過的範例命中率低） 好（LLM 泛化能力強） 差
成本 Embedding 費用（低） Gemini Flash 費用（低） 零
可解釋性 中（相似度分數） 高（可要求 LLM 解釋） 高（規則清楚）
適用場景 路由決策需要極快速度 品質優先 非常簡單的場景
推薦：雙層架構
Layer 1: Rule-based（極快速，處理明顯的情況）
Layer 2: Semantic Router（處理 Layer 1 通過的請求）
三、完整路由架構設計
┌──────────────────────────────────────────────────────────────┐
│ 用戶請求 │
└──────────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ Layer 1：Rule-based 快速路由（< 1ms） │
│ │
│ 明確路由到小模型（Gemma）： │
│ ├── 請求長度 < 50 tokens AND 無 Tool-calling 歷史 │
│ ├── 純問候語（pattern match） │
│ └── 格式轉換任務（JSON → CSV 等） │
│ │
│ 明確路由到大模型（Gemini Pro）： │
│ ├── 請求含 tool_calls 欄位（需要工具能力） │
│ ├── 請求長度 > 5,000 tokens（複雜上下文） │
│ └── 用戶明確標記為「高精度模式」 │
│ │
│ 不確定 → 進入 Layer 2 │
└──────────────────────────┬───────────────────────────────────┘
│ 不確定的請求
▼
┌──────────────────────────────────────────────────────────────┐
│ Layer 2：Semantic Router（~50ms） │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Embedding Model（text-embedding-004，輕量） │ │
│ │ → 將當前 Query 轉為向量 │ │
│ └─────────────────────────┬────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ In-memory Vector Index（FAISS 或小型向量快取） │ │
│ │ │ │
│ │ 「簡單任務」黃金範例： │ │
│ │ ├── "今天天氣怎樣？" │ │
│ │ ├── "幫我把這段文字翻譯成英文" │ │
│ │ └── "這個 JSON 格式對嗎？" │ │
│ │ │ │
│ │ 「複雜任務」黃金範例： │ │
│ │ ├── "分析這份合約的法律風險並給出建議" │ │
│ │ ├── "根據這些數據建立一個財務預測模型" │ │
│ │ └── "找出這段程式碼的 bug 並修復" │ │
│ └─────────────────────────┬────────────────────────────┘ │
│ │ │
│ ▼ │
│ 相似度分數： │
│ ├── 與「簡單任務」相似度 > 0.88 → Gemma-7b │
│ ├── 與「複雜任務」相似度 > 0.88 → Gemini Pro │
│ └── 不確定（兩者都 < 0.88）→ 保守策略 → Gemini Pro │
└──────────────────────────┬───────────────────────────────────┘
│
┌───────────┴───────────┐
▼ ▼
┌──────────────────────┐ ┌──────────────────────────────┐
│ Gemma-7b on GKE │ │ Gemini 1.5 Pro (Vertex AI) │
│ 低延遲、低成本 │ │ 高品質、有 Tool-calling │
│ ~0.3s / ~$0.05/1Mtp │ │ ~3s / ~$1.25/1M input tp │
└──────────────────────┘ └──────────────────────────────┘
四、黃金範例的設計：路由器的核心資產
黃金範例設計原則：
原則 1：覆蓋真實用戶查詢的分布
不要只放教科書式的例子
「幫我總結一下」可以很簡單，也可以很複雜（總結什麼？多長？）
需要覆蓋邊界情況
原則 2：難以確定的案例放到「複雜」類別（保守偏誤）
誤判方向的不對稱性：
├── 把複雜問題送給 Gemma（假負例）→ 回答品質差，用戶不滿 ← 嚴重
└── 把簡單問題送給 Gemini（假正例）→ 浪費成本，但用戶滿意 ← 輕微
所以：不確定時，送 Gemini（寧可成本高一點，不要品質差）
原則 3：定期更新
每個月從生產日誌中抽樣，分析「哪些被路由到 Gemma 但回答品質差」
→ 這些案例加入「複雜任務」範例庫，更新路由器
範例質量評估：
好的範例 → 在向量空間中，簡單/複雜兩個群集間的距離大（容易分類）
差的例子 → 兩個群集高度重疊（路由器頻繁不確定）
五、Eval Pipeline：確保路由品質不下滑
路由器評估的核心挑戰：
「這個問題被路由到 Gemma，但 Gemma 的回答對嗎？」
→ 不能只評估路由決策，也要評估路由後的最終品質
Eval Pipeline 設計：
┌──────────────────────────────────────────────────────────────┐
│ 週期性 Shadow Evaluation（每日自動跑） │
│ │
│ Step 1：從生產日誌中抽取 5% 的被路由到 Gemma 的請求 │
│ │
│ Step 2：Shadow Run │
│ 同一個請求，同時送給： │
│ ├── Gemma-7b（實際路由結果） │
│ └── Gemini Pro（黃金標準，僅用於評估，不給用戶） │
│ │
│ Step 3：比較兩者答案 │
│ ├── Semantic Similarity（語意相似度） │
│ ├── LLM-as-Judge（品質評分） │
│ └── Task Success（任務是否完成） │
│ │
│ Step 4：計算 Routing Error Rate │
│ Gemma 回答 vs Gemini 回答 差距 > 閾值的比例 → 誤判率 │
└──────────────────────────┬───────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────┐
│ 動態閾值調整 │
│ │
│ 如果某類 Query 的 Gemma 誤判率 > 10%： │
│ └── 自動將這類 Query 的路由閾值調高（更保守） │
│ 例：「合約相關問題」 → 閾值從 0.88 調到 0.95 │
│ 效果：這類問題更容易被判為「複雜」，路由到 Gemini │
│ │
│ 如果某類 Query 的 Gemma 誤判率 < 2%： │
│ └── 可以小幅降低閾值（增加 Gemma 的路由比例，省更多錢） │
└──────────────────────────────────────────────────────────────┘
六、Gemma on GKE 的部署考量
為什麼要自己部署 Gemma，而不是用 Vertex AI 托管：
Vertex AI 托管：
├── 優點：zero ops，自動擴縮
└── 缺點：成本比自托管高，且 Gemma 的 API 計費跟 Gemini 差不多
GKE 自托管：
├── 優點：只付 GPU 成本，大量使用時遠比 API 便宜
│ L4 GPU（GKE 上）：$0.60/hr
│ Gemma-7b 吞吐量：~2,000 tokens/sec/GPU
│ 等效成本：$0.60 / (2,000 × 3600 / 1M) = ~$0.08/1M tokens
└── 缺點：需要維護 Deployment，需要手動處理擴縮
GKE 部署考量：
┌────────────────────────────────────────────────────────┐
│ HPA（Horizontal Pod Autoscaler）： │
│ └── 根據 GPU 使用率或請求佇列深度自動擴縮 │
│ │
│ 模型服務框架選擇： │
│ ├── vLLM（高吞吐量，KV Cache 優化）← 推薦 │
│ ├── TGI（Text Generation Inference by HuggingFace） │
│ └── Triton Inference Server（NVIDIA） │
│ │
│ 冷啟動問題： │
│ └── 保持至少 2 個 Warm Pod，避免第一個請求要等模型載入│
└────────────────────────────────────────────────────────┘
七、成本收益分析框架
路由系統的 ROI 計算：
假設：
每日 100,000 個請求
平均 2,000 tokens/請求
無路由：全部 Gemini Pro
路由後：70% → Gemma，30% → Gemini Pro
無路由月成本：
100,000 req × 2,000 tokens × 30 天
= 6,000,000,000 tokens = 6,000M tokens
× $1.25/1M = $7,500/月
路由後月成本：
Gemini Pro（30%）：
1,800M tokens × $1.25/1M = $2,250/月
Gemma on GKE（70%）：
4,200M tokens / (2,000 tokens/sec × 86,400 sec/day) = 需要 ~24 個 GPU 小時
~$1,440/月（GKE L4 GPU 費用）
路由器費用（Embedding + 少量 LLM 判斷）：~$100/月
總計：~$3,790/月
節省：$7,500 - $3,790 = $3,710/月（節省 49%）
投資回報率：路由系統開發成本通常 1~2 個月回本
八、面試答題要點
「設計混合路由系統要解決兩個問題：準確路由 + 品質保障。
路由架構用兩層：Layer 1 是 Rule-based 快速過濾（< 1ms），處理明顯的簡單或複雜請求；Layer 2 是 Semantic Router，用輕量 Embedding 模型計算當前請求和黃金範例的相似度，超過 0.88 閾值的送 Gemma，不確定的保守策略送 Gemini。
Gemma 部署在 GKE 上用 vLLM 服務，比 Vertex AI API 便宜約 15 倍。保持至少 2 個 Warm Pod 避免冷啟動延遲。
品質保障：每日從生產日誌抽 5%，做 Shadow Run（同一請求同時跑 Gemma 和 Gemini），比較答案差距，計算誤判率。如果某類 Query 誤判率超過 10%，自動調高路由閾值，確保那類問題更容易被判為複雜、路由到 Gemini。
量化的成本節省：在 10 萬請求/天的規模，從 $7,500/月降到 $3,790/月，節省約 49%。」
系列導覽：
← （二十三）RKK 實戰：多租戶 Agent 的限流、Fair-Share 與 Token 預算控制
→ （二十五）RKK 實戰：Self-Reflection 與幻覺校正迴圈設計
