LLM 后备路由是指当主路由无法以可接受的方式完成请求时，将 AI API 请求发送到备用路由的做法。备用路线可能是另一个区域中的相同模型、不同的部署、另一个提供商、辅助 API 密钥、较小的模型、高级紧急模型或非流路径。如果使用得当，回退路由可以提高可用性，而无需强迫每个应用程序团队手动编写特定于提供商的恢复逻辑。
困难的部分是 LLM 请求不是普通的 HTTP 调用。失败的一代可能仍会消耗速率限制容量。流式回答可能已经向用户显示了内容。围绕代理工具调用的重试可能会重复购买、电子邮件、票证或数据库写入。回退模型可能会返回有效的 HTTP 200 响应，同时违反任务契约、忽略架构、失去工具支持或产生较低质量的推理。因此，可靠的 LLM API 故障转移设计必须协调重试策略、模型兼容性、延迟预算、成本控制、可观察性和团队治理。
本指南介绍如何将 LLM 回退路由设计为操作模式。它涵盖了何时重试、何时进行故障转移、如何选择回退模型、如何避免重试风暴、如何保留语义，以及 Model Gate 等多模型网关如何集中API 访问、计费归属、API-密钥管理、分析以及围绕路由决策的团队控制。
LLM 回退路由的实际含义
回退路由比“如果模型 A 出现故障，请尝试模型 B。”在生产 AI 系统中，路由通常是以下几项的组合：请求的模型别名、解析的提供者模型、提供者帐户、API 键、区域、端点类型、流模式、配额桶、定价层、安全策略和请求参数。在主路由不可用、过载、速度太慢、超出预算、请求不受支持或验证失败后，回退会更改其中的一个或多个选择。
简单的回退链可能如下所示：将聊天请求发送到主要模型，在瞬态 503 上重试一次，然后在总期限仍然允许的情况下转移到兼容的辅助模型。更成熟的政策可能会使用运行状况评分、断路器、租户级许可名单、支出限制、每次尝试超时以及用于聊天、代码生成、提取、RAG、代理工作流程和批处理作业的单独后备组。
目标不是最大化尝试次数。目标是在定义的可靠性、延迟、成本和质量范围内完成用户请求。有时，最好的后备方案是使用较小的型号。有时它是高级型号。有时它是排队的批处理路径。有时，正确的行为是失败关闭并告诉应用程序没有可用的合规路由。
重试与回退不同
重试通常意味着针对同一路由的另一次尝试。后备意味着改变路线。这种区别很重要，因为重试和回退解决了不同的故障模式。
重试适用于同一路由可能很快成功的瞬时故障：网络超时、临时过载、某些 408 响应、某些 429 响应和某些 5xx 响应。提供商指南通常建议遵守Retry-After（如果存在），使用带抖动的指数退避，并限制重试次数和总重试时间。官方 SDK 可能已经重试符合条件的 429 和 503 响应，因此应用程序级重试需要考虑到这一点。
当同一路由不太可能在请求截止日期内恢复或无法再满足请求时，可以使用回退。示例包括区域中断、配额桶耗尽、不健康的部署、禁用的模型、提供商事件、不兼容的功能或排除主要路由的策略决策。AI 模型后备路由还可用于控制降级，例如在高级容量受限时将低风险汇总任务转移到更便宜的模型。
常见的失败是在没有共享预算的情况下组合两种模式。如果 SDK 重试 3 次、应用程序重试 3 次、网关重试 3 次、队列工作线程重试整个作业，则一个用户请求可能会变成数十个上游调用。这可能会恶化速率限制、增加成本并使中断更难以恢复。
从路由策略开始，而不是硬编码列表
持久模型回退策略从显式策略对象开始。该策略应定义主要路由、后备候选、资格规则、可重试错误类别、总期限、每次尝试超时、最大尝试次数、后备禁用控制和日志记录要求。它还应该定义什么才算是成功。对于结构化提取任务，成功可能需要有效的模式。对于代理工作流程，成功可能需要将生成恢复与工具执行分开。对于流式聊天请求，成功可能需要第一个令牌计时以及后备是否仍然安全的明确边界。
实用策略包括：
- 主要路线：首选模型、提供商、区域、关键类或模型别名。
- 后备组：满足相同功能配置文件的排序或评分候选者。
- 重试预算：1请求路径中所有重试和回退尝试的端到端预算。
- 错误分类：哪些错误可重试，哪些错误会触发回退，哪些错误应立即失败。
- 兼容性约定：所需的端点形状、上下文长度、模式、工具支持、结构化输出支持、流式传输行为、安全限制和响应格式。
- 成本规则：请求是否可以升级为更昂贵的模型、降级为更便宜的模型，或者在主要路由不可用时停止。
- 管理规则：租户许可名单、团队权限、区域限制、保留要求和关键级别预算限制。
- 可观察性规则：必须为每个尝试的路由记录哪些元数据。
明确这些规则可以使后备行为变得可审查。它还可以对不同的工作负载应用不同的策略，而不是对每种请求类型强制采用一个全局链。
在采取行动之前对故障进行分类
可靠的 LLM API 路由取决于良好的错误分类。并非每个失败的响应都值得再次尝试，也不是每个错误都应使用相同的后备路由。
好的重试候选
重试候选通常是暂时的且是路由本地的。它们包括临时网络错误、收到任何响应之前的连接重置、请求超时、某些 408 响应、提供程序过载、某些 429 速率限制响应和 5xx 错误。对于 429 响应，应用程序或网关应遵循提供商指南，例如 Retry-After（如果可用）。退避应包括抖动，以便许多客户端不会同时重试。
良好的后备候选
后备候选包括主要提供商中断、持续 5xx 速率、配额桶耗尽、区域运行状况故障、已知不良部署、不可用模型、流量峰值或未通过功能检查的路由。如果限制是短暂的，则 429 可能会触发重试；如果配额存储桶已用完并且另一个批准的存储桶或提供程序可以满足请求，则可能会触发回退。
通常不应重试的错误
身份验证失败、格式错误的请求、无效的模型 ID、不支持的参数、策略拒绝、信用不足、缺少权限、上下文溢出和不兼容的工具架构通常需要更改配置或请求。重试通常会产生额外的成本和噪音，而不会提高可靠性。仅当已知后备路由支持确切的请求协定且策略允许时，其中一些错误才会触发备用路由。
按功能而不是流行程度构建后备组
后备模型不能仅仅因为可用而可互换。它必须满足请求的功能配置文件。对于聊天，这可能包括系统消息、长上下文、JSON 模式、流式传输和工具调用。对于 RAG，它可能包括大的上下文窗口和一致的引文格式。对于结构化提取，它可能包括模式遵循和确定性输出。对于视觉或音频，它必须支持相关的输入模式。对于受监管的工作负载，可能需要相同的保留、区域和安全约束。
这就是许多多模型后备设计失败的地方。他们将几种流行的模型放在一个列表中，并假设网关可以从一个模型移动到下一个模型。在实践中，提供商参数有所不同。采样控制、推理控制、消息角色、工具模式、响应格式、文件输入、安全设置和计费单位可能无法清晰地映射。无法遵循相同输出架构的后备模型可能会将可用性问题转化为正确性问题。
更好的方法是根据工作负载和兼容性创建后备组。一组可以提供一般聊天服务。另一个可能提供代码帮助。另一个可能会使用严格的架构来提供 JSON 提取。另一个可能提供视觉输入。在每一组中，应在生产使用之前使用一致性装置对后备候选方案进行测试。
通过一个端到端截止时间控制延迟
后备通过花费更多时间尝试备用路径来提高可用性。同样的额外时间可能会违反用户的延迟预期。答案是对整个请求使用一个端到端的截止时间，而不是在每一层使用独立的超时。
例如，如果面向用户的 SLO 为 5 秒，则策略可能允许 1.5 秒的主要尝试、短暂的退避以及仅在剩余足够时间的情况下进行一次回退尝试。如果主要模型流式传输令牌，则策略可能会优化第一个令牌的时间，并在发出有意义的输出后禁止回退。如果请求是后台批处理作业，则该策略可能允许更长的退避时间和更多的尝试，因为面向用户的延迟不太重要。
重试预算应包括 SDK 次重试、网关重试、队列重试、提供程序重试和回退尝试。它还应该定义何时停止。已经消耗了大部分截止日期的请求不应开始昂贵的回退尝试，因为这种尝试不太可能按时完成。
定义流式传输和副作用边界
流式传输改变了回退问题。在交付任何内容之前，失败的尝试通常可以重试或路由到其他地方。当内容对用户可见后，回退就变得有风险。重试同一代可能会产生重复、矛盾或混乱的输出。某些系统允许在流标头之前回退。有些允许它在第一个内容令牌之前。有些不允许在流生命周期开始后进行回退。重要的一点是有意定义边界，并将部分流与普通故障分开记录。
代理工作流添加了另一个边界：副作用。起草工具操作的模型调用通常可以重试。发送电子邮件、向卡收费、写入数据库、创建支持票证或调用外部 API 的工具调用不能盲目重复。生成重试和工具执行需要单独的状态。当围绕改变外界的操作使用回退路由时，幂等密钥、工作流状态机和持久执行记录至关重要。
使用断路器和运行状况评分
如果没有运行状况控制，回退可能会继续将流量发送到已知发生故障的路由。断路器可以防止这种情况发生。在多次失败、高超时率或强烈的提供商事件信号后，路由会暂时被抑制。流量可以在冷却、运行状况检查或小型探测成功后恢复。
运行状况评分可以考虑最近的错误率、超时率、延迟、提供程序状态、配额信号以及按工作负载观察到的成功情况。它不应该因为某个模型或区域出现故障而盲目地将所有流量从提供商处路由出去。相反，它不应该将一个成功的请求视为路线完全健康的证据。评分窗口应足够长，以避免波动，但也应足够短，以便对真实事件做出反应。
健康状态还需要租户意识。当特定的 API 密钥、项目、配额存储桶或帐户耗尽时，提供程序可能在全球范围内保持健康。 LLM API 故障转移应区分提供程序级别的运行状况和凭据级别的运行状况。
将成本和管理纳入政策的一部分
回退更改成本。备用路由可能更便宜、更昂贵或计费方式不同。失败的尝试仍可能消耗令牌或速率限制容量。部分流式响应可能是收费的。如果在中断期间回退从经济型模型升级为高级模型，则服务可能会保持可用，而单位经济效益会发生巨大变化。
因此，回退应与预算和结算政策相结合。一些租户可能允许保费紧急回退。其他人可能更喜欢更便宜的降级路线。当没有经批准的低成本路线可用时，某些工作负载应该停止。需要细粒度控制的团队应将回退与 LLM API 键支出限制保持一致，这样辅助路由就无法绕过保护主路由的控制。
统一结算也很重要，因为最终答案可能会隐藏多个上游尝试。一份干净的发票或使用报告仍应能够解释请求了哪种型号、解决了哪条路线、哪些尝试失败、哪些尝试成功以及解决了哪些成本。支持统一 AI API 计费的网关为团队提供了一种更一致的方式来确定跨模型和提供商的成本归属，尤其是当回退行为跨越多个供应商时。
为每个请求记录一个尝试分类帐
没有出处的回退很难调试。应用程序会看到最终响应，但运营团队需要知道在此过程中发生了什么。尝试分类帐应记录每次路由尝试，而不仅仅是获胜者。
有用的字段包括请求的模型或别名、解析的模型、提供商、区域、凭证类别、租户、团队、API 键、请求 ID、尝试编号、开始时间、延迟、超时、错误类别、重试决策、后备决策、提示令牌、完成令牌、缓存令牌（如果相关）、估计成本、结算成本、流式传输状态、部分输出状态以及响应是否被接受或丢弃。
此数据支持事件响应、成本分析、模型评估和客户支持。它还有助于检测无声的质量回归。如果用户报告的答案较弱，分类账可以显示他们在提供商事件期间是否收到了较低层的后备模型。运营团队可以将路由来源与 AI API 使用情况分析仪表板结合起来，以按团队、密钥、模型或工作负载查看回退率、提供商错误、支出变化和延迟变化。
多模型网关适合的位置
多模型网关是集中路由策略的自然场所，因为它已经位于应用程序和提供商之间。 Model Gate 是一个 OpenAI 兼容的多模型 API 网关，具有统一计费、API-密钥管理、使用分析、团队控制、Telegram 集成以及用于在平台上构建服务的合作伙伴 API。这些功能与后备路由的操作环境直接相关：模型访问、凭据管理、成本归因、使用情况可见性和团队级治理。
这并不意味着每个网关都会自动执行此处描述的每种后备模式。在这种情况下，考虑 Model Gate 的负责任的方式是将其作为多模型 API 访问和可观察性的中央控制点。如果您的应用程序本身实现回退逻辑，网关仍然可以简化模型访问、计费记录、密钥管理和分析。如果在网关层中实现回退行为，则同样的治理和报告问题仍然适用：保留租户控制、记录每次尝试、公开有用的元数据并避免不透明的模型替换。
兼容 OpenAI 的接口还可以减少迁移摩擦。应用程序通常可以保持熟悉的 SDK 形状，同时在幕后更改基本 URL 和路由策略。这种兼容性很有价值，但它并不能消除在依赖生产中的回退之前测试特定于提供商的行为、工具调用、架构输出、流式传输、延迟和成本的需要。
在事件发生之前测试回退
第一个真正的提供商事件不应该是回退路由的第一个端到端测试。构建一个测试工具来测试您期望看到的故障模式。
有用的固定装置包括带或不带 Retry-After 的 429 速率限制、408 超时、500 和 503 提供程序错误、格式错误的提供程序响应、不受支持的参数、无效的模型 ID、上下文溢出、预算拒绝、策略拒绝、第一个令牌之前的流式传输中断、部分输出后的流式传输中断、工具调用重试、配额耗尽和质量验证失败。测试路由决策和生成的日志。成功但没有留下尝试记录的后备在操作上仍然不完整。
还要测试负面案例。确认客户端错误不会在不必要的情况下重试。确认可以禁用基准测试、审计、再现性和精确模型评估的回退。确认租户许可名单、团队权限、区域限制和支出限制适用于后备路由，就像它们适用于主路由一样。
要避免的常见错误
最常见的错误是将后备视为备用模型的简单有序列表。这隐藏了真正的要求：功能兼容性、截止日期、预算、政策和可观察性。
另一个错误是重试每个错误。身份验证、格式错误的请求、不支持的参数、策略拒绝、信用耗尽和无效模型错误通常需要更改配置或不同的请求。重试会浪费时间并增加成本。
嵌套重试循环同样危险。 SDK、应用程序代码、网关、队列和提供商客户端都可以有自己的重试设置。如果不协调，一个用户请求可能会增加许多上游调用，并加剧速率限制压力。
静默替代是另一种风险。完全隐藏回退可能会使客户端 API 看起来很干净，但开发人员需要足够的元数据来解释质量、合规性、延迟和计费结果。正确的透明度级别取决于产品，但路由层至少应保留内部来源。
最后，当错误答案比暂时失败更糟糕时，不要回退到质量较低的模型。法律、财务、医疗、安全、合规性和高影响力的自动化工作流程通常需要故障关闭行为，除非后备路由符合与主要路由相同的标准。
可行的设计清单
- 为主要工作负载类型定义单独的路由策略，而不是一个全局后备链。
- 在重试或故障转移之前对错误进行分类。
- 使用一个端到端跨 SDK、应用程序、网关、队列和提供程序层的重试预算。
- 根据功能配置文件而不是模型流行度构建后备组。
- 设置明确的延迟期限和每次尝试超时。
- 在生产使用之前定义流式后备边界。
- 将模型调用重试与代理中的外部副作用分开工作流程。
- 对不健康的路由使用运行状况评分、冷却时间和断路器。
- 在回退期间保留租户、密钥、团队、支出、区域和模型访问控制。
- 记录每次尝试，包括失败和丢弃的尝试，以进行分析和计费。
- 在开发人员需要时公开回退元数据以进行调试、审核或客户服务支持。
- 使用类似提供商的固定装置测试成功和失败路径。
结论
LLM 后备路由是一种可靠性和治理模式，而不仅仅是一种便利功能。它可以帮助应用程序应对提供商过载、速率限制、超时、区域事件、不健康的部署和配额失败的情况。但只有当重试、故障转移、模型替换、延迟预算、成本规则、兼容性检查和可观察性一起设计时，它才能发挥良好作用。
强大的 AI API 重试和回退策略始于明确的策略：可以重试什么、可以替换什么、请求可以运行多长时间、可能花费多少费用、允许哪些路由以及必须记录哪些内容。对于使用多个模型和提供程序的团队来说，Model Gate 等网关层可以为 OpenAI 兼容访问、API 密钥管理、计费归因、使用情况分析以及围绕这些决策的团队控制提供中心位置。应用程序仍然需要特定于域的验证和副作用安全性，但路由基础变得更容易管理、衡量和改进。