什麼是 LLM 閘道器?
每個應用、Agent 和 IDE 都只呼叫的那一個端點 —— 也是你統一路由、計量、管控和稽核模型流量的地方。
LLM 閘道器 · AI 閘道器 / LLM 代理 / LLM 路由
這個詞用得比較鬆:廠商們把同一層叫 AI 閘道器、LLM 代理或 LLM 路由。本頁給它一個精確的定義,把它和容易混淆的東西分開,並明確說清什麼時候你不該部署它。
什麼是 LLM 閘道器?
LLM 閘道器是位於應用與模型廠商之間的一層服務。應用只呼叫一個端點;閘道器把每個請求轉發到你設定的模型,做協定互譯、保管廠商金鑰並記錄用量。它不用你的流量訓練,不改寫你的提示詞,也不替代模型本身。
- •它是基礎設施,不是模型 —— 模型仍然屬於你選擇的那家廠商。
- •同一個端點可以服務聊天應用、編碼 Agent、批次任務、即時語音和 MCP 工具呼叫。
- •有用的分界線:請求路徑歸閘道器,提示詞歸應用。
LLM 閘道器到底做什麼?
四件事:把每個請求路由到合適的模型;做協定歸一,讓任何用戶端都能和任何廠商對話;集中管理金鑰與存取控制;記錄每一次呼叫以便算錢和稽核。快取、預算和內容檢查都建立在這四件事之上,而不是取代它們。
- •路由與備援:依 Agent 角色選模型,主要廠商 5xx 或逾時時換一家重試,上游金鑰池化負載平衡。
- •協定互譯:四類聊天協定雙向互譯,用戶端可以繼續用自己已經在用的 SDK。
- •治理:金鑰分組、依請求標頭准入、依租戶配額、SSO 與 SCIM、請求級稽核日誌。
- •可觀測性:依金鑰、團隊和模型給出分鐘級 token 與成本時序。
企業為什麼要在模型前面放一個閘道器?
因為模型存取不再是一個團隊的事。當多個團隊、多家廠商和多個 Agent 都在呼叫模型時,問題就變成採購問題:誰能用哪個模型、每個部門花了多少、資料有沒有出網、換一家廠商要花多少工程時間。閘道器用設定回答這些問題,而不是改程式碼。
- •成本歸屬:每次呼叫都帶金鑰和標籤,花的錢能直接依團隊拆開,不用再做一個對帳專案。
- •資料路徑:閘道器跑在你的網路裡,請求只發往你設定的端點。
- •連續性:廠商故障和模型變化在路由層處理,不用改每一個應用。
- •採購:自架 + BYOK 讓金鑰和流量留在你自己的廠商合約下。
什麼時候真的需要 LLM 閘道器?
符合任意兩項就該考慮:不只一家模型廠商、不只一個使用團隊、有合規或資料落地要求,或者花費已經大到沒人能解釋這張帳單。在這條線以下,直接呼叫廠商 API 更簡單也更便宜 —— 閘道器是多一個要維運的服務。
- •為了能力、成本或容災而用了兩家以上廠商。
- •依團隊或依客戶的成本報表是反覆出現的需求。
- •資料不能離開特定網路、區域或租戶邊界。
- •多個 Agent 和 IDE 現在共用一兩個 API 金鑰。
什麼情況下上閘道器是錯的選擇?
當你只有一個團隊、一家廠商、一個應用時。閘道器會多一跳、多一個部署、多一圈值班面。如果每月的模型花費可預測、合規要求也簡單,直接呼叫廠商 API,等第二家廠商、第二個團隊或第一次稽核要求出現時再回來看。
- •只有一家廠商上的原型或單一內部工具,不需要。
- •提示詞管理和模型評測是另外的產品,閘道器取代不了它們。
- •任何閘道器都不能替你去讀廠商合約。
閘道器和中轉服務、直接呼叫廠商 SDK 有什麼差別?
中轉服務替你把流量轉發給廠商,通常還替你保管金鑰並加收費用;你自己執行的閘道器把金鑰和流量留在你的網路裡,並加上路由、計量和策略。直接用廠商 SDK 省掉了這層間接,但重試、協定和計量邏輯會散落在每個應用裡。
- •原型階段用中轉服務沒問題;代價是提示詞和金鑰離開了你的網路。
- •只用 SDK 是最省的做法,直到第二家廠商出現 —— 那時每個應用都要寫同一套膠水程式碼。
- •三者之中只有閘道器能告訴你:錢是誰花的。
| 判準 | 自架閘道器 | 中轉 / 聚合商 | 只用廠商 SDK |
|---|---|---|---|
| 執行位置 | 你的 VPC 或地端機房 | 廠商雲端 | 每個應用內部 |
| 誰保管金鑰 | 你自己的金鑰庫;執行時在閘道器記憶體 | 中轉服務商 | 每個應用各自保管 |
| 模型覆蓋 | 你設定的任意廠商 | 服務商的目錄 | 每個 SDK 一家廠商 |
| 路由與備援 | 依角色、依金鑰、跨廠商 | 受限於服務商目錄 | 由你自己寫 |
| 成本報表 | 依金鑰、分組、模型,資料來自你自己的帳本 | 服務商後台 | 看你自己做了什麼 |
| 稽核面 | 你擁有的請求級日誌 | 服務商日誌 | 散落在各應用裡 |
閘道器應該自架還是用 SaaS?
當金鑰、提示詞或日誌不能離開你的網路,或者採購不接受再多一個子處理者時,選自架。沒有平台團隊、想要零維運時,SaaS 更合適。決定性問題不是時髦,而是:誰能讀到你的流量。
- •自架的代價是容器、升級和一份 runbook;SaaS 的代價是訂閱和一個子處理者審查。
- •還有混合形態:自架的資料面加廠商控制面 —— 提示詞可能留在內網,中繼資料未必。
- •要資料流圖,不要行銷頁。
| 判準 | 自架 | SaaS |
|---|---|---|
| 資料路徑 | 留在你的網路內 | 經過廠商 |
| 金鑰保管 | BYOK,只在閘道器記憶體 | 由廠商管理或轉發 |
| 維運成本 | 你跑容器、做升級 | 廠商執行 |
| 首次可用時間 | 一個 Compose 檔案 | 註冊帳號 |
| 合規面 | 你的 DPA、你的子處理者 | 廠商 DPA 與子處理者 |
| 故障域 | 你的基礎設施 | 廠商的狀態頁 |
該怎麼選?
依五件事給候選打分:它跑在哪裡、帳單錨定在什麼上、原生支援哪些協定和 SDK、對金鑰和租戶的治理有多細、廠商明年還會不會繼續做這個產品。最後再核對一件任何矩陣都看不出的事:你今天能不能重現一個月前的成本報表?
- •部署形態:自架、SaaS 還是混合 —— 以及控制面會不會回連廠商。
- •計費錨點:依執行個體、依席次、依 token,還是依消費額抽成。
- •協定:OpenAI、Anthropic、Gemini、DashScope 雙向互譯,串流與工具呼叫要真的等價。
- •治理:金鑰分組、請求標頭 ACL、預算、SSO 與 SCIM、稽核匯出。
- •可重現性:同樣的輸入,幾個月後仍是同樣的數字。