供应商路由 — 多源负载均衡

概述

当前仓库中的“供应商路由”主要由后台 models 表、provider_api_keys 表和 ModelRouter 共同完成。客户端只需要传入 model，网关会在后台解析 provider、model_code、base_url 与上游 Key。

路由策略

1. 模型映射

先根据请求中的 model 查询后台模型记录，确定其 provider、model_code 与 base_url：

配置示例

                        model_id: qwen3.5-plus
provider: bailian
model_code: qwen3.5-plus
base_url: https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions
                    

对于图像能力，推荐把同一个上游模型拆成多个入口，例如 qwen-image-2.0-pro_t2i 与 qwen-image-2.0-pro_i2i。这样路由层可以直接根据 model_id 选择不同的真实提交地址和操作类型，而不需要在适配器里猜测。

2. 提供商 Key 选择

当同一 provider 配置了多把上游 Key 时，系统会从可用 Key 中按权重选择一把用于请求：

配置示例

                        provider: openai_compatible
provider_api_keys:
  - key_a (weight=100)
  - key_b (weight=50)
                    

控制台展示层会把 openai_compatible 的显示名为 OpenAI，但配置值仍为 openai_compatible，不要在数据库或脚本里把它改写成别的 provider 值。

3. 能力与类型校验

路由成功并不代表一定可用，请继续根据模型类型和能力标记校验接口适配性：

配置示例

                        type: chat / image / video / audio / embedding
capabilities:
  - responses_api
  - vision_input
  - audio_input
  - realtime
                    

配置方式

当前这些配置主要在后台模型管理和上游 Key 管理中完成；仓库内未发现对外公开的“按请求传 Header 自定义路由”的能力。

应用场景

统一入口：前台只关心模型 ID，不关心上游 provider 细节
Key 级分流：同 provider 多 Key 时减轻单 Key 压力
能力隔离：通过模型类型和能力标记区分 chat / image / video 等入口
后台管控：通过启用/停用模型控制对外可用列表

💡 提示

如果您需要真正的多 provider 策略切换，请优先在后台维护多个模型记录和多个 provider Key，而不是在前台文档中承诺未开放的动态路由 Header。