1. 这次更新到底改了什么从单点转发到智能路由的跃迁1Panel 的 AI 网关模块这两年在自建服务圈子里热度一直不低原因很直接大家手里攒了一堆本地模型、云端 API、第三方推理服务如果没有一个统一的入口去管理光是记各个服务的地址和密钥就够头疼的。这次智能路由新增支持 Jev 模式本质上解决的是请求该往哪走这个核心问题。先说清楚 Jev 模式是什么定位。在它出现之前1Panel AI 网关的智能路由主要依赖权重轮询和故障转移这两套逻辑配置起来不算复杂但灵活性有限。Jev 模式引入的是一套基于请求特征动态决策的路由策略你可以把它理解成给网关装了一个调度大脑——它不再只是机械地按权重分发而是会根据请求携带的模型名称、路径前缀、请求头特征等条件把流量精准导向不同的后端服务。这个变化对谁最有价值我梳理了三类人第一类是同时跑着本地 Ollama 和云端 API 的开发者需要按模型名自动分流第二类是做多租户服务的团队不同客户要走不同的推理后端第三类是单纯想折腾一下路由规则、做灰度测试的技术爱好者。如果你属于这三类中的任何一类这次更新值得花时间研究。需要提前说明的是Jev 模式并不是要取代原有的轮询和故障转移而是作为第三种路由策略并存。你可以在同一个网关实例里针对不同的上游服务组分别配置互不干扰。这种设计思路很务实避免了升级即重构的尴尬。2. 智能路由的底层逻辑与 Jev 模式的方案选型2.1 为什么需要智能路由而不是简单轮询很多人一开始会想我后端就两三个服务轮询不就够了吗这个想法在小规模场景下没错但一旦服务数量上去、模型种类变多轮询的短板就暴露了。举个我实际遇到的例子我本地有一台机器跑着 7B 的小模型做日常问答另一台带显卡的跑着 70B 的大模型处理复杂任务。如果用轮询一个简单的今天天气请求可能被分到 70B 那台白白占用显存还拖慢响应反过来复杂请求落到小模型上回答质量又不行。智能路由要解决的就是这种请求与后端不匹配的问题。它的核心思路是在请求进入网关的那一刻先解析请求的特征再根据预设规则决定去向。这个解析-决策-转发的链路就是 Jev 模式的工作基础。从技术实现角度看网关需要在转发前读取请求体中的 model 字段、URL 路径、以及自定义 header。这里有个细节值得注意读取请求体意味着网关要缓冲整个 body对于流式请求比如 SSE 流式输出需要特别处理否则会破坏流式体验。1Panel 在这块的实现是做了流式透传优化的这也是我在实测中比较关注的点。2.2 Jev 模式与其他路由策略的对比为了让你直观理解 Jev 模式的定位我整理了一张对比表路由策略决策依据适用场景配置复杂度动态调整能力权重轮询预设权重比例后端性能相近、请求同质化低弱需手动改权重故障转移健康检查结果高可用要求、主备切换中中自动切换Jev 模式请求特征匹配规则多模型分流、多租户、灰度中高强规则可精细控制从表里能看出来Jev 模式的配置复杂度是最高的但换来的是最强的控制力。我的建议是如果你的后端服务少于三个且请求类型单一老老实实用轮询就行别为了用新功能而用新功能只有当你有明确的按条件分流需求时Jev 模式才真正发挥价值。2.3 规则匹配的优先级设计Jev 模式在规则匹配上采用的是自上而下、首次命中即停止的策略。这一点非常关键直接决定了你配置规则的顺序。我踩过一次坑把一条宽泛的规则放在了具体规则前面结果所有请求都被宽泛规则截胡了后面的精细规则根本没机会执行。正确的做法是把最具体、最严格的规则放在最上面越往下越宽泛最后放一条兜底规则。这个逻辑跟防火墙规则、Nginx 的 location 匹配是一个道理。理解了这个优先级你在配置时就不会犯低级错误。3. 核心配置细节与实操要点拆解3.1 前置准备确认版本与模块状态动手之前先确认你的 1Panel 版本是否包含这次更新。登录面板后进入AI 网关模块如果左侧菜单里能看到智能路由并且策略选项中有 Jev 模式说明版本没问题。如果看不到先去应用商店把 1Panel 更新到最新版本。这里有个实操心得更新前务必备份现有的网关配置。1Panel 的配置导出功能在设置-备份里导出一份 JSON 存到本地。我见过太多人更新完发现路由规则乱了又没备份只能一条条重配非常痛苦。另外要确认后端服务的连通性。在配置路由之前先用面板自带的连通性测试功能把每个上游服务的地址、端口、密钥都测一遍。Jev 模式再智能后端不通也是白搭。3.2 上游服务组的创建与命名规范Jev 模式的路由目标是上游服务组所以第一步是把后端服务分组。我的建议是按用途模型规模来命名比如local-small、local-large、cloud-gpt、cloud-claude这种一眼就能看出这个组是干什么的。创建服务组时需要注意几个参数负载均衡方式服务组内部仍然可以选择轮询或故障转移Jev 模式决定的是请求进哪个组组内怎么分发是另一层逻辑。健康检查路径不同推理服务的健康检查端点不一样Ollama 是/api/tagsOpenAI 兼容接口一般是/v1/models填错了会导致服务被误判为不健康。超时时间大模型推理动辄几十秒超时时间设太短会导致请求被中断。我一般把大模型组的超时设到 120 秒以上小模型组 30 秒足够。3.3 Jev 模式规则的具体配置方法进入智能路由配置页面选择 Jev 模式后你会看到规则编辑区。一条完整的规则包含三个部分匹配条件、目标服务组、优先级。匹配条件支持多种维度我常用的有这几种模型名称匹配比如请求体里model字段是gpt-4就走云端组是qwen:7b就走本地组。这是最常用的方式。路径前缀匹配比如/v1/chat/completions和/v1/embeddings走不同的后端适合把对话和向量化分开处理。请求头匹配通过自定义 header 来区分租户比如X-Tenant-ID为某个值时走专属后端。配置时有个细节模型名称匹配支持通配符比如qwen*能匹配所有 qwen 开头的模型。这个功能在做批量分流时特别省事不用一个个列出来。注意规则保存后不会立即生效需要点击应用配置按钮。我刚开始用的时候改完规则直接测试发现没生效折腾了半天才发现是忘了点应用。3.4 参数计算超时与重试的合理设置超时和重试这两个参数看似简单实则最容易出问题。我分享一套自己的计算方法。超时时间应该这样估算超时 首字节响应时间 生成时间。首字节响应时间指后端开始返回第一个 token 的时间生成时间指完整生成的时间。对于流式接口网关通常只关心首字节时间因为一旦开始流式输出就不会超时了。我实测本地 7B 模型首字节大概 1-2 秒云端 API 大概 0.5-1 秒所以超时设 30 秒对大多数场景都够用。重试次数要谨慎设置。对于幂等的请求比如 embeddings重试 2-3 次没问题但对于对话生成重试可能导致重复计费或者返回重复内容。我的做法是只在连接失败时重试不在生成超时时重试。这个区分很重要能帮你省下不少冤枉钱。4. 完整实操流程从零搭建一套 Jev 路由4.1 环境准备与后端服务接入假设你手头有两个后端本地 Ollama地址http://192.168.1.100:11434和一个云端 OpenAI 兼容接口。目标是把小模型请求导向本地大模型请求导向云端。第一步在 1Panel AI 网关里创建两个上游服务组。本地组填 Ollama 地址云端组填 API 地址和密钥。创建完成后分别点测试确保两个组都是绿色健康状态。第二步进入智能路由新建一条 Jev 模式的路由规则。规则名我习惯写成模型分流-本地小模型方便后续维护。第三步添加匹配条件。选择模型名称匹配模式选通配符填入qwen*、llama*、gemma*这几个本地部署的模型前缀。目标服务组选本地组。第四步再建一条规则处理云端模型匹配gpt*、claude*、deepseek*目标选云端组。第五步建一条兜底规则匹配条件设为全部目标选一个默认组。这条规则必须放在最后防止有请求匹配不上任何规则导致 404。4.2 规则顺序调整与冲突排查规则建好后检查一下顺序。在规则列表里可以拖拽调整优先级。记住前面说的原则具体的在上宽泛的在下。如果发现某条规则不生效排查思路是这样的先看请求实际命中了哪条规则。1Panel 的网关日志里会记录每条请求的匹配结果在日志-路由日志里能看到。如果日志显示命中了错误的规则那就是顺序问题如果显示没命中任何规则那就是匹配条件写错了。我遇到过一次诡异的情况规则明明写对了但就是不生效。后来发现是模型名称大小写的问题——请求里是Qwen我规则里写的是qwen。Jev 模式的匹配默认是区分大小写的这个坑大家注意一下。解决办法要么统一大小写要么在规则里把大小写变体都列上。4.3 灰度发布场景的配置实例Jev 模式还有一个很实用的场景灰度发布。假设你要把一个模型从旧版本切换到新版本想先放 10% 的流量过去测试。配置方法是这样的先建两个服务组一个指向旧模型一个指向新模型。然后在 Jev 规则里用请求头匹配来做分流。给测试用户发一个特定的 header比如X-Canary: true匹配到这个 header 的请求走新模型组其余走旧模型组。这种基于 header 的灰度比基于权重的灰度更可控因为你能精确指定哪些用户进入灰度而不是随机分配。对于需要收集特定用户反馈的场景这种方式明显更合适。4.4 配置验证与压测配置完成后别急着上线先做一轮验证。我一般分三步走单请求验证用 curl 分别发几个不同模型的请求看返回是否来自预期的后端。可以在后端服务的日志里确认请求是否到达。并发验证用简单的压测工具发几十个并发请求观察网关的响应时间和错误率。这一步主要看网关本身会不会成为瓶颈。异常验证手动停掉一个后端服务看网关是否能正确返回错误或者切换到备用组。这一步验证的是容错能力。# 单请求验证示例测试模型分流是否生效 curl -X POST http://你的网关地址/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的网关密钥 \ -d { model: qwen:7b, messages: [{role: user, content: 测试}] }发完请求后去本地 Ollama 的日志里看如果有对应的请求记录说明分流成功。5. 常见问题与排查技巧实录5.1 请求 404 或 502 的排查路径这是配置 Jev 模式后最常见的问题。404 通常意味着请求没有匹配到任何规则或者匹配到了但目标服务组不存在。502 则一般是后端服务不可达。排查顺序我总结成一张速查表现象可能原因排查方法解决方式404无兜底规则查看路由日志匹配结果添加全部匹配的兜底规则404模型名大小写不符对比请求与规则中的模型名统一大小写或加通配符502后端地址填错用测试功能验证连通性修正地址端口502后端服务未启动直接访问后端健康检查端点启动后端服务超时超时时间设太短查看日志中的耗时记录调大超时时间流式中断网关缓冲了请求体检查是否开启流式透传开启流式优化选项5.2 流式响应被破坏的处理流式输出是 AI 网关的一个特殊难点。因为 Jev 模式需要读取请求体来做匹配如果实现不当网关会把整个请求缓冲下来再转发导致流式变成一次性返回。如果你发现流式输出变成了等半天然后一次性吐出来检查两个地方一是网关的流式透传选项是否开启二是匹配规则是否过于复杂导致解析耗时过长。1Panel 在这块做了优化正常情况下不会破坏流式但如果你的规则里用了正则匹配这种耗时的操作可能会有影响。我的建议是匹配条件尽量用简单的前缀或通配符避免复杂的正则表达式。规则越简单网关的处理开销越小流式体验越流畅。5.3 多租户场景下的密钥隔离做多租户的时候一个容易忽略的问题是密钥隔离。不同租户应该用不同的网关密钥这样在日志里能区分请求来源也方便做用量统计。Jev 模式配合请求头匹配可以实现租户 A 的请求走后端 A租户 B 的请求走后端 B。配置时给每个租户分配一个专属 header 值规则里按 header 匹配。这样即使两个租户用的是同一个模型名也能正确分流到各自的后端。提示租户密钥建议定期轮换并且在网关日志里开启请求记录方便审计和排查。5.4 性能瓶颈的定位方法网关本身也是会消耗资源的。如果你的请求量比较大需要关注网关所在机器的 CPU 和内存占用。Jev 模式因为要做请求解析和规则匹配比纯轮询模式更吃 CPU。定位性能瓶颈的方法在网关日志里看每个请求的处理耗时。如果处理耗时不含后端响应时间超过 50 毫秒说明网关本身有压力。这时候可以考虑几个优化方向减少规则数量、简化匹配条件、给网关机器加配置、或者把网关和后端部署在同一内网减少网络延迟。我实测下来在 4 核 8G 的机器上Jev 模式处理简单规则的开销大概在 5-10 毫秒完全够用。只有当规则数量超过 50 条且匹配条件复杂时才会感觉到明显延迟。6. 进阶玩法与后续扩展方向6.1 结合反向代理实现多站点统一入口热词里提到的1panel 配置反向代理 多个网站其实和 AI 网关可以结合起来玩。思路是这样的用 1Panel 的反向代理功能把不同的域名或者路径前缀代理到 AI 网关再由网关的 Jev 模式做二次分流。比如你有ai.example.com和api.example.com两个域名都指向同一个网关。在网关的 Jev 规则里根据请求的 Host 头或者路径前缀把ai.example.com的请求导向对话模型把api.example.com的请求导向 embeddings 模型。这样一套网关就能服务多个业务场景管理起来非常清爽。配置反向代理时注意开启 WebSocket 支持和流式传输否则 AI 接口的流式输出会被代理层截断。1Panel 的反向代理配置里有对应的开关记得勾上。6.2 基于请求内容的动态路由设想Jev 模式目前主要基于模型名、路径、header 这些元信息来匹配。一个更有想象力的方向是基于请求内容本身来路由比如根据用户问题的长度、语言、复杂度来决定用大模型还是小模型。这个需求目前 Jev 模式还不能直接支持但可以通过一个中间层来实现写一个轻量级的预处理服务分析请求内容后打上自定义 header再转发给网关网关根据这个 header 做路由。这种预处理网关的组合方案灵活性非常高适合有定制需求的团队。6.3 监控与告警的配套建设路由配好了还得有监控。1Panel 自带的监控面板能看到请求量、错误率、响应时间这些基础指标。但如果你想做更细粒度的分析比如每个模型组的调用次数、每个租户的用量就需要把日志导出到外部系统。我的做法是把网关日志通过 syslog 转发到一台日志服务器用简单的脚本做统计。这样既能满足日常监控又能在出问题时快速定位。对于个人用户来说1Panel 自带的日志功能其实已经够用了不用过度建设。6.4 规则版本管理与回滚规则改多了容易乱建议养成版本管理的习惯。每次修改规则前先在本地记录一下当前配置或者用 1Panel 的配置导出功能存一份。如果改完发现问题能快速回滚。我自己的做法是给规则文件加日期后缀比如jev-rules-20250115.json改之前先导出一份。这个习惯帮我省过好几次事尤其是做灰度测试的时候随时能切回稳定版本。7. 我在实际配置中踩过的坑与经验总结聊了这么多配置细节最后分享几个只有实际动手才会遇到的坑。第一个坑是模型名称的匹配精度。我一开始用gpt做前缀匹配结果把gpt-3.5和gpt-4都匹配到了同一个组。后来改成精确匹配加通配符组合才把不同版本的模型分开。教训是通配符虽然方便但用之前要想清楚匹配范围别把不该匹配的也圈进去了。第二个坑是健康检查频率。默认的健康检查间隔是 30 秒对于本地服务来说太频繁了会产生大量无意义的请求。我把间隔调到了 60 秒既保证了故障发现的及时性又减少了后端压力。这个参数没有标准答案根据你的服务稳定性来调。第三个坑是日志量。开启详细日志后每个请求都会记录完整的请求体和响应体日志文件涨得飞快。我建议只在排查问题时临时开启详细日志平时用普通级别就行。如果确实需要长期记录记得配置日志轮转别让磁盘被写满。第四个坑是关于密钥管理的。网关的密钥如果泄露别人就能白嫖你的后端服务。我的做法是给每个使用方分配独立密钥并且定期检查日志里有没有异常调用。1Panel 的密钥管理功能支持设置有效期这个功能要用起来。说到底Jev 模式是一个能力越大、责任越大的功能。它给了你精细控制流量的能力但也要求你对规则逻辑有清晰的理解。我的建议是先从最简单的模型名分流开始跑通了再逐步增加规则的复杂度。别一上来就搞十几条规则那样出了问题很难排查。如果你也在用 1Panel 的 AI 网关不妨试试 Jev 模式从一条简单的规则开始感受一下智能路由带来的便利。配置过程中遇到问题多看看路由日志大部分答案都在日志里。
1Panel AI网关智能路由Jev模式：动态分流与多模型路由配置实战
1. 这次更新到底改了什么从单点转发到智能路由的跃迁1Panel 的 AI 网关模块这两年在自建服务圈子里热度一直不低原因很直接大家手里攒了一堆本地模型、云端 API、第三方推理服务如果没有一个统一的入口去管理光是记各个服务的地址和密钥就够头疼的。这次智能路由新增支持 Jev 模式本质上解决的是请求该往哪走这个核心问题。先说清楚 Jev 模式是什么定位。在它出现之前1Panel AI 网关的智能路由主要依赖权重轮询和故障转移这两套逻辑配置起来不算复杂但灵活性有限。Jev 模式引入的是一套基于请求特征动态决策的路由策略你可以把它理解成给网关装了一个调度大脑——它不再只是机械地按权重分发而是会根据请求携带的模型名称、路径前缀、请求头特征等条件把流量精准导向不同的后端服务。这个变化对谁最有价值我梳理了三类人第一类是同时跑着本地 Ollama 和云端 API 的开发者需要按模型名自动分流第二类是做多租户服务的团队不同客户要走不同的推理后端第三类是单纯想折腾一下路由规则、做灰度测试的技术爱好者。如果你属于这三类中的任何一类这次更新值得花时间研究。需要提前说明的是Jev 模式并不是要取代原有的轮询和故障转移而是作为第三种路由策略并存。你可以在同一个网关实例里针对不同的上游服务组分别配置互不干扰。这种设计思路很务实避免了升级即重构的尴尬。2. 智能路由的底层逻辑与 Jev 模式的方案选型2.1 为什么需要智能路由而不是简单轮询很多人一开始会想我后端就两三个服务轮询不就够了吗这个想法在小规模场景下没错但一旦服务数量上去、模型种类变多轮询的短板就暴露了。举个我实际遇到的例子我本地有一台机器跑着 7B 的小模型做日常问答另一台带显卡的跑着 70B 的大模型处理复杂任务。如果用轮询一个简单的今天天气请求可能被分到 70B 那台白白占用显存还拖慢响应反过来复杂请求落到小模型上回答质量又不行。智能路由要解决的就是这种请求与后端不匹配的问题。它的核心思路是在请求进入网关的那一刻先解析请求的特征再根据预设规则决定去向。这个解析-决策-转发的链路就是 Jev 模式的工作基础。从技术实现角度看网关需要在转发前读取请求体中的 model 字段、URL 路径、以及自定义 header。这里有个细节值得注意读取请求体意味着网关要缓冲整个 body对于流式请求比如 SSE 流式输出需要特别处理否则会破坏流式体验。1Panel 在这块的实现是做了流式透传优化的这也是我在实测中比较关注的点。2.2 Jev 模式与其他路由策略的对比为了让你直观理解 Jev 模式的定位我整理了一张对比表路由策略决策依据适用场景配置复杂度动态调整能力权重轮询预设权重比例后端性能相近、请求同质化低弱需手动改权重故障转移健康检查结果高可用要求、主备切换中中自动切换Jev 模式请求特征匹配规则多模型分流、多租户、灰度中高强规则可精细控制从表里能看出来Jev 模式的配置复杂度是最高的但换来的是最强的控制力。我的建议是如果你的后端服务少于三个且请求类型单一老老实实用轮询就行别为了用新功能而用新功能只有当你有明确的按条件分流需求时Jev 模式才真正发挥价值。2.3 规则匹配的优先级设计Jev 模式在规则匹配上采用的是自上而下、首次命中即停止的策略。这一点非常关键直接决定了你配置规则的顺序。我踩过一次坑把一条宽泛的规则放在了具体规则前面结果所有请求都被宽泛规则截胡了后面的精细规则根本没机会执行。正确的做法是把最具体、最严格的规则放在最上面越往下越宽泛最后放一条兜底规则。这个逻辑跟防火墙规则、Nginx 的 location 匹配是一个道理。理解了这个优先级你在配置时就不会犯低级错误。3. 核心配置细节与实操要点拆解3.1 前置准备确认版本与模块状态动手之前先确认你的 1Panel 版本是否包含这次更新。登录面板后进入AI 网关模块如果左侧菜单里能看到智能路由并且策略选项中有 Jev 模式说明版本没问题。如果看不到先去应用商店把 1Panel 更新到最新版本。这里有个实操心得更新前务必备份现有的网关配置。1Panel 的配置导出功能在设置-备份里导出一份 JSON 存到本地。我见过太多人更新完发现路由规则乱了又没备份只能一条条重配非常痛苦。另外要确认后端服务的连通性。在配置路由之前先用面板自带的连通性测试功能把每个上游服务的地址、端口、密钥都测一遍。Jev 模式再智能后端不通也是白搭。3.2 上游服务组的创建与命名规范Jev 模式的路由目标是上游服务组所以第一步是把后端服务分组。我的建议是按用途模型规模来命名比如local-small、local-large、cloud-gpt、cloud-claude这种一眼就能看出这个组是干什么的。创建服务组时需要注意几个参数负载均衡方式服务组内部仍然可以选择轮询或故障转移Jev 模式决定的是请求进哪个组组内怎么分发是另一层逻辑。健康检查路径不同推理服务的健康检查端点不一样Ollama 是/api/tagsOpenAI 兼容接口一般是/v1/models填错了会导致服务被误判为不健康。超时时间大模型推理动辄几十秒超时时间设太短会导致请求被中断。我一般把大模型组的超时设到 120 秒以上小模型组 30 秒足够。3.3 Jev 模式规则的具体配置方法进入智能路由配置页面选择 Jev 模式后你会看到规则编辑区。一条完整的规则包含三个部分匹配条件、目标服务组、优先级。匹配条件支持多种维度我常用的有这几种模型名称匹配比如请求体里model字段是gpt-4就走云端组是qwen:7b就走本地组。这是最常用的方式。路径前缀匹配比如/v1/chat/completions和/v1/embeddings走不同的后端适合把对话和向量化分开处理。请求头匹配通过自定义 header 来区分租户比如X-Tenant-ID为某个值时走专属后端。配置时有个细节模型名称匹配支持通配符比如qwen*能匹配所有 qwen 开头的模型。这个功能在做批量分流时特别省事不用一个个列出来。注意规则保存后不会立即生效需要点击应用配置按钮。我刚开始用的时候改完规则直接测试发现没生效折腾了半天才发现是忘了点应用。3.4 参数计算超时与重试的合理设置超时和重试这两个参数看似简单实则最容易出问题。我分享一套自己的计算方法。超时时间应该这样估算超时 首字节响应时间 生成时间。首字节响应时间指后端开始返回第一个 token 的时间生成时间指完整生成的时间。对于流式接口网关通常只关心首字节时间因为一旦开始流式输出就不会超时了。我实测本地 7B 模型首字节大概 1-2 秒云端 API 大概 0.5-1 秒所以超时设 30 秒对大多数场景都够用。重试次数要谨慎设置。对于幂等的请求比如 embeddings重试 2-3 次没问题但对于对话生成重试可能导致重复计费或者返回重复内容。我的做法是只在连接失败时重试不在生成超时时重试。这个区分很重要能帮你省下不少冤枉钱。4. 完整实操流程从零搭建一套 Jev 路由4.1 环境准备与后端服务接入假设你手头有两个后端本地 Ollama地址http://192.168.1.100:11434和一个云端 OpenAI 兼容接口。目标是把小模型请求导向本地大模型请求导向云端。第一步在 1Panel AI 网关里创建两个上游服务组。本地组填 Ollama 地址云端组填 API 地址和密钥。创建完成后分别点测试确保两个组都是绿色健康状态。第二步进入智能路由新建一条 Jev 模式的路由规则。规则名我习惯写成模型分流-本地小模型方便后续维护。第三步添加匹配条件。选择模型名称匹配模式选通配符填入qwen*、llama*、gemma*这几个本地部署的模型前缀。目标服务组选本地组。第四步再建一条规则处理云端模型匹配gpt*、claude*、deepseek*目标选云端组。第五步建一条兜底规则匹配条件设为全部目标选一个默认组。这条规则必须放在最后防止有请求匹配不上任何规则导致 404。4.2 规则顺序调整与冲突排查规则建好后检查一下顺序。在规则列表里可以拖拽调整优先级。记住前面说的原则具体的在上宽泛的在下。如果发现某条规则不生效排查思路是这样的先看请求实际命中了哪条规则。1Panel 的网关日志里会记录每条请求的匹配结果在日志-路由日志里能看到。如果日志显示命中了错误的规则那就是顺序问题如果显示没命中任何规则那就是匹配条件写错了。我遇到过一次诡异的情况规则明明写对了但就是不生效。后来发现是模型名称大小写的问题——请求里是Qwen我规则里写的是qwen。Jev 模式的匹配默认是区分大小写的这个坑大家注意一下。解决办法要么统一大小写要么在规则里把大小写变体都列上。4.3 灰度发布场景的配置实例Jev 模式还有一个很实用的场景灰度发布。假设你要把一个模型从旧版本切换到新版本想先放 10% 的流量过去测试。配置方法是这样的先建两个服务组一个指向旧模型一个指向新模型。然后在 Jev 规则里用请求头匹配来做分流。给测试用户发一个特定的 header比如X-Canary: true匹配到这个 header 的请求走新模型组其余走旧模型组。这种基于 header 的灰度比基于权重的灰度更可控因为你能精确指定哪些用户进入灰度而不是随机分配。对于需要收集特定用户反馈的场景这种方式明显更合适。4.4 配置验证与压测配置完成后别急着上线先做一轮验证。我一般分三步走单请求验证用 curl 分别发几个不同模型的请求看返回是否来自预期的后端。可以在后端服务的日志里确认请求是否到达。并发验证用简单的压测工具发几十个并发请求观察网关的响应时间和错误率。这一步主要看网关本身会不会成为瓶颈。异常验证手动停掉一个后端服务看网关是否能正确返回错误或者切换到备用组。这一步验证的是容错能力。# 单请求验证示例测试模型分流是否生效 curl -X POST http://你的网关地址/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer 你的网关密钥 \ -d { model: qwen:7b, messages: [{role: user, content: 测试}] }发完请求后去本地 Ollama 的日志里看如果有对应的请求记录说明分流成功。5. 常见问题与排查技巧实录5.1 请求 404 或 502 的排查路径这是配置 Jev 模式后最常见的问题。404 通常意味着请求没有匹配到任何规则或者匹配到了但目标服务组不存在。502 则一般是后端服务不可达。排查顺序我总结成一张速查表现象可能原因排查方法解决方式404无兜底规则查看路由日志匹配结果添加全部匹配的兜底规则404模型名大小写不符对比请求与规则中的模型名统一大小写或加通配符502后端地址填错用测试功能验证连通性修正地址端口502后端服务未启动直接访问后端健康检查端点启动后端服务超时超时时间设太短查看日志中的耗时记录调大超时时间流式中断网关缓冲了请求体检查是否开启流式透传开启流式优化选项5.2 流式响应被破坏的处理流式输出是 AI 网关的一个特殊难点。因为 Jev 模式需要读取请求体来做匹配如果实现不当网关会把整个请求缓冲下来再转发导致流式变成一次性返回。如果你发现流式输出变成了等半天然后一次性吐出来检查两个地方一是网关的流式透传选项是否开启二是匹配规则是否过于复杂导致解析耗时过长。1Panel 在这块做了优化正常情况下不会破坏流式但如果你的规则里用了正则匹配这种耗时的操作可能会有影响。我的建议是匹配条件尽量用简单的前缀或通配符避免复杂的正则表达式。规则越简单网关的处理开销越小流式体验越流畅。5.3 多租户场景下的密钥隔离做多租户的时候一个容易忽略的问题是密钥隔离。不同租户应该用不同的网关密钥这样在日志里能区分请求来源也方便做用量统计。Jev 模式配合请求头匹配可以实现租户 A 的请求走后端 A租户 B 的请求走后端 B。配置时给每个租户分配一个专属 header 值规则里按 header 匹配。这样即使两个租户用的是同一个模型名也能正确分流到各自的后端。提示租户密钥建议定期轮换并且在网关日志里开启请求记录方便审计和排查。5.4 性能瓶颈的定位方法网关本身也是会消耗资源的。如果你的请求量比较大需要关注网关所在机器的 CPU 和内存占用。Jev 模式因为要做请求解析和规则匹配比纯轮询模式更吃 CPU。定位性能瓶颈的方法在网关日志里看每个请求的处理耗时。如果处理耗时不含后端响应时间超过 50 毫秒说明网关本身有压力。这时候可以考虑几个优化方向减少规则数量、简化匹配条件、给网关机器加配置、或者把网关和后端部署在同一内网减少网络延迟。我实测下来在 4 核 8G 的机器上Jev 模式处理简单规则的开销大概在 5-10 毫秒完全够用。只有当规则数量超过 50 条且匹配条件复杂时才会感觉到明显延迟。6. 进阶玩法与后续扩展方向6.1 结合反向代理实现多站点统一入口热词里提到的1panel 配置反向代理 多个网站其实和 AI 网关可以结合起来玩。思路是这样的用 1Panel 的反向代理功能把不同的域名或者路径前缀代理到 AI 网关再由网关的 Jev 模式做二次分流。比如你有ai.example.com和api.example.com两个域名都指向同一个网关。在网关的 Jev 规则里根据请求的 Host 头或者路径前缀把ai.example.com的请求导向对话模型把api.example.com的请求导向 embeddings 模型。这样一套网关就能服务多个业务场景管理起来非常清爽。配置反向代理时注意开启 WebSocket 支持和流式传输否则 AI 接口的流式输出会被代理层截断。1Panel 的反向代理配置里有对应的开关记得勾上。6.2 基于请求内容的动态路由设想Jev 模式目前主要基于模型名、路径、header 这些元信息来匹配。一个更有想象力的方向是基于请求内容本身来路由比如根据用户问题的长度、语言、复杂度来决定用大模型还是小模型。这个需求目前 Jev 模式还不能直接支持但可以通过一个中间层来实现写一个轻量级的预处理服务分析请求内容后打上自定义 header再转发给网关网关根据这个 header 做路由。这种预处理网关的组合方案灵活性非常高适合有定制需求的团队。6.3 监控与告警的配套建设路由配好了还得有监控。1Panel 自带的监控面板能看到请求量、错误率、响应时间这些基础指标。但如果你想做更细粒度的分析比如每个模型组的调用次数、每个租户的用量就需要把日志导出到外部系统。我的做法是把网关日志通过 syslog 转发到一台日志服务器用简单的脚本做统计。这样既能满足日常监控又能在出问题时快速定位。对于个人用户来说1Panel 自带的日志功能其实已经够用了不用过度建设。6.4 规则版本管理与回滚规则改多了容易乱建议养成版本管理的习惯。每次修改规则前先在本地记录一下当前配置或者用 1Panel 的配置导出功能存一份。如果改完发现问题能快速回滚。我自己的做法是给规则文件加日期后缀比如jev-rules-20250115.json改之前先导出一份。这个习惯帮我省过好几次事尤其是做灰度测试的时候随时能切回稳定版本。7. 我在实际配置中踩过的坑与经验总结聊了这么多配置细节最后分享几个只有实际动手才会遇到的坑。第一个坑是模型名称的匹配精度。我一开始用gpt做前缀匹配结果把gpt-3.5和gpt-4都匹配到了同一个组。后来改成精确匹配加通配符组合才把不同版本的模型分开。教训是通配符虽然方便但用之前要想清楚匹配范围别把不该匹配的也圈进去了。第二个坑是健康检查频率。默认的健康检查间隔是 30 秒对于本地服务来说太频繁了会产生大量无意义的请求。我把间隔调到了 60 秒既保证了故障发现的及时性又减少了后端压力。这个参数没有标准答案根据你的服务稳定性来调。第三个坑是日志量。开启详细日志后每个请求都会记录完整的请求体和响应体日志文件涨得飞快。我建议只在排查问题时临时开启详细日志平时用普通级别就行。如果确实需要长期记录记得配置日志轮转别让磁盘被写满。第四个坑是关于密钥管理的。网关的密钥如果泄露别人就能白嫖你的后端服务。我的做法是给每个使用方分配独立密钥并且定期检查日志里有没有异常调用。1Panel 的密钥管理功能支持设置有效期这个功能要用起来。说到底Jev 模式是一个能力越大、责任越大的功能。它给了你精细控制流量的能力但也要求你对规则逻辑有清晰的理解。我的建议是先从最简单的模型名分流开始跑通了再逐步增加规则的复杂度。别一上来就搞十几条规则那样出了问题很难排查。如果你也在用 1Panel 的 AI 网关不妨试试 Jev 模式从一条简单的规则开始感受一下智能路由带来的便利。配置过程中遇到问题多看看路由日志大部分答案都在日志里。
