路由与调用稳定性
为同一模型配置多个上游，可以分配流量并在上游异常时使用其他可用节点。本页说明现有路由配置，以及应用遇到限流和中断时的处理原则。
配置多上游
在管理员后台 AI 网关 → 商业 API 中编辑服务，添加各上游的 Endpoint、凭据和权重，并检查健康状态。请选择提供相同目标模型能力的上游，并核对请求参数和响应格式是否兼容。
| 路由策略 | 配置与适用场景 |
|---|---|
| 轮询 | 在上游间依次分配请求，适合独立调用；结合权重设置分配比例 |
| 会话哈希 | 将相同标识的请求尽量分配到同一节点，适合希望复用上游缓存的场景 |
会话哈希可指定 HTTP 请求头，例如 X-Session-Id；未指定会话头时，按调用者 ID 分流。哈希副本数表示哈希环虚拟节点数量，管理文档中的默认值为 64。配置界面见商业 API 管理。
会话哈希提供路由亲和性，不负责保存对话历史。调用方仍需按接口要求发送上下文；节点异常或路由配置变化时，请求可能转向其他节点。
健康检查与故障切换
网关提供上游健康检查、异常熔断、故障隔离与请求级切换。为使这些能力发挥作用，需要至少存在一个配置正确且满足访问要求的备用上游。
验证服务时，可以检查：
- 各上游在正常请求下是否可用，流量分布是否符合预期。
- 某个上游异常后，其健康状态与其他上游的请求分布是否变化。
- 故障恢复后，服务是否按当前配置恢复请求分配。
请在测试环境检查不同错误和请求阶段的切换结果。流式请求中断后，应用需保留已接收的内容，并根据业务状态决定是否重新发起请求。
限流、超时与客户端重试
TPM 限制单位时间内的 Token 使用量，与累计消费额度不同，参见额度、计量与费用。实际限流范围和阈值以部署配置为准。
应用应为请求设置可 接受的等待时间，并根据实际错误区分权限、额度、限流和上游故障。重试建议：
- 权限或额度错误先修正原因，反复重试不会使请求获得权限或额度。
- 对可恢复故障使用有次数和总时限的退避重试，避免持续增加上游压力。
- 流式中断后确认已收到的内容和业务状态，再决定是否重新发起完整请求。
- 涉及工具写操作时，在应用和工具服务中做好幂等处理，避免重试导致重复执行。
取消、断流或超时后，请检查上游请求的结束状态，并通过消费记录核对已产生的费用。