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

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

「目前的狀況簡直是一團糟，」一位工程師於 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，它的外部處理篩選器可讓你連接一個服務，用來檢查及變更請求與回應。但你仍須自行建置並維運該服務。

在一則關於閘道能否降低成本的 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 的代管閘道會替你營運這項服務。對於相容的應用程式而言，要送出第一個請求，可能只需更改 URL 並取得 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 等供應商，並由閘道負責處理供應商憑證與路由。