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

结论先行：如果重点是为 Claude Code 等编码 Agent 接入本地模型，并使用阶段路由，优先评估 Switchyard；如果需要广泛的模型提供商兼容、统一 API、重试与回退，优先评估 LiteLLM；如果团队更看重托管控制台、可观测性和治理工作流，则应评估 Portkey。这不是“谁性能最高”的排名，而是按真实客户端、后端和运维责任来选择网关。

谁适合阅读这篇对比

这篇内容适合需要为多个模型提供统一 API 的 AI 应用团队，也适合正在治理模型凭证、回退策略和使用记录的平台工程师。

如果开发团队希望为 Claude Code 等工具配置模型路由，或者准备在本地推理、云端模型和私有端点之间切换，下面的指标拆解会比单看支持模型数量更有参考价值。

最后更新于 2026 年 8 月 14 日。本文根据三款产品截至该日期的官方仓库、官方文档、许可证说明、安装文档和发布记录核对；开源版、托管服务和企业功能没有混写。

先按协议兼容性筛掉不合适的方案

AI Gateway 对比 2026 的第一项，不应只是确认“能不能发送聊天请求”，而要验证编码 Agent 实际会用到的请求格式、流式响应、工具调用、结构化输出和提供商扩展字段。

Switchyard 的定位更接近面向 LLM 流量的 Python 代理。官方仓库明确提到，它可以在 OpenAI Chat、Anthropic Messages 和 OpenAI Responses 格式之间进行转换，并将请求转发到 vLLM、NVIDIA NIM、Ollama 或其他 OpenAI 兼容端点。对于 Claude Code 这类已经固定客户端协议的工具，这种“客户端保持原协议、网关负责转换”的方式更直接。可参考 Switchyard 官方仓库中的协议与路由说明。

LiteLLM 的核心优势是统一接口和较宽的提供商接入范围。官方文档列出了 Chat Completions、Responses、Embeddings、Images、Audio、Batches 等接口形态，并说明其代理服务可以用统一输入输出格式访问 100+ 个模型。需要注意的是，基础请求成功并不等于工具调用、流式事件和结构化输出在所有后端上都完全一致，生产验收必须逐项测试。可参考 LiteLLM 官方入门文档。

Portkey 也提供统一 API、SDK 与网关配置，但其重点更偏向把请求路由、重试、缓存、Guardrails、日志和治理控制放在同一个平台中。对于只想给编码 Agent 找一个轻量协议代理的团队，这套能力可能显得偏重；对于已经存在多团队、多环境和审计要求的组织，则更有价值。可参考 Portkey AI Gateway 官方文档。

再比较模型与后端覆盖范围

三款网关的“模型覆盖”不能简单按网页上的模型数量排序，因为真正影响选型的是后端接入方式和长期维护边界。

• Switchyard：适合把编码 Agent 请求转向本地或私有推理后端，尤其适合需要 OpenAI 与 Anthropic 协议转换、单模型直通、配置文件路由或阶段式升级的场景。它的重点不是建立一个覆盖所有云模型的目录，而是让 Agent 流量可以进入指定的模型和推理服务。
• LiteLLM：适合同时连接多家托管模型、云平台部署和本地推理后端。其官方文档提供 Python SDK 与 Proxy Server 两条接入路径，并将模型名称、凭证和后端参数集中到配置中。平台团队需要确认具体模型是否由当前版本官方适配，而不是把社区示例当成长期维护承诺。
• Portkey：适合把托管模型、私有端点和本地模型统一放进一个治理控制面。其官方资料列出多种主流模型提供商、私有模型和本地部署接入方式，但托管能力、企业部署能力与开源 Gateway 的边界必须分开核对。

如果团队优先考虑自托管，判断重点应放在三个问题：网关本身是否能稳定运行，凭证和日志是否能安全维护，以及团队是否有能力长期处理升级、回滚和后端兼容问题。只想在一台开发机或内部服务器上转发编码 Agent，请先看 Switchyard 与 LiteLLM；希望拥有团队级控制台和策略管理，则需要单独评估 Portkey 的托管或企业方案。

路由、回退与可靠性要按故障类型验收

模型回退和路由通常可以拆成三层：

1. 静态路由：按模型名称、环境变量或配置文件，将请求固定转发到某个后端。
2. 可靠性路由：当出现超时、限流、认证失败或上游服务错误时，执行重试、备用模型或备用密钥。
3. 条件或阶段路由：根据请求元数据、任务阶段、分类结果、用户等级或内容类型选择不同后端。

Switchyard 的特点是路由逻辑更贴近编码 Agent。官方仓库说明其启动器可以使用内置分类路由，也可以通过弱模型、分类模型、配置文件和置信度参数调节阶段路由；同时支持单模型直通。对于“简单任务用便宜或本地模型，复杂任务再升级”的工作流，这种显式路由更容易理解和调试。

LiteLLM 的 Router 提供多部署重试、回退、负载均衡和成本跟踪能力。官方文档明确将多个部署组织成模型组，并在调用失败后执行回退。它更适合平台团队建立统一的提供商级冗余，但需要明确哪些错误允许回退：限流和暂时性网络错误通常可以重试，认证错误、参数不兼容和工具调用格式错误则不应无限重试。

Portkey 的 Gateway Configs 覆盖 fallback、load balancing、conditional routing、自动重试、超时和熔断等策略；其条件路由可以根据请求中的元数据选择不同目标，负载均衡也可以按目标权重分配请求。相关能力可参考 Portkey 条件路由文档 与 Portkey 负载均衡文档。

如果开发团队正在设计回退链，建议先建立错误分类表，而不是直接堆叠备用模型：

• ✅ 遇到限流、短暂网络异常或上游超时，可设置有限次数的重试和备用部署。
• ✅ 遇到某个模型暂时不可用，可回退到同等能力、相同输出协议的模型。
• ⚠️ 遇到工具参数不兼容、结构化输出失败或上下文长度不足，应优先修正请求或更换兼容后端。
• ❌ 不要把所有 4xx 错误都交给回退策略，否则会掩盖凭证、参数和权限配置问题。

这里最容易踩坑的是：路由层“成功返回”不代表结果质量合格。切换模型后，工具参数格式、上下文长度、代码修改风格和结构化输出都可能变化，因此高级路由必须结合真实任务集和结果评测，而不能只看错误率。

凭证、预算与访问治理需要拆开版本判断

三款产品都能减少应用代码直接保存上游密钥的情况，但实现深度不同。

• Switchyard：更适合作为本地或内部流量代理使用。其优势在于让编码 Agent 面对统一入口，并将模型和后端选择放进启动参数或路由配置。若需要复杂的团队角色、虚拟密钥、预算审批和审计留痕，平台团队还要补充外围权限系统。
• LiteLLM：官方文档将 Proxy Server 定位为集中式网关，提供认证授权、虚拟访问凭证、项目级成本跟踪、预算、限流和管理界面。开源能力与企业能力不能混成一行，尤其是 SSO、审计、支持服务和组织级治理，需要以当前版本说明为准。可参考 LiteLLM Proxy Server 功能说明。
• Portkey：更强调控制台、工作区、团队治理、预算、速率限制和策略配置。其托管平台适合不希望自行维护完整控制面的团队；若采用开源 Gateway 或私有部署，则应逐项确认哪些治理功能仍然可用。可参考 Portkey 官方开源 Gateway 仓库。

预算控制也不能只看“是否支持限额”。平台工程师还应检查成本是按项目、用户、API Key 还是模型维度归属，是否能区分重试请求，是否能在日志中看到实际路由目标，以及密钥轮换时旧凭证能否立即失效。

日志与可观测性决定生产排障速度

开发环境里，看到请求成功就够了；生产环境里，至少需要记录请求 ID、路由原因、目标模型、上游响应状态、延迟、输入输出令牌、重试次数和最终错误。

LiteLLM 官方文档提供回调式可观测性，并支持把日志发送到多个外部追踪系统；这意味着接入灵活，但平台团队需要自行决定日志系统、脱敏方式、保留周期和访问权限。Portkey 则把日志、追踪、成本、错误模式和治理能力作为平台产品的一部分，更适合希望减少自行拼装工作的团队。Switchyard 的流量代理和使用统计更适合轻量化、可控的内部部署，但不应在没有实测的情况下推断其具备与托管控制台相同的审计深度。

无论选择哪款方案，都建议在上线前勾选：

• ✅ 是否能区分首次请求、重试请求和回退请求；
• ✅ 是否记录实际命中的模型与提供商；
• ✅ 是否能对 Prompt、工具参数和输出进行脱敏；
• ✅ 是否能设置日志保留周期与访问角色；
• ✅ 是否能把错误关联到具体客户端、项目和部署版本；
• ❌ 不要只凭一个漂亮的仪表盘判断可观测性是否足够。

按自托管复杂度决定长期成本

自托管的成本不只包括服务器资源，还包括配置管理、密钥保护、升级回滚、健康检查、日志存储和故障值班。

Switchyard 的部署思路相对聚焦：作为 Python 代理运行，配置路由文件、模型参数和后端地址即可开始验证。它适合个人编码 Agent、实验环境和需要快速控制流量方向的开发团队，但生产使用前仍需补齐进程守护、TLS、权限隔离和日志留存。

LiteLLM 的 Proxy Server 适合平台化部署，官方资料提供 CLI、容器和配置文件路径。它的接入范围更广，因此配置项、提供商差异和版本升级验证也可能更多。若团队没有专门的平台维护人，应该先用少量模型和单一客户端做灰度，而不是一次性接入全部后端。

Portkey 的托管模式可以减少网关本身的运维工作，但控制面、数据流向、企业部署边界和费用模型需要在采购前确认；开源 Gateway 的本地运行方式不能自动等同于完整托管平台。

用这份验收清单做最终选择

在真实流量切换前，建议按下面 5 步执行：

1. 固定客户端：先选定 Claude Code、内部 SDK 或现有 Agent，不要只用简单的 Curl 请求。
2. 固定后端：至少准备一个云端模型、一个 OpenAI 兼容端点和一个本地或私有推理后端。
3. 验证协议：分别测试流式输出、工具调用、结构化输出、长上下文和提供商扩展字段。
4. 注入故障：模拟超时、限流、错误密钥、空响应、格式错误和模型不可用，确认回退是否符合预期。
5. 检查日志：核对路由原因、令牌记录、延迟、重试次数、敏感信息脱敏和预算归属，再决定是否接入生产流量。

最终可以这样判断：

• 个人编码 Agent：优先评估 Switchyard；若需要大量云模型、虚拟密钥和集中成本统计，再评估 LiteLLM。
• 快速增长的 AI 应用：优先评估 LiteLLM 与 Portkey，重点比较模型接入速度、回退稳定性、日志治理和团队权限。
• 企业平台团队：优先评估 Portkey 的托管或企业能力，同时把私有部署、审计、数据驻留和故障响应写进验收条件。
• 自托管优先且团队规模较小：Switchyard 更适合快速搭建编码 Agent 路由；LiteLLM 更适合逐步扩展为多团队统一网关。

当前方案与 Mac 方案的取舍

如果团队现在把网关部署在个人 Windows 电脑、临时云主机或共享开发环境上，常见问题是运行环境不一致、后台进程容易中断、密钥和日志权限难以隔离；当还要同时运行本地模型、容器、编码 Agent 和测试服务时，资源争用也会让故障定位变得更困难。

对于需要临时搭建隔离开发环境、验证自托管网关或进行故障注入测试的团队，租赁 nuvcloud 的 Mac 环境可以减少本地设备差异，并把测试环境与日常办公设备分开。若团队需要长期稳定重负载推理、特殊 GPU、物理接口或完全掌控硬件，直接购买并维护自己的设备可能更合适；若只是进行阶段性验证，可以先查看 nuvcloud 的 Mac 方案，再结合 控制中心 和 帮助文档 确认凭证交付、远程访问与故障验收方式。