Switchyard vs LiteLLM vs Portkey：2026 最好的 AI Gateway 對比

編碼 Agent 已經要同時連接多個模型，但每個供應商的 API、工具呼叫格式和錯誤行為都不一致，直接在應用程式內逐一維護通常會很快失控。

最快解法：AI Gateway 對比 2026 的選型不應只看模型數量；編碼 Agent 的本地代理與階段路由先評估 Switchyard，廣泛供應商相容與成熟代理功能先評估 LiteLLM，重視託管控制台、可觀測性和治理工作流的團隊則可評估 Portkey。

這篇適合需要統一模型 API 的 AI 應用團隊、正在治理模型憑證與使用記錄的平台工程師，以及希望為 Claude Code 等工具設定模型路由的開發團隊。若目前只呼叫單一模型、沒有回退或權限需求，暫時不必急著加入網關層。

注意：本文以 2026 年 8 月 14 日為核對日期，功能邊界逐項對照三款產品的官方儲存庫與文件；開源版本、雲端服務及企業功能必須分開判斷，不能把不同版本的能力放在同一列比較。

先用指標軸定位三款網關

三款產品的重點並不相同。Switchyard 更接近面向編碼 Agent 的本地代理與路由框架；LiteLLM 是覆蓋廣泛模型供應商的 LLM Proxy 與平台元件；Portkey 則把 Gateway、路由設定、追蹤和治理工作流結合起來。這不是單純的「誰功能最多」問題，而是要先確認團隊真正需要哪一層。

決策指標	Switchyard	LiteLLM	Portkey
主要定位	編碼 Agent 本地代理、協議轉換與可組合路由	多供應商統一 API、Proxy Server 與模型管理	Gateway、託管控制台、觀測與治理工作流
客戶端接入	支援 OpenAI Chat、Anthropic Messages 與 OpenAI Responses 轉換，並提供 Claude、Codex 等啟動器	Proxy Server 與 Python SDK；以統一格式接入多個模型	REST、SDK 與統一 API；透過 Gateway Config 管理策略
路由重點	隨機路由、分類器路由、階段路由及自訂路由	重試、回退、負載平衡、成本與部署群組	回退、條件路由、負載平衡、重試、斷路器與 Canary
管理能力	偏向本地配置與請求統計	虛擬金鑰、團隊權限、支出和速率控制	控制台、追蹤、請求記錄、治理與企業工作流
自託管判斷	適合希望把代理放在開發機或隔離環境的團隊	適合願意維護中央 Proxy Server 的平台團隊	可自託管 Gateway，但雲端與企業能力需另行核對

Switchyard 官方儲存庫明確列出 OpenAI Chat、Anthropic Messages 及 OpenAI Responses 的轉換能力，並示範以 switchyard launch claude 啟動本地代理；這使它在 Claude Code 類編碼工作流中具有較清楚的切入點。Switchyard 官方 GitHub 儲存庫

LiteLLM 官方文件則將 Proxy Server 定位為中央 LLM Gateway，列出虛擬金鑰、團隊支出管理、速率限制、日誌掛鉤及多供應商整合；文件目前宣稱可透過 OpenAI 輸入與輸出格式連接 100+ 個 LLM，這類動態數字應在部署前重新核對。LiteLLM 官方入門文件

Portkey 的官方 Gateway 文件列出統一 API、回退、條件路由、快取、負載平衡、斷路器、預算限制與速率限制等能力，官方開源儲存庫則將其描述為可連接 1,600+ 個 LLM 的 Gateway；這是官方產品說明，不代表每個模型在所有版本、所有參數和所有工具呼叫模式下都具備完全相同的相容性。Portkey AI Gateway 官方文件 Portkey Gateway 官方儲存庫

再查協議與模型後端

客戶端與協議

基礎聊天請求能通，不等於網關適合生產環境。平台工程師至少要驗證四個邊界：

• 工具呼叫是否能完整保留名稱、參數、呼叫結果及多輪順序。
• 串流回應中斷後，網關是否能正確回報錯誤，而不是把半段內容誤判為成功。
• 結構化輸出、JSON Schema 或提供商專用欄位是否會在轉換時被刪除。
• Anthropic、OpenAI 及本地推理後端的系統訊息、停止條件和使用量欄位是否能被一致記錄。

Switchyard 的優勢在於它把協議轉換放在本地代理層，對需要保留原生編碼 Agent 使用方式的團隊較直觀。LiteLLM 的優勢是應用程式可以維持統一呼叫格式，再由 SDK 或 Proxy 處理不同後端。Portkey 則適合希望把接入、路由配置和追蹤放在較集中控制平面的團隊。

模型與後端

模型覆蓋應拆成三組檢查：託管模型、私有端點，以及本地推理後端。

Switchyard 官方文件示範可把請求送往 vLLM、NVIDIA NIM、Ollama 或 OpenAI 相容端點，因此適合需要在編碼 Agent 與自有推理服務之間切換的環境。LiteLLM 文件列出 OpenAI、Anthropic、Azure、Vertex AI、Ollama、Hugging Face 等整合，但實際支援清單及參數仍應以版本化文件為準。Portkey 同時提供 Gateway 與雲端服務，但某項模型整合是否屬於開源 Gateway、託管服務或企業層能力，必須逐項確認，不能只看總模型數。

經驗：模型名稱能被接受，只能證明路由入口認得這個名稱；要確認真正可用，還需要測試工具呼叫、串流、結構化輸出、上下文長度錯誤及供應商專用欄位。

接著驗證路由、回退與可靠性

AI Gateway 如何實現模型回退和路由，關鍵不在於配置檔案是否漂亮，而在於「什麼錯誤可以回退」以及「回退後的結果是否仍然合格」。

Switchyard 的路由方向較適合編碼 Agent 階段化處理，例如先用較快的模型完成分類，再把複雜任務升級到較強模型；官方儲存庫同時列出隨機路由、LLM 分類器路由、訊號驅動階段路由及自訂路由。這類策略需要真實任務集驗證，因為分類器誤判可能令簡單任務被升級，也可能讓複雜程式修改落到不適合的後端。

LiteLLM 的 Router 重點是部署群組、重試、回退、負載平衡和成本追蹤，適合平台團隊把多個供應商端點整理成一致入口。Portkey 則把回退策略配置化，官方文件示範可按狀態碼觸發回退，並在追蹤中查看同一請求的多次嘗試。Portkey 回退文件

驗收時應特別區分以下情況：

• 429 限流：通常可切換金鑰或供應商，但要避免瞬間重試造成更大壓力。
• 5xx 錯誤：可考慮回退，但要記錄主要後端失敗原因。
• 逾時：應設定明確上限；否則多層重試可能令單一請求等待過久。
• 串流中途失敗：不能簡單重送，尤其當工具已經執行部分動作時。
• 答案品質下降：HTTP 成功不代表任務成功，程式編譯、測試和結構化輸出都應納入驗收。

然後拆開憑證、預算與治理

LiteLLM 的平台價值不只在模型轉換，也在 Proxy Server 的管理層：官方文件列出虛擬金鑰、專案或使用者支出追蹤、預算及速率限制等能力。這對多個團隊共用模型供應商金鑰尤其重要，因為應用程式不必直接持有所有上游憑證。LiteLLM Proxy Server 文件

Portkey 的治理重點更偏向控制台與工作流，例如把模型、提供商、路由設定、日誌和追蹤集中管理；但評估時要分開記錄「開源 Gateway 可做到什麼」和「託管或企業服務額外提供什麼」。若團隊要求單一租戶隔離、審批流程、長期日誌保留或企業身份整合，不應只根據開源儲存庫下結論。

Switchyard 則更偏向本地配置和請求統計，適合個人開發機、隔離測試環境或希望自行掌握路由程式碼的團隊；若需要跨團隊的虛擬憑證、預算封頂和集中權限，通常要在它外部補上治理層。

最後檢查日誌與自託管負擔

可觀測性至少要回答五個問題：哪個客戶端發出請求、網關為何選擇該模型、使用了多少 Token、延遲花在哪裡，以及回退是否真的改善結果。

Portkey 官方追蹤文件說明，重試和回退請求可以被放在同一個 Trace 中，並按時間順序查看失敗與成功嘗試；官方文件同時列出不同服務層的日誌量與保留週期，因此生產採用前應重新核對當日方案。Portkey Tracing 官方文件

LiteLLM 可透過 Proxy 的日誌掛鉤、支出追蹤和外部可觀測性整合建立平台記錄。Switchyard 則提供每次請求的延遲、Token 和成本統計，但平台團隊仍需要自行決定資料脫敏、保留週期、存取權限及告警方式。

自託管比較不能根據「Python、TypeScript 或其他語言」推測效能。實際成本來自安裝依賴、環境變數管理、TLS、反向代理、日誌儲存、升級回滾、供應商金鑰輪換和故障演練。可先參考本站的控制中心使用說明，把隔離環境、憑證交付與部署責任列成驗收項目，而不是先把流量全部切過去。

三類團隊的選擇路徑

個人編碼 Agent

若主要目標是讓 Claude Code 或相近工具快速切換模型，並且希望本地代理能接入私有或本地推理端點，優先評估 Switchyard。驗收重點是工具呼叫、串流、上下文傳遞及階段路由，而不是單純完成一次聊天。

若個人開發者同時管理多組供應商金鑰，或需要記錄每個專案的支出，LiteLLM 會更有吸引力。Portkey 則適合本來就希望使用託管控制台、追蹤與回退配置的工作流。

快速成長的 AI 應用

當應用從一個服務增加到多個服務，模型憑證、配額、錯誤回退和成本歸屬會比單次延遲更快成為問題。此時 LiteLLM 通常是較穩妥的第一個評估對象，因為它把模型供應商整合與 Proxy 管理放在同一層。

如果團隊不希望自行拼接日誌、追蹤、路由設定和治理流程，可同步評估 Portkey；但要先決定哪些資料可以離開自有環境，以及託管控制台與開源 Gateway 的功能差異是否可接受。

企業平台團隊

企業團隊不應只問「哪個網關支援最多模型」，而應在真實客戶端、真實後端和故障注入條件下完成驗收。至少要測試：

• OpenAI 相容請求與 Anthropic Messages 請求。
• 工具呼叫、串流和結構化輸出。
• 429、503、逾時及串流中斷。
• 主要後端失敗時的回退順序。
• 日誌是否遮蔽提示詞、金鑰及個人資料。
• 升級後能否回滾到已驗證版本。
• 團隊、專案和服務帳戶是否能分開計算支出。

若上述檢查尚未完成，三款產品都不應直接承擔全部生產流量。建議先以小比例流量做影子測試，再比較成功率、回退後品質、完整延遲和每個任務的實際成本。

FAQ：選型時最容易混淆的五個判斷

這五個問題適合在試用前逐一回答。若團隊無法說明失敗條件、日誌責任和版本邊界，先補齊驗收文件，通常比立即更換網關更有效。

結尾決策與部署出口

對個人編碼 Agent 而言，Switchyard 的本地代理與階段路由是最直接的切入點；對需要廣泛模型供應商、虛擬憑證和支出治理的平台，LiteLLM 更值得優先評估；對希望把託管控制台、回退、追蹤和治理工作流集中起來的團隊，Portkey 具有較完整的管理方向。

如果目前方案是每個程式直接保存供應商金鑰，常見缺點是憑證散落、回退邏輯重複，以及很難追查一次 Agent 任務究竟用了哪些模型。若把網關長期固定在某一台開發機上，又會遇到離線、權限、升級回滾和團隊共用問題；直接使用一般雲端主機則還要自行處理隔離、日誌保留和故障驗收。對需要臨時算力、隔離測試環境或短期自託管網關的團隊，租用 nuvcloud 的 Mac 環境可以先把開發機與網關部署分開，再按照實際週期決定是否長期保留。正式遷移前，可先查看支援與使用指南，確認憑證交付、環境隔離和故障測試流程是否符合團隊要求。

最後更新於 2026 年 8 月 14 日；資料核實自 Switchyard、LiteLLM 與 Portkey 官方儲存庫、功能文件、安裝文件、授權資訊及發布記錄。