LLM API 串接在 2024 年還是一段 fetch 就能解決的事。到了 2026 年中，多數正式服務已經面對截然不同的問題：哪個應用打哪家模型、誰花了多少額度、Anthropic 限流時要不要切到 Bedrock 的 Claude、新進工程師的 OpenAI 金鑰要不要直接配發。這些問題堆在一起會逼出一個明確結論——應用程式不應該再直接呼叫廠商端點，中間需要一層 AI Gateway。
LiteLLM 把這個類別從概念推成預設選項。從 2023 年一個 Python SDK 出發，到 2026 年已經支援超過一百家供應商，自架版本接管虛擬金鑰、成本追蹤、速率限制與多供應商容錯。但 Python 的 GIL 在高吞吐情境下會撞到上限。Bifrost 在 2025 年由 Maxim 團隊以 Apache 2.0 釋出，用 Go 重寫整套閘道，在 5K RPS 持續壓測下只多 11 微秒延遲，宣稱比 LiteLLM 快上五十倍。
AI Gateway 已經不是選配，而是基礎建設的一層
把 LLM 呼叫直接散落在各個服務裡會在三件事上出問題。第一是成本歸屬：CFO 拿到 Anthropic 月帳問哪個產品線吃了八成額度，沒有閘道就只能靠埋 log 拼湊。第二是供應商容錯：OpenAI 半夜當機，希望業務流程自動切到 Vertex AI 的 Gemini，沒有閘道就得讓每個應用各自實作 fallback 邏輯。第三是治理：給合約商一把 key、給內部工程師另一把、不同團隊的預算上限不同，原生 API 沒有這個概念。
這三個問題單獨解都不難，但要做到統一就需要一個中介層。AI Gateway 接管的就是這層——它對外提供 OpenAI 相容的 endpoint，對內把流量分派、計費、稽核、容錯抽象成可組態的策略。當 2025 年中型團隊普遍導入這套設計之後，這個類別就從「可選工具」變成「跟 reverse proxy 同等地位的基礎元件」。
LiteLLM 把生態系拉起來，也撞到了 Python 的天花板
LiteLLM 之所以變成主流，是因為它把所有廠商的請求格式統一成 OpenAI Chat Completions。一個 Anthropic、一個 Bedrock、一個 Vertex AI，原生 SDK 的參數、串流格式、錯誤碼全部不同；LiteLLM 在中間做翻譯，下游應用只需要假設自己在打 OpenAI。Proxy 模式進一步把這層搬進獨立程序，搭配 Postgres 做虛擬金鑰、預算、稽核日誌，自架版本可以撐起整個公司的 LLM 流量分發。
問題出在它是 Python。GIL 讓單一程序的請求處理被序列化，正式環境想吃滿一台 8 核心機器就得開八個 process 在 load balancer 後面排隊。社群實測在 1K RPS 以上的壓力下，LiteLLM 大約會額外加上 40 毫秒的閘道延遲——對於需要等模型回應的同步請求或許不痛，但對於 agent 場景一次工作流要打十幾次 LLM 的情境，這個延遲會累加成可觀的尾延遲。
更實際的限制是部署複雜度。LiteLLM 在正式環境通常需要 Postgres 存設定、Redis 做快取、Prometheus 收 metric，外加 N 個 worker process。對於只想跑一台 VPS 處理幾百 QPS 的中型團隊，這套堆疊偏厚。
Bifrost 換了一條路徑：Go、零外部依賴、Plugin 化
Bifrost 沒有試圖比 LiteLLM 多支援哪一家廠商，而是把 Gateway 這層重新設計。整個服務用 Go 寫成單一 binary，預設不需要外接資料庫，啟動之後直接吃進設定檔或透過 Web UI 動態調整。把 LiteLLM 那套「Postgres + Redis + 多 worker」的編排簡化成一支執行檔，是它最直接的賣點。
架構分成幾個明確的層：核心提供供應商抽象與請求/回應 schema、Transport 層處理 HTTP 與 WebSocket、Plugin 系統用來掛載治理、快取、稽核、可觀測性。語義快取、MCP Gateway、預算控制、OIDC 登入全部都是 first-class plugin，可以選擇開啟或拔掉。
效能數字是它最被引用的點。在 5,000 RPS 的持續壓測下，Bifrost 的閘道層平均只額外增加 11 微秒延遲，記憶體佔用比 LiteLLM 對等配置少約六成八。這不是寫死的 mock，而是把請求實際轉發到 OpenAI、Anthropic 之後扣掉上游時間量出來的結果。對應的具體場景是：一個 agent 工作流要連續打八次 LLM，閘道本身只貢獻不到一毫秒的累積延遲。
不過效能數字向來要保留懷疑空間。50x 是廠商自己提出的對比，社群獨立實測差距更接近 30 到 40 倍，且只有在高並發下才會明顯。如果服務全天 QPS 不到一百，Bifrost 對比 LiteLLM 的差異主要不在速度，而在維運的單純程度。
語義快取與 MCP Gateway 才是真正省錢的兩個閥門
LLM 帳單最大的洩漏點不是延遲，是「同樣意思的問題被問了第二次」。語義快取的概念是用向量相似度去判斷新請求跟某個快取項目語意接近，直接回傳之前的回應。Bifrost 內建這套機制，支援 Valkey、Qdrant、Weaviate、Pinecone 作為向量儲存後端。實測 cache hit 大約在 5 毫秒回應，cache miss 含 embedding 計算約 60 毫秒。
這套機制在文件問答、客服 bot、agent 工具呼叫情境下命中率特別高。一個典型的內部知識庫機器人，員工 70% 的問題會集中在前 50 種意圖上，啟用語義快取之後 token 用量可以直接腰斬。LiteLLM 也有快取，但只做精確雜湊比對，要求字串完全一樣才命中，實務上能省下的 token 有限。
MCP Gateway 則是另一個 2025 下半年才浮上來的需求。當 agent 開始大量呼叫外部工具，每個請求都要把所有可用工具的 schema 塞進 prompt，光是「告訴模型有哪些 tool 可以用」就吃掉幾千個 token。Bifrost 的 MCP Gateway 接管 STDIO、HTTP、SSE 三種傳輸協定的 MCP server，做 tool filtering，每次請求只把當下相關的工具 schema 傳給模型。社群測得在多 MCP server 的 agent 工作流下，token 消耗可以再砍掉約一半。
語義快取省的是重複問題的錢，MCP Gateway 省的是工具描述的錢。兩者疊加是中型團隊把 LLM 月帳壓進預算的主要手段。
在 VPS 上自架的實務細節
Bifrost 的部署在小規模情境簡單到接近 trivial。一台 2 vCPU、4 GB RAM 的 VPS 就能撐住每秒一兩百個請求。最直接的方式是 Docker：
1 | docker run -d --name bifrost \ |
這裡刻意只把 port 綁到 127.0.0.1，不要直接寫 -p 8080:8080——Docker 會繞過 UFW 直接打開公網的 8080，等於把含金鑰的管理 UI 裸奔在 Internet 上。啟動之後透過 SSH tunnel 或反向代理連到 127.0.0.1:8080 就會看到管理 UI，廠商金鑰、虛擬金鑰、預算、限流規則都從 Web UI 設定，落地存進 SQLite，重啟不會掉。要做語義快取的場景再多開一個 Valkey 或 Qdrant 容器即可。
正式環境前面再擺一層 Caddy 或 Nginx 接 TLS，公開的部分只暴露 /v1/chat/completions 這類 OpenAI 相容路徑，管理 UI 用 Basic Auth 或 OIDC 擋掉，或乾脆只開放從內網存取。日誌量在高流量下會迅速膨脹，內建的 Plugin 可以把詳細請求/回應內容轉發到外部物件儲存或 ClickHouse，避免本機磁碟塞爆。
如果整個機房在臺灣、目標讀者也在亞太，Gateway 跟使用者放同區可以省下大約 100 到 200 毫秒的往返時間，這段延遲在 agent 工作流的尾延遲上會被放大很多倍。
什麼時候不該換到 Bifrost
LiteLLM 在兩個情境下仍然是更務實的選擇。一是已經在用 LiteLLM 的 Python SDK 直接 import 進應用程式碼當函式庫使用——那個場景不需要獨立閘道，Bifrost 也沒打算提供等價的 Python SDK。二是依賴 LiteLLM 某個特定 plugin 或廠商整合，例如某個冷門地區的本地 LLM 服務商，LiteLLM 多年累積的廠商覆蓋目前仍領先。
效能數字也要看真實負載決定價值。QPS 在 50 以下的小團隊，Python 的天花板根本碰不到，這時候挑 LiteLLM 還是 Bifrost 比的是維運偏好，不是速度。Bifrost 的優勢真正會體現在 agent 工作流、批次推論、企業內部多應用共享閘道的中高並發場景。
結論
AI Gateway 從可選工具變成中型團隊基礎建設的一層，已經是 2026 年的既定事實。LiteLLM 撐起了這個類別的早期，並把 OpenAI 相容介面變成行業預設；Bifrost 把效能瓶頸打開、用 Go 簡化部署、把語義快取與 MCP Gateway 做成內建。對於正在規劃自架 AI Gateway、或從 LiteLLM 評估升級的團隊，Bifrost 在 2026 年的版本已經穩定到可以投入正式環境。
把 AI Gateway 放在臺灣本地有兩個現實好處：使用者到閘道之間少 100 到 200 毫秒的延遲、流量不必繞出國跨海。NCSE Network 在臺灣是方電訊機房提供配備 Intel Gold CPU 與 NVMe SSD 的 VPS 主機，搭配充足的對外頻寬，適合作為自架 AI Gateway 的落腳點。需要把 LLM 流量收回自己手裡的團隊，可以參考 NCSE Network 的 VPS 方案。
