故障转移

故障转移指某个供应商失败时,自动改试同组的下一个候选。它让你在单个供应商抖动、限流或鉴权失效时,请求仍然能跑完。

什么时候换下一个

情况行为
网络错误 / 连接超时 / 流式空闲超时换下一个候选。
401 / 403换下一个候选,并计为该供应商的一次失败。
408 / 429换下一个候选。
5xx换下一个候选。
其他 4xx按原样返回,不换。

流式已开始就不再拼接

流式响应一旦已经开始下发,中途断掉就中止,不会把多个渠道的输出拼在一起。

冷却

连续失败累计到阈值后,该供应商(或该供应商模型)进入冷却,从候选里暂时移除:

  • 冷却期间不再尝试它,请求直接流向其他候选。
  • 冷却时间随失败次数递增,到上限为止,然后自动放回。
  • 冷却状态可在逻辑模型的模型行上看到。

调参

参数都在设置 → 可靠性 → 故障转移:

设置项默认值含义
失败阈值3连续失败多少次进入冷却。
基础冷却时间30 秒冷却的起始时长。
最大冷却时间5 分钟冷却的时长上限。
请求超时30 秒单次尝试的超时,超时即换下一个。

超时也在供应商级

供应商自己的「请求超时」会覆盖这里的默认值(见供应商与模型)。

只在一组里转移

故障转移只在一组之内发生。一组可能是:

  • 一个逻辑模型下挂着的模型;或
  • 一条显式开启协议转换的渠道。

不会跨组兜底

某条请求用的渠道不支持原生协议、也没开转换时,它不会因为这个而改走其他组——那属于路由的职责(见请求选路)。

观察

  • 逻辑模型页:模型行的「连续失败次数」与「冷却中」标记。
  • 统计分析:故障转移的频次与失败原因分布。
  • 请求记录:某次请求的尝试明细,能看出它在哪个候选上失败、最后落在谁身上。

同一会话反复命中不同供应商会打散上游的提示词缓存,下一节缓存亲和解决这个问题。