前言

在 LLM 應用從小規模 PoC 走向生產環境的過程中，AI Gateway 不再只是簡單的 API 轉發器，它已經演變為關鍵的「AI 控制平面」。

選擇 Gateway 就是選擇你對 非確定性 (Non-determinism) 的管理方式。一個好的 Gateway 決定了你如何處理模型飄移、成本失控、合規風險和糟糕的用戶體驗。本文將拋開行銷術語，從架構師視角拆解市面上的主流方案，助你做出最符合技術戰略的決策。

認識 AI Gateway 核心架構：控制平面 vs. 資料平面

多數成熟的 AI Gateway 都可拆成兩個面向：資料平面追求極致快、控制平面承擔治理複雜度：

• 資料平面 (Data Plane) - 效能的極致追求： 這是處理每一筆即時請求的「熱路徑 (Hot Path)」。它位於使用者請求到 LLM 回應的關鍵路徑上，因此對低延遲 (Low Latency) 和高吞吐 (High Throughput) 有著極其嚴苛的要求。在這裡，任何一個毫秒的延遲都會直接影響終端使用者的體驗。它的核心任務就是：快、狠、準地完成請求的轉發、基礎驗證和回應。
• 控制平面 (Control Plane) - 功能的複雜需求： 這是負責管理、配置和監控的「冷路徑 (Cold Path)」。它處理所有非即時的複雜邏輯，例如設定路由策略、管理 API 金鑰、分析成本與用量、提供監控儀表板、更新安全規則等。它的核心任務是：強大、靈活、可觀測。

一個優秀的 AI Gateway 架構，必須將這兩個平面清晰地分離，避免讓控制平面的複雜性拖慢資料平面的效能。讓我們以 TrueFoundry 的架構為例，來看看這是如何實現的。

上圖清晰地展示了這種分離式設計：

• 控制平面： 開發者/管理者透過 UI 進行配置，這些設定被儲存在後端資料庫（如 Postgres）。所有請求的日誌和指標數據被非同步地發送到佇列(NATS)，最終由後端服務處理並存入分析型資料庫（ClickHouse）進行分析。這是一個完整的管理與觀測迴路。
• 資料平面： 應用程式的 LLM Request 直接發送給輕量的 Gateway 實例。這些 Gateway 實例在記憶體中執行所有必要的決策，然後將請求轉發給 LLM，並接收回應。

實現高效能資料平面的關鍵設計原則：

TrueFoundry 的架構體現了幾個最大化資料平面效能的關鍵原則，這在許多頂尖的 Gateway 解決方案中都能看到：

1. 記憶體內執行 (In-Memory Enforcement)： 所有高頻操作，如身份驗證、速率限制、負載平衡等決策，都完全在 Gateway 的記憶體中完成。規則和配置由控制平面提前同步到資料平面，避免了在處理即時請求時，還需要去查詢外部資料庫，從而實現了毫秒甚至亞毫秒級的回應時間。
2. 請求路徑中零外部呼叫 (Zero External Calls on Request Path)： 一旦請求進入資料平面（Gateway），就不會再觸發任何額外的網路或磁碟 I/O 操作（除非啟用語義快取等特定功能）。這從根本上消除了不可預測的外部延遲，保證了 Gateway 本身的效能穩定性。
3. 非同步日誌記錄 (Asynchronous Logging)： 資料平面的首要任務是處理請求，而不是等待日誌寫入。Gateway 會將日誌和指標數據「即發即忘 (fire-and-forget)」地推送到一個高速訊息佇列（如 NATS）。控制平面的後端服務會非同步地消費這些數據。即使後端的日誌系統出現故障或延遲，也絕不會阻塞或減慢即時的請求處理流程。
4. 無狀態與水平擴展 (Stateless & Horizontally Scalable)： 資料平面的 Gateway 實例本身是無狀態的，不保存任何會話資訊。這意味著可以根據流量負載，輕鬆地增加或減少 Gateway 實例的數量（水平擴展），以應對數萬甚至數十萬 RPS（每秒請求數）的龐大流量。

不同的 AI Gateway 解決方案在控制平面與資料平面的設計上會有不同的取捨。有些輕量級的開源方案可能更專注於提供一個高效的資料平面，而在控制平面的功能上較為精簡。而一些企業級的商業方案則可能提供極其強大的控制平面，但在部署和效能上需要更多考量。

AI Gateway 四大選型路線：從設計與技術實作解析

市面上的 AI Gateway 隨著 LLM Agent 的盛行以及管理負擔的指數增加，現行的解決方案有如雨後春筍般的出現，第一時間看到實在令人感到眼花撩亂。現在我們大略的使用四大流派來劃分戰場，深入探討其技術底層。

效能至上：專注於資料平面的極致化

這一派別的核心哲學是：Gateway 絕不能成為性能瓶頸，其自身開銷應趨近於零。他們追求的不是功能的廣度，而是資料平面 (Data Plane) 的極致效率。這種性能優勢並非僅來自於將日誌等操作非同步化（這已是現代後端的標準實踐），其根本原因在於底層技術棧的選擇。

Bifrost（by Maxim）：追求微秒級的透明代理

Bifrost 採用 Go 語言，利用其輕量級的併發模型 (Goroutines) 和高效的網路處理能力，專為大規模 I/O 密集型場景而生。官方宣稱的 11μs 新增延遲，不僅是將重操作移出關鍵路徑，更是在關鍵路徑上對每一次記憶體分配、每一次資料複製都進行了極致優化，以降低對 Go 垃圾回收 (GC) 的壓力，從而保證穩定的低延遲。

• 技術核心：極薄關鍵路徑（鑑權/限流/路由最小化）、串流友善、重打點改走旁路事件。
• 架構啟示：特別適合 Realtime API、對話式 Agent 等對 P99 尾延遲極敏感的場景。
• 選型提醒：你需要已有或願意自建完善的觀測/治理系統，Bifrost 專注「快」。

LangDB：Rust 賦能的可編程路由

LangDB 以 Rust 撰寫而成。Rust 沒有垃圾回收機制，通過編譯期的所有權檢查解決了記憶體安全問題。這意味著沒有 GC 停頓 (GC Pauses) 的風險，能夠提供極其平滑且可預測的 P99 尾部延遲，這對於即時互動或 Agent 應用至關重要。其強大的可編程路由能力，是建立在這個高性能、無 GC 的基石之上。

• 技術核心：延遲/成本加權路由、腳本化策略、回退與條件降級。
• 架構啟示：能把短文本導向便宜模型、長文本交給長上下文模型，精細化利用供應商差異。
• 選型提醒：路由強、治理薄；效能與策略靈活並存，但審計/合規要額外補齊。

你可能會問，這種速度的代價是什麼？答案是生態整合的便利性。

選擇 Go 或 Rust，意味著選擇了性能的「硬核模式」。相較於像 LiteLLM 這樣以 Python 為核心的方案，它們與主流 AI 框架（如 LangChain、LlamaIndex）的整合通常不那麼直接。選擇效能極客路線，等於做出了一個清晰的架構權衡：你願意用更專業的開發資源和額外的整合工作，去換取資料平面上毫秒必爭的極致性能與穩定性。 這是一個為解決規模化瓶頸而生的選擇，而非追求開箱即用的功能完整性。

企業方案穩定至上：構建完整的 AI 治理體系

這一派把 Gateway 視為安全與合規的邊界，重點在縮短「從零自建到可審計/可回溯/可控」的時間。它們的企業版多半已內建 RBAC、審計、PII 脫敏、金鑰生命週期、配額/預算與 SSO/SCIM 整合，對需要從頭打造 AI 基礎設施的團隊，是極具效率的捷徑。

Kong AI Gateway

Kong 把既有的 API 治理能力（鑑權、RBAC、配額、限流、審計）原樣延伸到 LLM 流量，企業環境可直接沿用既有 Kong 生態與運維流程。

• 技術核心：基於 NGINX/Envoy 的插件體系（如 ai-proxy、ai-request-transformer、PII Sanitizer），策略與審計集中化。
• 架構啟示：已部署 Kong 的企業幾乎零摩擦接手 AI 流量：同一套門戶、同一套策略、同一套觀測。
• 選型提醒：功能成熟且一體化，上線快、風險低；但把更多政策「內聯」到資料平面會帶來一定延遲與成本，需依 SLO 調整啟用範圍。

TrueFoundry：MLOps 與應用團隊的橋樑

TrueFoundry 強項是把 LLM 納入雲原生與 MLOps 的既有秩序：Kubernetes、Secret Managers、RBAC、多租戶配額與成本追蹤都能一站接軌。

• 技術核心：集中路由/回退、團隊級配額與成本追蹤、金鑰與密鑰治理、與現有平台流程打通。
• 架構啟示：中大型組織要把 LLM 當「共享基礎設施」管理時的實用路徑，減少「旁路系統」造成的治理破碎。
• 選型提醒：治理面完整、企業適配度高；導入期需要平台/安全/資料團隊協作並做自家延遲壓測。

在這派的使用者會更多注重在專業 SaaS 解決方案的「企業級成熟度 + 上線速度」。Kong 與 TrueFoundry 已把審計、配額、金鑰、合規、SSO/SCIM、成本治理，這些進階功能整包準備好，能把你從「自建 3–6 個月」壓縮到「幾天到幾週上限」。

彈性靈活至上：抽象化加速實驗

這個流派的核心價值是標準化與相容性：用一套 API 換遍百家模型並且與多種類型工具無縫整合，讓研發可以快試快切、快速疊代。

LiteLLM：擁有最龐大的社群生態以及整合資源

LiteLLM 以開源 Proxy 與豐富適配聞名，支援 100+ 供應商；虛擬金鑰帶來精細預算/速率控制，也內建多種快取（含語義快取）。

• 技術核心：OpenAI 風格統一抽象、Virtual Keys、配額/速率、字串與語義快取、基本路由。
• 架構啟示：DX 友善、A/B 快速，特別適合模型試錯期與多後端並行。
• 選型提醒：極端吞吐/尾延遲不是主要目標；要搭配自家監控與壓測優化。

OpenRouter：託管式模型聚合

OpenRouter 是 SaaS 聚合器，一把金鑰接數百模型、免去自行維護審批與上/下線的痛。

• 技術核心：單一相容 API、供應商與地區路由、簡化金鑰與帳務。
• 架構啟示：PoC/新創可最快上線、先把價值驗證做起來。
• 選型提醒：長期要評估成本與資料政策；成長到一定規模多半會回到自託管 Gateway。

以開源的 LiteLLM 來說，其擁有多元的功能以及對各種主流 LLM 生態工具極大的整合度，有如 AI Gateway 界的「Grafana」。以 TypeScript 編寫的它不會是人們效能的第一考量，但簡易且無縫整合進現有 LLM 基礎設施的能力非常突出。

平台整合至上：雲端基礎設施的延伸

既然 AI Gateway 也是作為所有流量與請求的統一入口，那把 AI 流量當成既有平台（CDN、邊緣、API 中樞）的基礎設施供應商，自然能提出底層整合體驗最好的角覺方案，並且直接繼承其網路、分析與安全能力。

Cloudflare AI Gateway：邊緣網路的威力

Cloudflare 把全球邊緣快取、限流、重試/回退、分析打包成一鍵開啟的 Gateway；遇到完全相同請求可直接在最近節點命中，延遲與成本一起省。

• 技術核心：邊緣字串快取、動態路由、DDoS/速率、逐請求日誌與統計。
• 架構啟示：知識庫/FAQ 這類重複查詢場景收益極高；對 Workers/Pages 用戶幾乎零摩擦。
• 選型提醒：語義快取仍需自建/整合；複雜治理可與其他守門員方案搭配。

選擇 Cloudflare AI Gateway，與其說是選擇一個新工具，不如說是將你對現有平台的投資效益最大化。其核心競爭力源自其全球邊緣網路：在請求觸及昂貴的 LLM API 之前，就近利用快取終結它。這不僅為重複性查詢帶來了極致的成本與延遲優化，更讓你免費獲得了世界級的 DDoS 防護與流量管制能力。對於已經深度使用 Cloudflare 的團隊而言，這是在不增加架構複雜度的前提下，為 AI 應用加上「可靠性」與「成本護欄」的最短路徑。

技術深度對比：快取、路由與可觀測性

不同 Gateway 在「怎麼省錢、怎麼更穩、怎麼看得見」上，其實落差很大。有的只做最簡單的字串快取與固定配額，有的已經做到語義快取、以「成本/預算」作為路由條件，並把 Trace 送進 OpenTelemetry 生態。下面三個面向，最容易拉開差距。

快取策略的選擇

快取能同時降成本與延遲，但每個 AI Gateway 解決方案的實作深度大不同，快速的判斷可以從這兩點由淺到深，從「完全相同請求才命中」到「用向量相似度判斷語意相近也命中」。

• 精確匹配（Exact-Match / 字串快取）
  • 代表做法：Cloudflare AI Gateway 直接在邊緣節點快取相同請求，命中就不打到上游模型（典型用在 FAQ/重複查詢）。
  • 特性：性能極高、零語義風險；但「字面不同」就不會命中。
• 語義快取（Semantic Cache）
  • 代表做法：LiteLLM 在 Proxy/SDK 層支援Redis/Qdrant 等語義快取；透過嵌入與向量檢索命中相似查詢。
  • 取捨：要付出Embedding 與向量檢索的額外成本/延遲，且要管好閾值，不然會有答非所問的風險（Precision/Recall 取捨）。

路由與容錯（Fallback）的智能程度

就連路由與 Fallback 的功能也會需要特地了解是否足夠進接到滿足自己的需求，從「輪詢/配重」一路到延遲感知、成本/預算感知、百分比分流與自動回退，成熟度各家差很大。

• 靜態路由
  • 做法：權重、輪詢（Round-Robin）等固定策略，多數方案的基本方案。
• 動態路由（延遲/可靠度感知）
  • 代表：LangDB 提供延遲感知、腳本式、回退等多種動態路由，按速度/成本/可用性最佳化。
  • 代表：Cloudflare 的 Dynamic Routing 可用視覺化/JSON 編排條件、逾時/重試與回退。
• 成本/預算感知（預算感知）
  • 代表：Cloudflare 動態路由的 JSON 支援count-based 與 cost-based 限制節點，可把「預算/花費」納入路由與回退流程。
  • 代表：Portkey 與 LiteLLM 皆支援預算/速率限制（團隊/金鑰/用戶），常見做法是到額度就切換或阻擋。
• 容量感知（Rate-limit）
  • 代表：Cloudflare 內建速率限制與回退，常與動態路由搭配。

可觀測性的支援度

在 AI Gateway 中的 LLM 可觀測性，並不只是侷限於把 Request(prompt) / Response 內容當作 Log 儲存起來而已。進階的場景完全可以實現分散式追蹤（Trace），並且進一步與 OpenTelemetry 深度整合。

• 請求級日誌與分析
  • 代表：Cloudflare 提供逐請求日誌（模型、狀態、Token、成本、時長），並有分析面板（請求/Token/成本/快取/錯誤）。
• 分散式追蹤（Traces）與低耦合接入
  • 代表：LiteLLM 平台支援與 OpenTelemetry 可觀測性後端系統整合，可非同步的傳送 LLM 應用的日誌 / 指標 / 追蹤到現有系統中，避免把可觀測功能成為 Critical Path。
  • 代表：Portkey 也提供 OpenTelemetry 相容的觀測方案，方便與既有 APM 打通。
  • 延伸：整合 OpenTelemetry 的好處是能把資料直接匯到 Datadog、Grafana 等第三方，形成全鏈路視角。
• 治理向欄位與審計（Audit）
  • 代表：Kong 在使用 PII Sanitizer 時，審計日誌會增加 PII 偵測/脫敏的細節欄位（含處理耗時與類別）。

結語

目前在業界中 AI Gateway 的選擇沒有標準答案。但我們從以上介紹可以看得出來：LiteLLM 可能是最靈活的起點，Cloudflare 提供了最佳的快取性能，而 Kong 或 Portkey 則是企業級治理的基石。

聰明的架構師會將 AI Gateway 視為一個持續演進的控制平面，而非一次性的部署。選擇一個能與你的團隊持續進化的解決方案，才是長久之計。