模型服务故障时如何降级？设计备用模型、排队与人工接管

模型 API 不可用时，产品不能只有“再试一次”或悄悄改用另一款模型。一次限流可能很快解除，也可能是额度耗尽；一项允许延后完成的草稿可以排队，正在等待账单解释的顾客却需要明确的状态和接手人。降级的目标是让每个请求仍然得到可信的结果或诚实的未完成状态，而不是把所有请求伪装成成功。

本页处理推理依赖出故障后，应用怎样选择重试、接纳、排队、备用模型与人工路径。服务并发试验测固定配置在多大到达率下仍达标；Agent 恢复手册处理已经发生的外部写入和补偿。推理路由不能替它判断邮件是否已经发出、付款是否已经提交。

先判断错误属于哪一类

保留 HTTP 状态、供应商错误码、Retry-After、请求与模型标识、开始和失败时间，以及流式输出是否已经开始。不要只凭状态码决定重试。以 2026 年 10 月核对的官方文档为例，OpenAI 的临时限流可返回 429，模型暂时过载可返回 503；但额度和支出上限也可能返回 429，必须看更具体的错误码。Anthropic 文档把暂时过载列为 529，同时说明 429 也可能表示已达到月度用量上限。这些是供应商实例，不能把某一家的映射当成所有模型 API 的协议。

观察	可考虑的动作	立即排除的误判
明确的临时限流或过载，且仍在任务截止时间内	遵守有效的 Retry-After；没有提示时有限退避；必要时走预先批准的其他路径	在服务建议等待期间抢先重试，或多层重试放大流量
额度、账单、认证、权限或无效输入	暂停该路由，通知负责人修正配置；给用户合适的延迟或人工路径	把无法靠等待恢复的错误当成短暂故障
连接超时或输出中途断开	记录已经向用户展示了什么，按完整响应验收处理	把两款模型的半截输出拼成一个“已完成”回答
返回成功但结构或内容未通过任务验收	拒收结果，按质量故障规则处理	把 HTTP 200 当成合格交付

流式响应还有一个容易漏掉的分界：供应商可能已经返回 HTTP 200，随后在事件流中报错。若用户看到了前半段文字，就明确标成中断；是否清空并重新生成应由产品预先定义，不能把备用模型续写的内容直接接在后面。若模型调用后还会触发工具写入，改由恢复手册核对外部状态。

从用户截止时间倒推重试预算

对每个任务切片写一个端到端截止时间，并为结果校验、告知用户与人工交接留出时间。单次 HTTP 超时不是整项任务的截止时间。若 Retry-After 已超过剩余时间，应延期或走其他获准路径，不能为了满足界面等待而忽略服务提示。没有有效提示时，退避可带随机错开，但尝试次数与总耗时都要封顶。OpenAI 与 Anthropic 的 SDK 都可能自动重试某些暂时性错误；先核对安装版本的配置，避免 SDK 两次、应用再三次的嵌套尝试。

持续失败时，可在一段观测窗口达到事先设定门槛后打开熔断器，使新请求快速进入降级判断；冷却后只放少量探针，确认恢复再逐步扩大。门槛应来自你的流量和用户要求，不应把本文中的供应商错误示例写成通用数值。也要给入口设置接纳上限：当全部允许路径都没有余量时，及时拒绝或延期，并给出可见状态，比把请求无限塞进不可见队列更可靠。

备用模型先过质量和数据两道门

备用路由要在故障之前按同一任务获得批准。用冻结案例集比较必备字段、引用或事实支持、无答案行为、结构化格式、关键切片、严重错误、延迟及每项合格任务的成本。主模型能用的 Prompt、工具或 JSON 结构不一定能原样迁移。先在模型选型评分表记录候选版本和阻断失败；换模型或改 Prompt 后重测。备用路由只对通过的任务切片开放，不能凭一组简单提问推断它能处理所有输入。

再用数据边界图逐字段核对发送地点、供应商、日志、保留和工具外联。备用模型即使来自同一家供应商，也可能使用不同端点、区域或功能；跨供应商切换更需要单独批准。若某字段不得离开当前环境，就不能在主模型不可用时把原文发往未批准的备用 API。质量或数据门槛任一缺证据，该路由保持关闭；必要时只交付不含个人事实的固定说明，并明确人工接管。

把降级写成逐任务的路由阶梯

这是一组条件分支，不是所有请求都必须按顺序走完五级。为每级写触发信号、最长停留、可接受任务、用户看到的状态和退出条件。

路径	适用条件	对用户和负责人必须留下什么
主路有限重试	错误可恢复；等待仍落在截止时间内；总重试预算未用尽	正在处理状态、原始请求标识、尝试数与服务提示
有期限的异步队列	用户同意稍后取回；任务在过期前仍有价值；队列可持久保存和取消	任务编号、预计复查时间、取消入口、过期后的处理人
已批准备用模型	该任务切片通过质量和数据门槛，备用端有容量和费用余量	实际模型版本、校验结果、相对主路的限制
人工处理或明确不可用	关键风险不能降级，或等待与备用路径都失败	已知事实、未完成部分、接手人和下一次联系时间

同一任务可以先进入队列，超过保留窗口后再由人处理；另一个任务可能跳过排队，直接使用已批准备用模型。路由决定由任务性质和当前证据决定，而不是简单按模型价格排序。完整成本图还应把重复调用、排队、人工复核与放弃任务的费用计入。

让队列有容量、期限和退出方式

队列适合可异步完成的草稿、批处理或报告。Azure 的队列削峰模式强调，若平均生产速度长期高于消费速度，积压和延迟会一直增加；对必须低延迟同步返回的请求，队列也可能不适合。因此写清最大待处理量、最长等待、任务过期时间、消费者并发与下游速率。观察队列深度之外，还要看最老任务的年龄和已经超过用户截止时间的比例。

入队时保存稳定任务 ID、到期时间、最小必要输入或受控引用，以及可查询、可取消的状态。不要因浏览器刷新就生成第二份同一草稿，也不要把敏感原文无期限地留在队列。恢复时先检查旧任务的资料版本和用户意愿；已过期、已取消或需要重新批准的请求不能随积压队列自动重放。若工作涉及发布、发送或付款，仍需单独的动作权限与恢复规则。

案例一：公开活动介绍的多语言草稿

这是合成演练。活动团队把已公开的地点、日期与报名规则翻译成三种语言；页面只生成编辑草稿，不自动发布。负责人先选出含日期变更、容量限制、否定条件和缺失地点的保留案例，比较主、备模型是否保留这些事实，并把任何凭空添加地点或截止日设为阻断错误。只有备用模型通过同题验收，才允许它处理这类公开草稿。

假设主 API 返回临时 429。路由先读错误码和有效的 Retry-After，再计算剩余交稿时间。如果提示等待仍能留出校对时间，就等待并在总预算内重试；若不能，已同意异步交稿的任务进入有期限的队列，或转给获批的备用模型。队列超过过期时间就标记未完成并通知编辑，而不是继续生成可能已过时的活动信息。编辑检查事实后才发布。这里的分支是演练规则，不是声称任何供应商或模型已有某项实测通过率。

案例二：私密账户账单说明不能随意换供应商

另一项合成任务是帮助客服解释顾客账户中的一笔费用。输入包含账户识别字段和内部调整记录。主 API 返回暂时过载，但备用供应商尚未获批接收这些字段。即使备用模型响应很快，质量评分也不错，数据门槛仍不允许自动转发。顾客界面显示“需要人工核对，当前不能给出该笔费用的解释”，提供客服接手方式；交接材料只包含受控工单号、故障类型和已核实的查询位置，不粘贴完整账单到通用队列。

演练还应注入“主模型已输出半句解释后断流”。产品不得把这半句当成最终结论，也不能让备用模型猜测后半句。客服在权威账单系统中复核后作答。若后来批准了新的数据路径，也要重新核对提供商端点、保留配置和任务案例，而不是把一次事故中的临时绕路固化为常规流程。

演练故障，并小范围返回主路

下方工作表逐任务填写路由阶梯，并至少演练：临时 429、额度类 429、503 或 529、单次超时、HTTP 200 后的流中断、备用模型格式错误、禁止转出的字段、队列已过期、主服务恢复时积压仍未清空。每种演练都记录原始到达请求数、成功交付数、超时、取消、转人工与明确拒绝；不能只用成功返回的请求计算“可用率”。同时看用户等待分布、队列最老年龄、备用模型的严重质量失败和每项合格结果的费用。

主路恢复后，先用受控探针确认错误码、延迟和输出验收正常，再缓慢恢复正常路由。若立刻释放积压，可能再次触发限流或挤走新请求。出现质量阻断错误、数据路径变化、备用模型版本更换或长期队列积压时，负责人应暂停相应分支并重新演练。用于主服务质量变化的持续观察，可接到漂移观察板；本页的工作表记录的是故障期间谁可以走哪条交付路径。

常见问题

备用模型更便宜也更快，可以直接在故障时切吗？ 不能。先证明这项任务的质量、格式和数据流向都合格，再写清适用切片。一次漂亮的普通示例不等于对关键失败的放行。

429 是否一律排队等恢复？ 不是。按供应商的错误体区分暂时限流和额度、账单类错误；后者需要负责人修正。即使能恢复，任务在等待后已过截止时间也不该留在队列里。

用户关闭页面后任务还能继续吗？ 只有业务确实支持异步交付、队列持久化、状态可查询、取消与过期规则明确时才可以。否则应把本次请求标为未完成，不要许诺一个无法追踪的稍后结果。

不适用边界

这份阶梯不证明供应商的可用性承诺，也不替代容量压测、模型质量评测、隐私合同或事故响应。它适用于一项已定义任务的推理交付路径；工具写入、付款、邮件发送等外部效果仍须按独立权限与恢复手册核对。错误码、SDK 自动重试和提供商数据控制会变化，部署前应按实际 API、模型、账户及版本重新查证并演练。