LLM閘道：AI智能體的路由、驗證和成本控制

LLM閘道是一個HTTP反向代理，位於AI智能體程序和上游模型提供者端點之間，作為所有出站推論流量的資料平面運作。它在轉發前在線路層解析不透明的金鑰句柄，使用滑動視窗計數器執行每租戶的節流配額，每請求發出OpenTelemetry支出遙測，並在上游P99延遲超過設定閾值時開啟斷路器。智能體應用程式碼無需任何變更。任何執行三個或更多並發推論消費者的機群都應部署一個。

LLM閘道是一個HTTP反向代理，位於AI智能體程序和模型提供者端點之間的資料平面，提供線路層的不透明金鑰解析、透過滑動視窗計數器的每租戶配額執行、每請求的OpenTelemetry支出遙測，以及斷路器故障移轉——所有這些都作為對應用程式碼不可見的基礎設施原語。

多智能體推論中的資料平面問題

沒有專用的推論資料平面，每個智能體程序都管理自己的上游連線：從環境狀態解析金鑰、無每程序配額、無每請求遙測、無法了解上游端點是否降級。有兩個智能體時可以管理。有二十個時，會產生四種不同的故障模式。

透過環境自我檢查進行金鑰洩露

每個在環境中持有明文提供者金鑰的智能體程序，只需一條對抗性指令就可能洩露它。攻擊面就是程序環境本身：os.environ，Linux主機上的/proc/self/environ，序列化程序狀態的詳細錯誤追蹤，以及捕獲包括Authorization欄位的出站HTTP標頭的偵錯日誌設定。

導致智能體回顯環境狀態的提示注入攻擊是針對持有明文金鑰的智能體的一類有據可查的攻擊（OWASP LLM01:2025）。結構性修復不是更好的輸入驗證：而是完全從智能體程序中刪除明文金鑰。LLM閘道在Authorization標頭被寫入之前在線路層解析不透明句柄（$CRED{openai}），意味著智能體程序永遠不會持有可以被洩露的材料。

OpenLegion的網格在基礎設施層級實現這一點：$CRED{}句柄在網格主機邊界解析。智能體容器在結構上無法到達解析的值——不是因為它們被指示不這樣做，而是因為解析發生在它們的地址空間之外。

共享金鑰節流導致配額耗盡

上游模型提供者在API金鑰層級進行節流。在二十個智能體程序共享一個金鑰的機群中，單個程序以預期速率10倍發出請求——無論是透過重試風暴、失控迴圈還是導致無限推論呼叫的提示注入有效載荷——都可能將金鑰推入其他十九個的速率限制區域。

閘道使用以智能體識別碼為索引鍵的滑動視窗計數器執行每租戶配額。當智能體的計數器達到設定的上限時，閘道在閘道層以HTTP 429回應：不分發上游請求，不消耗提供者配額，兄弟智能體不受影響。

每智能體配額也是OWASP LLM10:2025（無限消費）的結構性緩解措施。

缺少上游可觀察性

沒有推論資料平面，每請求遙測需要在每個智能體程序內部進行儀器化。這既是重複的又是不一致的。閘道在線路層每請求發出OpenTelemetry OTLP日誌記錄，捕獲：智能體識別碼、上游端點、模型名稱、輸入權杖計數、輸出權杖計數、快取命中權杖、HTTP回應狀態和請求持續時間。

每請求的支出記錄（輸入權杖 × 每1k輸入價格 + 輸出權杖 × 每1k輸出價格）累積到每智能體的支出帳本中。該帳本支援每日和每月的支出上限以及支出異常警報。

不可見的上游降級

提供者端點會降級。容量事件期間GPT-4o的P99尾延遲可達12秒（OpenLegion基礎設施基準測試，2026年6月）。沒有資料平面中的斷路器，機群中的每個智能體都會在每次請求時吸收這種降級。

具有斷路器的閘道追蹤每端點的錯誤率和P99延遲。當可設定的故障閾值被超越時——例如五個連續的5xx回應，或30秒視窗內P99超過8秒——電路開啟：後續請求立即被分發到設定的備用端點，無需等待降級的主端點逾時。

OpenLegion 2026年6月基準測試測量了GPT-4o主端 → Claude 3.5 Sonnet備用拓撲：P99從12秒降至3.1秒（3.9倍），無需對智能體程式碼進行任何修改。

閘道架構：資料平面與控制平面

資料平面：每請求執行

每個推論請求按順序通過資料平面：

TLS終止：智能體程序透過TLS連線到閘道。對於mTLS部署，智能體也提供憑證。mTLS消除了智能體和閘道之間每請求驗證權杖的需求。
工作負載身分解析：閘道將連線工作負載對應到租戶身分。在mTLS部署中，用戶端憑證中嵌入的SPIFFE SVID攜帶工作負載身分。
不透明句柄解析：閘道檢查出站Authorization標頭中的$CRED{}句柄模式。相符的句柄根據閘道的支援秘密存放區解析。
配額檢查：閘道遞增租戶的滑動視窗計數器並與設定上限比較。如果計數器超過上限，閘道傳回帶有Retry-After標頭的429。不開啟上游連線。
斷路器檢查：閘道評估目標端點的電路狀態。如果電路開啟，請求立即重新導向到備用端點，無需嘗試主端點。
上游分發：閘道從自己的連線集區開啟到上游端點的連線，並將回應串流傳輸回來。
遙測發射：回應完成時，閘道將OTLP日誌記錄寫入遙測管道。

暖路徑的總開銷：0.7-2.1ms。冷路徑（需要出站秘密存放區查詢的快取未命中）：2.6-6.6ms。在500ms-30s的提供者推論延遲下，暖路徑開銷低於總往返時間的0.5%。

控制平面：設定和原則

控制平面管理資料平面的行為。主要職責：

租戶身分和配額設定、端點拓撲、句柄權限範圍：哪些工作負載身分被允許解析哪些句柄。具有openai:read範圍的租戶可以解析$CRED{openai}但不能解析$CRED{anthropic}。這防止了租戶之間的橫向移動。

稽核原則：OTLP日誌記錄中顯示哪些欄位。

控制平面API不應從智能體側網路存取。GHSA-53mr-6c8q-9789（LiteLLM，CVE-2026-35029，在v1.83.0中修補）展示了當控制平面的設定寫入路徑在沒有足夠授權的情況下可透過網路存取時會發生什麼。

部署拓撲

集中式入口

單個閘道叢集處理智能體機群的所有出站推論流量。適合最多約50個智能體的機群，此時操作簡單性優先。

邊車模式

每個智能體容器在其回送介面上執行閘道程序。故障域是一個智能體容器。適合大型機群（50+智能體），此時每智能體故障隔離是優先級。

網格原生代理

在OpenLegion中，推論代理是一個網格服務。網格原生模型原生處理工作負載身分：每個智能體容器在產生時接收網格發布的身分。

OpenLegion的觀點

LLM閘道功能集——mTLS、滑動視窗配額執行、OTLP支出遙測、斷路器故障移轉——不是多智能體機群的可選基礎設施。它是最小可行資料平面。

OpenLegion 2026年6月基礎設施測試的三個測量值量化了風險：

無故障移轉的P99尾延遲：在提供者容量事件期間，純GPT-4o部署上12秒。在閘道層設定Claude 3.5 Sonnet作為斷路器備用時：3.1秒。3.9倍的改進不需要對智能體應用程式碼進行任何變更。

金鑰洩露攻擊面：在所有智能體在其環境中持有明文金鑰的20智能體機群中，被提示注入（OWASP LLM01:2025）入侵的單個智能體可以洩露對其他每個智能體上游連線有效的金鑰。在具有不透明句柄解析的閘道中介機群中，相同的受入侵智能體沒有可以洩露的材料。

OWASP LLM覆蓋率：閘道的每租戶配額執行解決了LLM10:2025（無限消費）。句柄範圍執行解決了LLM06:2025（過度代理）。

對於評估AI智能體憑證管理模式的團隊，閘道的不透明句柄解析是那裡描述的保險庫代理模式的部署層級實現。

LLM閘道比較

功能	自託管 (LiteLLM)	OpenAI原生	OpenLegion網格代理
金鑰解析模型	Postgres支援的金鑰存放區	託管服務	不透明句柄 → 線路層的保險庫
mTLS工作負載身分	不支援	不支援	每智能體容器的SPIFFE SVID
配額執行	基於設定，每金鑰	每組織限制	滑動視窗計數器，每租戶
斷路器故障移轉	基於外掛程式	不可用	原生，帶半開探測
OTLP支出遙測	部分	不匯出	每請求，所有欄位
控制平面隔離	手動；預設暴露	託管	僅私有網格子網路
CVE歷史 (2024-2026)	GHSA-53mr-6c8q-9789 + 其他	無公開	無

為您的機群選擇閘道

mTLS與Bearer權杖驗證

mTLS（mutual TLS）在任何HTTP有效載荷交換之前，在TLS握手層同時驗證用戶端（智能體）和伺服器（閘道）。用戶端憑證攜帶SPIFFE SVID——一個可加密驗證的工作負載身分。標頭中不傳輸Bearer權杖；不需要發行、分發或輪換權杖。

對於生產多智能體機群，帶有SPIFFE發行SVID的mTLS是正確的驗證模型。它完全消除了權杖管理面。

滑動視窗與固定視窗配額計數器

固定視窗計數器在時鐘邊界重置。智能體可以透過在一個視窗最後幾秒和下一個視窗前幾秒以最大速度請求來以名義速率兩倍進行突發。滑動視窗計數器在沒有可利用時鐘邊界的連續時間間隔內維護滾動計數。對於推論工作負載，滑動視窗執行是正確的模型。

遙測粒度要求

每請求OTLP記錄是有用機群可觀察性的最低要求。評估閘道是否在每條記錄上提供這些欄位：agent_id、model_id、input_tokens、output_tokens、cache_tokens、upstream_latency_ms、upstream_status。聚合遙測的閘道無法支援每智能體支出異常偵測或準確的斷路器校準。

開始使用

使用mTLS工作負載身分、滑動視窗配額執行和每請求OTLP支出遙測部署多智能體推論機群。

在OpenLegion上開始閱讀文件比較LiteLLM與OpenLegion

常見問題

什麼是LLM閘道？

LLM閘道是位於AI智能體程序和上游模型提供者端點之間資料平面的HTTP反向代理。它在線路層解析不透明金鑰句柄（智能體程序從不持有明文金鑰），在分發到上游前執行每租戶滑動視窗配額限制，每請求發出OpenTelemetry支出遙測，並在上游端點超過設定閾值時開啟斷路器。這些功能作為不需要對智能體應用程式碼進行變更的基礎設施原語運作。

如果我只使用一個模型提供者，我需要LLM閘道嗎？

單提供者機群仍然受益於三個閘道功能：不透明句柄解析、每租戶配額執行和每請求OTLP支出遙測。暖路徑開銷為0.7-2.1ms——相對於提供者500ms到30秒的推論延遲可以忽略不計。

LLM閘道中的斷路器故障移轉如何運作？

閘道在滾動觀察視窗內追蹤每端點的錯誤率和P99延遲。當可設定的故障閾值被超越時——例如五個連續5xx回應，或30秒視窗內P99超過8秒——電路開啟：所有後續請求立即轉發到設定的備用端點，無需等待降級的主端點逾時。冷卻期後，閘道向主端點分發一個半開探測。成功的探測關閉電路；失敗的探測重啟冷卻計時器。OpenLegion 2026年6月基準測試測量到在GPT-4o → Claude 3.5 Sonnet拓撲上P99從12秒降至3.1秒。

什麼是mTLS，為什麼它對LLM閘道很重要？

mTLS（mutual TLS）在任何HTTP有效載荷交換之前，在TLS握手層同時驗證連線的智能體程序和閘道。智能體提供攜帶SPIFFE SVID（加密可驗證的工作負載身分）的用戶端憑證。HTTP標頭中不傳輸Bearer權杖；不需要發行、分發或輪換任何權杖。從SVID派生的工作負載身分驅動句柄範圍執行：閘道允許連線工作負載只解析其SPIFFE身分有權範圍的不透明句柄，即使一個智能體容器被入侵也能防止租戶間橫向移動。

滑動視窗和固定視窗配額執行有什麼區別？

固定視窗計數器在時鐘邊界重置。智能體可以透過在一個視窗最後幾秒和下一個視窗前幾秒以最大速度請求來以名義速率兩倍進行突發。滑動視窗計數器在沒有可利用時鐘邊界的連續時間間隔內維護滾動計數。對於突發可能觸發上游提供者節流的推論工作負載，滑動視窗執行是正確的模型。

每請求OTLP遙測與聚合支出報告有何不同？

每請求OpenTelemetry OTLP記錄在每次推論呼叫時捕獲個別欄位：智能體識別碼、模型變體、輸入權杖、輸出權杖、快取命中權杖、上游延遲和HTTP狀態。這些記錄累積到每智能體支出帳本中，支援每日和每月預算上限、支出異常偵測和跨模型成本基準測試。聚合支出報告無法支援異常偵測，因為訊號在每請求方差中。

閘道控制平面不應向智能體側網路暴露什麼？

控制平面管理配額設定、端點拓撲、句柄權限範圍和稽核原則。應部署在沒有外部存取路徑的私有子網路中。GHSA-53mr-6c8q-9789（LiteLLM，CVE-2026-35029，在v1.83.0中修補）記錄了管理API上的授權不足。智能體側網路只應到達閘道的資料平面連接埠。

如何為我的機群校準斷路器閾值？

在兩到四週的生產流量中收集每提供者端點的P50、P95和P99延遲直方圖。斷路器開啟閾值應設定在相對於提供者正常SLA明顯降級的P99值——通常是中位P99的2-3倍。半開探測前的冷卻期應超過提供者的典型恢復時間——30-60秒是合理的基線。