GitHub user mochengqian added a comment to the discussion: [AI] AI gateway milestones
**承接本帖的方向：把 AI 失败状态下沉进 cluster picker** 接着本帖里 key 级 cooldown 的讨论（某个 API key 触发 429 不应把整个 endpoint 标成不健康）——我想先探一下大家对这个方向上一个小而聚焦的步骤是否有兴趣。 **当前现状。** #932 之后，cluster 已经有了通过 `atomic.Pointer` 发布的不可变 `EndpointSnapshot`（成员 + 健康），但 picker 选址只看健康状态。AI 失败状态（cooldown）目前活在 LLM filter 的进程级全局 map 里（`pkg/filter/llm/proxy/filter.go` 的 `sharedCooldownStore`），picker 看不到它。所以 fallback 是 filter 侧的一个循环，“跳过处于 cooldown 的 endpoint”这件事从来没进入选址决策。 **建议方向——做的是状态基底，不是新算法。** 对 endpoint 失败做分类（429 / 5xx / timeout / context-length / quota），并把 per-endpoint 的 runtime 状态放进 cluster，让 picker 能够跳过处于 cooldown 的 endpoint。其中最值得一提的是 `context_length_exceeded`：它是请求与 endpoint 的“不匹配”，而不是 endpoint 故障——正确的反应是把这个请求路由到 context 更大的模型，而不是把该 endpoint 冷却掉。二元健康（healthy/unhealthy）无法表达这一点，而这和上面 key 级的问题是同一个形状。 **唯一需要先达成共识的设计点。** 我们不能简单地在 snapshot 的 endpoint 上加一个 `cooldownUntil` 字段：cooldown / inflight / latency 是每个请求都在变的，如果每次请求都去重建那个不可变 snapshot，会毁掉 #932 刚拿到的零分配读路径。因此建议把两者拆开： - 不可变的成员/健康 snapshot（沿用 #932 不变），以及 - 一个按 endpoint ID 索引、跨 snapshot 重建而存活的 per-endpoint `EndpointState`，其中快变字段用 atomic 承载；当 ID 不变时，重建时复用同一个 state 指针。 这与 Envoy 把静态 host config 和可变的负载/异常统计分开的做法是一致的。 **时序与边界。** 这是 #939（把 cooldown store 改为注入、移除全局变量）之后自然的下一步，并假设 #958（config/runtime 解耦）确立的 ownership 模型。它刻意不包含 scorer（cost / quota / latency 加权打分）、语义路由，以及多 cluster-kind——这些各自是后续独立的步骤。 不知道大家对这个方向是否有兴趣？如果有，我会把它整理成一个完整的 `[RFC]` issue，附上接口草图、兼容性说明，以及测试 / benchmark 计划。 GitHub link: https://github.com/apache/dubbo-go-pixiu/discussions/696#discussioncomment-17162858 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
