智能路由
智能路由在同一模型的多个服务商之间动态分配请求。应用始终使用请求中的模型 ID，路由只选择由哪一家可用服务商处理，不会替换成其他模型。
路由决策
一次请求通常经过以下步骤：
- 校验 API Key、项目、预算、限流和模型权限。
- 按协议、模态和模型能力筛选可用服务商。
- 排除停用、熔断或健康状态不符合要求的服务商。
- 根据所选模式，对价格、TTFT、总延迟、吞吐和失败风险加权评分。
模态校验会读取请求内容：携带图像、音频或视频输入的请求，只会路由到为该模型声明对应理解能力的服务商。若没有可用服务商声明该能力，网关返回 INPUT_MODALITY_NOT_SUPPORTED，不会把请求转发给无法处理该输入的服务商。
5. 按评分结果动态选择服务商并发送请求。
6. 将延迟、错误、Token、成本和重试写入 Trace 元数据。
选择路由策略
| 策略 | 优先目标 | 适合场景 | 主要取舍 |
|---|---|---|---|
| 均衡模式 | 兼顾价格、TTFT、总延迟、吞吐和失败风险 | 大多数在线业务、新项目 | 不追求单一指标的极致 |
| 价格优先 | 提高价格在综合评分中的权重 | 批处理、离线生成 | 仍会保留少量流量用于动态评估，延迟可能更高 |
| 速度优先 | 提高 TTFT、总延迟和吞吐在综合评分中的权重 | 对话、代码补全、实时交互 | 可能选择价格更高的服务商 |
新项目建议先使用均衡模式，积累真实 Trace 后再调整。不要只凭一次压测选择长期策略。
价格优先
价格优先会在同一模型的可用服务商中提高价格因素的权重，通常让价格更低的服务商获得更多流量。它不会把请求替换成另一种便宜模型，也不是无条件固定到最低价服务商；健康状态、失败风险和动态探测仍会影响最终选择。对于 Token、请求次数或媒体时长等不同计费方式，平台会使用对应的计费配置进行比较。
速度优先
速度优先提高近期 TTFT、端到端延迟和吞吐量的权重，适合对响应速度敏感的交互式业务。平台使用近期请求数据持续调整选择概率；失败风险和价格仍参与评分，因此“速度优先”不等于忽略稳定性与成本。
均衡模式
均衡模式让价格、TTFT、总延迟、吞吐和失败风险共同参与决策，是新项目的默认起点。所有三种模式都会应用健康检查、异常检测和熔断；平台目前没有单独的“可用性优先”模式。
是否需要指定服务商
请求可通过可选请求头 X-InOneAPI-Provider 固定到模型详情页展示的服务商名称，例如 X-InOneAPI-Provider: 腾讯云。指定后，低价、速度和均衡路由模式不参与服务商选择；网关只会请求该服务商。该服务商配置的多个 API Key 仍可在内部轮换或重试，但不会切换到其他服务商。指定服务商不支持当前模型或 API 时，网关返回 PROVIDER_NOT_AVAILABLE；该服务商暂时不可用时，请求失败也不会回退到其他服务商。复制模型详情页的服务商名称即可使用。
大多数应用只需选择模型并使用智能路由。以下情况可以考虑在产品支持的范围内限制服务商：
- 合规或数据区域要求明确指定处理方。
- 业务依赖某个服务商独有的能力。
- 正在进行可重复的服务商基准测试。
限制服务商会缩小路由选择空间，并降低自动故障转移带来的韧性。多服务商路由可以降低单一上游异常造成的中断风险，但不能承诺请求永不中断。
验证策略
按项目和模型观察至少一个完整业务周期，比较成功率、P50/P95 延迟、TTFT、重试率和单位请求成本。切换模式后，可通过请求记录和 X-Gateway-Trace-ID 判断变化来自路由、服务商还是流量结构。