Portkey gateway：一个把 1600 多个模型收敛成单一 OpenAI 接口的路由层
A blazing fast AI Gateway with integrated guardrails. Route to 1,600+ LLMs, 50+ AI Guardrails with 1 fast & friendly API.
秒懂
- 它是什么？
- Portkey gateway 是一个 TypeScript 写的 AI 网关，用 OpenAI 兼容接口把 1600 多个模型和 50 多种护栏收拢到一个本地服务里。它解决的是多供应商接入和故障转移问题，但自带护栏的用法和它的商业版边界需要先看清楚。
- 适合谁用？
- 适合已经受困于多家模型供应商 API 差异、需要统一入口和自动重试回退的团队。它把路由、重试、负载均衡和基础输出护栏打包成一个 OpenAI 兼容服务，本地用 npx 就能起，接入成本低。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 113 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是 API 碎片化，不是模型质量问题
做 AI 应用的人迟早要面对同一个问题：OpenAI、Anthropic、Bedrock、Groq 各有各的请求格式、鉴权方式和限流策略。Portkey gateway 把这一层差异吞掉，对外只暴露一个 OpenAI 兼容的 /v1 接口。它的定位不是帮你选更好的模型，而是让你换模型时不改业务代码。README 里给出的核心数字是 1600 多个语言、视觉、音频和图像模型，以及 50 多种 AI 护栏。目标用户很明确：那些在多个供应商之间切换、需要统一日志和故障转移能力的工程团队，而不是只调一家 API 的个人开发者。
本地启动只需一条 npx 命令，但依赖 Node.js
最快的方式是执行 npx @portkey-ai/gateway，然后服务就跑在 http://localhost:8787/v1 上。同端口还有个 /public/ 路径，是本地日志控制台。README 明确写了需要 Node.js 和 npm，所以这不是一个免依赖的二进制。除了本地运行，文档里还列了 Docker、Cloudflare Workers、Replit 和 AWS EC2 的部署方式，其中 EC2 有现成的 CloudFormation 模板。对只想快速试一下的人，npx 那条路最直接。但要注意，npx 拉的是 npm 包，版本跟随发布节奏，如果你要固定版本做生产部署，应该用 Docker 镜像或直接锁 package.json 里的版本号。
请求怎么走：从 OpenAI 兼容客户端到任意供应商
用法上最讨巧的一点是它兼容 OpenAI SDK。README 里的 Python 例子先用 portkey_ai 的 Portkey 客户端，指定 provider 为 openai 或 anthropic、bedrock、groq 等，再传那个供应商的 API key。之后调 client.chat.completions.create 时，模型名直接写 gpt-4o-mini 这种目标模型。也就是说，你已有的 OpenAI 调用代码，换掉 base_url 指向本地网关，再在客户端里声明 provider 和 key，就能转发到别家。网关内部处理协议转换、鉴权透传和响应格式化。它支持的语言库覆盖 JS、Python、REST、LangChain、LlamaIndex、Autogen、CrewAI，覆盖面在同类项目里算宽的。
config 是核心机制：重试、回退和护栏都靠它
路由规则不是散落在代码里的，而是集中在一个叫 config 的字典里。README 给的例子很短：retry 设 attempts 为 5，output_guardrails 里用 default.contains 检查输出是否包含 Apple，operator 为 none 表示不允许出现，deny 为 True 表示拒绝。把这个 config 用 client.with_options(config=config) 挂上，之后每次请求都会先过护栏，输出不合格就触发重试。这个设计把可靠性策略从业务逻辑里抽出来了，好处是策略可以跟着配置走，坏处是 config 的语义需要自己摸索，文档里没有完整的字段说明。护栏是输出侧的，输入侧有没有同等力度的检查，README 没提。
性能声明要打折看，122kb 和 1ms 是营销数字
README 开头写着小于 1ms 延迟、122kb 体积、每天处理超过 100 亿 token。这些数字不能当作可复现的基准。1ms 大概率是纯转发路径上的某个内部测量，不含网络往返和上游模型响应时间。122kb 可能是打包后的体积，但运行时内存和 CPU 占用没有数据。每天 100 亿 token 是 Portkey 托管服务的运营数字，不代表你自建实例能达到同样规模。我的判断是：网关本身的转发开销确实可以做到很低，因为它的工作主要是改写请求头和转发 JSON，但任何声称的延迟都必须在你自己的网络条件下重新测。别拿 README 的数字去做容量规划。
真正的限制：护栏深度和商业版边界都不透明
这个项目最模糊的地方在护栏。README 说支持 50 多种 AI 护栏，但只给了 default.contains 这一个例子，而且它做的事只是字符串匹配。真正的内容安全、PII 检测、提示注入防护这些，README 没有展开。另一个问题是开源版和 Portkey 商业产品的关系。README 顶部写着 Gateway 2.0 预发布版会把核心企业网关合并进开源，同时 MCP Gateway 的企业认证和可观测性功能指向了商业文档。这意味着你现在用的开源版可能不是完整能力集，某些高级特性要等 2.0 合并或者用托管版才有。如果你需要的是开箱即用的深度内容审核，而不是自己拼字符串规则，这个项目目前的文档支撑不够。
同类工具怎么选：LiteLLM 是更轻的替代，Kong 是更重的
和 Portkey gateway 最像的开源项目是 LiteLLM，它也提供一个 OpenAI 兼容接口来转发到多家供应商，同样支持重试和回退。区别在于 LiteLLM 的 config 是 YAML 文件驱动的，模型到供应商的映射写在文件里，而 Portkey 的 config 是跟着客户端请求走的运行时字典。前者适合配置集中管理的场景，后者适合在代码里动态切换策略。另一个极端是 Kong 这种通用 API 网关，它也能做请求路由和限流，但你要自己写 LLM 供应商的转换插件，没有现成的模型列表和护栏语义。Portkey 的价值在于它把 LLM 特有的东西（模型名映射、输出检查、供应商鉴权）做成了内置功能，而不是让用户从零搭。
维护成本和许可证：MIT 是友好的，但版本节奏要留意
项目用 MIT 协议，可以自由修改和商用，这点没有争议。仓库默认分支是 main，最近一次推送是 2026 年 5 月，稳定版停在 v1.15.2，2026 年 1 月发布。版本号跳到 1.15 说明接口已经相对稳定，但 2.0 预发布分支的存在意味着配置格式可能在未来有变化。升级成本取决于你怎么部署：用 npx 每次拉最新，用 Docker 镜像可以锁 tag。代码是 TypeScript，如果你想改源码自己编译，需要熟悉它的构建链。文档里没有提供迁移指南，所以从 1.x 升到 2.0 时要做好配置兼容性测试。整体看，MIT 协议和活跃的发布节奏是加分项，但你要为 2.0 的接口变动预留时间。
编辑结论
适合已经受困于多家模型供应商 API 差异、需要统一入口和自动重试回退的团队。它把路由、重试、负载均衡和基础输出护栏打包成一个 OpenAI 兼容服务，本地用 npx 就能起，接入成本低。不适合那些需要深度定制请求改写、或者想完全脱离 Portkey 商业产品体系的用户，因为代码库与托管版的边界在文档里并不清晰，部分高级能力（如 MCP Gateway 的企业认证）明确指向商业文档。采用前先验证三件事：你的目标供应商是否在它支持的列表里，护栏的默认规则是否满足你的合规要求，以及 2.0 预发布分支与当前稳定版 v1.15.x 的配置格式差异会不会影响你已有的 config。这个项目的价值在于把多供应商的混乱收敛到一个端口，代价是你得接受它定义的 config 结构和护栏语义。
社区笔记