大多數團隊的做法：讓小模型先回答，覺得不好再丟給大模型——結果是雙倍延遲加雙倍成本。
正確的做法：在小模型生成第 10 個 Token 的那一刻，就已經知道要不要升級了。
路由的決策點不在答案完成之後，
而在答案開始生成的前幾個 Token 之間。
面試情境
面試官：「一個金融科技客戶，為了隱私合規，90% 的查詢必須留在地端私有伺服器處理。他們在地端部署了 Gemma-2-9b，雲端備用 Gemini Pro。但目前的架構是：小模型先跑完整回答，人工審核覺得不好才重送到雲端，導致平均延遲高達 6.8 秒。你如何重新設計路由機制，讓延遲降到 3.6 秒以下，同時確保敏感 PII 資料絕不離開地端？」
一、核心問題：為什麼「先跑再判斷」的架構從根本上就錯了
傳統雙軌架構的根本缺陷：
┌─────────────────────────────────────────────────────────────┐
│ 用戶 Prompt → 地端小模型（完整推理 3.5s） │
│ ↓ │
│ 品質評估（人工或 LLM 評分 0.5s） │
│ ↓ │
│ [品質不足] → 雲端大模型（完整推理 2.8s） │
│ │
│ 最壞情況延遲 = 3.5 + 0.5 + 2.8 = 6.8 秒 │
│ 最壞情況成本 = 地端 + 評分 LLM + 雲端大模型（三份費用） │
└─────────────────────────────────────────────────────────────┘
為什麼這個架構在生產環境中必然崩潰：
問題 1：確定性延遲疊加
└── 任何需要升級的查詢都承受 100% 的雙倍延遲，沒有優化空間。
金融客服場景中，約 35% 的查詢需要升級 → 平均延遲被拉高 2.4s。
問題 2：「評估 LLM」是一個謊言
└── 用 LLM 評分 LLM 的輸出，等於再跑一次推理。
GPT-4 Judge 模式：額外 $0.03/query、額外 1.2s。
這讓「省成本部署小模型」的初衷完全破功。
問題 3：冷啟動的隱藏殺手
└── 地端 GPU 伺服器閒置後 VRAM 被釋放，冷啟動需要 8-12 秒載入模型。
金融客服的流量高峰突發（早上 9:00 開盤時 QPS × 10），
前 30 個請求全部超時，客戶體驗災難性崩潰。
問題 4：PII 資料外洩風險
└── 若路由邏輯沒有 PII 偵測層，包含身份證字號、帳戶餘額的查詢
可能在「升級」過程中被送往雲端 API，直接違反 PDPA/GDPR。
正確的心智模型：
路由決策 ≠ 「跑完再評估」
路由決策 = 「開始生成的前 10 個 Token 就已經告訴你答案了」
資訊理論基礎：
一個對答案不確定的模型，其生成的前幾個 Token 的概率分佈會極度分散。
H = -∑ p(x) log p(x) 熵值高 → 模型不確定 → 早點放棄，送給大模型。
熵值低 → 模型對接下來要說什麼非常有把握 → 繼續本地生成。
這個問題的本質是推理資源的最優分配：讓對的模型處理對的查詢，而不是讓所有查詢都走同一條路。
二、三個演進階段
╔══ Phase 1（POC / < 10K 用戶）══╗
最小可行路由：基於規則的靜態分流
┌──────────────────────────────────────────────────────────────┐
│ Phase 1 架構：靜態規則路由 │
└──────────────────────────────────────────────────────────────┘
用戶 Prompt
│
▼
┌─────────────────┐
│ 規則分類器 │ ← 關鍵字字典 + 問題長度 + 類型標籤
│ (Python dict) │ 例：長度 < 50 字 → 本地
│ │ 包含「法規」「訴訟」→ 雲端
└────────┬────────┘
│
┌────┴────┐
│ │
▼ ▼
┌───────┐ ┌───────────┐
│ 地端 │ │ 雲端 │
│Gemma │ │Gemini Pro │
│ 9b │ │ │
└───────┘ └───────────┘
Phase 1 新增元件（vs 無路由基線）：
- 關鍵字字典分類器（Python dict，< 1ms）
- 問題長度閾值規則（< 50 字走本地）
- 固定路由比例目標（80% 本地 / 20% 雲端）
成本 / 複雜度：
- 開發時間：2–3 週，1 名工程師
- 基礎設施：地端 1 × A100 GPU 節點，雲端 Vertex AI API
- 月費用估算（10K 用戶 × 50 queries/月）：
- 地端 GPU 租用：$800/月
- 雲端 Gemini Pro：10K × 20% × $0.015 = $30/月
- 總計：≈ $830/月
遺留問題：
- 關鍵字規則維護困難，新業務場景需手動更新字典
- 邊界案例（問題既長又簡單）路由錯誤率高達 18%
- 沒有即時置信度感知，仍有部分雙倍延遲
- 沒有 PII 偵測，敏感資料外洩風險存在
╔══ Phase 2（MVP / 10K–200K）══╗
生產級路由：Cross-Encoder 分類器 + 基礎熵值監控
┌──────────────────────────────────────────────────────────────┐
│ Phase 2 架構：Cross-Encoder 前置分類 + PII 強制本地 │
└──────────────────────────────────────────────────────────────┘
用戶 Prompt
│
▼
┌─────────────────┐
│ PII 偵測層 │ ← NER (spaCy) + Regex 身份證/帳號
│ (< 5ms) │ 命中 → 強制本地，永不升級
└────────┬────────┘
│ 非 PII
▼
┌─────────────────┐
│ Cross-Encoder │ ← mBERT fine-tuned（1萬筆標注資料）
│ 分類器 │ 輸出：[本地置信度, 升級置信度]
│ (< 20ms) │ 閾值：升級置信度 > 0.7 → 雲端
└────────┬────────┘
│
┌────┴────┐
│ │
▼ ▼
┌──────────────────────────────┐ ┌───────────────┐
│ 地端 vLLM │ │ 雲端 │
│ Gemma-2-9b │ │ Gemini Pro │
│ logprobs=True │ │ Vertex AI │
│ + 熵值監控（閾值 H > 2.5） │ │ │
└──────────────────────────────┘ └───────────────┘
│
H 超閾值時
│
▼
[TCP RST 中斷]
原始 Prompt → 雲端（帶 Context Cache ID）
Phase 2 新增元件（vs Phase 1）：
- mBERT Cross-Encoder（需要標注資料集，延遲 < 20ms）
- PII 偵測層（spaCy NER + Regex，< 5ms）
- vLLM logprobs API 開啟（overhead < 5ms）
- 基礎熵值計算 + HTTP/gRPC 中斷機制
- 地端模型 Keep-Warm 機制（避免冷啟動）
成本 / 複雜度：
- 開發時間：6–8 週，2–3 名工程師
- 標注資料：需 1 萬筆 query 路由標注（外包約 $3,000）
- mBERT fine-tuning：Cloud Run GPU $120 一次性費用
- 平均延遲（本地路徑）：< 2.1s（vs Phase 1 的 3.5s）
- 升級路徑延遲：< 3.6s（因早停，省去 2.8s 完整推理）
遺留問題：
- Cross-Encoder 需要定期重新標注（業務場景擴展時）
- 雲端大模型沒有預熱，突發流量時冷啟動 8–12s
- 熵值閾值 H > 2.5 是固定值，不同業務類型最佳閾值不同
- 缺少路由決策的 A/B 測試基礎設施
╔══ Phase 3（Scale / 200K–1M+）══╗
企業級路由：早停熵值路由 + 動態閾值 + 多層冷啟動優化
┌──────────────────────────────────────────────────────────────┐
│ Phase 3 架構：完整 Early-Exit Confidence Routing 系統 │
└──────────────────────────────────────────────────────────────┘
用戶請求（QPS: 500–2000）
│
▼
┌─────────────────────┐
│ API Gateway │ ← Cloud Run，全球負載均衡
│ Rate Limiting │ 限流：500 QPS/node
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ PII 偵測層 │ ← spaCy NER + Regex + DLP API
│ (< 5ms P99) │ 命中 → 強制本地 Flag，寫入 Audit Log
└──────────┬──────────┘
│ 非強制本地
▼
┌─────────────────────┐
│ 輕量前置分類器 │ ← 嵌入相似度（FAISS，< 3ms）
│ 快取路由記憶體 │ 歷史相似 Query 結果快取
└──────────┬──────────┘
│
┌────┴────┐
│ │
▼ ▼
┌───────────────────┐ ┌──────────────────────┐
│ 地端 vLLM 叢集 │ │ 雲端 Vertex AI │
│ Gemma-2-9b │ │ Gemini Pro │
│ A100 × 4 節點 │ │ 預熱實例（3 個） │
│ logprobs=True │ │ Context Cache 支援 │
│ │ │ │
│ ┌───────────────┐ │ └──────────────────────┘
│ │ 熵值監控微服務│ │ ▲
│ │ Token 1-10 │ │ │
│ │ H = -∑p log p│ │ [早停升級] │
│ │ H > 閾值(動態)│─┼──────────────┘
│ └───────────────┘ │
│ Keep-Warm: │
│ VRAM 常駐 │
└───────────────────┘
│
▼
┌─────────────────────┐
│ 路由 Metrics 層 │ ← Prometheus + Grafana
│ A/B 閾值實驗 │ 動態調整各業務類型閾值
│ 動態閾值 API │ 每 6 小時重新校準
└─────────────────────┘
Phase 3 新增元件（vs Phase 2）：
- FAISS 嵌入快取路由（重複 Query 0ms 決策，命中率 ~40%）
- 動態閾值校準（每 6 小時，按業務類型調整 H 閾值）
- Vertex AI 預熱實例（3 個常駐，突發時 < 1s 啟動）
- Cloud Pub/Sub 非同步審計日誌（PII 路由決策 100% 留存）
- A/B 測試框架（不同閾值策略的對照實驗）
成本 / 複雜度：
- 地端 4 × A100 節點：$6,400/月
- Vertex AI 預熱實例（3 個）：$1,200/月
- 雲端推理成本（1M 用戶 × 20% 升級 × $0.015）：$3,000/月
- 總計：≈ $10,600/月（vs 全雲端方案 $22,500/月，節省 53%）
- 平均延遲：本地路徑 1.8s，升級路徑 3.2s（vs 原始 6.8s）
三、Early-Exit 熵值路由的核心實作細節
這是整個架構最關鍵的技術突破。傳統路由在答案完成後才判斷，而熵值路由在答案開始的第 10 個 Token 就做出決策。
Early-Exit Confidence Routing 完整流程：
┌──────────────────────────────────────────────────────────────┐
│ 步驟 1：開啟 vLLM logprobs API │
└──────────────────────────────────────────────────────────────┘
地端 vLLM 設定：
POST /generate
{
"prompt": "用戶的問題",
"logprobs": 5, # 每個 Token 位置輸出前 5 高概率
"stream": true, # 串流模式，Token by Token 傳回
"max_tokens": 512
}
返回格式（每個 Token）：
{
"token": "我",
"logprobs": {
"我": -0.12, → p("我") = 0.887
"您": -2.31, → p("您") = 0.099
"這": -3.45, → p("這") = 0.032
"無": -4.21, → p("無") = 0.015
"抱": -5.10, → p("抱") = 0.006
}
}
overhead：< 5ms per token（vs 不開啟 logprobs 的基線）
┌──────────────────────────────────────────────────────────────┐
│ 步驟 2：熵值計算與閾值判斷 │
└──────────────────────────────────────────────────────────────┘
熵值計算（Shannon Entropy）：
H = -∑ p(x) log₂ p(x)
案例 A：模型非常確定（低熵）
概率分佈：[0.91, 0.05, 0.02, 0.01, 0.01]
H = -(0.91×log₂0.91 + 0.05×log₂0.05 + ...) = 0.52 bits
判斷：H < 2.5 → 繼續本地生成 ✓
案例 B：模型極度不確定（高熵）
概率分佈：[0.22, 0.20, 0.19, 0.21, 0.18]
H = -(0.22×log₂0.22 + ...) ≈ 2.32 bits
判斷：H > 2.5 → 立即升級到雲端 ✗
拒絕詞偵測（補充機制）：
前 10 個 Tokens 中出現：
└── 「我不確定」「抱歉，我無法」「這超出我的」
→ 不用等熵值，直接觸發升級
┌──────────────────────────────────────────────────────────────┐
│ 步驟 3：早停中斷與無縫升級 │
└──────────────────────────────────────────────────────────────┘
中台微服務（Cloud Run）的決策邏輯：
監控第 1-10 個 Token：
├── 任一 Token 熵值 H > 2.5 → 觸發中斷
└── 或連續 2 個拒絕詞 → 觸發中斷
中斷流程：
1. 向地端 vLLM 發送 TCP RST（中止 TCP 連線）
→ vLLM 接收到連線中斷，停止生成，釋放 KV Cache
→ 地端 GPU 算力立刻空閒（避免浪費剩餘的 ~450 Tokens 推理）
2. 同時發出雲端請求：
→ 原始用戶 Prompt（未修改）
→ 附上 Context Cache ID（如果有歷史對話 Cache）
→ 優先使用 Vertex AI 預熱實例（< 1s 冷啟動）
3. 用戶側感知：
→ 前 10 個 Token 生成約 0.3s
→ 中斷 + 切換到雲端約 0.2s
→ 雲端生成 2.7s
→ 總計 3.2s（vs 雙倍推理的 6.8s）
延遲節省原理：
└── 本地跑完再升級：3.5s（地端）+ 2.8s（雲端）= 6.3s
└── Early-Exit 升級：0.3s（早停）+ 0.2s（切換）+ 2.7s（雲端）= 3.2s
└── 節省：3.1s（節省 49%）
四、PII 強制本地路由的設計
隱私合規是整個雙軌架構的存在理由，PII 路由層必須做到零誤報（false negative）。
PII 偵測架構（多層防禦）：
┌──────────────────────────────────────────────────────────────┐
│ Layer 1：Regex 快速掃描（< 1ms） │
└──────────────────────────────────────────────────────────────┘
台灣 PII 正則表達式：
身份證字號：[A-Z][1-2]\d{8}
銀行帳號： \d{7,14}（搭配金融機構關鍵字）
手機號碼： 09\d{8}
統一編號： \d{8}（8位數字）
命中任一 → 立即標記為 PII_DETECTED，跳過後續層
┌──────────────────────────────────────────────────────────────┐
│ Layer 2：spaCy NER 實體識別（< 3ms） │
└──────────────────────────────────────────────────────────────┘
識別實體類型：
├── PERSON（人名）：「幫我查李大明的帳戶」
├── ORG（機構名）：「我在○○銀行的貸款」
├── MONEY（金額）：「餘額 $285,000」
└── ID（識別碼）：「帳號 1234567890123」
spaCy 模型：zh_core_web_lg（中文大型模型）
準確率：PERSON 98.2%、MONEY 99.1%
┌──────────────────────────────────────────────────────────────┐
│ Layer 3：Cloud DLP API（非同步審計，不阻塞路由） │
└──────────────────────────────────────────────────────────────┘
Cloud Data Loss Prevention API：
├── 對每個已路由到本地的請求做非同步深度掃描
├── 掃描結果寫入 Cloud Pub/Sub → BigQuery 審計表
└── 若 DLP 發現 Regex/NER 未捕捉的 PII → 更新 Regex 規則庫
PII 路由審計保存策略：
├── 路由決策記錄保存 7 年（PDPA 合規）
├── 敏感 Query 本身不保存（只記錄 Hash + 決策）
└── 月報：PII 命中率、漏報率、規則更新頻率
強制本地路由的效果：
零升級違規（升級到雲端的請求中 PII 命中率 = 0%）
PII 偵測總延遲：< 5ms（Regex + NER，串行執行）
PII 偵測誤報率（非 PII 被標記）：< 0.8%（影響效率，可接受）
五、冷啟動優化策略
地端模型的冷啟動是延遲的隱藏殺手，必須在架構層面徹底解決。
冷啟動問題的規模：
Gemma-2-9b 模型規格：
├── 模型參數：9B（約 18GB FP16 權重）
├── 載入到 A100 VRAM：需要 8–12 秒（NVMe 讀取 + CUDA 初始化）
└── 冷啟動期間請求：全部超時（4s timeout）
金融客服流量模式：
├── 早上 9:00 開盤：QPS 從 0 突增到 400（10倍峰值）
├── 午休 12:00–13:00：QPS 下降 80%（VRAM 有被釋放風險）
└── 收盤 15:00：第二波突發
若無冷啟動優化：
早上 9:00 前 30 個請求（QPS 突破閾值後）全部超時。
用戶體驗評分：1/5 星
┌──────────────────────────────────────────────────────────────┐
│ 策略 1：地端 Keep-Warm（模型常駐 VRAM） │
└──────────────────────────────────────────────────────────────┘
vLLM 設定：
├── --gpu-memory-utilization 0.85：預留 15% 給系統
├── --max-model-len 8192：設定最大上下文長度（影響 KV Cache）
└── 不設定 idle timeout：模型永遠常駐於 VRAM
成本代價：
└── A100（80GB VRAM）全天保留 → $3.50/小時 × 24 = $84/天
└── 但避免了 30 次超時 × 平均訂單損失 $15 = $450/天
└── ROI 非常正面
Keep-Warm 的監控：
└── Prometheus 監控 VRAM 使用率（vllm:gpu_cache_usage_perc）
└── 告警：VRAM 使用率 < 70%（可能模型已卸載）→ 立即重載
┌──────────────────────────────────────────────────────────────┐
│ 策略 2：雲端大模型 Vertex AI 預熱實例 │
└──────────────────────────────────────────────────────────────┘
Vertex AI Dedicated Serving（預熱實例）：
├── 最少 3 個實例常駐（覆蓋基線雲端升級流量）
├── 自動擴展：上限 20 個實例（峰值應對）
└── 冷啟動時間：常駐實例 < 1s，新實例 15–20s
費用分析：
├── 3 個 Gemini Pro 預熱實例：$1,200/月（固定費用）
├── 節省的冷啟動損失：雲端升級請求 P99 延遲從 22s → 3.2s
└── 高峰時段升級請求成功率：從 76% → 99.2%
┌──────────────────────────────────────────────────────────────┐
│ 策略 3：流量預測 + 提前暖機 │
└──────────────────────────────────────────────────────────────┘
基於歷史流量的預測暖機：
├── 每天 8:45 → 自動觸發地端模型健康檢查（確認 VRAM 常駐）
├── 每天 8:50 → 發送 5 個 Dummy Warm-up Requests（預熱 KV Cache）
└── 每天 11:50 → 檢查午休期間 VRAM 狀態，必要時預載
Dummy Warm-up Request 設計：
└── 內容：代表性的簡單問題（如「你好，請問可以幫我什麼？」）
└── 目的：讓 CUDA Kernel 進入熱態，KV Cache 機制初始化
└── 延遲效果：第一個真實請求從 3.8s 降到 1.9s
六、動態閾值校準與 A/B 測試
靜態閾值 H > 2.5 在不同業務場景下表現差異極大，需要動態調整。
不同業務類型的最佳熵值閾值：
業務類型 最佳閾值 說明
─────────────────────────────────────────────────
基本帳戶查詢 H > 3.0 問題簡單，小模型通常夠用
理財產品諮詢 H > 2.0 需要更嚴格的升級觸發
法規合規問題 H > 1.5 高風險，寧可多升級
一般問候/簡單查詢 H > 3.5 幾乎都讓小模型處理
固定閾值 2.5 的問題：
├── 對帳戶查詢過嚴（不必要地升級 23% 的簡單查詢）
└── 對合規問題過鬆（15% 的合規問題沒有升級，答案品質差）
動態閾值校準流程（每 6 小時執行一次）：
1. 從 BigQuery 取最近 6 小時的路由日誌
2. 計算每個業務類型的：
└── 本地模型答案品質評分（用戶回饋 + 自動評估）
└── 升級率（升級到雲端的比例）
└── 用戶滿意度（CSAT）
3. 對閾值做梯度優化（最大化：品質 × 效率 × 成本）
4. 更新 Redis 中的閾值配置（動態讀取，無需重啟）
A/B 測試框架：
┌─────────────────┐ ┌─────────────────┐
│ Control Group │ │ Treatment Group │
│ H 閾值 = 2.5 │ │ H 閾值 = 2.2 │
│ 10% 流量 │ │ 10% 流量 │
└─────────────────┘ └─────────────────┘
│ │
└────────────┬───────────┘
│
┌─────────▼─────────┐
│ 統計顯著性測試 │
│ p < 0.05 判斷 │
│ 贏家閾值推廣至 │
│ 100% 流量 │
└───────────────────┘
實驗週期：48 小時（確保覆蓋完整的工作日流量模式）
評估指標：用戶滿意度（CSAT）、升級率、平均延遲、每查詢成本
七、觀測性與故障診斷
完整觀測性架構：
┌──────────────────────────────────────────────────────────────┐
│ Metrics（Prometheus + Grafana） │
└──────────────────────────────────────────────────────────────┘
路由層指標：
├── router_local_ratio：本地路由比例（目標：> 78%）
├── router_escalation_rate：升級率（目標：< 22%）
├── router_entropy_histogram：熵值分佈直方圖
├── router_early_exit_count：早停觸發次數/分鐘
└── router_pii_detection_rate：PII 命中率
地端推理指標：
├── vllm:gpu_cache_usage_perc：VRAM 使用率（告警：< 70%）
├── vllm:num_requests_running：目前推理中的請求數
├── vllm:time_to_first_token：TTFT（目標：< 200ms P99）
└── vllm:model_load_time：模型載入時間（冷啟動監控）
雲端指標：
├── vertex_ai_latency：雲端推理延遲（目標：< 3s P95）
├── vertex_ai_error_rate：API 錯誤率（告警：> 0.1%）
└── vertex_ai_cost_per_hour：每小時費用
┌──────────────────────────────────────────────────────────────┐
│ Traces（Cloud Trace） │
└──────────────────────────────────────────────────────────────┘
每個請求的完整鏈路：
請求接收 → PII 偵測（5ms）→ 分類器（20ms）→
vLLM 開始（Xms）→ [早停決策（Yms）] →
[TCP RST（1ms）→ 雲端發送（10ms）→ 雲端推理（Zms）]→
響應返回
關鍵 Span 標記：
├── span.early_exit = true/false
├── span.entropy_value = H 值（浮點數）
├── span.pii_detected = true/false
└── span.route = "local" | "cloud" | "forced_local"
┌──────────────────────────────────────────────────────────────┐
│ 常見故障與診斷鏈 │
└──────────────────────────────────────────────────────────────┘
症狀 A：升級率突然從 20% 飆到 55%
→ Grafana：router_escalation_rate 告警
→ 看 router_entropy_histogram：熵值整體分佈上移
→ 可能原因：新業務類型的問題湧入（小模型訓練資料外分佈）
→ 解法：臨時調高閾值（H > 3.0），同時觸發模型更新流程
症狀 B：平均延遲從 2.1s 突升到 8.3s
→ Trace：看 vLLM span 時長，發現 TTFT 從 150ms → 9.2s
→ Metrics：vllm:gpu_cache_usage_perc 降到 0%（模型卸載了！）
→ 可能原因：另一個服務佔用了 VRAM，觸發了 OOM 卸載
→ 解法：重新載入模型（2 分鐘），並設定 GPU 資源隔離
症狀 C：PII 稽核日誌發現雲端請求含有帳戶資訊
→ Cloud Pub/Sub DLP 審計 Topic 收到告警
→ 追查 Trace：看到 pii_detected=false，但 DLP 偵測到 PII
→ 可能原因：Regex 未覆蓋新型帳號格式（銀行系統更新）
→ 解法：更新 Regex 規則（< 5 分鐘），重新過濾歷史日誌
八、為什麼選 X 不選 Y
| 選擇 | 選 X 的理由 | 不選 Y 的理由 | Flip Condition |
|---|---|---|---|
| 熵值早停路由 vs LLM-as-Judge | 在 Token 10 決策，額外 overhead < 5ms；無需額外推理費用；可即時中斷。每次節省 3.1s | LLM-as-Judge 需要跑完整推理才能評分，額外 $0.03/query + 1.2s；等同於三層費用（地端 + Judge + 雲端） | 若查詢平均長度 < 3 個 Token（例如純關鍵字搜尋），熵值資訊不足，此時用規則路由 |
| TCP RST 中斷 vs Graceful Cancel | 即時釋放 GPU（< 1ms），地端算力立刻可用；適合高並發場景（500+ QPS） | Graceful Cancel 需等待 vLLM 完成當前 Token 批次，平均多耗費 80–200ms；在高 QPS 下 GPU 被「半廢棄」的請求佔用 | 若地端 GPU 閒置率 > 60%（輕載），可用 Graceful Cancel 保留部分生成結果給快取使用 |
| mBERT Cross-Encoder vs 規則字典 | 泛化能力強，新業務類型自動覆蓋；F1 = 0.91 vs 規則字典 0.74；不需手動維護字典 | 規則字典：需持續人工更新，18% 邊界案例誤路由；對同義詞和語意變形完全無感 | 若業務類型固定（< 5 類型，語料穩定），規則字典的 < 1ms 延遲 + 零標注成本更具優勢 |
| vLLM logprobs vs 外部分類服務 | 推理同步取得，overhead < 5ms；不需額外網路 hop；天然和推理引擎整合 | 外部分類服務：每次請求多一次 HTTP 往返（15–50ms）；服務依賴鏈增加故障點；費用 $0.001–0.003/query 額外成本 | 若地端推理引擎不支援 logprobs（如 llama.cpp CPU 模式），外部輕量分類器是唯一選項 |
| Vertex AI 預熱實例 vs 按需啟動 | 雲端升級 P99 延遲從 22s → 3.2s；突發流量（× 10 QPS）時不丟請求；月費 $1,200 固定，ROI 明確 | 按需啟動：平均冷啟動 15–20s；突發時 76% 的升級請求超時；用戶流失率估算每月 $8,000 損失 | 若升級率 < 5%（雲端請求稀少），預熱實例成本 > 收益，可改用最小 1 個實例 + Pub/Sub 異步排隊 |
| spaCy NER + Regex vs 純 LLM PII 偵測 | 延遲 < 5ms（同步阻塞路由決策路徑上）；規則透明可審計；誤報率 0.8%；符合法規要求 | 純 LLM PII 偵測：需 LLM 推理 200–800ms；在路由決策前增加不可接受的延遲；且 LLM 對 PII 判斷有概率性誤差（不適合合規場景） | 若僅做非同步稽核（不阻塞路由），LLM PII 偵測準確率更高（99.5%），適合事後審查 |
九、系統效應：優化前後對比
| 指標 | 優化前（雙倍推理架構） | 優化後（早停熵值路由） | 改善幅度 |
|---|---|---|---|
| 平均請求延遲（升級路徑） | 6.8s（地端完整 + 雲端完整） | 3.2s（早停 0.3s + 切換 0.2s + 雲端 2.7s） | -53% |
| 平均請求延遲（本地路徑） | 3.5s | 1.8s（VRAM 常駐，KV Cache 熱態） | -49% |
| P99 延遲（升級路徑） | 14.2s（包含冷啟動） | 4.1s（Vertex AI 預熱實例） | -71% |
| 每查詢成本（平均） | $0.0052（地端 + Judge + 20% 雲端） | $0.0018（地端 $0.0001 × 80% + 雲端 $0.015 × 20%） | -65% |
| 月總費用（1M 查詢/月） | $5,200 | $1,800 | -65% |
| 本地路由比例 | 80%（靜態規則，精度差） | 83.5%（熵值路由，精度高） | +3.5pp |
| PII 外洩事件 | 不確定（無偵測層） | 0 次（雙層 PII 防護） | 100% 消除 |
| 冷啟動超時率 | 12.3%（峰值突發時） | 0.1%（Keep-Warm + 預熱實例） | -99% |
| 升級路由正確率 | 74%（人工審核主觀） | 91.2%（熵值閾值 + 自動校準） | +17.2pp |
| 地端 GPU 算力浪費 | 100%（即使升級也跑完整推理） | 8%（早停後僅浪費 10 Tokens 推理） | -92% |
| 用戶滿意度（CSAT） | 3.2/5（延遲投訴多） | 4.4/5 | +37.5% |
十、系統效應：整體架構演進圖
架構演進總覽：
Phase 1（靜態規則） Phase 2（Cross-Encoder） Phase 3（熵值早停）
───────────────── ───────────────────── ─────────────────
Prompt → 規則字典 Prompt → PII 偵測 Prompt → PII 偵測
│ │ │
┌───┴───┐ Cross-Encoder FAISS 快取路由
│ 地端 │ 完整推理 │ │
└───────┘ ↓ ┌───┴───┐ ┌───┴────────────┐
品質差 │ 地端 │ logprobs=True │ 地端 vLLM │
↓ └───────┘ │ │ Token 1-10 │
雲端完整推理 熵值監控 ──┤ │ 熵值計算 │
│早停 └───────┬────────┘
TCP RST │ H > 閾值
│ │
雲端 TCP RST
│
雲端（預熱）
延遲：6.8s 延遲：3.6s 延遲：3.2s
成本：$0.0052/q 成本：$0.0028/q 成本：$0.0018/q
PII 保護：無 PII 保護：有 PII 保護：有 + 審計
冷啟動：12%超時 冷啟動：3%超時 冷啟動：0.1%超時
十一、面試答題要點
「這個問題的核心矛盾是：傳統的『先跑完再判斷』路由，把路由決策點放在答案完成之後，導致任何需要升級的查詢都承受雙倍延遲。我的解法是把決策點前移到答案生成的前 10 個 Token：透過 vLLM 的 logprobs API（overhead < 5ms），即時計算 Shannon 熵值 H = -∑p log p，若 H > 2.5 代表模型對當前答案高度不確定，立刻送出 TCP RST 中斷地端生成，同步將原始 Prompt 送到 Vertex AI 預熱實例。這個早停機制讓升級路徑延遲從 6.8s 降到 3.2s（-53%），同時節省了 92% 的地端 GPU 算力浪費。在 PII 保護方面，我在路由決策上游設計雙層防禦：Regex（< 1ms）+ spaCy NER（< 3ms）同步阻塞路由，任何 PII 命中都強制本地路由，永不升級到雲端，達成零 PII 外洩事件。架構從 Phase 1 的靜態規則字典，演進到 Phase 2 的 Cross-Encoder（F1 = 0.91），最終在 Phase 3 加入動態閾值校準（每 6 小時自動校準各業務類型的最佳 H 閾值）和 FAISS 嵌入快取路由（重複查詢命中率 ~40%，0ms 決策），讓整體每查詢成本從 $0.0052 降到 $0.0018（-65%）。」
系列導航
← Part 46：前一篇主題 | Part 48：下一篇主題 →
