TheRouter.aiTheRouter.ai
← 全部文章

LLM API Fallback Routing：构建更稳的多供应商 AI 应用

LLM API fallback routing 实战指南：故障切换顺序、重试、延迟、成本护栏、监控，以及 OpenAI-compatible SDK 示例。

· TheRouter

LLM API Fallback Routing：构建更稳的多供应商 AI 应用

LLM API fallback routing 的意思是：当第一条供应商、模型或区域路径不可用、被限流、延迟过高或超出预算时，应用可以尝试备用路径。好的方案不是“随机换一个供应商试试”，而是一套可观测的路由策略：分类失败、谨慎重试、保持请求兼容、限制成本、监控每一次跳转，并保留人工覆盖能力。

TheRouter 做的正是这层运行时能力。我们会把 OpenAI-compatible 请求路由到已配置的供应商，并在已实现的产品路径中支持 provider/model routing 和 fallback。本文只讲可验证的工程模式，不承诺零停机、支持所有模型，也不承诺一定最便宜。

为什么 LLM API fallback routing 重要

LLM API 依赖快速变化的模型目录、配额系统、区域 endpoint 和供应商自身的稳定性。生产应用可能因为上游返回 429、模型 ID 变更、某个区域变慢、账户 quota 用尽，或供应商 incident 而失败。OpenAI 文档说明 rate limits 可能按模型或账户维度生效，并建议对 429 使用 exponential backoff；错误码文档也区分了认证、权限、限流和服务端错误。来源：OpenAI rate limits、OpenAI error codes，检索于 2026-06-08。

Fallback routing 把这类风险变成策略问题。不要把供应商专属重试逻辑散落在每个业务服务里，而应把决策放在 API 边界：哪些错误可重试、哪个备用模型可接受、下一次应该走哪个供应商，以及什么时候应该快速失败。

策略 1：按顺序做 provider failover

最简单的 LLM API fallback routing 是有序列表：先走 primary provider，再走一到两个能满足同一请求形态的 backup。它适合“正确性和兼容性比极致省钱更重要”的场景。

一条可靠的有序 failover 规则至少包含四项：

  1. Primary route：首选供应商或模型。
  2. Compatible backups：能接受同一 OpenAI-compatible 请求体，或已知可安全转换的请求体。
  3. Retryable status codes：例如临时的 429、500、502、503、504。
  4. Stop conditions：认证错误、无效模型 ID、请求格式错误或策略错误。

不要对所有错误都 fallback。如果请求本身无效，把它发给三个供应商只会让排障更混乱。如果是 quota 或 billing 错误，需要的是人工处理和告警，而不是继续重试。

策略 2：weighted routing 与成本护栏

Weighted routing 会按比例把流量分发给多个供应商。它适合逐步迁移、新模型灰度，或给高价值请求保留更强模型。但它必须搭配成本护栏，因为备用路径可能比 primary route 贵很多。

一个实际策略可以是：日常摘要 80% 走低成本模型，20% 走第二供应商用于健康采样；客服升级请求则直接走更强模型。关于供应商比较和配置，可继续看我们的 OpenAI-compatible API providers、中国 OpenAI-compatible APIs、SiliconFlow、阿里云百炼 Model Studio 和 DeepSeek 页面。

重点是统计“每次成功请求的有效成本”，而不是只看标价。重试、更长输出、缓存未命中和失败尝试都会改变真实账单。

策略 3：按延迟选择 provider

Latency-aware routing 会根据近期性能选择供应商。它比有序 failover 更复杂，因为你需要新鲜 telemetry：首 token 时间、总生成时间、错误率和区域延迟。

这类规则要谨慎使用。一个供应商可能短对话最快，却不适合长上下文代码分析。Streaming 也会影响体验：首 token 很快但尾部较慢的模型，在聊天界面里可能比总耗时更短但长时间沉默的模型更好用。

稳妥做法是：保留首选 route，持续测量 backup health，并且只有当 backup 有足够近期成功样本时才迁移流量。不要基于一次慢请求做路由判断。

OpenAI-compatible SDK 示例

OpenAI Python SDK 支持自定义 base_url，这也是很多 OpenAI-compatible providers 能在不大改应用代码的情况下切换的原因。来源：OpenAI libraries，检索于 2026-06-08。

from openai import OpenAI, APIError, RateLimitError

ROUTES = [
    {
        "name": "primary",
        "base_url": "https://api.primary-provider.example/v1",
        "api_key": "PRIMARY_API_KEY",
        "model": "primary-chat-model",
    },
    {
        "name": "backup",
        "base_url": "https://api.backup-provider.example/v1",
        "api_key": "BACKUP_API_KEY",
        "model": "backup-chat-model",
    },
]

def is_retryable(exc: Exception) -> bool:
    status = getattr(exc, "status_code", None)
    return isinstance(exc, RateLimitError) or status in {500, 502, 503, 504}

def chat_with_fallback(messages):
    last_error = None
    for route in ROUTES:
        client = OpenAI(api_key=route["api_key"], base_url=route["base_url"])
        try:
            return client.chat.completions.create(
                model=route["model"],
                messages=messages,
                timeout=30,
            )
        except APIError as exc:
            last_error = exc
            if not is_retryable(exc):
                raise
    raise last_error

这个示例刻意保持精简。生产代码还应加入带 jitter 的有界重试、request ID、结构化日志、idempotency 规则，以及清晰的 model substitution 策略。

Router 应该保留哪些信息

Routing layer 应该让供应商切换更安全，而不是危险地“透明”。至少要保留 request ID、实际 provider、实际 model、status code、latency、可用时的 token usage，以及 fallback reason。如果某个 provider 返回只有它自己支持的字段，只有在文档或代码验证后才应保留；不要假设所有上游响应形态完全一致。

Solo.io Agentgateway 文档把 OpenAI-compatible provider configuration 放在 gateway 层，用于集中处理 routing、policy 和 provider setup。Portkey 也记录了用 unified API 在多个供应商之间路由请求的方式。来源：Agentgateway OpenAI-compatible provider docs、Portkey unified API guide，检索于 2026-06-08。

信任 fallback 前要监控什么

日志或指标至少应回答这些问题：

  • 哪个 provider 处理了请求？
  • 这是 primary route 还是 fallback route？
  • 哪个错误触发了 fallback？
  • 总共尝试了几次？
  • 首 token 时间和总延迟是多少？
  • Backup model 是否改变了输出质量或 token usage？
  • Fallback 是否让该 workload 超出预算？

告警不应只看总错误数，也要看持续 fallback 量。用户侧可能看起来“都成功了”，但系统已经悄悄把 60% 流量送到了更贵的 backup。

Production checklist

在把 LLM API fallback routing 用到客户流量前，先确认这些基础项：

  • 定义 retryable 与 non-retryable errors。
  • 确保 backup models 与请求形态兼容。
  • 设置 per-route budget 和 max-attempt limits。
  • 记录 provider、model、latency、status、token usage 和 fallback reason。
  • 在真实 incident 前做 synthetic failure 测试。
  • 保留手动禁用某个 provider 的 override。
  • 说明哪些 workload 可以使用更低成本或能力较弱的 backup。
  • 流量迁移前复核 provider terms、数据处理规则和区域要求。

FAQ

Fallback routing 和 load balancing 一样吗？

不一样。Load balancing 分发正常流量；fallback routing 处理首选路径不健康、被限流、太慢或不可用时的异常。很多团队会同时使用两者。

Fallback routing 能保证零停机吗？

不能。它降低一类上游依赖风险，但不能保证零停机。你自己的网络、请求兼容性、供应商账户状态、quota 和应用逻辑依然会影响可用性。

每个请求都应该有 backup model 吗？

不一定。有些 workload 对模型差异很敏感。对合规、评测或需要稳定行为的流程来说，快速失败并告警可能比静默切换模型更安全。

TheRouter 在哪里发挥作用？

TheRouter 位于应用和上游供应商之间，作为 API routing layer。我们会把 OpenAI-compatible 请求路由到已配置的供应商，并在已实现的路径中支持 provider/model routing 和 fallback。可以从我们的 docs 开始，也可以先比较 OpenAI-compatible API providers。

Sources 检索于 2026-06-08: OpenAI rate limits, OpenAI error codes, OpenAI libraries, Agentgateway OpenAI-compatible provider docs, Portkey unified API guide. Provider capabilities and pricing change; verify live docs before procurement or migration decisions.

帮助与联系