OpenAI SDK 多供应商路由模式：Fallback、分层成本与负载均衡

OpenAI Python SDK 接受一个 base_url 参数。换掉它，同一个 client.chat.completions.create() 调用就会打向通义千问百炼、DeepSeek、SiliconFlow 或其他任何兼容 OpenAI 的 endpoint。这个参数把单供应商集成变成了多供应商路由层，前提是你得知道哪些模式在生产环境里真正经得起考验，哪些只会带来更多麻烦。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

我们通过 TheRouter 做多供应商路由已经有一段时间，对什么模式扛得住有了自己的判断。这篇指南覆盖四种模式，给出可运行的代码、真实的定价数字，以及我们踩过的坑。TheRouter 把 OpenAI-compatible 请求路由到已配置的供应商，并在已上线的产品路径中支持 provider/model routing 和 fallback。我们不承诺零停机，不承诺支持所有模型，也不承诺一定最便宜。

模式 1：primary/fallback 链

最直白的多供应商模式就是一个有序列表。所有请求先走 primary provider，如果它返回了可重试的错误，再走下一个。你在定义一套明确的策略，规定哪些错误触发切换，哪些应该立即失败。

一个有效的 fallback 链需要四个决策。

1. Primary route. 正常流量走的供应商和模型。按成本、延迟或能力匹配来选。
2. Backup routes. 一到两个能接受相同请求体的替代方案，或者你知道可以安全转换请求体的方案。
3. 可重试的错误码. 临时性的 429、500、502、503、504。它们表示"再试一次"，不表示"你的请求有问题"。
4. 停止条件. 认证失败（401、403）、无效模型 ID、请求格式错误、计费问题。不要把一个坏请求连续发给三个供应商。

用 OpenAI SDK 手动做 fallback 的代码像这样。

import os
from openai import OpenAI

providers = [
    {
        "base_url": "https://api.deepseek.com/v1",
        "api_key": os.environ["DEEPSEEK_API_KEY"],
        "model": "deepseek-chat",
    },
    {
        "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1",
        "api_key": os.environ["DASHSCOPE_API_KEY"],
        "model": "qwen3.8-max",
    },
]

RETRYABLE = {429, 500, 502, 503, 504}

def chat(messages: list[dict]) -> str:
    last_error = None
    for p in providers:
        client = OpenAI(base_url=p["base_url"], api_key=p["api_key"])
        try:
            resp = client.chat.completions.create(
                model=p["model"], messages=messages
            )
            return resp.choices[0].message.content
        except Exception as e:
            status = getattr(e, "status_code", None)
            if status and status not in RETRYABLE:
                raise  # 非重试类错误，直接抛出
            last_error = e
    raise last_error

这个模式适合 backup 模型能处理同样 prompt 而不出现质量退化的场景。如果 backup 模型缺少 prompt 依赖的能力（vision、tool calling、超长 context），fallback 的结果就是垃圾。在把一个供应商加进 fallback 链之前验证模型能力，而不是等第一个用户投诉之后。

关于故障切换顺序、重试预算和监控的完整拆解，可以看我们的 LLM API fallback routing 指南。

模式 2：成本分层路由

成本分层路由把不同类型的请求分配到不同价格档位。日常摘要用不着 frontier 模型，复杂推理任务也不应该只为省钱就往最便宜的选项上扔。

一个实际的成本分层配置可能是这样。

来源 DeepSeek 定价、DashScope 定价、OpenAI 定价，检索于 2026-09-03。

路由决策发生在 API 调用之前，不在 SDK 内部。你先对请求做分类（通过 system prompt、调用方元数据、输入长度或显式的 tier 参数），然后选出对应的 client 配置。

import os
from openai import OpenAI

TIERS = {
    "economy": {
        "base_url": "https://api.deepseek.com/v1",
        "api_key": os.environ["DEEPSEEK_API_KEY"],
        "model": "deepseek-chat",
    },
    "standard": {
        "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1",
        "api_key": os.environ["DASHSCOPE_API_KEY"],
        "model": "qwen3.8-max",
    },
    "premium": {
        "base_url": "https://api.openai.com/v1",
        "api_key": os.environ["OPENAI_API_KEY"],
        "model": "gpt-5.5",
    },
}

def chat(messages: list[dict], tier: str = "standard") -> str:
    cfg = TIERS[tier]
    client = OpenAI(base_url=cfg["base_url"], api_key=cfg["api_key"])
    resp = client.chat.completions.create(
        model=cfg["model"], messages=messages
    )
    return resp.choices[0].message.content

难点不在代码，在分类。一个看起来很简单的请求可能依赖推理深度，扔给 economy tier 就会输出垃圾。建议先从手动 tier 分配开始（调用方自己选），等积累了足够的标注数据再做自动分类。

更多供应商的定价细节，可以看我们的 LLM API 供应商比较 和 成本优化路由策略。

模式 3：按内容路由

按内容路由检查请求的实际内容，然后把它发给最合适的供应商。这比成本分层更进一步，它考虑能力匹配、context 长度和模态。

按内容路由的规则举例。

• Vision 请求（消息里包含图片 URL 或 base64 图片）路由到支持视觉的模型。Qwen3.8-Max、GPT-5.5 和 Claude 都支持。不要把图片内容发给纯文本模型。
• 长 context 请求（输入 token 数超过 32K）路由到有大 context window 的模型。Qwen3.7-Max 支持 1M tokens，DeepSeek V4 支持 128K。把 200K token 的 prompt 发给 32K context 的模型，要么静默截断，要么直接报错。
• Tool-calling 请求路由到 function calling 实现可靠的模型。不是每个 OpenAI-compatible 供应商对 tools 和 tool_choice 的实现都一样。可以看我们的 function calling 跨供应商比较 了解差异。
• 推理密集请求（数学证明、多步规划、复杂系统的代码生成）路由到支持 extended thinking 或 chain-of-thought 的模型。

def classify_and_route(messages: list[dict], tools: list | None = None) -> dict:
    has_images = any(
        isinstance(c, dict) and c.get("type") == "image_url"
        for m in messages
        for c in (m.get("content") if isinstance(m.get("content"), list) else [])
    )
    estimated_tokens = sum(len(str(m.get("content", ""))) // 4 for m in messages)

    if has_images:
        return TIERS["standard"]  # 视觉模型
    if estimated_tokens > 32_000:
        return TIERS["standard"]  # 大 context
    if tools:
        return TIERS["premium"]   # 可靠的 tool calling
    return TIERS["economy"]       # 默认走最便宜的

按内容路由是最强大的模式，也是最脆弱的。每条路由规则都是对模型能力的假设，供应商更新模型时这些假设可能失效。在路由层建好可观测性，记录每条规则的触发情况和下游响应质量，在用户发现问题之前就捕获退化。

模式 4：地理路由

地理路由根据请求的来源地区或数据必须留在哪里来选择供应商。这个模式重要有两个原因，一个是延迟，一个是合规。

来源 DashScope OpenAI 兼容、OpenAI Python SDK 参考、DeepSeek API 文档，检索于 2026-09-03。

路由决策用的是请求元数据（IP 地理位置、显式的 region header 或部署区域）来选择供应商。

import os
from openai import OpenAI

REGION_MAP = {
    "cn": {
        "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1",
        "api_key": os.environ["DASHSCOPE_API_KEY"],
        "model": "qwen3.8-max",
    },
    "ap": {
        "base_url": os.environ.get(
            "DASHSCOPE_SG_BASE_URL",
            "https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
        ),
        "api_key": os.environ["DASHSCOPE_API_KEY"],
        "model": "qwen3.8-max",
    },
    "global": {
        "base_url": "https://api.openai.com/v1",
        "api_key": os.environ["OPENAI_API_KEY"],
        "model": "gpt-5.5",
    },
}

def chat(messages: list[dict], region: str = "global") -> str:
    cfg = REGION_MAP.get(region, REGION_MAP["global"])
    client = OpenAI(base_url=cfg["base_url"], api_key=cfg["api_key"])
    resp = client.chat.completions.create(
        model=cfg["model"], messages=messages
    )
    return resp.choices[0].message.content

DashScope 一直在向 workspace 专属域名迁移。如果你还在用旧的 dashscope.aliyuncs.com 或 dashscope-intl.aliyuncs.com，建议查看官方迁移公告，切换到 {WorkspaceId}.{region}.maas.aliyuncs.com 格式。旧 endpoint 还能用，但可能不再获得性能优化。来源 DashScope OpenAI 兼容，检索于 2026-09-03。

地理路由经常和模式 1（fallback）一起用。如果区域供应商宕了，就 fallback 到全球供应商，而不是直接返回错误。跨区域 fallback 带来的延迟惩罚几乎总是好过一次停机。

组合模式：生产级路由策略

在实际生产环境中，你会组合多种模式。一个完整的路由策略可能是这样的流程。

1. 分类请求。按内容类型、复杂度和地区做判断。
2. 选择 primary provider。综合内容路由、地理路由和成本分层的结果。
3. Fallback。如果 primary 返回可重试的错误，走 fallback 链。
4. 日志。记录每一次路由决策，包括触发了哪条规则、选了哪个供应商、响应状态码。

TheRouter 在 gateway 层面处理这种组合。你不需要在应用代码里自己写路由逻辑和维护 fallback，而是用声明式配置来定义路由规则，由 gateway 处理故障切换、重试和供应商选择。TheRouter 把 OpenAI-compatible 请求路由到已配置的供应商，并在已上线的产品路径中支持 provider/model routing 和 fallback。

关于处理这种组合的 gateway 比较，可以看我们的 LLM API gateway 统一比较 和 OpenRouter 替代方案比较。

生产检查清单

把多供应商路由推到生产环境之前，逐项验证以下内容。

1. API key 隔离。 每个供应商的 key 放在独立的环境变量里。不要跨供应商共享 key。按周期轮换。关于 key 治理模式，可以看我们的 API key 管理指南。
2. 模型 ID 映射。 同一个概念上的模型在不同供应商的 ID 不同。DeepSeek 上叫 deepseek-chat，DashScope 上叫 qwen3.8-max，OpenAI 上叫 gpt-5.5。你的路由层必须做映射。
3. 错误处理。 不是所有供应商返回错误的格式都一样。OpenAI SDK 会标准化大部分错误，但存在边界情况。可以看我们的跨供应商错误处理参考。
4. Streaming 兼容性。 如果用了 streaming（stream=True），需要验证路由表里每个供应商都支持同一 chunk 格式的 SSE streaming。可以看我们的 streaming SSE 实现指南。
5. Rate limit 感知。 每个供应商有自己的速率限制。一次故障切换把所有流量打到 backup 供应商，可能几分钟就把它的 quota 跑满。可以看我们的 rate limit 比较。
6. 成本监控。 按供应商、按 tier、按请求类型追踪成本。一条配错的路由规则可以无声地把账单放大 10 倍。
7. 超时配置。 为每个供应商设置独立的 timeout。一个慢的供应商应该触发 fallback，而不是无限阻塞请求。
8. 健康检查。 主动检查供应商健康状态，而不是通过用户报错来发现故障。

FAQ

能不能用同一个 API key 调多个 OpenAI-compatible 供应商？

不能。每个供应商发自己的 API key。DashScope 的 key 还和区域绑定，在北京区域创建的 key 不能用在新加坡的 endpoint 上。来源 DashScope 跨区域文档，检索于 2026-09-03。

OpenAI SDK 能和这里列出的所有供应商一起用吗？

OpenAI Python SDK（openai 包）可以和任何实现了 /v1/chat/completions endpoint 的供应商一起用。DashScope、DeepSeek、SiliconFlow 和其他很多供应商都支持。供应商专有的扩展（额外的响应字段、非标准参数）不一定被 SDK 保留。关于各供应商的具体细节，可以看我们的 OpenAI-compatible API 供应商参考。

怎么处理不同供应商的 context length 限制？

在路由之前先估算输入 token 数。如果超过了某个供应商的 context window，就路由到 window 更大的供应商。不要指望供应商会优雅地拒绝超长请求，有些供应商会静默截断。

应该每个请求新建一个 OpenAI client 还是复用？

为每个供应商配置创建一个 client，然后复用。OpenAI SDK 内部做了连接池，每次请求新建 client 会浪费连接、增加延迟。

TheRouter 怎么处理这些模式？

TheRouter 在 gateway 层面实现这些路由模式，你的应用代码只需要一个指向 TheRouter endpoint 的 OpenAI SDK 调用。路由规则、fallback 链和供应商选择都在 gateway 配置里完成。可以看 TheRouter 快速开始 和 model fallbacks 文档 了解配置细节。