主模型限流之后，Portkey 可以按规则切到备选服务

应用接入模型以后，用户等到的有时不是回答，而是限流或服务错误。为每个入口分别写重试、备用模型和请求记录，很容易把相同逻辑散在多个地方。Portkey AI Gateway 把这些规则放到请求经过的网关中：先用哪项服务、什么情况重试、何时换备选，都可以通过配置组织。

它适合已经在调用模型 API、准备接入多个服务商的开发团队。这里最有用的能力，是把失败后的下一步写成可检查的路径，而不是只在界面提示“请稍后再试”。

一次429，怎样决定接着找谁

当前回退文档把备选服务排列在 targets 中，配置 fallback 策略后，主服务失败时按顺序尝试下一项。默认触发条件是非2xx状态码，也能用 on_status_codes 指定范围。

官方给出的一个例子只在429限流时回退。放进教学情境里，就是：请求先去服务 A；A 返回429，才去配置好的 B。如果 A 已经正常返回，则不会为了“再比较一个答案”而额外调用 B。用户要的是一个能继续处理的结果，网关负责落实选择路径。

猫目依据官方配置规则绘制的教学示意，只表示已设置429触发条件的路径，不是一次运行记录或可用性保证。打开清晰原图。

这条规则也揭示了范围：没有另外配置内容校验时，一段以200状态正常返回、却答错了的文字，不会仅凭“内容不对”触发上述状态码回退。需要先分清自己要解决的是接口调用失败，还是回答质量，再决定接哪种处理机制。

自动重试文档说明，可以设置尝试次数、触发状态码，并通过指数退避拉开请求间隔；也可以选择遵循提供商返回的 Retry-After 等等待提示。它仍是在既定目标上争取一次成功，回退则会沿备选清单换目标。

如果限流只是短暂波动，等待再试可能有价值；如果备选仍处在同一处故障或相同配额下，换一个名字也未必解决问题。采用时应结合实际账号、部署位置和任务所需能力安排备选，不把“有两家模型”自动理解成完整保障。

仓库还有一张直观的官方规则图：示例检查返回里是否包含 Apple，命中后在尝试次数范围内重试。这说明内容检查也能参与流程，但必须先有明确配置。

来源：官方 README 引用的规则示意图。图中是特定关键词检查与重试的教学逻辑，不是任意回答的质量评测；也没有完整画出耗尽尝试后的处理。打开官方原图。

值得记住的是，检查条件只能覆盖自己定义的范围。拒绝某个单词的规则，可以解释校验怎样接入请求，但不能据此推导出系统已经理解了业务正确性。

当前平台文档说明，回退链路会保留各次请求，可以先用 Config ID 筛选某套配置，再用 Trace ID 查看一次请求中的尝试。这样才能分清主服务失败、备选成功，与单次调用本来就成功的情况。

这对之后的判断很重要。备选可能有不同的响应时间、费用或输出特征；一项请求也可能产生多次模型调用。若应用要求固定 JSON 结构、图片输入或工具调用，备选也需要具备对应能力，不能只因为能返回文字就认定可以替换。

比较合适的起步方式，是选一条容易核对的任务，准备两个真正可用的目标，先明确触发错误，再观察请求链。这里没有执行故障注入或模型调用测试，文中路径用于理解配置；不要把示意当成已测得的成功率。

Gateway 仓库采用 MIT 许可；模型服务、托管平台和企业能力另有条件。README 顶部将2.0标为预发布，不能把预发布分支计划并入当下稳定功能。自建时应沿所用分支的安装与参数示例，托管部署则沿对应平台文档，避免混用配置格式和能力范围。

当前文档页脚也已注明，Portkey 现为 PRISMA AIRS AI Gateway；开源仓库仍使用 Portkey 名称。核对名称、版本与部署路线，比照抄一段旧教程更能帮助判断自己实际接入了什么。

它适合解决的，是模型应用已经存在、多个请求入口需要一套明确路由规则的阶段。先把一类失败后的去向和记录做清楚，才能判断这层网关是否减少了应用里分散的处理逻辑。