如何在不破坏延迟、成本或输出合同的情况下设计 LLM 后备方案

后备不仅仅是备份模型列表。对于使用多个 LLM 提供商的工程团队来说，回退是一种路由策略，它决定请求何时可以从一个提供商或模型转移到另一个提供商或模型、哪些内容必须保持不变，以及系统如何证明替代路径使应用程序更可靠。

读者的问题通常很简单：减少失败的请求并降低尾部延迟，而无需默默更改输出质量、架构有效性、安全行为或成本。该解决方案比“尝试其他提供商”更具体。可靠的 LLM 回退策略需要错误分类、请求截止时间、模型兼容性规则、成本限制、断路器以及提供商和路由级别的可观察性。

从回退策略开始，而不是重试代码

重试和回退可以解决不同的问题。重试要求同一提供者在暂时失败后完成同一请求。后备要求使用不同的模型、提供商、区域或路线来完成工作。混合这些问题会导致系统在发生事件时难以推理。

事实：云基础设施提供商的可靠性指南通常建议有界指数退避、抖动、最大重试限制、幂等性检查，并避免多层重试，因为重试风暴会加剧过载。主要 LLM 提供商还记录暂时性错误、速率限制、过载响应、超时和 SDK 重试行为。

建议： 为每个请求路径实现一个重试层。如果应用程序网关重试，下游服务也不应该独立重试，除非重试所有权是明确的。每次重试都应消耗相同的调用者截止时间，而不是创建新的开放式超时。

最低限度的策略应在编写任何代码之前回答以下问题：

• 哪些故障可以在同一提供程序上重试？
• 哪些故障允许回退到另一个提供程序或模型？
• 哪些故障决不能触发回退？
• 哪些输出协定必须保持相同？
• 允许的最大成本增加是多少？
• 在不允许回退之前，请求截止时间可能会花费多少时间？
• 哪种遥测技术可以证明回退是否有助于或隐藏了缺陷？

在路由之前对错误进行分类他们

当每个 non-200 响应都被同等对待时，回退是危险的。提供程序超时与格式错误的请求不同。速率限制与安全拒绝不同。输出验证失败与网络故障不同。

实用的分类法应至少包括以下类：

• 可重试传输失败：连接重置、DNS 问题、临时网络故障或网关超时。
• 提供程序过载：记录的过载或服务器端瞬态失败。
• 速率限制： 请求、令牌、加速或配额速度限制，尤其是在提供了 Retry-After 值时。
• 提供程序超时： 提供程序接受了请求，但未在其服务窗口内完成。
• 无效请求： 负载格式错误，参数不受支持、架构无效或模型不兼容的选项。
• 身份验证或配置错误：密钥错误、帐户被禁用、权限缺失或帐户级配额用完。
• 安全拒绝或阻止：提供商基于安全原因故意拒绝或阻止内容策略。
• 输出验证失败： 模型响应，但响应不满足应用程序约定。

建议： 仅重试调用方延迟预算内的暂时性失败。仅允许对产品和平台团队明确批准的错误类进行回退。除非产品定义了特定的备用安全行为，否则请勿依靠身份验证错误、格式错误的请求、确定性架构错误或安全拒绝进行回退。

这种区别很重要，因为回退可能会隐藏错误。如果某个模式对于主要提供程序无效并且碰巧被后备提供程序忽略，则系统可能会显得更健康，同时返回受约束较少的输出。这不是可靠性；而是可靠性。这是合同漂移。

使用截止时间，而不仅仅是超时

尾部延迟问题通常来自技术上有限但实际上太慢的重试。面向用户的预算为 15 秒的请求不应花费 14 秒在主路由上失败，然后开始无法及时完成的​​完整回退尝试。

使用通过整个堆栈的请求截止时间。每个路由决策都应在重试或回退之前检查剩余时间。例如：

request_deadline_ms = 6000
primary_attempt_timeout_ms = 3500
retry_backoff_budget_ms = 500
minimum_fallback_budget_ms = 1800

if remaining_deadline_ms < minimum_fallback_budget_ms:
    return controlled_failure

具体数字取决于工作负载。聊天完成路线可以为一种替代模型保留足够的时间。后台提取作业可能允许多次尝试。实时自动完成路径可能更喜欢快速失败而不是延迟回退答案。

建议：按路由类别而不是全局定义延迟预算。低延迟 UI 路由、批量分类路由和长上下文分析路由不应共享相同的重试和回退信封。

按工作负载定义模型类

供应商名称对于回退来说是一个糟糕的抽象。应用程序关心工作负载属性：上下文长度、推理深度、工具支持、结构化输出行为、延迟、数据处理约束和成本。应围绕这些属性组织后备路由。

有用的模型类包括：

• 快速草稿： 响应短、延迟低、质量容忍度适中。
• 结构化提取： 严格 JSON 输出、架构验证、格式容忍度低
• 推理：多步骤分析、更高的质量要求、更高的可接受延迟。
• 长上下文：大文档、高令牌窗口、谨慎的截断规则。
• 低成本批量：针对单元优化的异步或非紧急作业经济。
• 高级升级：仅在政策允许时使用昂贵但功能强大的模型。

对于每个类别，列出允许的主要模型、允许的后备模型和禁止的降级路径。长上下文请求不应退回到默默截断提示的短上下文模型。结构化提取任务不应回退到无法满足架构约束的模型。高级推理任务可能允许回退到另一个高级模型，但不允许回退到快速草稿模型，除非用户体验明确支持降级答案。

对于构建企业 LLM API 的团队，这些类应存在于配置或政策数据中，而不是分散在应用服务中。这使得路由行为可审计，并且在提供程序事件期间更容易更改。

保护结构化输出协定

结构化输出回退是最容易产生细微生产错误的地方之一。提供程序在支持 JSON 模式、JSON 架构、工具调用、拒绝字段、安全反馈、完成原因和架构子集方面有所不同。适用于一种模型的架构不能保证可移植到另一种模型。

事实：一些提供程序文档描述了受支持模型的严格架构遵守情况，而其他文档则说明仅支持 JSON 架构的子集。提供程序响应还可能包括拒绝字段、提示反馈、安全评级、完成原因或提示被阻止或无效时没有候选者。

建议：将输出验证视为路由的一部分，而不是可选的调用者问题。网关应在将最终响应返回给应用程序之前对其进行验证。如果验证失败，路由应对失败进行分类并决定是否允许回退尝试。

有两种可行的模式：

使用可移植架构子集

将架构保留在经批准的回退提供程序支持的功能的交集处。这提高了便携性并降低了操作复杂性。代价是您可能会失去更丰富的特定于提供商的约束。

使用特定于提供商的架构适配器

维护将应用程序协定转换为每个提供商支持的架构格式的适配器。这保留了功能，但增加了测试和维护负担。它还需要一个兼容性矩阵，以便工程师知道哪些路由可以安全回退。

基本兼容性记录可能如下所示：

{
  "route": "invoice_extraction_v3",
  "contract": "invoice_json_schema_v3",
  "primary": "provider_a.structured_model",
  "fallbacks": ["provider_b.extraction_model"],
  "disallowed": ["provider_c.fast_model"],
  "requires": ["json_schema", "enum", "required_fields"],
  "validation": "strict_before_return"
}

建议： 切勿仅仅因为它是格式良好的文本而返回回退输出。仅在满足主要路由预期的相同应用程序级合同后才将其返回。

在事件发生之前控制成本

回退通常会在流量增加或提供商降级时将流量转移到更昂贵的模型。如果没有成本控制，可靠性机制可能会成为支出事件。

设置回退规则，包括：

• 每条路线的最大回退价格乘数。
• 组织、工作区或环境允许的模型层。
• 每日或每小时回退支出预算。
• 单独的政策适用于交互式和批量工作负载。
• 回退是否可以跨提供商、区域或模型系列边界的规则。

建议：衡量每次成功响应的成本，而不仅仅是原始请求成本。如果更昂贵的回退可以防止关键路由上出现用户可见的故障，则可能是合理的。对于低优先级批量工作来说，同样的回退可能是不可接受的。

成本政策也应该对使用该平台的组织可见。团队可能希望允许生产客户支持工作流程的高级回退，同时阻止其用于开发、测试或内部实验。这是一项治理决策，而不仅仅是路由决策。

为每个提供商、模型、区域和错误类添加断路器

简单的回退可能会损害降级的提供商。每个失败的主要请求都会触发另一个主要尝试，然后触发另一个回退尝试，而其他服务也会执行相同的操作。断路器可减少重复压力并使路由行为更加可预测。

断路器应足够具体以避免反应过度。不要因为一个区域中的一个模型返回结构化输出故障而将整个提供者标记为不健康。尽可能按提供商、模型、区域、路由和错误类别跟踪运行状况。

一个简单的断路器状态机足以满足许多团队的需求：

• 已关闭： 正常流量流向该路由。
• 打开： 路由在错误阈值达到后暂时避免超出。
• 半开放：在完全流量恢复之前有限的探测流量测试恢复。

阈值应考虑到流量。一分钟内发生十次故障对于低容量路由可能有意义，但对于每分钟处理数千个请求的路由则无关紧要。使用最小样本量、滚动窗口和错误类过滤器。

建议： 断路器不应只计数 HTTP 次故障。他们还应该分别跟踪输出验证失败、超时率、速率限制率以及拒绝或阻止模式。这些类意味着不同的操作响应。

记录路由决策，而不仅仅是最终错误

改善用户体验的回退仍然会使事件更难以诊断。如果日志仅显示最终成功的提供程序，工程师将失去主要提供程序失败的证据。

每个请求都应记录：

• 原始提供程序、模型和路由。
• 使用时的回退提供程序、模型和路由。
• 触发重试或回退的错误类。
• 以下情况下的提供程序请求 ID：可用。
• 重试计数和退避持续时间。
• 每次尝试前消耗的最后期限。
• 输出验证结果。
• 每次尝试的预计成本和最终成本。
• 最终答案是来自主答案还是后备答案。
• 组织、工作区、环境和应用元数据，其中政策允许。

此遥测支持工程和商业治理。当不同的团队、产品或客户有不同的可靠性和预算政策时，它还会将回退行为与 AI API 成本控制联系起来。

衡量回退是否确实有帮助

原始成功率是不够的。回退策略可能会增加最终 200 个响应，同时使 p99 延迟更差、成本加倍或返回无效的结构化输出。

至少通过以下路径衡量这些指标：

• 主要成功率。
• 重试和回退后的最终成功率。
• 之前和之后的 p50、p95 和 p99 延迟回退后。
• 回退调用率。
• 每次成功响应的成本。
• 合同有效的响应率。
• 提供商的安全拒绝或阻止率。
• 来自特定应用的质量回归信号评估。

预测：随着越来越多的公司使用多提供商 LLM 基础架构，后备策略将变得更像流量工程，而不是临时异常处理。团队期望按工作区、环境和工作负载类别进行策略控制，并通过审核日志解释选择模型的原因。

实施清单

在生产路由上启用回退之前使用此清单：

• 定义路由的延迟预算和请求截止时间。
• 将提供程序错误分为可重试、符合回退条件和最终错误类。
• 记录哪些故障不得触发回退。
• 按工作负载类别列出批准的主要模型和回退模型。
• 验证每个回退的上下文长度、工具支持、架构支持和安全行为。
• 根据应用合同验证每个最终响应。
• 设置最大重试次数、回退、抖动和处理后重试。
• 按提供商、模型、区域和错误类别配置断路器。
• 设置成本乘数和后备支出限制。
• 记录请求 ID、错误类别、尝试、验证结果、延迟和成本。
• 在推出后查看 p95 和 p99 延迟，而不仅仅是平均值延迟。
• 测试提供程序中断、速率限制、无效架构、安全拒绝和输出验证失败场景。

可行的结论

良好的 LLM 后备策略是受管理的路由策略。它将重试与回退分开，对故障进行精确分类，保留输出合同，遵守延迟期限，并在事件发生之前使成本可见。

关键的设计原则是不变性。确定当流量从主要模型转移到后备模型时必须保持真实的内容：模式有效性、安全行为、上下文处理、工具支持、成本限制和可观察性。然后，仅当可以保留这些不变量时才允许回退。

从一条高价值路由开始，而不是全局回退开关。定义其错误分类、兼容的后备模型、验证规则、断路器和指标。针对该路线进行故障演习。如果最终成功率有所提高，且没有出现不可接受的 p99 延迟、合同有效的响应丢失或成本增加，则将该策略扩展到下一个工作负载类别。

相关阅读

• 按团队和应用分配 LLM 支出