多供应商 Token 网关和普通 API 网关有什么区别？

普通 API 网关的路由是静态的——路径到后端服务的映射在部署时确定。Token 多供应商网关的路由是动态的——每次请求都要根据当前各供应商的价格、延迟、可用性、配额余量等实时指标决定发到哪家。这更像一个实时交易路由层，而不仅仅是代理层。

路由策略用轮询还是按价格加权？

轮询只适合各供应商完全同质化的场景，实际中很少见。推荐按价格加权 + 延迟惩罚的动态策略：基础权重与价格成反比，同时叠加近 5 分钟的 p99 延迟作为惩罚因子——某供应商延迟升高时自动降低其权重。这个策略不需要复杂的预测模型，实现简单且效果稳定。

供应商故障怎么快速检测和切换？

两阶段检测：第一层是被动检测——请求超时或返回 5xx 时计数，达到阈值（如连续 5 次失败）标记为"疑似故障"；第二层是主动探测——对被标记的供应商每隔 10 秒发一次健康检查请求，连续 3 次成功则恢复。切换时不要直接摘除，而是渐进降权，防止所有流量瞬间打到剩下供应商造成雪崩。

请求重试的幂等怎么保证？

需要在网关层给每个请求分配全局唯一 ID（request_id），供应商在响应中回传这个 ID。网关重试时带上相同的 request_id，供应商侧根据 ID 去重——同一个 ID 的请求即使收到多次也只执行一次。这个机制需要供应商配合实现，如果供应商不支持去重，网关层只能做"至少一次"语义，由业务方自行处理重复。

大模型 Token 多供应商算力撮合：网关架构、路由策略与容错设计

多供应商 Token 聚合网关的核心是路由层：按价格、延迟、可用性动态分配请求，供应商故障时自动容错。本文从网关分层架构出发，讨论路由算法选型、熔断与降级的工程实现，以及请求重试的幂等保证——适合正在评估或自建 Token 聚合服务的架构师和技术负责人。

先说结论：多供应商 Token 网关的核心不是”能调多个 API”，而是”能在供应商之间做实时路由决策”

AI Token 平台架构那篇讨论了 Token 聚合的整体架构，本文聚焦其中的路由与容错层——这是多供应商网关最核心、也最容易被低估复杂度的部分。

1. 网关分层架构

一个可运维的多供应商 Token 网关分为三层：

客户端 → 接入层 → 路由层 → 供应商适配层 → 各 AI 供应商 API

接入层：统一入口，负责认证、限流、计费日志。对所有客户端暴露同一套 API，屏蔽后端供应商差异。

路由层：这是核心。每次请求进来，路由层根据当前各供应商的实时状态决定发到哪家。决策输入包括：各供应商的实时价格、历史延迟（p50/p95/p99）、当前可用性、配额余量、以及请求本身的约束（如模型类型、优先级）。

供应商适配层：将统一的内部请求格式转化为各供应商的 API 格式，处理认证方式差异（API Key 位置、签名算法）、响应格式差异、以及错误码映射。每接入一个新供应商，只需在这一层添加一个适配器。

2. 路由算法选型

算法一：按价格加权（推荐）

权重_i = 基准价 / 供应商_i 的当前价
选择概率_i = 权重_i / 所有权重之和

价格越低，被选中的概率越高。这个策略简单直观，但有两个问题：

只考虑价格，不考虑质量：最便宜的供应商可能延迟最高或稳定性最差
价格变动时可能出现流量震荡：某供应商降价 → 大量流量涌入 → 该供应商延迟升高 → 体验变差

算法二：价格加权 + 延迟惩罚（推荐方案）

权重_i = (基准价 / 价格_i) × clamp(1 - (p99_i - p99_基准) / p99_基准, 0.3, 1.0)

在价格加权的基础上，叠加近 5 分钟的 p99 延迟作为惩罚因子。延迟越高的供应商权重越低，但有一个下限（0.3），防止完全被饿死。

这个方案的优点是：

不需要预测模型，计算成本极低
价格和质量的平衡是自动的
流量震荡被延迟惩罚阻尼

算法三：加权轮询 + 熔断保护

对于对延迟不敏感、但对吞吐量有要求的场景（如批处理），可以用加权轮询。但必须配合熔断器——当某供应商的错误率超过阈值时，熔断器打开，直接跳过该供应商，不再向其分配流量。

3. 熔断与降级

熔断器状态机

关闭（正常转发）
  → 错误率超过阈值（如连续 5 次失败或 5 分钟内错误率 > 30%）
  → 打开（直接失败，不转发）
  → 半开（经过超时窗口后，放行少量请求试探）
  → 成功则关闭，失败则继续打开

熔断器是按供应商粒度配置的——一个供应商熔断不影响其他供应商。熔断器状态需要暴露到监控面板，方便排查。

降级策略

当所有供应商都不可用或配额耗尽时，网关应优雅降级而非直接报错：

降级到缓存：对非实时性请求（如文本补全的缓存命中），返回缓存结果
降级到排队：对实时请求，返回队列位置估计，客户端轮询结果
降级到友好错误：返回”当前算力紧张，请稍后重试”而非裸 502

4. 请求重试的幂等性

重试是多供应商网关最隐蔽的坑。一个请求发到供应商 A，超时了，重试发到供应商 B，结果供应商 A 其实执行成功了——那用户被扣了两次钱。

解决方案：request_id 去重

网关层为每个请求生成全局唯一的 request_id（UUID 或雪花 ID），供应商侧承诺：

同一个 request_id 的请求，即使收到多次，也只执行一次

如果供应商不支持幂等去重，网关层只能退而求其次：

读操作（如查询余额）可直接重试，无副作用
写操作（如发起推理）需要业务方在应用层做去重，或在网关层记录已发送的 request_id 做短暂去重（5 分钟内收到的相同 ID 请求直接返回上一次的结果）

5. 配额管理

每个供应商都有调用频率和总量限制。网关需要维护一个配额跟踪表：

供应商	模型	分钟配额	已用	剩余	配额重置时间
A	GPT-4	1000	342	658	2026-07-24 12:00
B	Claude-3	800	800	0	2026-07-24 12:00

路由层在决策时排除配额已耗尽的供应商。配额重置前 5 分钟，可以开始预分配请求给即将恢复的供应商，避免瞬间流量冲击。

总结

模块	关键决策	常见错误
路由算法	价格加权 + 延迟惩罚	只用价格加权，忽略质量
熔断器	按供应商粒度 + 半开状态	全局熔断，一崩全崩
重试	request_id 去重	幂等不保证，重复扣费
配额	实时跟踪 + 预分配	只在配额耗尽时报错
适配层	适配器模式	路由逻辑和适配逻辑混在一起

多供应商网关的复杂度不在”连上 API”，而在”供应商之间做实时决策”——路由、熔断、重试、配额，每一个模块单独看都不难，组合起来才是真正的工程挑战。