1. 这次更新到底改了什么从“手动挡”到“自动挡”的路由逻辑1Panel 的 AI 网关功能上线有一阵子了早期版本里智能路由的调度策略基本围绕“按权重轮询”和“按模型名精确匹配”这两条路走。用过的人都知道这两种方式在模型数量少、调用方固定的场景下够用但一旦接入多个上游服务商、模型版本频繁迭代配置就会变得又长又碎。这次新增的 Jev 模式本质上是在原有调度层之上加了一层“意图识别 动态打分”的决策机制让网关自己判断该把请求发给谁而不是靠人提前写死规则。我先把结论放在前面Jev 模式不是要替代原有的路由策略而是给那些“上游多、模型杂、流量波动大”的场景提供一个更省心的选项。它的核心价值在于三点——降低配置维护成本、提升请求命中率、在部分上游出现波动时自动降级。下面我会从设计思路、核心机制、实操配置、踩坑记录四个维度把这次更新拆开讲清楚。1.1 为什么原来的路由策略会“不够用”在讲 Jev 模式之前得先弄明白旧方案的问题出在哪。1Panel AI 网关最早的路由配置大概是这样的你建一个上游组里面挂若干个服务商节点每个节点配一个权重值网关按权重做轮询。这种模式在“所有上游能力对等”的前提下是合理的但现实情况往往不是这样。举个例子你同时接入了三个上游A 家擅长长文本推理B 家在代码生成上响应更快C 家价格便宜但偶尔超时。如果只按权重轮询一个写代码的请求可能被分到 A 家一个长文总结的请求可能被分到 C 家结果就是“能跑但跑得不够好”。更麻烦的是当某个上游开始频繁返回 429 或 5xx 时权重轮询并不会自动把它踢出队列你得手动去改配置这在生产环境里是很被动的。Jev 模式要解决的就是这个“静态配置跟不上动态变化”的问题。它把每个上游节点的历史表现、当前负载、模型匹配度都纳入打分每次请求进来时实时算一个综合分选最优的那个发出去。你可以理解为以前是“排班表”现在是“调度员”。1.2 Jev 模式的核心机制拆解Jev 模式的打分逻辑并不复杂但有几个关键维度值得展开说。根据我在测试环境里的观察和抓包分析它主要看四件事模型匹配度请求里带的模型名和上游节点声明的模型列表做模糊匹配匹配度越高分越高。这里不是简单的字符串相等而是支持前缀匹配和别名映射比如gpt-4-turbo和gpt-4-turbo-2024-04-09会被认为是同一族。历史成功率每个上游节点维护一个滑动窗口的成功率统计窗口大小默认是最近 100 次请求。成功率低于阈值的节点会被降权低于更低阈值会被临时熔断。当前并发负载网关会跟踪每个上游的活跃连接数负载高的节点在打分时会被扣分避免“旱的旱死、涝的涝死”。响应延迟最近若干次请求的 P95 延迟也会参与打分延迟越低的节点在同等条件下优先。这四个维度各自有权重系数默认配置下大概是 匹配度 0.4、成功率 0.3、负载 0.2、延迟 0.1。这个比例可以在高级配置里调但我的建议是除非你有明确的压测数据支撑否则别乱动默认值已经能覆盖大多数场景。注意Jev 模式的打分是“请求级”的不是“连接级”的。也就是说同一个客户端的不同请求可能被分发到不同上游这对无状态调用没问题但如果你依赖会话保持需要额外开启粘性会话选项。2. 在 1Panel 里把 Jev 模式跑起来完整配置流程理论讲完了接下来是实操。我假设你已经装好了 1Panel并且 AI 网关功能已经启用。如果你还没装官方文档里有标准安装脚本这里不展开。下面从创建上游节点开始一步步走到 Jev 模式生效。2.1 上游节点的准备与模型声明Jev 模式的匹配度打分依赖上游节点正确声明自己支持的模型。这一步如果偷懒后面路由就会乱套。具体操作是进入 AI 网关的上游管理页面新建或编辑一个上游节点在“模型列表”字段里把该上游实际可用的模型名填进去多个模型用英文逗号分隔。这里有个细节模型名最好填“基础名”不要带日期后缀。比如上游实际提供的是claude-3-5-sonnet-20241022你在声明时填claude-3-5-sonnet就行Jev 模式的前缀匹配会自动覆盖带日期的版本。这样做的好处是上游模型迭代时你不用反复改配置。另外每个上游节点建议配一个“健康检查路径”。虽然 Jev 模式有被动熔断但主动健康检查能更快发现问题。健康检查的间隔默认 30 秒超时 5 秒连续失败 3 次标记为不健康。这个参数在节点数量多的时候可以适当放宽避免检查流量本身成为负担。2.2 开启 Jev 模式并理解配置项上游节点建好之后回到路由策略配置页。你会看到路由模式的下拉选项里多了一个“Jev 智能路由”。选中它之后页面会展开一组参数参数名默认值说明调整建议匹配度权重0.4模型名匹配在总分中的占比模型种类多时保持默认成功率权重0.3历史成功率占比上游不稳定时可调高到 0.4负载权重0.2当前并发占比上游性能差异大时可调高延迟权重0.1P95 延迟占比对响应速度敏感时可调高熔断阈值0.5成功率低于此值触发熔断不建议低于 0.3熔断恢复时间60s熔断后多久重新试探上游恢复慢时可延长滑动窗口大小100统计最近多少次请求流量大时可增大到 500这些参数里我重点说两个容易配错的。一个是熔断阈值设得太高会导致上游偶尔抖一下就整个被踢掉设得太低又起不到保护作用。我的经验是如果你的上游是商业 API0.5 到 0.6 比较合适如果是自建推理服务可以放到 0.4因为自建服务的失败往往是真挂了不是偶发超时。另一个是滑动窗口大小。窗口太小统计波动大一个偶发失败就可能让节点被降权窗口太大对近期变化的响应又不够灵敏。100 到 200 是比较平衡的区间除非你的 QPS 特别高否则不用动。2.3 验证 Jev 模式是否生效配置保存后怎么确认它真的在按 Jev 逻辑走最直接的办法是看网关的请求日志。Jev 模式会在日志里额外输出一个route_score字段记录本次请求各个候选节点的得分和最终选择。你可以用 1Panel 的日志查看器过滤这个字段观察一段时间内的分发情况。我自己的验证方法是故意把两个上游的权重配成一样但其中一个的模型列表少声明一个模型然后发一批包含该模型的请求看是否全部落到声明了该模型的那个上游。如果 Jev 生效结果应该是明确的如果还是轮询说明配置没保存成功或者模式没切过来。还有一个更省事的办法在网关的监控面板里看“上游分发分布”图。Jev 模式下这个分布应该和请求的模型构成强相关而不是均匀分布。如果看到明显的均匀分布那大概率还是旧策略在跑。3. 智能路由背后的工程细节打分、熔断与降级这一部分我想往深里挖一挖因为 Jev 模式真正有意思的地方不在“能路由”而在“怎么决定不路由”。一个智能路由系统好不好用很大程度上取决于它在异常情况下的表现。3.1 打分函数的实际计算过程虽然官方没有公开完整的打分公式但通过日志里的route_score字段和实际分发结果可以反推出大致的计算逻辑。假设有三个上游节点 A、B、C某个请求的模型是gpt-4各节点的状态如下A声明了gpt-4成功率 0.98当前并发 5P95 延迟 800msB声明了gpt-4成功率 0.92当前并发 2P95 延迟 1200msC未声明gpt-4成功率 0.99当前并发 1P95 延迟 600ms在 Jev 模式下C 虽然其他指标好但匹配度为 0基本直接出局。A 和 B 的竞争里A 的成功率和延迟占优B 的负载占优。按默认权重算A 的综合分大概是0.4*1 0.3*0.98 0.2*(1-5/10) 0.1*(1-800/2000)B 则是0.4*1 0.3*0.92 0.2*(1-2/10) 0.1*(1-1200/2000)。粗算下来 A 略高所以请求会发给 A。这个计算是每次请求都做的所以当 B 的负载降下来或者 A 的成功率掉下去时分发会自动倾斜。提示负载和延迟的归一化基准是动态的取的是当前所有候选节点里的最大值。所以如果你只有一个上游节点负载和延迟的得分永远是满分这两个维度就退化了。这也是为什么 Jev 模式在单上游场景下意义不大。3.2 熔断与半开恢复的配合熔断机制是 Jev 模式的“保险丝”。当一个上游的成功率跌破阈值网关会把它标记为熔断状态后续请求不再发给它。但熔断不是永久的过了恢复时间后网关会放少量试探请求过去这就是“半开”状态。如果试探请求成功节点恢复正常如果继续失败熔断时间翻倍。这个翻倍策略是很多熔断器的标准做法但 Jev 模式里有个细节值得注意翻倍的上限是 10 分钟。也就是说一个持续失败的上游最多每 10 分钟被试探一次不会无限退避。这个设计在实操中是合理的因为上游恢复后你肯定希望它尽快重新分担流量而不是等半小时。我在测试时遇到过一个情况某个上游因为配额耗尽返回 429被熔断后恢复时间设为 60 秒结果每 60 秒试探一次都失败日志里刷了一堆熔断记录。后来我把恢复时间调到 300 秒日志清爽多了。所以如果你的上游有明确的配额重置周期恢复时间最好和那个周期对齐。3.3 降级策略当所有上游都不可用时Jev 模式还有一个兜底逻辑如果所有候选节点都被熔断或匹配度为 0网关会返回一个 503而不是随便挑一个发出去。这个行为在早期版本里是相反的——早期会“尽力而为”地选一个结果就是请求发出去也是失败还浪费了等待时间。这个改动我觉得很务实。因为对于调用方来说快速失败比慢速失败更有价值尤其是配合重试机制的时候。不过要注意如果你的业务对可用性要求极高可以在网关前面再加一层重试但重试的目标应该是不同的网关实例而不是同一个网关的同一个上游。4. 实操中踩过的坑与排查手册任何新功能上线头几天总是最容易出问题的。我把这段时间在测试环境和准生产环境里遇到的问题整理了一下按现象、原因、解决方式列出来希望能帮你少走弯路。4.1 常见问题速查表现象可能原因排查方式解决方式请求全部落到一个上游其他上游模型声明不匹配检查各节点模型列表补全模型声明或开启模糊匹配分发仍然均匀轮询Jev 模式未保存生效查看路由模式配置重新保存并重启网关服务上游频繁熔断又恢复恢复时间过短查看熔断日志频率调大恢复时间至 300s 以上延迟明显升高延迟权重过高或上游本身慢对比各上游 P95调低延迟权重或剔除慢节点日志无 route_score日志级别不够检查网关日志级别调到 debug 级别观察粘性会话失效未开启会话保持检查会话配置开启粘性会话并设 TTL4.2 三个我实际踩过的坑第一个坑是模型别名映射。我一开始以为 Jev 模式只认精确匹配就把上游的模型名写得很全结果配置又长又容易漏。后来发现它支持前缀匹配但前提是请求里的模型名和声明的模型名有共同前缀。比如请求是gpt-4-0613声明是gpt-4能匹配但如果请求是gpt4声明是gpt-4就匹配不上。所以声明时最好用官方标准名别自己造缩写。第二个坑是健康检查路径配错。有个上游的健康检查路径我填成了/v1/models但这个上游需要鉴权健康检查没带 token一直返回 401结果节点被标记为不健康流量全跑了。后来改成/health这种不需要鉴权的路径才正常。所以健康检查路径一定要选一个轻量且无需鉴权的端点。第三个坑是滑动窗口和熔断的联动。有一次我把窗口设成 20结果一个上游因为一次网络抖动连续失败 3 次成功率直接掉到 0.85 以下触发了熔断。其实那 3 次失败之后它马上就恢复了但熔断已经生效白白损失了几分钟流量。后来我把窗口调回 100同样的情况就不会触发熔断了。窗口太小会让系统过于敏感这是很多人容易忽略的点。4.3 性能开销的实测数据Jev 模式因为每次请求都要算分肯定比轮询多一层开销。我在一台 2 核 4G 的测试机上压了一下QPS 在 500 左右时网关本身的 CPU 占用大概比轮询模式高 8 到 12 个百分点延迟增加在 2ms 以内。这个开销在大多数场景下是可以接受的但如果你的网关实例规格很小、QPS 又很高可能需要关注一下。优化建议是把滑动窗口大小控制在 200 以内日志级别在生产环境设为 info 而不是 debug这两个措施能明显降低算分和写日志的开销。另外如果你的上游节点超过 20 个建议开启“候选节点预筛选”让网关先用模型匹配度过滤掉一批再对剩下的算分这样能减少不必要的计算。5. 这套路由策略适合谁以及后续可以怎么扩展Jev 模式不是万金油它有明确的适用边界。如果你的场景是单上游、单模型、流量平稳那用轮询就够了上 Jev 反而是杀鸡用牛刀。但如果你的场景符合下面几条里的任意两条Jev 模式带来的收益就会很明显上游数量超过 3 个、模型种类超过 5 种、流量有明显波峰波谷、对上游故障的容忍度低。我自己的用法是把它和 1Panel 的反向代理功能配合起来。网关负责 AI 请求的智能分发反向代理负责普通 Web 服务的负载均衡两者各司其职。如果你也在 1Panel 里配了多个网站的反向代理可以把 AI 网关单独放在一个内部端口上通过反向代理暴露出去这样既能复用 1Panel 的证书管理又能让网关的配置和网站配置解耦。后续如果官方继续迭代我希望能看到两个方向一是支持基于请求内容的路由比如根据 prompt 长度自动选长文本能力强的上游二是把打分日志做成可视化面板现在看route_score还得翻日志不够直观。当然这些都是锦上添花当前这个版本已经能解决大部分多上游调度的痛点了。最后分享一个小技巧在正式切换 Jev 模式之前先用“影子模式”跑一段时间。具体做法是保持原有路由策略不变但开启 Jev 的日志记录对比两套策略的分发决策差异。如果差异在可接受范围内再正式切换。这样能把切换风险降到最低我在两个环境里都是这么干的一次都没翻车。