LLM 閘道如何運作？工程團隊實用指南

LLM 閘道位於你的應用程式與透過它連接的模型供應商之間，讓你在同一處管理憑證和追蹤用量。

「現時簡直是一場 s**t show。」一名工程師於 2026 年 9 月在 Reddit 的 r/LLMDevs 上寫道。

「每個人都各自持有一套 Claude、OpenAI、AWS Bedrock，以及我們使用的所有其他推理服務供應商的密鑰。」

BigGo 對 llm-proxy-tk 的報道（llm-proxy-tk 是一款輕量級 FastAPI 閘道）把這種做法比喻為將 LLM 變成「企業自來水」，而閘道就是整幢大廈的總水掣。

不過，在你如此信任這套「水管」之前，先看看你要安裝的究竟是甚麼。

甚麼是 LLM 閘道？

LLM 閘道是用於模型呼叫的反向代理。你的應用程式會把請求發送給閘道，而不是直接發送到 OpenAI、Anthropic、Google 或你使用的任何 LLM 供應商。閘道會轉發這些請求，並在途中套用你的規則。

每個 LLM 供應商都有自己的 API：各有不同的請求結構、身份驗證方式和錯誤回傳方式，各自的速率限制和故障模式也不一樣。如果它們前面沒有一個共用層，每個呼叫供應商的應用程式就得自己處理所有事情，而且做法各有些微差異。

自來水的比喻只能說明到某個程度，但至少能說明這一點：供應商只需在閘道接駁一次。從此以後，每個應用程式都有自己獨立計量的接駁，讓你清楚看到誰在用甚麼，也能關掉任何一條管線而不影響其他管線。

LLM、AI、MCP 與 API 閘道：有何分別？

LLM 閘道如何運作？

跟隨一個請求，看看它如何從你的應用程式到達模型，再返回。

1. 請求到達閘道：你的應用程式向閘道的端點發送一個看似普通的聊天請求，通常採用與 OpenAI 相容的格式。從應用程式的角度來看，這就是它用來連接模型的地址。
2. 閘道檢查請求者的身份及其權限：在轉發請求之前，閘道會驗證憑證，通常是發給某個團隊或產品的虛擬密鑰。如果你已接入輸入護欄，系統亦可掃描提示，檢查是否含有敏感資料，或有否試圖覆寫模型的指示。
3. 閘道檢查是否已有答案：如果已啟用快取，符合條件的相同請求可以直接以已儲存的回應作答，無須再次呼叫供應商。部分閘道亦提供語義快取，會尋找被判定為足夠相似（而非完全相同）的請求，適合常見問題類型的流量。
4. 閘道決定請求的去向：請求可能指定某個模型或別名。閘道會在你的設定中查找相應路由。你亦可以設定後備路由：如果供應商 A 逾時，閘道可以改試供應商 B。
5. 閘道準備呼叫並傳回回應：閘道會把你的請求轉換為所選供應商的格式，並為外發呼叫進行身份驗證。收到回應後，閘道會立即將其轉換為你的應用程式所需的格式。
6. 閘道記錄發生了甚麼：啟用日誌記錄後，閘道會記錄各項詳情，包括由誰發出呼叫、由哪個模型處理、Token 數量、延遲及成本。這正是引言中那位 Reddit 工程師所欠缺的記錄。

將閘道投入生產環境前須知的 4 件事

上一節所述的一切之所以可行，是因為閘道能看到經它路由的每個請求。這是它的賣點，但同時也描述了你必須預先規劃應對的攻擊面和廠商依賴。

閘道現在是你 AI 技術堆疊中最具價值的一環

閘道集中管理存取權限，因此亦讓單一服務能觸及大量憑證。Microsoft 安全團隊列出了 LiteLLM 部署可能持有或擷取的內容：供應商 API 密鑰、其本身的主密鑰、虛擬密鑰記錄、數據庫連接字串、路由設定及租戶政策。

2026 年 10 月，Check Point Research 披露了兩個高風險漏洞，均涉及 LiteLLM：

• CVE-2026-35029 讓已通過身份驗證的用戶（包括唯讀用戶）能夠存取管理功能並接管整個實例。
• CVE-2026-59823 讓用戶能把請求重新導向至他們控制的伺服器，從而截取供應商密鑰。

兩個漏洞均已在 1.83.9 版修復。使用閘道的應用程式不應能夠更改閘道的設定。

你的護欄需要一套故障處理政策

Pillar Security 於 2026 年 10 月 4 日發表的一份審查記錄了各大閘道的第三方護欄整合，包括 LiteLLM、Kong、TrueFoundry、Portkey、Azure API Management 和 Apigee。（Pillar 本身銷售護欄產品，閱讀其建議時請留意這一點。）

掛鈎（hook）是請求路徑上的一個點，通常位於提示發送至模型之前，或回應傳回之後；閘道可在此把內容交給外部掃描器作出判定。阻斷式檢查會等待判定結果，然後才讓流量繼續。Portkey 的文件將這些掛鈎稱為 before_request_hooks 和 after_request_hooks；TrueFoundry 則設有四個，額外在 MCP 工具呼叫前後加入檢查。

接下來，有兩件事要檢查：

• 如果掃描器本身出現故障，會怎樣？如果你阻擋請求，就能阻止未經檢查的流量，但可能會中斷你的應用程式。如果你放行請求，應用程式可以在缺少該項檢查的情況下繼續運作。故障日誌會在事後讓你知道該項檢查沒有執行，這固然有用，但並不等同真正執行了檢查。
• 能否更換掃描器？如果不支援其他供應商，你可能需要更新應用程式，或使用另一個代理來連接。

TrueFoundry 的 MCP 掛鈎把閘道的覆蓋範圍從模型請求延伸至工具呼叫。但它只能檢查經過它的流量。在開發人員電腦上執行指令的編程 AI 代理程式，可能就在其視野之外。

Perplexity 的開源工具 Numbat 正是在這一端運作。Numbat 透過本地掛鈎連接受支援的 AI 代理程式，能在計劃中的操作（例如 shell 指令或檔案寫入）執行之前加以檢查。阻擋功能為選用功能，預設為關閉。閘道看到的是經由它路由的模型流量，而 Numbat 則讓你看清 AI 代理程式如何運用得到的答案。

你需要知道閘道的控制範圍止於何處

Forkast News 指出，有三大系譜正從不同方向朝閘道靠攏：

• 以 LLM 為重點的閘道：LiteLLM 和 Portkey 最初專注於模型呼叫，包括在供應商之間轉換格式、路由請求及追蹤 Token。它們現正加入針對工具呼叫的控制。
• API 管理平台：Kong、Google 的 Apigee 和 Azure API Management 最初專注於身份驗證、權限和流量管理，其後加入了對模型及 AI 專屬規則的支援。
• AI 代理程式原生基礎設施：例如 agentgateway，就是圍繞 AI 代理程式與模型、工具及其他 AI 代理程式之間的通訊而構建，包括透過 MCP 和 A2A 進行的通訊。

分類的關鍵在於你要路由的是甚麼：

• 只有模型呼叫？以 LLM 為先的閘道是不錯的起點。
• 企業內已有大量 API 規則，再加上模型呼叫？先從你現有的平台著手。
• AI 代理程式呼叫工具，工具再呼叫模型？請確認這些連接同樣在覆蓋範圍內。

你會引入一個共用的單點故障

假設你的客戶支援聊天機械人使用 OpenAI，而研究工具使用 Anthropic，兩者都透過同一個閘道連接。但如果該閘道停止運作，即使 OpenAI 和 Anthropic 運作正常，兩個工具都會無法存取各自的模型。

這種情況確實發生過。在 2025 年 6 月 12 日的服務中斷期間，Cloudflare AI Gateway 的錯誤率最高達到 97%。該閘道依賴 Cloudflare 的 Workers KV 儲存服務存放設定，而該服務當時正發生故障。

如果你自行運行閘道，請另外保持一個副本運作，以便在其中一個故障時接手。如果閘道由其他人託管，請詢問他們如何在故障期間維持服務運作，以及在恢復期間你的請求會如何處理。

LLM 閘道應具備的主要功能

你將會把所有人的憑證交給閘道存取，所以理應對它能為你提供的回報抱有高要求。

• 以單一 API 對接多個供應商：你的程式碼只需使用一種格式（通常是與 OpenAI 相容的格式），由閘道負責轉換。LLM 供應商亦會遷就配合。例如，Perplexity 的 Agent API 支援 OpenAI 的 Responses API 介面，讓團隊可以重用現有的 OpenAI 用戶端程式庫。
• 附帶規則的虛擬密鑰：每個團隊或產品都有自己的密鑰，並附有規則，規管可使用的模型、請求限額及開支。
• 路由與後備：閘道會根據你的設定把請求發送到模型，這些設定可能側重成本、速度或特定供應商。如果呼叫失敗，閘道可以改試另一個。Perplexity 的 Agent API 讓你按偏好順序列出最多五個模型，包括來自不同供應商的模型。
• 快取：已儲存的回應可以讓你省去再次呼叫供應商。部分閘道會比對完全相同的請求；其他閘道亦可比對意思相近的請求。請檢查快取回應能否按用戶或團隊區分，以及能否針對個人化或具時效性的答案關閉快取。
• 串流與一致的錯誤處理：回應會在生成的同時陸續傳送，而供應商的錯誤會被轉換為你的應用程式能夠處理的格式。請檢查加入 AI 護欄後會有甚麼影響。
• 日誌記錄與成本歸屬：閘道會記錄由誰發出呼叫、由哪個模型處理、使用了多少 Token、耗時多久，以及估算成本。請檢查日誌是否包含提示和回應，以及保留多久。
• 護欄掛鈎：這些是請求路徑上的特定點，閘道可在此把內容發送給外部掃描器作出判定，通常位於模型請求之前或其回應之後。請檢查掃描器故障時請求會停止還是繼續，以及能否接駁其他掃描器。
• 可以鎖定的管理介面：閘道管理供應商憑證的存取權限，以及所有人共用的規則。請確認你能把管理存取權與應用程式流量分開限制，而且唯讀用戶無法更改設定。總水掣需要上鎖。

可以用哪些工具構建你的 LLM 閘道？

市面上各產品的功能列表大同小異。在一個討論內部模型存取的 Reddit 討論串中，發帖者問道：哪個閘道不會需要配備專職工程師？

我們認為這個問題問得對，而答案有四個，視乎你願意承擔多少工作。

自行編寫

一個最精簡的閘道只需處理幾項工作：接收請求、檢查呼叫者的密鑰、加入供應商憑證、轉發呼叫，以及記錄結果。但要支援不同供應商的格式，就會增加工作量；要維持整個系統運作，亦然。

如果你已在運行 Envoy，其外部處理過濾器（external-processing filter）可讓你接駁一項服務，用於檢查及修改請求和回應。不過，你仍需自行構建和運行這項服務。

在一個討論閘道能否削減成本的 r/LLMDevs 討論串中，u/QuanTradin 表示，在每次呼叫時記錄 Token 數量和快取命中標記，幫助他們找出兩項為完全相同的提示支付全價的工作。

「……修正這個問題的價值，比任何路由層可能帶來的都要高。」

這是一則用戶分享的經驗，也是一個不錯的起點。在構建複雜的路由方式之前，先弄清楚你在為甚麼付費。

自行託管開源閘道

LiteLLM 是這方面的常見選擇：與 OpenAI 相容、支援眾多供應商，並擁有龐大的社群。Bifrost 是另一選擇，專為降低每個請求的額外負擔而設計。如果可觀察性是你功能清單上的首要需求，Helicone 值得一看。

LiteLLM 和任何產品一樣，對某些團隊而言有其局限。在一個討論如何替代自行構建的 r/aiagents 討論串中，u/Own_Bar_920 表示，LiteLLM 處理路由毫無問題，但在跨團隊的提示版本管理，以及更換模型時的持續評估方面未能滿足他們的需要，因此他們轉用了另一款工具。

這些需求已超出基本的閘道路由範圍，而這正是重點所在：如果主要需求是路由，LiteLLM 對他們來說表現穩定。

你會得到一套現成的功能（部分功能視乎版本而定），並且可以把閘道保留在你的網絡之內。你亦須自行負責修補漏洞（前文 Check Point 披露的漏洞已清楚說明這一點），以及確保閘道的可用性（單點故障一節已說明這一點）。

不過，你要預留資源，讓專人對它負責。在一個關於內部存取閘道的 r/LLMDevs 討論串中，其中一個顧慮是維護問題。u/Informal-Writer9685 希望找到「不需要專職工程師維護」的方案，並詢問 LiteLLM 據報的升級不穩定問題，在他們的規模下是否真的會構成問題，抑或只是生產環境才需要擔心。

使用託管閘道

Cloudflare AI Gateway、Vercel AI Gateway、OpenRouter 和 Portkey 的託管閘道會替你運行服務。對於相容的應用程式而言，要讓第一個請求成功通過，可能只需更改網址並提供 API 密鑰。

這裡的取捨是，每個提示在到達供應商之前，都要先經過第三方。這意味著你的合規文件中又多了一個資料處理者，而閘道本身的服務中斷屬於廠商的事故，並非由你負責修復。

例如，在 2026 年 2 月 17 日及 19 日，由於一項快取依賴元件發生故障，OpenRouter 分別出現了持續 38 分鐘和 35 分鐘的服務中斷。部分客戶收到「User not found」錯誤，並花時間調試完全有效的 API 密鑰。問題其實出在閘道的基礎設施。

不過值得肯定的是，OpenRouter 發表了詳細的事後檢討報告，並加入了防護措施，以免快取故障令其數據庫不堪負荷。像 OpenRouter 這類託管閘道可以簡化存取，但正如 u/QuanTradin 在 r/LLMDevs 上指出，把帳單合併並不會自動減少開支。

擴展你現有的 API 閘道

如果你的服務已經以 Kong、Apigee 或 Azure API Management 作為前端，它們各自都具備 AI 專屬功能：Kong AI Gateway、Apigee 的 AI 閘道政策和 Azure API Management 的 AI 閘道。你可以在現有的身份驗證、網絡規則和操作程序基礎上，透過外掛程式或政策加入模型控制。

在大型企業中，這可能是組織阻力最小的途徑。這些 AI 功能的成熟度不及獨立閘道。請務必在你打算使用的全套外掛程式或政策中，測試基於 Token 的速率限制和串流功能。

所以，儘管安裝這個總閥門——這個萬能的閘道吧。不過，引言中那位工程師的說法也有道理：一家公司能否存取模型，不應取決於誰剛好在抽屜裏放着那把合適的鑰匙。

閘道把這些鑰匙集中管理，正好解決了這個問題，但這也令抽屜沒關好的後果更加嚴重。你必須清楚知道那是誰的抽屜。

LLM 閘道常見問題

LLM 閘道是免費的嗎？

如果你指的是這類產品，部分 LLM 閘道確實有免費版本。

LLM 閘道的價格由免費的開源軟件，到每月約 50 美元起的付費方案不等，企業部署則採用自訂定價。也有一些改為按百分比收費，例如 OpenRouter 的 Standard 方案會在購買點數時額外收取 5.5%。

哪個 LLM 閘道最好？

你願意自行承擔哪些工作？

• 如果你想自行架設並掌控設定，可以看看 Bifrost 或 Helicone。
• 如果團隊希望由別人負責營運服務，OpenRouter 或 Vercel AI Gateway 這類託管方案會較合適。
• 如果你已經在使用 Kong 或 Azure API Management，不妨先看看它們的 AI 功能。

用你自己的請求測試入圍名單上的選項，包括供應商出現故障時會發生甚麼事。

AWS 有 LLM 閘道嗎？

有。Amazon Bedrock AgentCore Gateway 支援透過 AWS 所稱的「推理目標」（inference targets）呼叫模型。應用程式可藉此使用單一端點連接 Amazon Bedrock、OpenAI 和 Anthropic 等供應商，而供應商憑證和路由則由閘道處理。