Portkey 网关配置指南3 步搞定 429 自动重试【免费下载链接】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你的聊天应用本地跑得好好的一上线就被 429 限流报错刷屏。本文用 Portkey AI Gateway 开源项目演示如何用一份 JSON 网关配置实现自动重试和多模型 fallback读完后你能独立写出一份生产级网关配置并在日志里验证它生效。痛点场景复盘LLM 请求为什么总在生产翻车凌晨三点监控开始报警GPT 调用批量返回 429 限流。影响是聊天请求成批超时工单开始堆积等你爬起来处理时对方已经自己恢复了。为了绕开单个供应商限流有人在代码里硬编码了第二个模型。影响是换一次流量比例就要改代码、回归测试再发版模型越换越乱。十几个用户每天问同样的问题每次都重新调用模型计费。影响是成本一路涨没人说得清钱花在哪。工作机制一图说清网关配置如何生效别急着写配置先建立心智模型。Portkey Gateway 部署在你的应用和所有模型供应商之间你的代码只需要向一个网关地址发标准请求。它读取你传入的 JSON 配置负责判断要不要重试、该发给哪家供应商、能不能直接走缓存。所谓网关配置本质就是跟着请求头走的一段 JSON改配置不用改代码下次请求就生效。流程一行说完请求 → 网关读配置→ 正常则转发目标模型异常则重试或降级到备用模型 → 响应。重试逻辑是开源的在 src/handlers/retryHandler.ts 里能看到遇到 429 时它会读取供应商返回的 Retry-After 头来决定退避时长这些细节你不用自己实现。最小可用配置最快给 AI Gateway 加自动重试直接说结论重试能力全靠下面这段 JSON先照抄这段。{ retry: { attempts: 3, on_status_codes: [429] } }白话解释attempts是重试次数on_status_codes指定哪些状态码触发重试不写它时默认对 429、500、502、503、504 都重试。把这段 JSON 粘贴到控制台的 Configs 页面保存会生成一个类似pc-xxxxx的配置 ID代码里按 ID 引用即可。除了 retry超时、fallback、缓存都能写在同一份 JSON 里。两种接入姿势SDK 与 OpenAI 兼容接入一步到位SDK 原生接入import { Portkey } from portkey-ai; const portkey new Portkey({ apiKey: 你的 Portkey API 密钥, // 替换位 1 virtualKey: 你的模型虚拟密钥, // 替换位 2 config: pc-xxxxx // 替换位 3上面保存的配置 ID }); // 之后所有请求自动带重试签名与 OpenAI SDK 一致 const res await portkey.chat.completions.create({ messages: [{ role: user, content: 你好 }], model: gpt-4 });OpenAI 兼容接入项目已经在用 OpenAI SDK 的话不用重写把baseURL指到网关存量代码直接获得重试能力。import OpenAI from openai; import { PORTKEY_GATEWAY_URL, createHeaders } from portkey-ai; const openai new OpenAI({ apiKey: 你的 OpenAI 密钥, // 替换位 1 baseURL: PORTKEY_GATEWAY_URL, // 流量全部改走网关 defaultHeaders: createHeaders({ provider: openai, apiKey: 你的 Portkey API 密钥, // 替换位 2 config: pc-xxxxx // 替换位 3配置 ID }) }); // 照旧调用 openai.chat.completions.create请求自动带重试配置 ID 建议放控制台统一管理和版本化改配置时热更新生效不用重新发版。进阶组合负载均衡、缓存与多级降级一起配真实场景主模型高峰期被限流同时月账单一直涨。把多目标负载、缓存和嵌套降级拼在一份配置里{ strategy: { mode: loadbalance }, targets: [ { virtual_key: openai-key-01, // 主力OpenAI吃七成流量 weight: 0.7, cache: true // 重复问题直接走缓存 }, { virtual_key: anthropic-key-01, // 备路Anthropic三成流量 weight: 0.3, strategy: { mode: fallback }, targets: [ { virtual_key: azure-openai-key-01 } // 再降级到 Azure ] } ] }它在防三件事70/30 分流让单个供应商限流不会打瘫全局缓存让重复提问不再重复计费Anthropic 那路失败时自动降到 Azure两条路都出问题时还有最后一层兜底。这个嵌套写法出自官方示例 cookbook/getting-started/resilient-loadbalancing-with-failure-mitigating-fallbacks.md。缓存开起来之后去 Analytics 页的 Cache 标签就能看到命中率和节省金额。验证生效与高频报错确认配置真的在跑最省事的验证方法发一条测试请求并带上自定义traceID比如retry-test-01然后到 Logs 页面按这个 ID 过滤。请求行上出现重试或 fallback 标记、并且能看到实际尝试次数说明配置生效了做法参考 cookbook/getting-started/automatic-retries-on-failures.md。高频错误码和一句话解法状态码常见原因一句话解法429触发供应商限流或配额配置on_status_codes加入 429 重试或用 loadbalance 分流500/502/503供应商侧服务故障默认重试码已覆盖仍失败就加 fallback 目标408请求超时在配置里加请求超时request_timeout给下游留反应时间401/403密钥错误或无权限重试没意义直接检查apiKey和virtualKey继续深入网关配置入门全文cookbook/getting-started/writing-your-first-gateway-config.md缓存原理与语义缓存cookbook/getting-started/enable-cache.mdDocker / K8s 部署方式docs/installation-deployments.md今天就能做的下一步用npx portkey-ai/gateway在本地把网关拉起来把你线上最常报 429 的那个请求从它身上过一遍去 Logs 里确认重试真的发生了。【免费下载链接】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），仅供参考