一套 API 管 1600 大模型Portkey AI Gateway 快速接入、容灾与护栏一文讲清【免费下载链接】gatewayA blazing fast AI Gateway with integrated guardrails. Route to 1,600 LLMs, 50 AI Guardrails with 1 fast friendly API.项目地址: https://gitcode.com/GitHub_Trending/ga/gateway接入过不止两家大模型服务的人都熟悉这种处境OpenAI、Anthropic、Bedrock每换一家就要换一套 SDK 和一套请求参数某家接口偶发限流或宕机只能自己在业务代码里手写重试与切换逻辑。Portkey AI Gateway 是一个开源 AI 网关把它部署在你和各家模型之间你的代码只需调用一个统一的地址由网关负责把请求转发到 1600 个文本、视觉、音频与图像模型并顺带处理重试、故障切换、负载均衡和内容安全检查。它到底解决什么问题一句话把对接多少家模型的问题从业务代码里挪到一张配置里。原理并不神秘。网关本身是一个轻量 HTTP 服务基于 Hono 框架构建官方宣称毫秒级以下的转发延迟对外暴露一组兼容 OpenAI 风格的端点例如/v1/chat/completions、/v1/embeddings。请求进来后它按你指定的 provider 参数转发给对应厂商并按统一格式把响应交还给你。真正的工作量都藏在配置里路由处理器 负责把端点分发到 各提供商适配器重试、回退和限流策略则由一份 JSON 配置驱动——加一条 fallback 规则比重构一层业务代码要省事得多。3 个高频使用场景容灾切换、内容护栏、成本审计如何配置 fallbacks 让请求自动切换到备用提供商场景很常见主用提供商突然限流线上功能直接报错。做法是声明式的。给请求挂一份配置把主备提供商写进去{ loadbalancing: [ { provider: openai, weights: [1] }, { provider: groq, weights: [0] } ] }效果第一个提供商失败时网关自动改走备选的 Groq 端点业务侧代码零改动。同一份配置还支持自动重试、按权重分流多个 key以及给慢响应设置超时具体规则可以参考配置示例文件。如何用 output_guardrails 拦截不合规的模型输出结论与其自己在业务层写一套内容审核不如让网关在响应返回前就把不合规内容拦下来。仓库内置了 50 多条护栏规则本地插件默认规则集就能做关键词、正则、字符数、JWT 校验这类检查。把一条规则挂到输出上即可output_guardrails: [ { default.contains: { operator: none, words: [Apple] }, deny: true } ]命中deny的响应会被拒绝配合重试策略模型会一直生成到通过检查为止——用户拿到的只有合规的答案。如何在本地控制台查看每次请求的成本与延迟先给结果本地跑起来后打开http://localhost:8787/public/就能看到每一条请求走了哪个模型、花了多少 token 和费用、延迟多少毫秒、缓存是否命中。排障时这非常实用某段时间请求明显变贵打开日志对比一下很快就能定位是哪家提供商、哪类问题在烧钱。什么人、什么情况下值得切换到 AI 网关不是所有项目都需要。只调一个提供商、且该提供商在你的业务里稳定可靠直接接官方 SDK 更轻、更快多垫一层网关反而是额外维护。但出现下面任何一种情况它就值得考虑同时接入两家以上模型希望随时按成本或速度切换默认提供商生产环境不能容忍某家接口抽风需要自动重试加备援回退面向外部用户的 AI 功能需要统一的内容安全检查与请求审计。对这几类团队来说网关省掉的是持续写胶水代码的功夫——容灾、护栏、计费追踪都变成改配置的活而不是重构业务层。从零到第一次跑通3 条命令本地启动并验证第一步装好 Node.js 后直接运行npx portkey-ai/gateway服务启动在http://localhost:8787/v1同时控制台页面在http://localhost:8787/public/。第二步验证连通性。带一个提供商 key 发一条 chat completion 请求curl http://localhost:8787/v1/chat/completions \ -H content-type: application/json \ -H x-portkey-provider: openai \ -H Authorization: Bearer $OPENAI_API_KEY \ -d {model: gpt-4o-mini, messages: [{role: user, content: 你好}]}能收到模型回答说明网关已经在工作。第三步面向生产部署克隆仓库git clone https://gitcode.com/GitHub_Trending/ga/gateway后执行npm install npm run build node build/start-server.js或者直接用docker run -p 8787:8787 portkeyai/gateway:latest。Cloudflare Workers、Kubernetes 等部署方式在部署指南里都有现成步骤。适合谁不适合谁适合多模型接入、需要容灾与内容安全的生产级 AI 应用。不适合只依赖单一稳定提供商、请求量很小的轻量脚本。建议如果你正在同时评估两三家模型服务花十分钟在本地把npx网关跑通先验证路由和容灾配置是否符合预期再决定是否正式引入——它带来的不是更多功能而是更少的重写。【免费下载链接】gatewayA blazing fast AI Gateway with integrated guardrails. Route to 1,600 LLMs, 50 AI Guardrails with 1 fast friendly API.项目地址: https://gitcode.com/GitHub_Trending/ga/gateway创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 一套 API 管 1600+ 大模型：Portkey AI Gateway 快速接入、容灾与护栏一文讲清
一套 API 管 1600 大模型Portkey AI Gateway 快速接入、容灾与护栏一文讲清【免费下载链接】gatewayA blazing fast AI Gateway with integrated guardrails. Route to 1,600 LLMs, 50 AI Guardrails with 1 fast friendly API.项目地址: https://gitcode.com/GitHub_Trending/ga/gateway接入过不止两家大模型服务的人都熟悉这种处境OpenAI、Anthropic、Bedrock每换一家就要换一套 SDK 和一套请求参数某家接口偶发限流或宕机只能自己在业务代码里手写重试与切换逻辑。Portkey AI Gateway 是一个开源 AI 网关把它部署在你和各家模型之间你的代码只需调用一个统一的地址由网关负责把请求转发到 1600 个文本、视觉、音频与图像模型并顺带处理重试、故障切换、负载均衡和内容安全检查。它到底解决什么问题一句话把对接多少家模型的问题从业务代码里挪到一张配置里。原理并不神秘。网关本身是一个轻量 HTTP 服务基于 Hono 框架构建官方宣称毫秒级以下的转发延迟对外暴露一组兼容 OpenAI 风格的端点例如/v1/chat/completions、/v1/embeddings。请求进来后它按你指定的 provider 参数转发给对应厂商并按统一格式把响应交还给你。真正的工作量都藏在配置里路由处理器 负责把端点分发到 各提供商适配器重试、回退和限流策略则由一份 JSON 配置驱动——加一条 fallback 规则比重构一层业务代码要省事得多。3 个高频使用场景容灾切换、内容护栏、成本审计如何配置 fallbacks 让请求自动切换到备用提供商场景很常见主用提供商突然限流线上功能直接报错。做法是声明式的。给请求挂一份配置把主备提供商写进去{ loadbalancing: [ { provider: openai, weights: [1] }, { provider: groq, weights: [0] } ] }效果第一个提供商失败时网关自动改走备选的 Groq 端点业务侧代码零改动。同一份配置还支持自动重试、按权重分流多个 key以及给慢响应设置超时具体规则可以参考配置示例文件。如何用 output_guardrails 拦截不合规的模型输出结论与其自己在业务层写一套内容审核不如让网关在响应返回前就把不合规内容拦下来。仓库内置了 50 多条护栏规则本地插件默认规则集就能做关键词、正则、字符数、JWT 校验这类检查。把一条规则挂到输出上即可output_guardrails: [ { default.contains: { operator: none, words: [Apple] }, deny: true } ]命中deny的响应会被拒绝配合重试策略模型会一直生成到通过检查为止——用户拿到的只有合规的答案。如何在本地控制台查看每次请求的成本与延迟先给结果本地跑起来后打开http://localhost:8787/public/就能看到每一条请求走了哪个模型、花了多少 token 和费用、延迟多少毫秒、缓存是否命中。排障时这非常实用某段时间请求明显变贵打开日志对比一下很快就能定位是哪家提供商、哪类问题在烧钱。什么人、什么情况下值得切换到 AI 网关不是所有项目都需要。只调一个提供商、且该提供商在你的业务里稳定可靠直接接官方 SDK 更轻、更快多垫一层网关反而是额外维护。但出现下面任何一种情况它就值得考虑同时接入两家以上模型希望随时按成本或速度切换默认提供商生产环境不能容忍某家接口抽风需要自动重试加备援回退面向外部用户的 AI 功能需要统一的内容安全检查与请求审计。对这几类团队来说网关省掉的是持续写胶水代码的功夫——容灾、护栏、计费追踪都变成改配置的活而不是重构业务层。从零到第一次跑通3 条命令本地启动并验证第一步装好 Node.js 后直接运行npx portkey-ai/gateway服务启动在http://localhost:8787/v1同时控制台页面在http://localhost:8787/public/。第二步验证连通性。带一个提供商 key 发一条 chat completion 请求curl http://localhost:8787/v1/chat/completions \ -H content-type: application/json \ -H x-portkey-provider: openai \ -H Authorization: Bearer $OPENAI_API_KEY \ -d {model: gpt-4o-mini, messages: [{role: user, content: 你好}]}能收到模型回答说明网关已经在工作。第三步面向生产部署克隆仓库git clone https://gitcode.com/GitHub_Trending/ga/gateway后执行npm install npm run build node build/start-server.js或者直接用docker run -p 8787:8787 portkeyai/gateway:latest。Cloudflare Workers、Kubernetes 等部署方式在部署指南里都有现成步骤。适合谁不适合谁适合多模型接入、需要容灾与内容安全的生产级 AI 应用。不适合只依赖单一稳定提供商、请求量很小的轻量脚本。建议如果你正在同时评估两三家模型服务花十分钟在本地把npx网关跑通先验证路由和容灾配置是否符合预期再决定是否正式引入——它带来的不是更多功能而是更少的重写。【免费下载链接】gatewayA blazing fast AI Gateway with integrated guardrails. Route to 1,600 LLMs, 50 AI Guardrails with 1 fast friendly API.项目地址: https://gitcode.com/GitHub_Trending/ga/gateway创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考