API 自动换了备用模型怎么办？回退范围、日志与失败验收

一次 API 调用最终返回成功，可能经历过原路径重试、同模型换服务商，或换成另一个模型。是否允许这些变化，应在失败之前约定。否则“可用率提高了”也可能意味着任务能力、数据去向或计费口径变了。

本文说明如何核对自动回退的范围、日志和验收条件。OpenRouter 与 LiteLLM 仅用于说明已有公开文档的机制，不代表其他中转站支持相同参数，也不构成品牌推荐。本文没有执行付费 API 调用，也没有对任何服务商的实际路由作鉴真结论。

1. 先区分重试、换服务商和换模型

这几种行为可以叠加。客户端重试一次时，网关内部可能又尝试多个候选；只看客户端的请求次数，无法计算全部上游尝试。

OpenRouter 的模型回退文档描述了按优先级提供 models 候选列表的机制。[1] 服务商路由则使用独立的 provider 配置。[2] LiteLLM 文档也区分重试与转向另一模型组：调用在配置的重试之后仍失败，才进入相应回退流程。[3] 这些是各自产品的契约，不能根据“兼容接口”四个字推定所有平台都照做。

2. 把“可以回退”改成明确的允许范围

为每类任务填写一张策略卡，至少写下：允许的模型及版本范围、允许的服务商或端点、必需功能、数据处理要求、预算和总时限。再写哪些失败可以进入回退，以及哪些情况下必须直接停止。

例如，以下是一份假设策略，不是平台参数：合同字段提取任务允许从模型 A 转到已验收的模型 B，只允许服务商 P 和 Q；必须保留字段约束和缺失值规则；不得把文本发送给名单外服务商。若候选都不满足条件，返回可解释的失败并转人工处理，不临时放宽限制。

从控制台或配置文件核对下列问题，并保存配置版本与核对日期：

1. 谁决定回退：客户端、你自己的网关，还是购买的中转服务？各层是否都启用了重试或备用列表？
2. 允许换的是端点、服务商、模型，还是三者都允许？模型别名会不会在不改配置的情况下变化？
3. 触发条件是什么：限流、超时、不可用、上下文错误是否分别处理？输入错误不应靠反复调用碰运气；内容政策拒绝也不应被当成绕过规则的信号。
4. 预算和截止时间由谁统一控制？每层自己的重试上限不等于整个业务请求有总上限。
5. 无合格候选时，是明确失败，还是平台会继续扩大搜索范围？后者若不可限制，就不适合有严格约束的任务。

平台没有关闭或限制能力时，客户端可以拒收不符合条件的结果，但不能撤回已经被平台发送给其他上游的数据。严格的数据边界必须在转发前落实，不能只靠事后检查。

3. 正确理解路由字段的作用范围

以核对当日的 OpenRouter 服务商路由文档为例：[2]

• provider.order 表达服务商优先顺序；文档说明，指定列表都不可用时，仍可能尝试其他服务商。它本身不是完整的允许名单。
• provider.allow_fallbacks 控制备用服务商；配合 order 可限制到所选列表。不要把这个服务商级开关当作对所有层级模型替换的总开关。
• provider.only 限制允许的服务商。账户级与请求级限制同时适用，交集为空时可能没有可用路由；这时应检查配置，不为恢复成功率直接删掉限制。
• provider.require_parameters 用来排除不支持请求参数的服务商。文档提醒，默认情况下部分不支持的参数可能被忽略。即使开启检查，最终输出仍应由业务校验器验收。

如果要求固定模型，还要分别检查请求里的模型候选、客户端备用设置、网关映射和别名。固定“服务商”不一定固定它的每一个部署端点或版本，精确端点标识的匹配规则也须看当前文档。

这些名称是该平台请求体中的字段，不是所有客户端都能原样填写的设置。使用 SDK、桌面客户端或二次代理时，先确认字段是否支持、如何命名、是否真正透传；不要因为界面显示“已保存”就认定限制已生效。

4. 用尝试链核对发生了什么

日志应把一个业务请求与它的各次尝试关联起来。建议记录：业务请求编号、尝试序号、父请求或网关请求编号、配置版本、请求模型、返回模型、服务商声明的端点、失败阶段、回退原因、开始结束时间、是否已收到内容、是否触发工具，以及对应的用量和账单标识。日志不保存 API Key 或未经脱敏的完整输入。

下面是一段假设记录的解释：尝试 1 向 A/P 发起请求，在返回内容前收到限流；策略允许尝试 2 的 B/Q；尝试 2 返回完整结果并通过字段校验。只有当 B/Q 在允许范围内，且预算、数据规则与总时限均满足时，才应把它算作“合规回退成功”。A/P、B/Q 都只是说明性标记，不是真实模型或服务商。

如果只有最终响应里的模型名，最多能核对服务端的声明。模型自报身份、回答风格和单个响应字段都不能独立证明底层模型；缺少路由日志时应记录“回退过程未获确认”，而不是推断“没有回退”或“模型造假”。

计费也按契约核对。OpenRouter 模型回退页说明，按最终使用的模型定价，并在响应的 model 字段返回该模型。[1] 这不能外推成所有中转站都免收失败尝试费用。客户端重复提交可能成为独立请求；其他平台还可能有自己的倍率、预扣或结算流程。应把尝试链与账单关联，不能用主模型的单价解释所有情况。

5. 在受控环境验收失败路径

先把策略写成预期结果，再在自己的测试环境用模拟上游制造故障。阻断测试环境对付费上游的访问，使用假凭据、脱敏输入和不会产生真实副作用的工具。不要通过压垮公共服务或故意消耗生产额度来触发回退。

受控模拟只能证明测试路径上的配置和程序行为，不能证明购买的中转站内部也遵守相同规则。托管服务若提供沙箱或官方测试能力，可按其当前说明另行验收；没有时，应明确保留未验证项，不能把本地模拟结果写成供应商实测。

建议把所有场景的输入编号、预期、观察结果、是否通过及未验证范围保存下来。本教程提供的是验收设计，没有声称已经执行这组路由测试。新增备用候选、升级客户端或修改路由规则后，应重新检查受影响的场景。

6. 流式输出与工具调用要单独收尾

对于已经开始输出的流，另一模型重新生成的文本不是原流的可靠续接。保留部分结果并明确标记中断；若用户选择重新生成，应显示为新尝试，避免混合两个答案。取消本地读取或达到超时，不一定撤销远端已经完成的计算和费用。

工具调用则有业务副作用边界。假设一次流程已经创建工单，随后模型回复失败：重新运行整个流程可能再创建一张工单。应使用业务操作标识查询已执行状态；只有工具服务明确支持并实际执行幂等规则时，才能依靠该规则防重。网关请求编号、模型给出的工具调用编号，都不能自动替代业务系统的幂等保证。

遇到状态不明、权限变化或重复执行风险时，暂停自动化并核对记录。不要通过“换一个模型再试”跳过原有权限、审批或数据处理限制。

上线前至少确认四件事：允许范围在转发前落实；尝试链能关联到结果与账单；不满足能力或数据要求时明确失败；部分输出和已执行动作有独立处理方案。之后再用任务验收方法检查备用输出质量，并按尝试链逐项核对实际消耗。普通聊天成功不足以覆盖这些边界。

7. 资料与适用范围

资料核对日期：2026-10-17。下列文档用于确认具体产品的路由机制；策略卡、日志字段和故障验收表属于本文的实施建议。本文不提供模型排名、实时报价或模型身份认证，也不把一个产品的默认值推广到全部中转服务。

1. OpenRouter：Model Fallbacks
2. OpenRouter：Provider Routing
3. LiteLLM：Fallbacks