2026 LLM Proxy 排名：四大方案比較

截至 2026 年 8 月 13 日，LiteLLM 官方文件已將代理伺服器定位為可統一接入 100+ 個 LLM 的 AI Gateway；這個資料點直接決定本週的選型方向：自托管平台先看 LiteLLM，編碼 Agent 與開放模型實驗看 Switchyard，想快速使用多供應商路由看 OpenRouter，需要路由、日誌、護欄與預算控制整合則看 Portkey。(docs.litellm.ai)

誰該看這篇：
如果你正在搭建統一模型入口、減少多供應商接入程式碼，或要替企業評估自托管、托管與混合 LLM Gateway，本文適合你。
如果你只想找一個聊天工具，這份排名不會是最高效的閱讀路徑。

最後更新於 2026 年 8 月 13 日；資料核實自 Switchyard、LiteLLM、OpenRouter 與 Portkey 的官方文件、公開儲存庫及部署文件。功能、政策或授權若有變化，排名應重新評估。

先按部署模式讀排名

本文不把四個工具硬塞進一張總分表。自托管代理與托管聚合服務的責任邊界不同，直接比較容易把「你要自行維護的成本」藏起來。

• 自托管平台排名：LiteLLM 第一。 適合要統一 API、虛擬金鑰、專案預算、負載平衡與回退策略的團隊。淘汰條件是你不願意維護資料庫、快取、監控與高可用。
• 編碼 Agent／本地模型排名：Switchyard 第一候選。 它特別適合需要在 Claude Code、Codex 或其他 Agent 與 vLLM、NVIDIA NIM、Ollama 及 OpenAI-compatible 端點之間轉換的團隊。淘汰條件是你需要成熟的多租戶帳務與企業級營運介面。
• 托管多供應商路由排名：OpenRouter 第一候選。 適合想快速接入供應商、使用排序與回退，而不想先部署 Gateway 的團隊。淘汰條件是所有請求都必須留在你自己的網路邊界內。
• 企業治理與可觀測性排名：Portkey 第一候選。 適合需要日誌、快取、護欄、預算、限流與條件路由的企業。淘汰條件是你只想要極簡、零託管依賴的本地代理。

這是按受眾的決策排名，不是吞吐量、延遲或市場份額排名。本文沒有使用未經核實的效能數字。

個人試驗與快速接入

個人開發者通常不應一開始就架設完整伺服器。你要先驗證模型選擇、提示詞和 API 相容性，再決定是否把代理層納入長期架構。

OpenRouter 的優勢是啟動快。你可以先使用統一 API，並在模型或供應商層設定排序、回退及資料政策篩選。官方文件指出，不同供應商有各自的保留及訓練政策，OpenRouter 會展示相關政策，但你仍要逐一閱讀實際供應商條款。(openrouter.ai)

LiteLLM 則把控制權放回你的環境。官方提供 Proxy Server 與 Python SDK 兩種模式，並列出鑑權、成本追蹤、限流、回退及可觀測性回呼等能力。(docs.litellm.ai)

如果你要在正式部署前確認遠端環境、權限和連線方式，可以先參考 VPSSpark 遠端環境使用說明，再決定把代理放在本機、雲端伺服器或混合網路中。

你的判斷可以很簡單：

1. 只做幾天模型試驗：先用 OpenRouter。
2. 需要保留 API 金鑰在自己的環境：部署 LiteLLM。
3. 需要追蹤每個專案的花費：不要只依賴供應商帳單，改用可記錄請求元資料的 Gateway。
4. 提示內容包含客戶資料、原始碼或個人資料：先確認資料是否會經過第三方路由，再決定是否托管。

編碼 Agent 與本地模型路徑

Switchyard 的定位不是「另一個通用帳務平台」。官方儲存庫將它描述為 Python LLM 流量代理，可在 OpenAI Chat、Anthropic Messages 與 OpenAI Responses 格式之間轉換，並把編碼 Agent 指向 vLLM、NVIDIA NIM、Ollama 或其他 OpenAI-compatible 端點。(github.com)

這對本地模型團隊的價值在於：Agent 不必因為後端換成開放模型，就重寫整套客戶端整合。你可以先用單一模型直通，再逐步加入路由設定、模型分流或分類器路由。

但要注意三個邊界：

• 協定相容不等於行為相容。 工具呼叫、串流事件、結構化輸出及上下文格式，仍需用你的 Agent 實際驗證。
• 本地端點仍有運維成本。 GPU、模型載入、併發、記憶體與升級都不會因為加上代理而消失。
• Switchyard 的成熟側重不同。 它更像是編碼 Agent 與模型端點之間的可程式化轉接層，不應直接當成 LiteLLM 的企業帳務替代品。

若你的主要問題是「讓多個團隊共用一個模型入口」，LiteLLM 通常更直接；若問題是「讓編碼 Agent 使用本地或開放模型」，Switchyard 更貼近需求。

自托管 LLM Gateway 的平台條件

自托管 LLM Gateway 應該選什麼，答案通常不是看支援多少模型，而是看你能否把它放進現有平台工程。

LiteLLM 的官方功能範圍包括統一 API、鑑權與授權、虛擬金鑰、專案或使用者層級的花費管理、負載平衡、回退，以及連接 Langfuse、MLflow 等觀測工具的回呼。(docs.litellm.ai)

你至少要預留以下運維工作：

• 資料庫： 儲存金鑰、團隊、使用量或配置時，資料庫本身要備份和限制權限。
• 快取： 若啟用回應快取，要定義哪些提示可快取，避免把敏感輸出長期留存。
• 監控： 只看 HTTP 200 不夠。你還要記錄供應商、模型、回退次數、Token、成本及錯誤類型。
• 高可用： 單一代理伺服器故障時，所有模型請求都會同時中斷。
• 升級與安全修補： 開源代理的便利性也代表你要建立版本、映像檔與漏洞修補流程。

因此，LiteLLM 的「第一名」只對有平台維護能力的團隊成立。沒有值班、備份和監控的單機部署，不能直接稱為生產級 Gateway。

托管路由與資料風險

OpenRouter 和 LiteLLM 的主要區別，不是模型名稱，而是流量責任歸屬。

OpenRouter 讓你把路由、供應商選擇與部分回退邏輯交給托管服務。官方資料顯示，它的供應商數量已達 70 多家，並支援按地理偏好與資料駐留要求處理路由。(openrouter.ai)

但「可選零資料保留」不代表所有上游都天然零保留。OpenRouter 官方說明指出，每個供應商有自己的資料處理政策；你要檢查模型頁、供應商條款及帳戶層級設定，而不是只看聚合平台的標籤。(openrouter.ai)

部署前請逐項確認：

1. 請求是否會被轉送到多個供應商。
2. 供應商是否保留提示與輸出。
3. 是否允許用於訓練、評估或改善模型。
4. 路由回退時，資料政策是否仍然符合你的要求。
5. 日誌是否包含完整提示、輸出、檔案或工具呼叫內容。

資料風險提醒： 企業合約、原始碼、客戶紀錄和個人資料，不應只根據「Zero Data Retention」字樣放行。你要把平台政策、上游供應商政策及實際請求日誌放在同一份審查表內。

企業治理與混合部署

Portkey 的價值在於把 Gateway 和治理功能放在同一個工作流。官方文件列出快取、回退、條件路由、自動重試、斷路器、負載平衡、限流、預算限制及護欄；其 Guardrails 也能依照結果拒絕請求、記錄結果、重試或回退到其他模型。(portkey.ai)

Portkey 是否適合統一管理多模型，取決於你要的是哪一種統一：

• 只要統一 API：LiteLLM 或 Portkey 開源 Gateway 都可能足夠。
• 要把日誌、護欄、成本和路由規則交給同一套管理介面：Portkey 更合適。
• 要求請求內容留在自己的 VPC：查看混合部署，而不是直接使用一般托管模式。
• 要完全自行控制控制面與資料面：Portkey 的開源 Gateway 可自托管，但企業托管功能與開源元件不能視為完全相同。

Portkey 的混合架構文件將 AI Gateway、快取與資料儲存放在客戶網路邊界內，控制面則負責管理配置、分析及非敏感元資料。這種模式較適合受監管團隊，但你仍要確認日誌欄位、密鑰流向和控制面依賴。(portkey.ai)

五步完成選型與驗收

1. 畫出資料路徑。 從應用程式、代理、快取、日誌到上游供應商逐段標記。
2. 建立模型別名。 不讓應用程式直接寫死供應商模型名稱，先用內部名稱隔離切換成本。
3. 測試三種錯誤。 模擬逾時、限流和供應商 5xx，確認回退不會重複扣款或改走不合規供應商。
4. 驗證鑑權與預算。 建立個人、專案和服務帳戶三種金鑰，確認權限、限額及撤銷流程。
5. 檢查日誌最小化。 比對成功、失敗、串流和工具呼叫日誌，刪除不必要的完整提示內容。
6. 做一次供應商切換演練。 在不修改應用程式程式碼的前提下，切換模型、API 金鑰和路由規則。
7. 設定淘汰門檻。 若一個方案不能滿足資料駐留、審計或回退要求，即使接入速度很快，也應退出候選名單。

結尾前的方案對照

下表是本文的選型工具。評分是依照部署模式、控制權、營運負擔與治理完整度作出的編輯評估，不是吞吐量或延遲實測。

從現有方案切換前的最後判斷

如果你現在直接讓每個程式各自連接 OpenAI、Anthropic、Gemini 或其他供應商，常見缺點是 API 格式分散、金鑰散落在不同程式庫、回退邏輯重複實作，而且很難按專案追蹤實際成本。若你把代理直接跑在開發者電腦上，還會多出連線不穩、休眠中斷、固定 IP 和權限隔離不足等問題。

這也是為什麼臨時測試、編碼 Agent 驗證或混合部署 PoC，不一定要先購買並長期維護一台實體 Mac。你可以先把測試環境、代理服務與客戶端隔離，再按需求使用 VPSSpark 的 Mac 租賃方案；若要確認可用的遠端環境與操作方式，可先查看 VPSSpark 支援中心。

若你的工作負載是長期穩定重負載、需要實體 USB／GPU 介面，或必須完全掌握硬體與資料位置，自購 Mac 或自建伺服器仍可能更合理。若只是短期算力、跨模型測試或驗證 LLM Gateway，先用租賃環境完成部署驗收，再決定是否投入固定硬體，通常更容易控制風險與前期成本。