Open cr7258 opened 1 month ago
多模型的fallback,目前在插件里实现的话,会导致fallback之后无法流式(因为只能通过send local response返回一个完整响应了)。 目前其实已经支持了多模型的fallback,不过是通过 envoy custom-response filter实现的。 在ai 代理插件内的实现,可以不用考虑多模型的fallback;不过可以考虑下apiTokens的failover机制,例如某个api token在一段时间内失败超过一定次数就直接屏蔽掉(比如可能这个api token的配额用完了),然后可以搞个定时器,对被屏蔽的timer进行定时测试(用一个固定的开销不大的问题),当测试通过时又把这个token给加回来。
然后可以搞个定时器,对被屏蔽的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?
目前其实已经支持了多模型的fallback,不过是通过 envoy custom-response filter实现的。
目前要使用到多模型的 fallback,需要做哪些配置吗?在官网上只找到这个注解配置,你指定是这个 fallback 吗?
然后可以搞个定时器,对被屏蔽的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的能力
好滴,那我把 issue 对应修改一下。
目前其实已经支持了多模型的fallback,不过是通过 envoy custom-response filter实现的。
目前要使用到多模型的 fallback,需要做哪些配置吗?在官网上只找到这个注解配置,你指定是这个 fallback 吗?
不是 ai fallback能力会在2.0.0版本开源
@johnlanni 已经根据建议在 issue 的描述中进行了调整。
背景
在使用 AI 服务时,可能会遇到 apiTokens 不可用的时候,比如 apiToken 被封禁、apiToken 超过调用次数限制等。为了提升服务的可用性和稳定性,可以配置 apiToken 的 failover 策略,主动定期对 apiToken 进行健康检测,当 apiToken 不可用时,将其移出 apiToken 列表。
功能说明
在 failure 配置中,可以设置触发 apiToken failover 的条件,包括匹配的 HTTP 状态码、HTTP 头信息和响应体内容。当满足 failover 条件时,将触发 failover 机制,将 apiToken 移出列表。
在 healthCheck 配置中,可以设置对 apiToken 的健康检测规则,包括健康检测的周期、成功阈值和健康检测成功的条件。当 apiToken 可用时,将 apiToken 加回列表。
参数配置
failure 字段
conditions 字段
当匹配具体的 HTTP 状态码、HTTP 头信息和响应体内容时,将触发 failover。 单个 condition 中设置的多个条件是“与”的关系,即所有条件都必须匹配才能触发 failover。 可以配置多个 condition,多个 condition 之间是“或”的关系,即只要有一个 condition 匹配就会触发 failover。
至少要设置一个 failure 的 condition。
healthCheck 字段
当配置了 healthCheck 字段时,当有 apiToken 被移除列表时,将定期使用该 apiToken 主动访问 LLM 进行健康检测,当 apiToken 重新可用时加回列表。
conditions 字段
当匹配具体的 HTTP 状态码、HTTP 头信息和响应体内容时,将认为健康检测成功。
配置示例