LLM Proxy 與 AI Gateway：架構、控制與取捨

LLM Proxy 與 AI Gateway 可能位於相同的網路位置，但兩者承擔的責任不一定相同。Proxy 的核心通常是轉送模型請求與回應；AI Gateway 則進一步理解模型、協定與工作負載，負責路由、故障轉移、用量紀錄、成本歸屬與存取政策。

這些名稱並不是標準。某些產品把具備模型感知能力的閘道稱為「Proxy」，也有產品把單一託管端點稱為「Gateway」。可靠的選擇方法不是比較名稱，而是逐項確認你需要的責任、可以驗證的行為，以及沒有這一層時應用團隊必須自行建置的能力。

先比較責任，而不是產品名稱

兩者通常都位於應用與模型供應商之間：

應用程式或程式設計代理
        ↓
LLM Proxy 或 AI Gateway
        ↓
模型供應商與指定模型

這張圖無法說明中間層真正做了什麼，因此評估應從責任矩陣開始。

責任	傳輸導向的 LLM Proxy	模型感知的 AI Gateway
TLS 終止與 HTTP 轉送	常見	常見
上游 URL 與 Header 處理	常見	常見
串流回應轉送	通常具備	通常具備，但仍須驗證事件協定
供應商憑證隔離	有時具備	常見，但須驗證儲存與存取邊界
OpenAI-compatible 請求介面	有時具備	常見，但相容性會因模型與功能而異
模型或供應商感知路由	有限或由應用負責	常見
重試與有序故障轉移	最多是基礎上游重試	通常能依模型與錯誤類型處理
工作負載級速率與額度	通常在外部	常見
Token、用量與成本紀錄	通常在外部	常見
請求級延遲診斷	通常在外部	常見
政策與稽核控制	通常在外部	視產品而定

「常見」不代表一定存在。對每一項重要能力，都應要求提供確切的請求協定、失敗行為、產生的紀錄，以及營運人員可使用的控制方式。

LLM Proxy 通常負責什麼

當主要需求是為上游 API 提供穩定入口時，傳輸導向的 Proxy 可能已經足夠。它可以集中管理 TLS、上游主機名稱、指定 Header、請求大小限制、逾時與基本日誌。針對 LLM 設計的 Proxy 也可能理解 Server-Sent Events，能在不緩衝完整回應的情況下轉送串流。

這類基礎設施能建立可控的網路路徑，並讓部分客戶端環境不必接觸供應商憑證。它也適合放置一般驗證與網路政策。

當 Proxy 開始轉換請求格式、選擇供應商、計算模型 Token 或費用時，責任邊界就已經改變。這些屬於模型感知行為，即使產品仍使用「Proxy」名稱，也應按照 Gateway 的標準評估。

以下情況通常適合從簡單 Proxy 開始：

• 單一應用只使用一個供應商與少量固定模型；
• 應用本身已負責重試、用量核算與事故診斷；
• 必須完整保留供應商原生功能，不希望經過格式轉換；
• 不需要依團隊或工作負載設定路由政策；
• 團隊希望維持最小的營運層。

AI Gateway 增加了什麼

AI Gateway 不會把模型請求只視為一般 HTTP 流量。它可以根據指定模型、協定、Key 政策、群組可用性、限制與先前嘗試結果決定路由，並將最終嘗試連結到 Token 用量、延遲、狀態與成本紀錄。

不同產品的功能仍有差異。例如，Cloudflare AI Gateway 文件涵蓋分析、日誌、快取、速率限制、重試與故障轉移；Kong AI Gateway 指標文件則描述模型、Token、成本、快取、延遲與錯誤指標。這些例子說明「Gateway」通常代表 AI 感知的控制層，但不構成統一標準。

當下列需求同時出現時，Gateway 的價值會更明確：

• 多個應用或代理需要可分別歸屬的 API Key；
• 同一指定模型存在多條合格路由；
• 速率或額度限制必須在上游開始工作與產生成本之前生效；
• 營運人員必須區分驗證、路由、上游等待、第一個有效輸出與生成時間；
• 每筆模型用量與最終費用都需要可解釋；
• 主要路由需要明確且有順序的故障轉移政策；
• 團隊需要跨多個模型群組的統一營運視圖。

Gateway 不會讓所有供應商自動變得可互換，也不能取代輸出驗證、工具冪等、應用端祕密保護或供應商特定功能測試。

使用工作負載決策矩陣

工作負載	主要需求	合理起點	原因
單一供應商、單一模型的內部服務	穩定網路路徑	直接 API 或小型 Proxy	路由與成本政策可能增加不必要複雜度
同一模型有多條合格路由的客戶應用	可用性與嘗試證據	AI Gateway	路由、有限故障轉移與逐次診斷需要一致的擁有者
全團隊使用的程式設計代理	Key、額度、用量歸屬與離職停權	AI Gateway	共用憑證與無法歸屬的支出會成為營運風險
使用全新供應商原生功能的應用	精確 Wire Contract	先用原生端點，再驗證 Proxy 或 Gateway	正規化介面可能延遲支援或遺漏欄位
已有 Queue 與重試控制器的批次流程	吞吐量與應用自行復原	關閉或限制重試的 Proxy/Gateway	多層重試會放大故障並重複工作
受監管或敏感工作負載	資料路徑、保存與存取證據	依已驗證控制決定	「Gateway」名稱不是安全或合規證明

工作負載成熟後，答案可能改變。只要應用保留清楚的模型客戶端邊界並測試遷移協定，先直接連接單一供應商、之後再加入 Gateway 是合理路徑。

納入隱藏的取捨

額外一跳必須量測

Proxy 或 Gateway 會增加網路與處理層。不要只看平均延遲；應在真實併發下量測上游 Header、第一個有效輸出、第一段可見文字、總時長與輸出速度。少量固定延遲可能換來更快的事故復原，但這是工作負載取捨，不是普遍的效能結論。

相容性取決於具體功能

「OpenAI-compatible」可能只代表 Base URL、驗證 Header 與基本 Chat Completions 請求；Responses 事件、Structured Outputs、Tool Calls、Usage 欄位或錯誤格式仍可能不同。請測試應用實際使用的每項功能。OpenAI-Compatible API 指南提供遷移基線，Responses API 與 Chat Completions 比較則說明為什麼僅看端點不足以推斷完整相容性。

集中化也會形成故障域

把 Key、路由、限制與日誌集中在一層能簡化責任，但也讓這一層變得關鍵。確認設定如何版本化與復原、控制平面無法使用時會發生什麼，以及營運變更期間既有請求能否完成。

成本紀錄需要明確真相來源

有些 Gateway 使用供應商牌價估算，有些使用設定價格、群組倍率或版本化計費表達式。應確認價格何時選定、是否在請求期間固定、快取 Token 與工具用量如何表示，以及最終扣費能否回溯到實際用量。更多分層方法請參考 AI API 成本追蹤。

退出成本同樣重要

採用正規化介面前，盤點應用是否依賴 Gateway 專用 Header、模型別名、路由名稱或日誌 API。好的 Gateway 應讓目前路由更容易營運，同時保留回到供應商原生協定的可能性。

三個實際案例

單一供應商的內部助理

若內部助理只對固定模型送出中等數量的非串流請求，應用已有 Job ID 與伺服器端供應商 Key，一般 Proxy 可能就足夠。此時跨供應商路由與另一套成本控制平面未必解決真實問題，但仍應保留供未來導入 Gateway 的內部模型介面。

多路由的生產應用

客戶應用希望某個上游帳號滿載時仍能使用同一指定模型，並知道哪條路由處理請求、哪次嘗試產生成本。這是 Gateway 的典型場景，因為故障轉移、計費與診斷必須共用請求識別。跨模型替換會改變品質、延遲、工具行為與價格，不應成為隱形捷徑。可參考可靠的 AI API 路由指南。

工程團隊的程式設計代理

程式設計代理可能從許多開發者裝置建立長時間且大量使用工具的工作階段。共用單一供應商 Key 會讓額度、歸屬、輪替與離職停權難以管理。Gateway 可以發放工作負載專用 Key、限制存取並把用量連結到團隊或專案，但 Repository 權限、Sandbox、工具核准與程式碼驗證仍屬於應用安全邊界。

Modelflare 的定位

Modelflare 的目標是提供 AI 感知的存取與路由層，而不只是透明 HTTP Relay。一般 API Key 可以指定主要模型群組與有序後備群組；Smart API Key 則可依設定策略評估合格群組。兩者都會為指定模型尋找合格路徑，不應在未告知的情況下替換成其他模型。

群組 RPM 會在計費與上游工作開始前，針對實際選定群組執行。若群組容量已滿，可繼續評估下一個合格群組；沒有路由時回傳 429。用量日誌把完成請求連結到狀態、Token、成本與時間資訊，並區分驗證、群組選擇、上游 Header、第一個上游事件、第一個有效輸出、第一段可見文字與總處理時間。

相容性仍有清楚邊界：GPT、Codex 與 OpenAI 流量是完整適配目標；其他 OpenAI-compatible 模型家族在額外行為未經驗證前，應視為原始 Chat Completions Pass-through。共用 Base URL 並不代表所有模型都提供相同的 Responses、工具或 Structured Outputs 協定。

可透過模型與價格查看目前公開的模型與群組，並在 Modelflare 文件中取得客戶端設定方式。

生產評估清單

• 協定： 是否保留應用實際使用的請求與回應格式？
• 串流： 事件是否未被緩衝、遺失或重排工具參數？
• 模型識別： 路由改變時是否仍保留指定模型？
• 故障轉移： 哪些錯誤可重試、最多幾次、何時停止？
• 限制： 速率與額度是否在上游工作及計費前套用？
• 用量與成本： Token 與最終扣費能否連結到實際路由與價格？
• 診斷： 能否區分 Gateway 處理、上游等待、第一個輸出與生成速度？
• 祕密： 誰可以讀取供應商憑證、請求本文與回應本文？
• 變更控制： 路由與政策能否審查及復原？
• 退出路徑： 是否能在不重寫應用的情況下回到原生端點？

使用相同模型、Prompt 類型、輸出長度、串流模式、工具、區域與真實併發執行測試。「Hello world」成功只能證明可連線，不能證明生產相容性。

常見問題

每個 OpenAI-compatible Proxy 都是 AI Gateway 嗎？

不是。OpenAI 相容性描述的是部分請求介面；Gateway 描述的是營運責任。Proxy 可以提供 OpenAI 格式而不負責路由、成本、限制與診斷。

AI Gateway 會消除供應商 Key 嗎？

不一定。有些 Gateway 保管供應商憑證，有些採用 BYOK，有些建立自己的計費關係。必須確認憑證位於何處、誰可以使用與匯出。

AI Gateway 會讓請求更快嗎？

不會自動變快。它增加一跳，但也可能帶來更好的路由可用性與診斷。應量測完整請求時間線，而不是採信通用延遲宣稱。

故障轉移應選擇不同模型嗎？

只有應用明確接受品質、相容性、延遲與價格取捨時才可以。較安全的預設是為指定模型與協定尋找另一條合格路徑。

實務上的差異很清楚：主要需要可控傳輸路徑時選擇 Proxy；模型感知路由、工作負載政策、用量、成本與請求證據需要一致責任時選擇 AI Gateway。無論產品名稱為何，都應逐項驗證這些責任。