供应商

Cordy Gateway 本身不托管模型。它把你客户端的请求路由到你所配置的上游供应商。本页介绍两条集成路径、受支持的上游，以及如何在 Admin 中接线一个供应商、通道与模型。

两条集成路径

每个通道通过以下两条路径之一抵达其上游：

1. LiteLLM——默认路径，通过单一集成即可访问 100+ 家供应商与模型。它把各供应商的 API 归一化为 OpenAI 形态。
2. 直连的兼容 OpenAI 透传——对于已经使用 OpenAI Chat Completions API 的上游，网关可通过池化的 httpx 客户端转发请求，不做翻译。数据平面实现了对话（一元与流式）、嵌入与文本补全。

当前源码限制：数据平面从 Channel.config.base_url 读取自定义端点，但当前 Channel 表单只保存 endpoint_url，不会写入该运行时设置；表单也没有原始通道 config 编辑器，受支持的通道导入命令也不接受端点。因此，此版本没有通过 Admin 或导入命令启用自定义/自托管端点的受支持流程。在产品连通这些字段之前，请勿依赖直连路径。下文步骤仅覆盖使用内置端点的供应商。

受支持的上游

运行时供应商注册表识别以下常见类型。Admin 也接受其他大写供应商标识，但接受标识并不能证明端点与鉴权字段构成可用集成。请使用下文的内置端点流程；自定义端点仍受上面限制约束。

• OpenAI
• Anthropic
• Azure OpenAI
• AWS Bedrock
• Google Vertex / Gemini
• Cohere
• Groq
• Together AI
• DeepInfra
• OpenRouter
• Mistral
• DeepSeek
• Hugging Face
• Replicate

运行时还包含 Ollama，以及 vLLM、火山引擎 Ark 等兼容 OpenAI 服务器的适配器。它们需要自定义端点，因此当前 Admin 接线限制使本版本的公开运维界面无法完成一套受支持的配置。

配置链

服务一个模型需要一小组记录，在 Admin 的 Gateway Configuration 下一次性创建：

Provider → Public model → Provider model → Channel → Channel-provider-model

它们在请求时如何解析见核心概念。以下步骤按序构建它们。

1. 添加供应商

为上游厂商创建一个 Provider：

• name——唯一的内部名，例如 openai-main。
• provider_type——大写标记，例如 OPENAI、ANTHROPIC、BEDROCK 或 CUSTOM。
• base_url——此源码快照中的控制平面元数据。使用内置供应商端点时留空；它不会提供数据平面读取的通道端点。
• status——ACTIVE。

供应商是全局系统资源。凭据不存放在供应商上——它们存放在其通道上。

2. 定义公开模型

创建一个 Public model——你客户端将在 model 字段中请求的 slug：

• slug——公开标识，例如 gpt-4o-mini。唯一。
• display_name、description——用于目录。
• status——ACTIVE；若希望出现在列表中则 is_public。

这是客户端唯一能看到的模型名。它由你掌控，无需匹配任何厂商的命名。

3. 映射供应商模型

创建一个 Provider model，把 Provider 与 Public model 关联到具体上游模型：

• provider_model_name——真实厂商模型字符串，例如 gpt-4o-mini。
• supports_chat、supports_embeddings、supports_streaming、context_window——能力标志。
• status——ACTIVE。

在该供应商模型下添加一条 Price history 记录用于计量：每 1,000 token 的输入/输出价格、货币、美元汇率、来源和生效起止窗口。同一供应商模型的价格窗口不能重叠；Price history 是请求成本的权威来源。

4. 添加通道

在供应商上创建一个 Channel——一个带自有凭据的具体路由目标：

• 上游凭据——供应商 API 密钥。它以 Fernet 静态加密存储；保存后 Admin 绝不返回明文。对 Bedrock，AWS secret 以同样方式存储。
• endpoint_url——显示在 Channel 表单上，但此源码快照尚未把它连到数据平面。内置端点应留空；规划自定义端点前请先阅读上面的限制。
• weight——加权路由的相对份额（默认 100）。
• priority——优先级更高的通道被优先选择；加权挑选在最高优先级带内进行（默认 0）。
• region——例如 us-east，用于区域感知路由。
• cost_weight——路由成本分数的乘子（>1 偏离，<1 偏向）。
• rate_limit、concurrent_limit、timeout_seconds——按通道的守卫。
• 冷却设置——可选地在反复出错后将抖动通道移出轮转。
• status——ACTIVE。

5. 在通道上启用该模型

创建一个 Channel-provider-model，把 Channel 与 Provider model 绑定。这才真正在该通道上启用该模型。该供应商模型必须属于该通道所属的供应商——你不能把供应商 B 的模型绑定到供应商 A 的通道上。

一旦至少有一个活跃通道绑定到该模型，公开模型即变为可路由，并在 GET /v1/models 中对被允许使用它的密钥显示。

跨通道路由

由于一个公开模型可由多个通道提供服务，你可以：

• 用 weight 在同一供应商的多个密钥或账户间负载均衡。
• 用 priority 优先某个主通道，并自动回退到其他通道。
• 当某个供应商宕机时完全故障转移到另一供应商——把同一公开模型绑定到不同供应商上的通道。
• 用 cost_weight 配合 cheapest 策略按成本偏置。
• 用 region 配合 region_aware 策略按区域路由。

路由策略由 GATEWAY_DEFAULT_ROUTING_STRATEGY 全局设置（默认 weighted），并可用 X-Routing-Strategy 请求头按请求覆盖：

策略	选择
weighted	优先级带内加权随机。
cheapest	路由成本分数 × cost_weight 最低。当前源码仍读取隐藏的旧 ProviderModel 价格列，而非 PriceHistory；使用前须验证。
fastest	观测 P95 时延最低；无数据时回退 weighted。
region_aware	先区域匹配，再加权。

故障转移、冷却与熔断器见核心概念。

完整示例

让一个公开模型 gpt-4o-mini 由两个 OpenAI 账户提供：

1. Provider： openai-main（provider_type: OPENAI、status: ACTIVE）。
2. Public model： slug gpt-4o-mini。
3. Provider model： 在 openai-main 下创建 provider_model_name: gpt-4o-mini，并添加一条不重叠的有效 Price history。
4. Channels： openai-account-a 与 openai-account-b，各自保存一把加密的 OpenAI 密钥，均设置 priority: 0、weight: 100。
5. Channel-provider-models： 把两个通道都绑定到该供应商模型，并保持两条绑定处于活跃状态。

客户端现在调用 model: "gpt-4o-mini"；默认 weighted 策略会在两个通道间分配请求，并可在其中一个不可用时故障转移。调整权重即可改变相对份额。

凭据安全

• 客户端仅以 wnx_ 网关密钥鉴权。它们从不看到、发送或接收上游供应商密钥。
• 上游凭据在通道记录中以 Fernet 加密存储，仅在派发请求时于内存中解密。见安全。
• 轮换上游密钥是 Admin 中的一次通道编辑；无需任何客户端改动。

后续步骤

• 核心概念——路由与故障转移如何工作。
• Admin 控制台——用户、密钥、配额、定价与监控。
• 安全——凭据加密与信任模型。
• 部署——规模化运行。