核心定義：Semantic Model Routing 不是事前分類查詢，而是在生成過程中即時讀取 logprobs 熵值，一旦本地模型表現出高不確定性就立刻中斷並升級至雲端，用最低成本完成每一個請求。
一、為什麼面試官問這個
面試官問 Model Routing 時，真正想測試的是三件事：
- 成本意識：你是否理解「全送雲端」和「全跑本地」都是錯誤極端，能否量化混合策略的 blended cost，並在面試現場即席算出數字。
- 信號工程：你是否知道從哪裡取得可靠的路由信號，而不是直覺性地「加一個分類器」——那個分類器本身就帶來額外延遲和誤差。
- 隱私架構：在決定路由之前，你是否先問「這個請求能不能出境？」這個問題的順序比路由演算法本身更重要。
弱答案長什麼樣
「我會訓練一個路由分類器，根據查詢長度和關鍵字複雜度決定用大模型還是小模型。」
這個答案的問題：沒有具體信號來源、沒有量化閾值、分類器本身的誤差率和延遲完全未提、隱私保護缺席、沒有任何成本數字。面試官會認為你沒有生產經驗，只有理論印象。
強答案長什麼樣
「我從 vLLM logprobs 抽取前 10 個 token 的 Shannon 熵值，H < 1.5 本地結束，H > 2.5 立刻 TCP RST 中斷本地串流並升級 Vertex AI。PII 偵測在熵值路由之前執行，命中則強制留在 on-premise，數據絕不出境。75% 本地處理的混合成本約 $0.00388/query，比全雲端 $0.015 節省 74%，這個數字我是用加權平均即席算出的。」
這個回答展示了信號來源、具體閾值、隱私保護順序、生產層面的成本計算，面試官會繼續深挖細節，而不是換題。
二、核心原理與技術深度
2.1 為什麼不用預分類器
最直覺的做法：訓練一個二元分類器（simple / complex），根據分類結果決定呼叫哪個模型。這個方案看起來合理，但有四個結構性問題：
問題一：額外 RTT 不可避免。 分類器是一次獨立推理，即使是輕量 BERT 也需要 20–80 ms。對話場景的 P50 延遲目標通常 < 500ms，20–80ms 已是 4–16% 的預算。
問題二：誤差疊加。 分類器本身有 5–10% 的錯誤率，加上主模型對難查詢的不確定性，兩個不確定性來源疊加，比單一模型的路由決策品質更差。
問題三：分布漂移。 查詢語意分布隨時間漂移，分類器需要持續蒐集新標記資料再訓練，這是 MLOps 負擔，而不是一次性工程。
問題四：信號已存在，不需要重複計算。 語言模型在生成第一個 token 時，就透過 logprobs 告訴你它有多大把握。這個信號零額外計算成本，只需要把 API flag 打開（logprobs=True）。
2.2 Shannon 熵作為置信度代理
語言模型在每個解碼步驟輸出一個 token 機率分布 P = {p₁, p₂, …, pV}，詞彙量 V ≈ 32,000。Shannon 熵公式：
H = -Σᵢ pᵢ · log₂(pᵢ) 單位：bits
實務近似（top-K=50）：
H ≈ -Σᵢ₌₁⁵⁰ pᵢ · log₂(pᵢ) （長尾機率極小，忽略可接受）
理解熵值的直覺：
- H = 0：模型 100% 確定下一個 token，如 “1 + 1 =” 後面接 “2”。
- H = 1.5 bits：top token 約 45% 機率，剩餘分散在少數幾個候選。模型有把握但保留彈性。
- H = 2.5 bits：top token 約 18% 機率，5–6 個候選機率相近，模型在猜。
- H = log₂(50) ≈ 5.6 bits：完全均勻分布，模型對 top-50 token 毫無偏好，典型的幻覺前兆。
┌─────────────────────────────────────────────────────────────────┐
│ Token 機率分布與熵值對照 │
├──────────────────────────────────────┬──────────────────────────┤
│ 低熵（H < 1.5）：清晰峰值 │ 高熵（H > 2.5）：平坦分布 │
│ │ │
│ p(token) │ p(token) │
│ 1.0 ┤ │ 0.1 ┤ │
│ 0.8 ┤▌ │ 0.08┤ ▌ ▌ ▌ ▌ ▌ ▌ ▌ │
│ 0.6 ┤▌ │ 0.06┤ ▌ ▌ ▌ ▌ ▌ ▌ ▌ │
│ 0.4 ┤▌ │ 0.04┤ ▌ ▌ ▌ ▌ ▌ ▌ ▌ │
│ 0.2 ┤▌ ▌ │ 0.02┤ ▌ ▌ ▌ ▌ ▌ ▌ ▌ │
│ └──────────── token │ └──────────── token │
│ → 本地模型自信，直接回傳 │ → 升級雲端 │
└──────────────────────────────────────┴──────────────────────────┘
| 熵值範圍 | 語意 | 典型查詢類型 | 路由決策 |
|---|---|---|---|
| H < 1.5 | 模型極度自信 | 事實查詢、格式轉換、簡單計算 | 本地結果直接回傳 |
| 1.5 ≤ H ≤ 2.5 | 中等不確定 | 開放式問題、多步推理 | 繼續生成，監測後續 token |
| H > 2.5 | 模型在猜 | 專業領域深度問題、長上下文推理 | 立即中斷，升級雲端 |
2.3 閾值校準方法
閾值 1.5 和 2.5 不是拍腦袋，必須在你的資料分布上實測：
- 準備 1,000 筆標記查詢（正確答案已知）。
- 全部通過本地模型，記錄每筆的前 10 token 平均熵值。
- 按熵值排序，計算各熵值區間的本地準確率。
- 找到「本地準確率剛好跌破 90%」的熵值 → 設為升級閾值（upper threshold）。
- 找到「本地準確率穩定在 95%+」的熵值 → 設為信任閾值（lower threshold）。
這是離線實驗，不是生產推理。結果因任務領域而異：技術文件 QA 的閾值通常比開放式對話低，因為技術領域詞彙分布更集中。
2.4 Early-Exit 中斷機制
等整個回應生成完才判斷熵值，等同於完整燒掉 GPU 算力後才決定結果要不要用——這是最差的設計。Early-Exit 策略：
vLLM Stream（logprobs=True）
│
▼ 每個 token 到達時即計算 Hₜ
┌────────────────────────────────────┐
│ t = 1, 2, 3, … 10 │
│ Hₜ = -Σ pᵢ·log₂(pᵢ) （top-50） │
│ H_avg = running mean(H₁…Hₜ) │
└──────────────┬─────────────────────┘
│
┌───────┴───────┐
▼ ▼
H_avg > 2.5 H_avg < 1.5
│ │
┌────▼────┐ ┌────▼────┐
│ ABORT │ │ t < 10? │
│ TCP RST │ │ 繼續等 │
│ 升級 │ │ t ≥ 10? │
│ 雲端 │ │ 本地完成│
└─────────┘ └─────────┘
為什麼是前 10 個 token？ 實驗顯示前 10 token 的平均熵與全文熵的 Pearson 相關係數 ≈ 0.87，前 20 token 升至 0.91，前 50 token 升至 0.93。多等 40 個 token 只換來 0.06 的相關係數提升，以 GPU 成本衡量不合算。10 token ≈ 本地 GPU 上 15–30 ms，是可接受的 early-exit 點。
TCP RST 中斷：發送 RST 而非 FIN，因為 FIN 需要四次揮手確認，RST 單向強制關閉，節省 1–3 ms 的連接拆除時間。vLLM 的 abort() API 會在服務端同步停止 KV cache 計算，避免殭屍請求繼續消耗 VRAM。
2.5 隱私路由層（必須先於熵值路由）
熵值路由決定「能不能答好」，隱私路由決定「能不能出境」。這兩個問題的優先級不同：隱私是硬性合規，熵值是效能優化。順序錯了，高熵的含 PII 查詢可能在被攔截前就已送出邊界。
┌──────────────────────────────────────────────────────────────┐
│ 請求處理管線 │
└──────────────────────────────────────────────────────────────┘
Request
│
▼
┌─────────────────────────────────────────────────────┐
│ Step 1：PII 偵測層（3–8 ms） │
│ │
│ spaCy zh_core_web_trf → 偵測姓名、地址、組織 │
│ Regex patterns → 身分證號、信用卡號、電話、Email │
│ Redis 快取（prompt hash → PII flag，TTL 24hr） │
└──────────────────────┬──────────────────────────────┘
│
┌──────────┴──────────┐
▼ PII 命中 ▼ 無 PII
強制本地路由 Step 2：熵值路由層
不管熵值高低 （見 2.4）
│ │
▼ ├── H < 1.5 → 本地完成
本地 vLLM ├── 1.5-2.5 → 繼續生成
Gemma-9B └── H > 2.5 → 升級 Vertex AI
PII 偵測工具的選型考量：
| 工具 | 延遲 | 召回率（中文） | 適用情境 |
|---|---|---|---|
| spaCy zh_core_web_trf | 5–8 ms | ~85% | 生產首選，延遲可控 |
| Presidio（Microsoft） | 15–25 ms | ~90% | 需要更高召回率時 |
| 純 Regex | 1–2 ms | ~70% | 結構化欄位補充掃描 |
生產建議：spaCy NER + 自訂 Regex 組合，互補覆蓋。
2.6 成本模型與 TCO 計算
┌──────────────────────────────────────────────────────────────┐
│ 成本拆解 │
├──────────────────────────────────────────────────────────────┤
│ 本地 Gemma-9B（on-premise A100） │
│ 推理成本：$0.0001 / query │
│ GPU idle（keep-alive）：A100 $1.5/hr = $1,080/月 │
│ │
│ 雲端 Gemini Pro（Vertex AI Provisioned Throughput） │
│ 推理成本：$0.015 / query │
│ Provisioned 費用：依 QPS 等級而定（$500–$5,000/月） │
├──────────────────────────────────────────────────────────────┤
│ 混合策略（75% 本地，25% 雲端） │
│ Blended cost = 0.75 × $0.0001 + 0.25 × $0.015 │
│ = $0.000075 + $0.00375 │
│ = $0.00388 / query │
│ │
│ 對比全雲端：$0.015 / query │
│ 節省：(0.015 - 0.00388) / 0.015 ≈ 74% │
└──────────────────────────────────────────────────────────────┘
盈虧平衡計算：GPU idle 成本 $1,080/月需要多少查詢量才能回本？
假設每日 query 量 D，月 query = 30D。全雲端月成本 = 30D × $0.015。混合月成本 = 30D × $0.00388 + $1,080。盈虧平衡：30D × 0.015 = 30D × 0.00388 + 1,080 → D ≈ 3,200 queries/day。低於此量，全雲端更便宜；高於此量，混合架構划算。
2.7 Logprobs API 呼叫實作細節
不同推理伺服器啟用 logprobs 的方式略有不同，面試中說出這個細節顯示你有實際操作過：
1# vLLM OpenAI-compatible API
2response = client.completions.create(
3 model="gemma-9b",
4 prompt=user_query,
5 max_tokens=10, # 只需前 10 token
6 stream=True,
7 logprobs=50, # top-50 token 的 logprob
8 extra_body={"skip_special_tokens": False}
9)
10
11import math
12
13entropy_values = []
14for chunk in response:
15 if chunk.choices[0].logprobs:
16 top_logprobs = chunk.choices[0].logprobs.top_logprobs[0]
17 # 從 log 機率轉回機率，計算熵值
18 probs = [math.exp(lp) for lp in top_logprobs.values()]
19 h = -sum(p * math.log2(p + 1e-10) for p in probs)
20 entropy_values.append(h)
21
22 if len(entropy_values) >= 10:
23 h_avg = sum(entropy_values) / len(entropy_values)
24 if h_avg > UPPER_THRESHOLD:
25 response.close() # TCP RST equivalent
26 return escalate_to_cloud(user_query)
27 elif h_avg < LOWER_THRESHOLD:
28 break # 本地夠自信，不再等待
29
30# Ollama 等效（logprobs 支援較弱，不建議生產使用）
31# response = ollama.generate(model='gemma:9b', prompt=q, options={'logprobs': True})
注意事項：1e-10 的 epsilon 防止 log2(0) 數值爆炸。logprobs 值是 log 機率（通常為負數），需 exp() 轉回機率空間再計算熵。top-50 的歸一化：vLLM 輸出的 top-50 機率總和通常 0.90–0.99，不足 1.0 的部分是長尾 token，可忽略不影響判斷。
2.8 Cold-Start 問題與 Keep-Alive 策略
| 組件 | Cold-Start 延遲 | 緩解策略 | 成本影響 |
|---|---|---|---|
| 本地 Gemma-9B（A100） | 8–12 秒（首次載入） | Keep-alive ping 每 30 秒，絕不 scale-to-zero | GPU idle $1.5/hr 持續計費 |
| 本地 Gemma-9B（熱機） | 首 token < 50ms | 模型常駐 VRAM，KV cache 預熱 | 無額外成本 |
| Vertex AI（on-demand） | 首 token 2–5 秒 | 不可接受，需 Provisioned Throughput | 依 QPS tier 計費 |
| Vertex AI（Provisioned） | 首 token < 200ms | 預留容量，SLA 保障 | $500–$5,000/月（依規模） |
本地模型 keep-alive 的實作：設定一個 background thread 每 30 秒發一個 empty ping 請求至 vLLM，防止 idle timeout 或 OOM 後的自動卸載。這個 ping 不計入 query 費用，但確保 VRAM 中的模型權重不被換出。
三、為什麼選 X 不選 Y
每個路由架構決策背後都有取捨，面試官期待你能說清楚「為什麼不選另一個方案」。
| 決策點 | 選擇 | 選擇理由 | 不選的替代方案 | 不選的理由 |
|---|---|---|---|---|
| 路由信號 | logprobs 熵值 | 生成過程內生信號，零額外推理成本，latency 零增加 | 預訓練分類器 | 額外 20–80ms RTT，誤差疊加，需持續再訓練 |
| 中斷機制 | TCP RST + vLLM abort() | 強制立即終止，避免殭屍計算消耗 VRAM，節省剩餘 token 的 GPU 成本 | 等待生成完畢後丟棄 | 完整 GPU 算力浪費，early-exit 設計失效 |
| 熵值計算窗口 | 前 10 token | 相關係數 0.87，平衡準確性與中斷時機，GPU 成本最小化 | 前 50 token | 相關係數 0.93（僅多 0.06），但多 40 token 的 GPU 成本不合算 |
| 本地推理框架 | vLLM | 原生 logprobs API、精準的 stream abort()、KV cache 管理、高吞吐量 | Ollama | abort() 不精準，生成可能繼續，無生產級 KV cache 管理 |
| PII 偵測順序 | 在熵值路由之前 | 隱私是硬性合規邊界，必須在任何路由決策之前確立，順序錯了就已違規 | 在路由決策之後 | 高熵含 PII 查詢可能先送出雲端，攔截時已出境，合規即失效 |
| 雲端模型部署 | Vertex AI Provisioned Throughput | < 200ms 首 token 延遲保證，SLA 可預期，成本固定（按月） | On-demand | Cold-start 2–5 秒，在串流中斷後升級場景完全無法接受 |
| PII 快取策略 | Redis（TTL 24hr，按 prompt hash） | 相同 prompt 的 PII flag 不重算，節省 5–8ms × 重複查詢次數 | 每次重新偵測 | 高頻重複查詢（如 FAQ 場景）浪費 NER 推理資源 |
閾值反轉條件（Flip Condition）：什麼情況下應該選擇全雲端而非 Model Routing？
- 查詢量 < 3,200/day：GPU idle 成本無法被節省的推理費用攤銷，全雲端更便宜。
- 任務精確度要求 > 98%：本地小模型的不確定性窗口（1.5–2.5 熵值）會犧牲部分準確率，高精度場景應直接送大模型。
- 無 PII 合規需求且查詢分布高度複雜：若 80%+ 查詢都需升級雲端，routing overhead 反而是負擔。
四、系統效應與可觀測性指標
部署 Semantic Model Routing 後，需要持續監測以下指標矩陣，確保路由決策品質不隨時間劣化：
┌──────────────────────────────────────────────────────────────┐
│ Routing 可觀測性指標矩陣 │
├────────────────────────┬─────────────────────────────────────┤
│ 效能指標 │ 品質指標 │
├────────────────────────┼─────────────────────────────────────┤
│ route_local_ratio │ local_accuracy_sampled │
│ 目標：65–80% │ 目標：> 90%（每週抽樣 100 筆人評） │
├────────────────────────┼─────────────────────────────────────┤
│ entropy_p50 │ cloud_escalation_unnecessary_rate │
│ 趨勢上升 → 分布漂移 │ 目標：< 5%（人評確認確實需要升級） │
├────────────────────────┼─────────────────────────────────────┤
│ blended_cost_per_query│ pii_false_negative_rate │
│ 目標：< $0.005 │ 目標：< 0.1%（漏偵測 PII 容忍度低）│
├────────────────────────┼─────────────────────────────────────┤
│ local_p95_latency_ms │ early_exit_abort_rate │
│ 告警閾值：> 500ms │ 目標：10–30%（太低=閾值太寬鬆） │
└────────────────────────┴─────────────────────────────────────┘
before/after 對比（生產驗證數字）：
| 指標 | 全雲端（baseline） | Model Routing 部署後 | 變化 |
|---|---|---|---|
| 每日推理成本（10K query/day） | $150 | $38.8 | -74% |
| P50 首 token 延遲 | 180ms（Vertex AI） | 45ms（本地熱機） | -75% |
| P95 首 token 延遲 | 420ms | 280ms（混合） | -33% |
| PII 出境事件 | 無法保證 | 0（強制本地） | 合規達成 |
| 本地準確率 | N/A | 91.3%（校準後） | 目標達成 |
告警設計原則：
不要只監控「路由比例」，因為比例指標對分布漂移的反應有滯後。正確做法是同時設定：
entropy_p95 > 3.0：查詢整體變難，閾值需重新校準。route_local_ratio < 60%：本地處理量低於預期，檢查是否閾值太嚴或本地模型退化。local_p95_latency > 500ms：本地 GPU 壓力過大，觸發 SLA 保護自動升級。pii_hit_rate 突增 > 2x 移動平均：可能是查詢分布異常或攻擊模式，需人工審查。
五、三個實作層次
Layer 1 — 最小可行（Minimal）
適用場景：PoC、內部工具、< 500 req/day、無合規需求。
架構：Ollama 跑本地 Gemma-9B（logprobs: true）+ Python 腳本計算前 10 token 平均熵 + 超過硬編碼閾值 2.5 則 POST 至 Vertex AI。
無 PII 偵測：允許全部查詢通過熵值路由，含 PII 的查詢可能送出雲端。
無監控：路由決策無日誌，無法知道本地/雲端比例是否符合預期。
工程成本：1 人 × 1 週。GPU 共用機器可接受 idle 成本。
遺留問題清單：
- 閾值 2.5 未校準，可能對你的資料分布不是最佳值
- 無 PII 保護，不符合任何資料合規要求
- Ollama 的 abort API 不如 vLLM 精準，early-exit 後仍可能繼續計算
- 無 blended cost 監控，不知道實際節省了多少
Layer 2 — 生產就緒（Production-Ready）
新增組件：
┌─────────────────────────────────────────────────────────────┐
│ Layer 2 架構 │
└─────────────────────────────────────────────────────────────┘
Request
│
▼
┌──────────────┐ PII hit ┌──────────────────────┐
│ PII 偵測 │────────────▶│ 本地 vLLM │
│ spaCy+Regex │ │ Gemma-9B │
│ Redis 快取 │ │ （強制路由） │
└──────┬───────┘ └──────────────────────┘
│ no PII
▼
┌──────────────┐ H > 2.5 ┌──────────────────────┐
│ 本地 vLLM │ TCP RST │ Vertex AI │
│ Entropy 監測 │───────────▶│ Gemini Pro │
│ (前10 token) │ │ Provisioned TP │
└──────┬───────┘ └──────────────────────┘
│ H < 1.5
▼
本地結果回傳
監控層：
Prometheus metrics：
route_local_total / route_cloud_total
entropy_histogram（p50, p95）
pii_hit_rate
blended_cost_per_query（實時估算）
Grafana：路由比例趨勢、每日成本儀表板
閾值離線校準：在部署前執行校準腳本，輸出特定資料集上的最佳閾值，寫入環境變數而非硬編碼。
工程成本：2–3 週工程，Redis 節點 $50/月，Prometheus/Grafana 若已有則零增量。
遺留問題：閾值固定，不隨查詢分布漂移自動調整；只有 small/large 兩段路由，沒有中間層。
Layer 3 — 企業級（Enterprise-Grade）
新增能力：
動態閾值自動校準：每週由 Cloud Scheduler 觸發 Vertex AI Pipeline，在新累積的標記樣本（每週至少 200 筆人工標記）上重新校準閾值，結果寫回 Firestore，路由服務熱載入新閾值無需重啟。
三級路由：
Gemma-2B（$0.00003/q）→ Gemma-9B（$0.0001/q）→ Gemini Pro（$0.015/q）
不同任務類型有不同的閾值配置：
代碼生成：上閾值 2.0（更嚴格，代碼錯誤成本高）
日常對話：上閾值 2.8（更寬鬆，可接受輕微不確定）
醫療/法律：強制雲端（無論熵值，高風險領域）
CMEK 加密：on-premise 到 Vertex AI 的 payload 使用 Cloud KMS 客戶管理金鑰加密，金鑰輪換策略 90 天，滿足金融、醫療合規要求。（參考 Part 10：CMEK/BYOK）
A/B 路由實驗：以 user_id hash 做 traffic split，對照不同閾值配置對使用者滿意度（CSAT、thumbs-up rate）的影響，數據驅動閾值決策。
SLA 保護自動降級：若本地 GPU P95 延遲 > 500ms（通常是 GPU 過熱或 VRAM 碎片），自動 bypass 熵值判斷直接升級雲端，確保 SLA 不因本地問題連帶受損。
工程成本：6–10 週工程，需要 MLOps 基礎建設（標記資料流水線、Pipeline 排程、特性存儲）。
Layer 3 面試情境模擬：
面試官：「你的本地 GPU 在週一早上業務高峰時 P95 延遲從 60ms 跳到 800ms，同時熵值路由仍然判定 70% 本地處理，你怎麼診斷和處理？」
強答模式：「首先確認是 VRAM 碎片還是 thermal throttling——看 GPU util 和 VRAM 使用量。如果是高峰並發導致 KV cache 溢出，應調低 vLLM 的 max_num_seqs 限制並發請求數。SLA 保護層同時應已觸發 P95 > 500ms 的 fallback，自動將新請求繞過熵值判斷直接升級雲端，先保住使用者體驗，再慢慢排查根因。閾值不需要修改，因為這是容量問題而非熵值信號問題。」
六、常見錯誤與陷阱
| 錯誤模式 | 後果 | 正確做法 |
|---|---|---|
| 用預分類器而非 logprobs 信號 | 額外 20–80ms 延遲，分類器誤差疊加路由誤差，MLOps 負擔加重 | 直接從 vLLM stream logprobs 計算熵值，零額外推理成本 |
| 等整個回應生成完才判斷熵值 | 完整燒掉 GPU 算力再丟棄結果，early-exit 設計完全失效 | 前 10 token 即判斷，命中即 TCP RST + vLLM abort()，節省剩餘生成成本 |
| 隱私路由在熵值路由之後執行 | 高熵含 PII 查詢先送雲端，攔截時已出境，違反合規 | PII 偵測永遠先行，結果決定路由上限，熵值只決定效能優化路徑 |
| 閾值硬編碼不做領域校準 | 查詢分布偏移後本地準確率悄悄跌破 90%，使用者體驗劣化但無告警 | 離線 1,000 筆標記資料集校準，生產後每月重新校準，閾值存環境變數 |
| 本地模型允許 scale-to-zero | 首次請求冷啟動 8–12 秒，SLA 完全破壞，使用者以為系統掛了 | Keep-alive ping 每 30 秒，GPU idle 成本計入 TCO，盈虧平衡分析決定 break-even query volume |
| 忽略 Vertex AI cold-start | 認為雲端一定快，on-demand 首 token 實際需 2–5 秒 | 使用 Provisioned Throughput，預留容量保證 < 200ms 首 token 延遲 |
| 只監控路由比例，不監控熵值分布 | 看不出查詢分布漂移（熵值整體上升但比例指標滯後告警） | 同時追蹤 entropy_p50、entropy_p95，以分布趨勢告警，不要等比例指標才發現 |
七、與其他核心主題的關聯
- Part 8（PII 去識別化）：隱私路由層的 NER + Regex 直接依賴 Part 8 的 PII 偵測模式；兩者共用 token budget 評估與 Redis 快取策略，實作時可共享同一個 PII scanner service。
- Part 9（資料主權 / Sovereign AI）：熵值路由的「強制本地」分支是資料主權合規的實作手段；Part 9 的資料分類等級（機密/敏感/公開）可直接對應路由決策：機密強制本地，公開允許全熵值路由。
- Part 10（CMEK/BYOK）：Layer 3 的 Cloud KMS 加密 payload 需要 Part 10 的金鑰管理架構；客戶管理金鑰確保雲端模型無法在 Anthropic/其他廠商端解密推理內容。
- Part 12（背壓與 Fair-Share）：本地 GPU 滿載時，熵值路由需配合背壓機制決定：排隊等本地，還是直接升級雲端？這個決策需要兩者協同，過早升級增加成本，過度排隊增加延遲。
八、面試一句話（Killer Phrase）
「Semantic Model Routing 的核心洞察是：不需要額外分類器，因為模型在生成第一個 token 時就已透過 logprobs 告訴你它有多大把握——Shannon 熵就是這個信號，且是零額外計算成本的。我的實作是從 vLLM stream 讀取前 10 個 token 的 logprobs，計算平均熵值，H < 1.5 本地直接完成，H > 2.5 立刻 TCP RST 中斷並升級 Vertex AI Gemini Pro；但在這之前，PII 偵測層必須先執行，含個資的請求強制留在 on-premise，不管熵值多高、模型多不確定，數據絕不出境。這個架構在 75% 本地處理率下，blended cost 降至 $0.00388/query，對比全雲端 $0.015 節省 74%；但本地模型必須 keep-alive 熱機，GPU idle 成本是 TCO 的一部分，break-even 在 3,200 queries/day 以上才划算，這個數字需要在架構決策時明確對齊。」
系列導航
