AI apitoken failover 机制设计

[cr7258]

背景

在使用 AI 服务时，可能会遇到 apiTokens 不可用的时候，比如 apiToken 被封禁、apiToken 超过调用次数限制等。为了提升服务的可用性和稳定性，可以配置 apiToken 的 failover 策略，主动定期对 apiToken 进行健康检测，当 apiToken 不可用时，将其移出 apiToken 列表。

功能说明

在 failure 配置中，可以设置触发 apiToken failover 的条件，包括匹配的 HTTP 状态码、HTTP 头信息和响应体内容。当满足 failover 条件时，将触发 failover 机制，将 apiToken 移出列表。

在 healthCheck 配置中，可以设置对 apiToken 的健康检测规则，包括健康检测的周期、成功阈值和健康检测成功的条件。当 apiToken 可用时，将 apiToken 加回列表。

参数配置

名称	类型	填写要求	默认值	描述
failure	object	必填	-	定义 failover 的规则
healthCheck	object	可选	-	定义对 apiToken 健康检测的规则

failure 字段

名称	类型	填写要求	默认值	描述
failureThreshold	int	可选	1	触发 failover 的失败阈值
conditions	array of object	必填	-	触发 failover 的条件

conditions 字段

当匹配具体的 HTTP 状态码、HTTP 头信息和响应体内容时，将触发 failover。
单个 condition 中设置的多个条件是“与”的关系，即所有条件都必须匹配才能触发 failover。
可以配置多个 condition，多个 condition 之间是“或”的关系，即只要有一个 condition 匹配就会触发 failover。

名称	类型	填写要求	默认值	描述
status_code	array of int	可选	-	HTTP 状态码
headers	array of string	可选	-	需要匹配的 HTTP 头信息
body	string	可选	-	需要匹配的响应体内容

至少要设置一个 failure 的 condition。

healthCheck 字段

当配置了 healthCheck 字段时，当有 apiToken 被移除列表时，将定期使用该 apiToken 主动访问 LLM 进行健康检测，当 apiToken 重新可用时加回列表。

名称	类型	填写要求	默认值	描述
periodSeconds	int	可选	300	健康检测的周期，单位为秒
successThreshold	int	可选	1	健康检测的成功阈值
content	string	可选	"who are you?"	请求的内容
conditions	array of object	可选	-	定义健康检测成功的条件

conditions 字段

当匹配具体的 HTTP 状态码、HTTP 头信息和响应体内容时，将认为健康检测成功。

名称	类型	填写要求	默认值	描述
status_code	array of int	可选	200	HTTP 状态码
headers	array of string	可选	-	需要匹配的 HTTP 头信息
body	string	可选	-	需要匹配的响应体内容

配置示例

provider:
  type: qwen
  apiTokens:
    - "api-token-1"
    - "api-token-2"
    - "api-token-3"
  modelMapping:
    'gpt-3': "qwen-turbo"
    'gpt-4-turbo': "qwen-max"
    '*': "qwen-turbo"
failover:
  failure:
    failureThreshold: 3
    conditions:
      - status_code:
          - 403
        headers:
          - "failure=true"
      - status_code:
          - 502
          - 503
      - body: "No quota available"
  healthCheck:
    periodSeconds: 10
    successThreshold: 1
    content: "你是谁？"
    conditions:
      - status_code:
          - 200
        body: "我是.*"
      - headers:
          - "success=true"

[johnlanni]

多模型的fallback，目前在插件里实现的话，会导致fallback之后无法流式（因为只能通过send local response返回一个完整响应了）。
目前其实已经支持了多模型的fallback，不过是通过 envoy custom-response filter实现的。
在ai 代理插件内的实现，可以不用考虑多模型的fallback；不过可以考虑下apiTokens的failover机制，例如某个api token在一段时间内失败超过一定次数就直接屏蔽掉（比如可能这个api token的配额用完了），然后可以搞个定时器，对被屏蔽的timer进行定时测试（用一个固定的开销不大的问题），当测试通过时又把这个token给加回来。

[cr7258]

然后可以搞个定时器，对被屏蔽的timer进行定时测试（用一个固定的开销不大的问题），当测试通过时又把这个token给加回来。

timer 貌似在 Wasm 里用不了，如果我使用当前的命令编译 Wasm 文件。

tinygo build -o main.wasm -scheduler=none -target=wasi -gc=custom -tags="custommalloc nottinygc_finalizer proxy_wasm_version_0_2_100" ./

当运行 timer 部分的代码的时候会报错：

panic: runtime error: scheduler is disabled

然后我尝试改成 -scheduler=asyncify 再编译，运行的时候提示：

Failed to load Wasm module due to a missing import: wasi_snapshot_preview1.poll_oneoff

所以看上去应该是哪里有些限制所以用不了 timer？

[cr7258]

目前其实已经支持了多模型的fallback，不过是通过 envoy custom-response filter实现的。

目前要使用到多模型的 fallback，需要做哪些配置吗？在官网上只找到这个注解配置，你指定是这个 fallback 吗？

[johnlanni]

然后可以搞个定时器，对被屏蔽的timer进行定时测试（用一个固定的开销不大的问题），当测试通过时又把这个token给加回来。

timer 貌似在 Wasm 里用不了，如果我使用当前的命令编译 Wasm 文件。

tinygo build -o main.wasm -scheduler=none -target=wasi -gc=custom -tags="custommalloc nottinygc_finalizer proxy_wasm_version_0_2_100" ./

当运行 timer 部分的代码的时候会报错：

panic: runtime error: scheduler is disabled

然后我尝试改成 -scheduler=asyncify 再编译，运行的时候提示：

Failed to load Wasm module due to a missing import: wasi_snapshot_preview1.poll_oneoff

所以看上去应该是哪里有些限制所以用不了 timer？

直接可以用wasm go sdk里封装好的接口，是基于host的能力

[cr7258]

好滴，那我把 issue 对应修改一下。

[johnlanni]

目前其实已经支持了多模型的fallback，不过是通过 envoy custom-response filter实现的。

目前要使用到多模型的 fallback，需要做哪些配置吗？在官网上只找到这个注解配置，你指定是这个 fallback 吗？

不是 ai fallback能力会在2.0.0版本开源

[cr7258]

@johnlanni 已经根据建议在 issue 的描述中进行了调整。