模型供应商退化事故处置：证据时间线、隔离实验与降级决策

模型供应商事故很少表现为整个平台完全不可达。更常见的是某个模型在一个区域首 token 变慢、流式连接提前结束、429 激增、工具调用字段缺失，或者响应成功但结构化输出质量下降。供应商状态页可能仍是绿色，自家网关也可能只显示总体成功率轻微波动。若值班人员一开始就认定“上游挂了”，很容易漏掉刚发布的 Prompt、代理配置或区域网络问题。

多模型容灾 讨论备用模型设计，LLM 网关路由策略 讨论日常选路。本篇不重复架构选型，而是规定事故发生后如何建立证据、缩小范围，并决定何时切换、何时恢复。

用用户症状声明事故

触发条件应来自端到端 SLI：某供应商的超时或 5xx 在两个五分钟窗口超过阈值、首 token p95 高于目标、流式完成率下降、结构化结果失败翻倍，或合成质量探针连续失败。单个 SDK 异常不必直接升级，但两个独立信号同时出现时应尽早指定 Incident Commander、Operations、Communications 和 Scribe，避免所有人同时查询而无人决策。

声明后先冻结模型、Prompt、网关、DNS 和出口网络的非紧急变更。所有记录使用 UTC 和同一事件 ID，不用“刚才”“大约十分钟”。第一条时间线至少包含：首次异常样本时间、监控首次可见时间、告警时间、人工确认时间、事故声明时间和当前用户影响。

2026-07-18T08:41:12Z first failed synthetic probe, provider=p1 model=m3
2026-07-18T08:43:00Z TTFT p95 crossed 4s in ap-southeast
2026-07-18T08:45:27Z pager fired; streaming completion fell to 91%
2026-07-18T08:49:10Z incident declared INC-2026-0718; changes frozen

每条事实附查询链接、Trace ID 或配置版本。供应商状态页和客服回复只能作为旁证，不能替代自身测量。

用隔离矩阵排除自家故障

建立一组小流量、相同输入的控制请求，每次只改变一个维度：生产网关与直接受控出口、主区域与备用区域、问题模型与同供应商另一模型、流式与非流式、当前版本与上一稳定 Prompt。直接请求仍需经过批准的诊断工具并隐藏凭证，不能让值班人员在个人终端复制生产 Key。

结果按 provider × model × region × transport × route_version 汇总。若同一供应商多个模型跨区域都慢，而另一供应商正常，上游退化概率高；只有生产网关路径失败时先查连接池、DNS、代理和最近部署；只有结构化输出失败时，要比较 Prompt、schema 与供应商模型快照。OpenTelemetry GenAI 属性应记录有限的 provider、operation、model 和 error type，同时保存供应商 request ID，便于升级工单。

sum by (provider, model, region) (
  rate(ai_provider_requests_total{outcome!="ok"}[5m])
)
/
clamp_min(
  sum by (provider, model, region) (
    rate(ai_provider_requests_total[5m])
  ),
  0.001
)

sum by (provider, model, region) (
  increase(ai_provider_requests_total[5m])
)

histogram_quantile(0.95,
  sum by (le, provider, model, region) (
    rate(ai_provider_time_to_first_token_seconds_bucket[5m])
  )
)

第一条是错误率，第二条是五分钟请求数。clamp_min 只防除零；15% 告警还要用 and on(provider, model, region) 连接 increase(...) >= 60，门槛由流量回放确定。低于门槛时标记“样本不足”并由合成探针佐证，不能把一个错误形成的 100% 当成退化结论。聚合流量也可能掩盖局部故障，仍需受控下钻。

选择三至五条失败 Trace 与同期成功对照，检查 DNS、TLS、排队、供应商处理、首 token、流式间隔和取消。error_class 构成应另查，不能让带该标签的分子直接除以无该标签的分母。

降级决策写成预先批准的门槛

可执行动作按风险排序：暂停非关键批任务，降低最大输出和并发，延长对用户可接受的超时，切同供应商稳定模型，最后才跨供应商切换。跨供应商会改变工具格式、内容安全、数据区域、成本和质量，必须使用已经通过评测的兼容配置。不要在事故中临时把任意模型名称写进路由表。

例如规定：主供应商同一 provider × model × region 五分钟至少六十次请求、错误率超过 15%，且备用探针连续三次通过时，将 10% 流量切备；十分钟内质量、延迟、错误和成本都在备用门槛内，再扩大到 50%。请求数门槛应按实际基线配置，不宜让所有区域共用一个拍脑袋的常量。高风险业务可选择返回明确的暂不可用，而不是把未经验证的低质量答案交给用户。LLM 灾难恢复 中的数据与能力等级应在事故前映射到这些动作。

所有变更进入时间线：决策人、依据、目标比例、配置版本、开始与完成时间、验证指标和撤销条件。Communications 每隔固定周期更新影响、缓解状态和下一次更新时间，即使没有新根因也要更新，避免业务方重复询问干扰操作。

恢复不能只看状态页变绿

供应商宣告恢复后，先运行隔离探针并观察至少两个长窗口。按 5%、25%、50%、100% 逐步回切，每阶段比较错误率、首 token、完整响应、schema 通过、质量分和单位成本。回切过程中不要同时恢复被暂停的批任务，否则新负载会污染判断。任何关键 SLI 再次越线，立即恢复上一稳定比例并延长观察。

若事故由自家发布导致，回滚必须使用不可变的网关、Prompt 或网络配置版本；确认新请求已落旧版本，在途长连接排空，合成探针和真实请求同时恢复。若需要临时提高重试，必须设置截止时间和总尝试预算，恢复后撤销，避免供应商仍脆弱时形成重试风暴。LLM SLO 与告警 可用于核对端到端错误预算，而不是把上游责任从用户体验中删除。

复盘重建事实而不是寻找归责

事故结束后导出只读时间线，计算发现时间、确认时间、缓解时间和完全恢复时间。检查监控为何先或后于用户发现、隔离矩阵缺了哪个维度、备用路径是否真的可用、供应商 request ID 是否完整，以及哪项人工操作没有预案。将真实失败模式转成合成探针、路由演练和告警测试。

最终产物应区分触发因素、根因、放大因素和恢复因素。供应商退化是触发因素时，自家无上限重试、单区域出口或未验证备用模型仍可能是放大因素。可靠的处置不是最快把责任指向上游，而是在证据不足时仍保持动作可逆，并让每次切换都有清楚的用户影响和退出条件。

延伸阅读

• 多模型降级与容灾
• LLM 网关路由策略
• LLM 应用的 SLO 与告警
• LLM 灾难恢复