把它想成「LLM 版的 API Gateway」：統一入口、路由、限流、成本與可用性，而不是再包一層 SDK。

產品開始接 OpenAI、Anthropic、自架 vLLM、甚至多個模型等級之後，呼叫端很快變成一堆 if/else：哪個模型、超額怎麼辦、供應商掛了怎麼切、重複問題要不要再燒一次 token。LLM Gateway 把這些模型側橫切關注點收到單一控制平面，讓應用只面對穩定的 completion／chat API。

這四個盒是本篇後續四節的骨架，也是同一筆請求會依序遭遇的四類規則；看的時候記住它們的計量單位不同——Route 看能力與延遲、Quota 看美元、SemCache 看相似度、Fallback 看供應商健康。

路由不是挑最貴模型，而是依 SLA、任務型態與成本曲線把流量分到正確池。

好的路由表會把「產品意圖」與「供應商細節」解耦：應用寫 model: chat-balanced，Gateway 決定今天是 GPT 小杯還是自架 Llama。面試時要講清楚：路由決策應可配置、可回放、可對成本歸因，而不是散落在業務程式碼的字串常數。

實務上會先把後端池分出能力級距：短分類與 FAQ 這種任務只需要最低一級；程式碼生成需要中間一級；長鏈推理才需要最高一級。這個級距是路由的硬前提——能力不足的池即使更便宜、更快，也不能拿來承接，只能在「沒有任何能力足夠的池可用」時當作降級選項（見第 4 節）。

解耦點就在第二個盒：應用只寫 model: chat-balanced，今天走哪一家、哪一杯是 Gateway 的政策決定的——換供應商不必動業務程式碼，成本也才歸得了因。

限的不只是 QPS——token、預算與租戶公平性才是 LLM 帳單的真實單位。

傳統 API Gateway 常以請求數或連線數限流；LLM 場景還要同時盯 input／output tokens、並發串流數與美元預算。否則「每分鐘 60 次」仍可能被超長 prompt 或 Agent 多輪迴圈打穿預算。

計費歸因至少要能拆到：租戶、虛擬模型、供應商、快取命中與否——否則「這個月貴在哪」無法回答。

逾時、配額用盡、區域故障時，Gateway 應能依政策切到備援供應商或較小模型。

Fallback 鏈常見順序：同供應商次級模型 → 另一供應商同級模型 → 降級回答（較短、較便宜）→ 快取／模板兜底。關鍵不是「永遠成功」，而是失敗可預期、行為可宣告（例如回應標頭標明實際模型與是否降級）。

這條鏈上有兩個常被混用的詞，面試時要分清楚：Fallback 指首選後端因健康問題（逾時、5xx、熔斷）出局，改由另一個能力同樣足夠的後端承接，答案品質不打折，代價通常是成本或延遲上升；Degrade（降級）指沒有任何能力足夠的後端可用（被延遲預算、context 上限或預算擋掉），只好用低一級的模型作答，品質確實會打折，因此必須在回應標頭標註。前者換家、後者換級。

Fallback 的目標不是永遠成功，而是讓失敗可預期：每一跳都要在回應標頭標明實際模型與是否降級，否則呼叫端會把降級答案當成旗艦模型的水準。

Exact-match cache 不夠；以 embedding 近似度命中歷史回答，是 Gateway 最常見的成本槓桿之一。

流程概觀：請求進來 → 產生 query embedding → 在向量索引找鄰近歷史 query → 相似度 ≥ 閾值則直接回傳快取 completion（或再經輕量校验）→ 否則打模型並寫回快取。這與 RAG 檢索不同：這裡快取的是對模型的既有答案，目的是跳過生成，不是組上下文。

Semantic cache 是成本與正確性的滑桿：面試要能說你如何選 τ、如何隔離租戶、以及哪些流量根本不該快取。

前面四節是規則，這一節把規則跑起來：同一筆請求，改一個旋鈕就換一個結論。

下面的決策器把第 2 到第 5 節的規則寫成一次判定。左邊調請求本身，右邊調 Gateway 當下的狀態；四個後端池與 Semantic Cache 會被畫成平面上的五個候選點，兩條約束線切出可行域，最後導出一個判定碼與它的數字理由。

把 Gateway 講成控制平面：路由、配額、fallback、快取——並畫清與 Agent／Tool Gateway 的責任邊界。