此頁面目前僅提供簡體中文版本。導覽與選單已經是繁體中文。

智能路由

智能路由在同一模型的多个服务商之间动态分配请求。应用始终使用请求中的模型 ID，路由只选择由哪一家可用服务商处理，不会替换成其他模型。

路由决策

一次请求通常经过以下步骤：

1. 校验 API Key、项目、预算、限流和模型权限。
2. 按协议、模态和模型能力筛选可用服务商。
3. 排除停用、熔断或健康状态不符合要求的服务商。
4. 根据所选模式，对价格、TTFT、总延迟、吞吐和失败风险加权评分。
5. 按评分结果动态选择服务商并发送请求。
6. 将延迟、错误、Token、成本和重试写入 Trace 元数据。

选择路由策略

新项目建议先使用均衡模式，积累真实 Trace 后再调整。不要只凭一次压测选择长期策略。

价格优先

价格优先会在同一模型的可用服务商中提高价格因素的权重，通常让价格更低的服务商获得更多流量。它不会把请求替换成另一种便宜模型，也不是无条件固定到最低价服务商；健康状态、失败风险和动态探测仍会影响最终选择。对于 Token、请求次数或媒体时长等不同计费方式，平台会使用对应的计费配置进行比较。

速度优先

速度优先提高近期 TTFT、端到端延迟和吞吐量的权重，适合对响应速度敏感的交互式业务。平台使用近期请求数据持续调整选择概率；失败风险和价格仍参与评分，因此“速度优先”不等于忽略稳定性与成本。

均衡模式

均衡模式让价格、TTFT、总延迟、吞吐和失败风险共同参与决策，是新项目的默认起点。所有三种模式都会应用健康检查、异常检测和熔断；平台目前没有单独的“可用性优先”模式。

是否需要指定服务商

大多数应用只需选择模型并使用智能路由。以下情况可以考虑在产品支持的范围内限制服务商：

• 合规或数据区域要求明确指定处理方。
• 业务依赖某个服务商独有的能力。
• 正在进行可重复的服务商基准测试。

限制服务商会缩小路由选择空间，并降低自动故障转移带来的韧性。多服务商路由可以降低单一上游异常造成的中断风险，但不能承诺请求永不中断。

验证策略

按项目和模型观察至少一个完整业务周期，比较成功率、P50/P95 延迟、TTFT、重试率和单位请求成本。切换模式后，可通过请求记录和 X-Gateway-Trace-ID 判断变化来自路由、服务商还是流量结构。