AI 服务中的多模型降级与熔断机制如何设计，怎样定义异常、状态流转和自动恢复条件？｜美团后端开发面经解析

60 秒回答模板

我会把多模型服务设计成带健康状态的路由层。每个模型或供应商维护 closed、open、half-open 等状态，异常包括超时、5xx、限流、鉴权失败、空响应、结构化解析失败、质量校验失败和成本/延迟超预算。熔断器在滑动窗口内根据错误率、连续失败数、p95 延迟或限流比例打开，打开后流量切到备用模型、缓存答案、规则兜底或提示稍后重试。恢复不能立刻全量放开，而是 half-open 探测少量请求，连续成功且延迟、质量达标后再逐步恢复。路由还要考虑模型能力差异、任务类型、上下文长度、成本和安全策略。

考点 异常要分层

难度 真实面经题

回答目标 证明你能设计稳定的 LLM 网关或模型路由层，兼顾可用性、质量、成本和恢复能力。

深入解析

异常定义

异常不只等于 HTTP 失败。AI 服务还要把超时、供应商 5xx、429 限流、鉴权错误、响应为空、JSON schema 不合法、拒答异常、质量检测失败、敏感内容违规和延迟超预算纳入不同错误类型。错误类型决定是否重试、降级还是直接失败。

熔断状态

典型状态是 closed、open、half-open。closed 正常放量并统计窗口；open 阻断对异常模型的主流量；half-open 只放少量探测请求验证恢复。状态迁移要基于滑动窗口、连续成功数、冷却时间和健康探测结果。

降级路由

降级路径可以是同供应商小模型、不同供应商等价模型、缓存结果、规则模板、异步处理或人工接管。路由时要按任务能力匹配，不能把长上下文、工具调用或强推理任务随便切到不支持的模型。

重试策略

重试要区分可恢复和不可恢复错误。网络抖动、5xx、短暂超时可以指数退避重试；schema 错可以尝试修复或二次解析；鉴权失败、权限拒绝、内容安全违规通常不应重试。重试还要控制预算，避免放大故障。

自动恢复

自动恢复要有冷却时间和探测流量。half-open 期间只放少量真实或合成请求，验证成功率、延迟、限流和质量检查都达标后逐步增加权重。若探测失败，则回到 open 并延长冷却。

观测治理

需要按模型、供应商、任务类型统计请求量、错误率、p95/p99、token 成本、fallback 率、重试率、质量校验失败率和用户感知失败率。熔断策略本身也要可配置、可回滚，并记录每次状态变化原因。

易错点

只讲备用模型，没有熔断状态机、统计窗口和自动恢复。
把所有异常都统一重试，导致限流和故障被放大。
忽略模型能力差异，把复杂任务降级到不支持的模型。
没有记录 fallback 原因和指标，线上无法判断策略是否有效。

面试官追问

质量失败也要触发熔断吗？

要看场景。如果结构化输出连续解析失败、拒答异常或事实校验失败集中出现，说明模型或上游路由有问题，可以降低权重或触发质量熔断。但质量指标通常需要抽样和延迟反馈，不能和 HTTP 错误完全同速处理。

如何避免降级导致用户体验更差？

要按任务类型配置降级链，明确哪些任务允许小模型、哪些必须排队或提示稍后。降级输出可以降低功能范围，但要保持格式、边界和可解释性，不能静默给出明显低质答案。

多模型 fallback 会不会重复扣费很高？

会，所以要设置请求预算、最大重试次数、超时阈值和成本上限。还可以在失败前做短超时探测、缓存确定性结果，对高成本任务优先异步处理或排队。

半开探测用真实流量还是合成流量？

两者可以结合。合成流量适合验证基础可用性，真实低比例流量能验证真实分布和质量。恢复初期要小流量、可回滚，并持续观察错误率和延迟。