https://yennj12.js.org/yennj12_blog_V4/tags/onpremise/Recent content in OnPremise on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 09:00:00 +0800https://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.