https://yennj12.js.org/yennj12_blog_V4/tags/modelrouting/Recent content in ModelRouting on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-18-semantic-model-routing-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-18-semantic-model-routing-zh/核心定義：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% 的預算。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part47-edge-model-routing-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part47-edge-model-routing-zh/大多數團隊的做法：讓小模型先回答，覺得不好再丟給大模型——結果是雙倍延遲加雙倍成本。 正確的做法：在小模型生成第 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.