EN

多供应商 AI 回退:生产架构指南

在 AI 提供商之间自动回退,确保可靠性

返回教程列表🌐 Read in English
进阶11 分钟

多供应商 AI 回退:生产架构指南

在 AI 提供商之间自动回退,确保可靠性

多供应商 AI 回退生产架构(2026):网关层集中策略(LiteLLM 配置示例)、能力等级抽象(应用调 tier 不调厂商)、健康路由+熔断、该/不该触发回退的信号。覆盖朴素回退漏掉的坑:提示词可移植性、特性不对称、延迟悬崖。

多供应商 AI 回退:生产架构指南

每个 LLM 提供商都会出故障——状态页面每月都在证明这一点。如果你的产品在某个 API 宕机时也跟着瘫痪,那是一个架构选择,而非命运。本指南涵盖多供应商弹性的生产架构:网关层、基于健康度的路由、模型等价类,以及朴素回退遗漏的故障模式。(关于请求级别的重试模式本身,请参见配套文章 LLM 回退链——本文是该模式周围的系统。)

架构:一个网关,N 个提供商

不要将回退逻辑分散到各个服务中。将其集中到网关层——自托管的 LiteLLM 代理是常见的开源选择(LiteLLM vs Portkey 权衡)——这样每个应用都使用一个兼容 OpenAI 的端点,策略通过配置管理:

yaml

litellm 代理配置——等价类与有序回退

model_list: - model_name: workhorse # 应用调用 "workhorse",从不使用供应商名称 litellm_params: { model: anthropic/claude-sonnet-4-6 } - model_name: workhorse litellm_params: { model: openai/gpt-5-mini } - model_name: workhorse litellm_params: { model: gemini/gemini-2.5-flash }

router_settings: routing_strategy: usage-based-routing num_retries: 2 fallbacks: [{ workhorse: [workhorse] }] # 在备用提供商上尝试相同类 cooldown_time: 60 # 对故障部署进行熔断

三个关键概念:

  • 等价类,而非模型名称。 应用请求一个*能力等级*("workhorse"、"frontier"、"cheap-classify");网关将等级映射到每个提供商的具体模型。这使得无需应用更改即可实现故障转移——并且强制进行真正重要的准备工作:在你的评估集上验证类成员对你的任务是否可互换评估工作流)。未经验证的回退是用静默质量回归换取停机时间。
  • 基于健康度的路由与冷却时间(熔断器):在 N 次失败后,停止向某个部署发送流量一段时间,而不是重试到正在崩溃的 API。对降级提供商的重试风暴是 429 错误变成级联延迟的原因。
  • 基于正确信号的故障转移:5xx/429/超时 → 故障转移;400 错误 → 不转移(你的请求在所有地方都是坏的);内容过滤拦截 → 策略决策,而非盲目重试。
  • 朴素回退遗漏的故障模式

  • 提示词可移植性:相同的提示词在不同提供商上的得分不同(提示词敏感性)。在需要时为每个类保留提示词变体;你的网关可以按提供商模板化。
  • 特性不对称:结构化输出、工具调用格式和推理控制各不相同(Claude vs OpenAI API)。将回退类限制为所有成员都支持的特性,或在网关层进行规范化。
  • 令牌计数漂移:不同提供商的令牌化方式不同——基于一个提供商计数的预算警报在故障转移后会失效。
  • 延迟悬崖:一个能工作但使 p95 翻倍的回退仍然可能突破你的用户体验预算——流式传输并显示进度(流式模式),并监控故障转移*率*,而不仅仅是错误。
  • 本地逃生舱:对于必须成功的流程,最后一环可以是自托管的小模型(vLLMOllama),提供降级但可用的体验。
  • 超越弹性的路由

    一旦网关就位,相同的机制可以用于成本和质量路由:分类任务优先使用廉价等级,困难推理使用前沿等级,按团队设置预算和速率限制,以及新模型的灰度切片(AI 灰度分析)。弹性是入场券;路由是复利回报。

    可观测性要求

    每个请求,标记并发送:请求的等级、解析的提供商+模型、尝试次数、故障转移原因、延迟、令牌数、成本。你会实际使用的仪表盘:按提供商的故障转移率(领先的故障指标)、每个等级每个提供商的 p95 延迟、以及每个等级的成本。网关层日志记录工具比较见 LangSmith vs Helicone vs Langfuse

    部署计划

  • 以透传模式(一个提供商)搭建网关——零行为变化,即时可观测性。
  • 定义等价类;在候选成员上运行你的评估集;记录差异。
  • 为一条非关键路由启用回退;通过在预发环境中屏蔽主提供商进行演练。
  • 逐条路由扩展;当故障转移变得平淡后,添加成本路由。
  • 常见问题

    构建还是购买网关? 自托管 LiteLLM 以获得控制权和低成本;当你想购买运维时使用托管网关(Portkey 类)。只有在规模异常或约束特殊时,才值得自己手写路由器。

    多提供商是否会使合规面加倍? 是的——回退链中的每个提供商都需要相同的 DPA/数据保留尽职调查(GDPR 指南)。对类成员进行合规把关。

    如何在对话中为用户保持行为一致? 在需要连贯性的地方,将对话固定到其起始提供商;仅在新对话中故障转移,除非主提供商完全宕机。


    *最后更新:2026 年 6 月。*

    相关工具

    litellmpython