1Panel的AI网关模块最近更新了一个让我比较兴奋的点：智能路由新增支持Jev模式。之前用1Panel管服务器，主要就是建站、跑Docker、配数据库，AI网关出来后我一直把它当"LLM API的统一钥匙串"来用，各业务的模型密钥收拢到一处管理，确实省心。这次升级把智能路由从简单的"按模型名转发"变成了"请求级动态决策"，整个使用逻辑完全不一样了。

如果你也和我一样，服务器上挂着好几个AI服务：有的给团队内部做助手，有的跑自动化脚本，有的给外部客户开放API，每个服务对接的模型厂商还不一样——那我强烈建议你看看这个Jev模式。它解决的问题很具体：多个模型供应商如何统一接入、请求如何根据租户/域名/业务线自动分发给合适的上游、某个上游挂了或限流时怎么无缝切换。简单说，AI网关就是给大模型API做"前台总机"，Jev模式则是给总机装了一套智能调度系统。这篇就来拆一拆Jev模式的设计思路、核心机制和我在1Panel里的完整配置过程。

1. 先弄清楚为什么需要AI网关，智能路由到底解决什么问题

1.1 多模型时代，API入口正在变得越来越乱

我手头维护过的项目里，最常见的一个乱象就是：每个业务各接各的模型厂商，A项目用OpenAI格式的接口，B项目直接调某家国产模型的原生SDK，C项目为了省成本接了个开源模型的自托管服务。API Key散落在不同环境变量文件里，谁用了哪个Key、哪个Key快到期了、哪家服务商这个月账单超了，全靠手工登记，时间一长肯定对不上账。

更麻烦的是模型厂商的稳定性不在一个水平线上。有的服务偶尔限流，有的服务在高峰期延迟翻倍，有的模型发新版后老版本接口直接断掉。业务方每次遇到问题，第一反应就是找我："是不是你网关配置错了？"其实根本不是，是上游服务商自己的问题。这种局面下，把所有的模型API放进一个统一网关里管理，几乎是必然选择。

网关的价值，往大了说就是四点：统一接入格式、集中管理密钥、控制配额权限、统一监控日志。这四点做扎实了，下面所有业务就不用各自关心"今天该调哪个模型""Key还能不能用"这类琐事。

1.2 1Panel AI网关的定位：私有化部署的LLM API统一入口

1Panel本身是个开源的Linux服务器管理面板，网站、数据库、容器、监控这些能力已经做得很成熟了。AI网关是它面向大模型应用场景推出的一个功能模块。和调用云端网关最大的区别就是：它部署在你自己的服务器上，请求从你的业务侧发出后，先到你的网关，再由网关转发给上游模型供应商，整个过程不经过任何第三方的网关中转。

数据不经过第三方这点，对很多团队来说是刚需。尤其当请求里带着内部Prompt、业务上下文甚至客户数据时，谁都希望这条链路越可控越好。1Panel AI网关在架构上相当克制：它提供一个OpenAI兼容的入口，也就是说，原来直接调用OpenAI SDK的业务代码，只要把base_url改成你服务器的网关地址，API Key换成在网关里生成的Key，代码基本不用动，就能把流量切到网关上来。

网关本身负责的事情包括：管理多个上游provider的密钥、按租户或用户维度控制调用配额、记录每次请求的模型、Token消耗、延迟和状态码。这些都是自托管API网关的标配能力，1Panel这次并没有堆太多花哨功能，而是把基础体验打磨得比较顺手。

1.3 智能路由：不是"挑一个模型"那么简单

智能路由是AI网关里最核心、也最容易被误解的功能。有人以为智能路由就是"配两个模型，网关自动选一个快的"，实际远不止如此。

网关面对的问题是这样的：进来的请求，带着不同的身份、不同的目标模型名、不同的请求内容，来自不同的业务域名。业务A希望优先用便宜的小模型，业务B必须用精度高的旗舰模型，业务C想先把5%流量切到新模型上做灰度。同时，上游模型供应商随时可能限流、故障、变更版本。智能路由要做的，是在这些约束下替每个请求找到最合适的上游。

这个决策过程需要维度，不能靠拍脑袋。Jev模式出现之前，普通路由基本只能做"模型名/请求路径完全匹配后固定转发"，灵活度完全不够用。Jev模式的出现，就是把路由从"if-else转发"升级成了"多维度的请求级决策"，这也是我这次重点研究的对象。

2. Jev模式到底改了什么：从静态规则到请求级决策引擎

2.1 普通路由和Jev模式的本质区别

普通路由，我之前的用法很直白：在网关里建一条规则，声明"当请求的model字段是gpt-4o时，转发到providerA"。规则之间是并列的，命中了就转发，没命中就落到默认配置。这适合模型简单、业务单一的部署阶段。

Jev模式的设计思路就完全不同了。它不再面向"模型名"做匹配，而是面向"请求上下文"做决策。可以理解为一套决策链：请求到达网关后，Jev模式会尝试按你配置的优先级和条件组合，把请求归类到某个策略分组里，再从该分组对应的候选上游列表中，结合权重、健康状态和当前并发情况，动态选出一个上游来执行转发。

用一句话概括：普通路由是"请求找规则"，Jev模式是"网关替请求做决定"。

Jev模式支持的匹配维度，除了模型名，还可包括：

• 来源域名或Host头
• 租户标识（比如请求头里的X-Tenant-ID）
• API Key所属的Key分组
• 请求体里的特定字段，比如max_tokens的规模、temperature范围
• 自定义Header标签

这意味着一个简单的例子：两个业务团队共用同一个网关，同一个模型名"deepseek-chat"，A团队希望走本地Ollama以节约成本，B团队必须走云端服务保证效果。传统模式做不到区分，因为model字段一样。Jev模式下，网关按Key或域名区分出是哪个团队，再各自走不同上游，这才是"智能"的意义。

2.2 Jev模式的一次完整路由决策流程

我实际测试之后，把Jev模式的内部流程拆成了六步，每一步都能在网关日志里看到对应记录。

第一步是鉴权。请求先验证API Key是否有效、属于哪个租户/Key分组。这一步在路由之前，因为后续的所有策略匹配都依赖这个身份标识。

第二步是策略匹配。Jev模式按自定义顺序依次匹配策略，每个策略可以配置多个条件，条件之间是AND关系，满足全部条件才会进入该策略。策略匹配是"首个命中生效"，所以顺序很重要，越具体的策略越要放在前面。

第三步是上游候选组确定。策略里不是直接指定一个上游，而是指定一个上游组，可以包含多个上游，每个上游带权重和优先级。这个设计非常实用，等于把"路由目标"从单点变成了集群。

第四步是健康检查与可用性判断。每个上游都有健康检查状态，连续失败几次会被标记为不健康，Jev模式在选上游时会跳过不健康节点。这一步是全自动的，不需要手动摘除故障节点。

第五步是选择上游。根据权重做加权随机，结合当前并发数做简单的最小负载判断。权重越高被选中的概率越大，但不代表一定会选它。

第六步是转发与熔断。请求转发到上游后，如果超时或返回5xx错误，Jev模式会依据配置决定是否立即重试到组内另一个上游（重试次数和条件可配置），同时把这次失败记录到健康检查计数里。

对比一下我之前用普通路由，配置固定转发后，上游一挂，请求就跟着挂。Jev模式至少给了这一层"自动逃生通道"，稳定性的提升是直接能感知到的。

2.3 故障转移和降级策略的细节设计

故障转移这块，我觉得Jev模式做得最到位的是两个小机制：被动健康检查的滑动窗口，以及降级路径的配置。

滑动窗口的意思是，网关不是"失败一次就拉黑"，而是统计最近一段时间内的失败率。比如配置了"最近30秒内失败3次则标记不健康"，就不会因为单次网络抖动误杀正常上游。这个阈值具体设多少，需要根据上游的真实稳定性来调，我自己的经验是：对云端API，超时设15秒，失败阈值设5次每30秒；对本地Ollama，超时设60秒，失败阈值设3次每60秒，因为本地服务一般是宕机而非抖动。

降级路径的配置也很有讲究。Jev模式里，每个策略可以配置主上游组和降级上游组。比如主组是"高精度模型+备用高精度模型"，降级组是"效果稍差但稳定便宜的模型"。当主组内所有上游都不健康时，网关才把请求切到降级组。这样既保证了高峰期尽量用高质量模型，又在极端故障下不至于完全不可用。

还有一个细节是慢启动。上游从故障中恢复后，不会立刻承接全量流量，而是先以小比例流量试探，确认稳定后逐步放开。这个机制避免了一台刚恢复的服务被瞬间打垮的尴尬。

2.4 缓存与配额控制：路由之外的配套能力

Jev模式不是一个孤立的路由开关，它和网关的缓存、配额控制是协同工作的。

缓存这块，之前的版本主要支持精确匹配的缓存：请求体完全一致，直接返回缓存结果，不走上游。Jev模式引入了语义缓存的思路，即通过向量化相似度来判断Prompt是否"等价"。比如线上两个用户问了大致相同的问题，语义相似度高，第二次请求可以直接复用第一次的答案。

这个能力适合哪些场景？客服机器人、重复性问答、内部知识库查询这类业务，语义缓存能把Token成本压得很低。不过要注意，语义缓存的相似度阈值需要仔细调，调得太高缓存命中率低，调得太低容易返回"答非所问"的脏数据。我目前阈值设在0.92左右，还能接受。

配额控制方面，Jev模式的策略可以绑定配额模板。比如某个租户每天最多消耗100万Token，超过后请求直接拒绝，或者自动降级到备用模型。从运维角度看，这个能力比在业务代码里做限流要可靠得多，因为业务侧无论如何都能绕过自己的限制，网关侧则卡死了所有入口。

3. 在1Panel里把Jev模式跑起来：多域名、反代和虚拟主机场景

3.1 准备工作：升级版本、启用AI网关

先确认你的1Panel版本支持AI网关及Jev模式。我升级前习惯先看一眼官方发布说明，再看看自己的面板版本号（面板左下角能看到），确认足够新之后再在应用商店里找到AI网关进行安装。安装前最稳妥的操作是先在面板里做一次快照备份，毕竟升级类和网络相关的组件，一旦出问题还能快速回滚。

AI网关安装完成后，默认会监听一个本机端口，比如8000或8089这类，具体以实际安装信息为准。端口默认不对外网开放，这个设计我觉得很安全。后续我们通过反向代理把域名转过来，比直接开公网端口可控得多。

另外建议在服务器防火墙里确认一下：面板端口、网关端口、网站端口（80/443）之间没有冲突。尤其当你一台服务器上已经跑了多个网站时，端口冲突是最高发的翻车点。

3.2 上游模型接入：先把provider配置好

在创建Jev路由策略之前，得先把上游模型服务方配置好。1Panel AI网关的provider类型主要分两类：OpenAI兼容接口和Ollama这类本地推理服务。

我目前接的三个比较有代表性：

• DeepSeek：官方API，OpenAI兼容，base_url填https://api.deepseek.com，模型名填deepseek-chat。
• 阿里云百炼上的通义千问：同样兼容OpenAI接口格式。
• 本地Ollama：地址填http://127.0.0.1:11434或服务器局域网IP，模型名填你本地拉取的模型，比如qwen2.5:7b。

每个provider需要配置的内容包括：显示名称、接口地址、API Key（本地服务的可留空）、默认超时时间、最大并发数。有一个使用心得：超时时间一定要按provider实际情况区分。云端API一般30秒足够，本地大模型如果跑的是7B以上参数，单次推理可能很慢，超时给到120秒都不过分。如果统一用同一个超时时间，本地模型很容易被误判为故障。

配置密钥时，建议为每个provider单独建Key，不要所有上游共用一个Key。一是账单维度清晰，二是将来某个provider需要轮换密钥时，只改一处就行，不会误伤其他上游。

3.3 创建Jev路由策略：权重、优先级和条件的组合

接下来就是重头戏：创建Jev模式的路由策略。在AI网关管理界面里，进入智能路由，新增策略时选择Jev模式。

界面上需要配置的核心内容有这么几块：

• 策略名称和匹配条件：比如匹配域名team-a.example.com、或者匹配Header里的租户标识。
• 主上游组：从已配置的provider里选择多个，给每个分配权重和优先级。
• 降级上游组：可选，配置在主组全部不可用时的兜底目标。
• 故障转移参数：重试次数、超时时间、健康检查阈值。
• 配额模板：可选，绑定后限制该策略的Token消耗速度。

我这里给你一个"成本优先"策略的参考配置：

主上游组里，Ollama权重60，DeepSeek权重30，通义千问权重10。这样大部分请求落到本地免费算力上，少量落到云端高质模型。优先级顺序则设为Ollama > DeepSeek > 通义，只有当高优先级的都不可用时，才轮到下一个。

再配一个"质量优先"策略，主组里旗舰模型权重80，备用模型权重20，开启降级组，降到成本优先组。这样当旗舰模型不可用时，服务质量会有一定下降，但链路不会断。

我实际测试下来，Jev模式对条件的匹配顺序非常敏感。一定要把"特殊业务先匹配，通用兜底放最后"这个原则贯彻到底。举个反例：如果兜底策略放在最前面，它就会吞掉所有请求，后面的策略永远匹配不到。

3.4 用反向代理和虚拟主机绑定多个域名

配置好Jev策略，下一步就是把网关通过域名暴露出去，然后让多个业务站点共用它。这一步正好用上1Panel的网站管理能力。

先说反向代理。在1Panel网站模块里新建站点，类型选反向代理，填上目标地址为AI网关的本地端口。站点绑定域名，比如我绑定了ai.example.com。保存后，https://ai.example.com就能访问到AI网关。

如果想让多个域名都指向同一个网关入口，1Panel里一个站点可以绑定多个域名，把ai-a.example.com、ai-b.example.com都加进去就行。这些域名共用同一个反代配置和证书。

虚拟主机场景则是把不同的域名反代到不同的入口。比如同一个Jev策略下，我想让team-a.example.com和team-b.example.com走不同的租户隔离策略，我会在1Panel里建两个反向代理站点，一个绑定域名A，一个绑定域名B，反代目标都是同一个AI网关端口，但域名进入网关后，Jev模式根据Host头区分策略，从而走不同的上游组。这样从业务方角度看，就是两个完全独立的AI API地址，互不影响。

证书方面，1Panel可以自动申请Let's Encrypt证书并定期续期，站点绑定域名后勾选HTTPS证书即可。注意有个坑：如果你在站点里同时绑了多个域名，证书申请时会把所有域名都加入证书覆盖范围（SAN），如果其中某个域名解析有问题，整个证书会申请失败。所以我现在的习惯是：域名先全部解析到服务器IP，再在面板里申请证书，顺序不能反。

还有一个端口规划的问题。AI网关监听在本地端口上，通过反代对外只暴露80/443。这样做的好处是你不必在防火墙上单独开网关端口，只需要开放网站端口，安全面小很多。我自己就是直接在反向代理里填127.0.0.1:端口号，服务器公网端口只开80和443，非常清爽。

3.5 用curl验证路由结果

配置完成后，强烈建议先用curl做一轮功能验证，不要急着让业务侧切流量。下面是我用的验证命令：

curl -sS https://ai.example.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-你的网关密钥" \ -d '{ "model": "deepseek-chat", "messages": [{"role": "user", "content": "介绍一下你自己"}], "max_tokens": 256 }'

返回结果里，除了正常的模型输出，注意看响应头。Jev模式会在响应头里带上本次路由的决策信息，比如命中的策略ID、实际转发的上游名称、缓存是否命中。我第一次看到这个头信息时，整个路由链路就一目了然了。

验证的测试点我建议做三组：

• 第一组，正常请求，确认路由到主上游组里的高权重节点。
• 第二组，手动停掉一个上游服务，再发请求，确认网关自动转移到组内其他上游，响应头里的上游ID会变化。
• 第三组，连续发送内容相同或高度相似的请求，确认缓存是否命中，Token消耗是否明显下降。

三组测试全通过，Jev路由才算真正跑起来了。

4. 常见问题与排查技巧实录

我在实际配置和使用Jev模式的过程中，遇到过不少问题，有些是新版功能特有的，有些是网关类共通的。整理成一张速查表，你直接对号入座：

有一个排查技巧很管用：Jev模式的所有路由决策日志都是结构化输出的，记录了请求从进入到转发出去的完整链路。遇到疑难杂症，别盯着界面猜，直接打开网关日志筛选当次请求的request_id，把路由决策时间线拉出来看，问题出在哪一环一目了然。我排查上面"路由规则不生效"的问题时，就是通过日志看到匹配命中的策略ID是兜底策略，才定位到是策略顺序错了。

另外说一个容易踩的坑：在绑定多个域名做虚拟主机场景时，如果有旧网站占用了443端口，新建反代站点就会遇到端口冲突。我遇到过两次，解决方式是确认旧站点与新站点共用的Nginx配置端口复用没有问题，然后在1Panel的站点管理里统一检查监听配置，避免新站点配置被覆盖。

5. 实操心得与进阶建议

5.1 怎么设计路由策略：成本优先还是效果优先

设计Jev策略时，最忌讳的是"一套策略走天下"。我现在的做法是：先按业务线隔离，再按成本敏感度分组。

对内使用的自动化脚本、批量任务，统一用成本优先策略：本地模型权重拉高，云端模型作为溢出和兜底。对外提供服务的业务，走质量优先策略：旗舰模型打底，保留降级通道保证可用性。两者之间用租户或域名区分，天然隔离，互不干扰。

每一个策略上线前，我都会先跑一周的流量观察数据，重点看：平均延迟、Token成本、错误率。如果某条策略的成本明显超出预期，我会下调对应上游的权重，而不是一次性把配置改得面目全非。路由策略的调整应该是小步快跑，不是重构式的大动干戈。

5.2 日志和监控是Jev模式的关键配套

智能路由再聪明，没有监控就是瞎子。我在服务器上部署了一个简单的定时任务，定期抓取1Panel AI网关的运行指标，主要看四个指标：每分钟请求数、路由策略命中分布、各上游的失败率、缓存命中率。

其中最有价值的是"路由策略命中分布"。它能告诉你配置的策略是不是真的在按预期承接流量。有一次我发现质量优先策略的命中占比低得离谱，查了一圈发现是某个业务侧把base_url配错了，请求根本没走网关，业务侧直连了上游。没有监控的话，这种隐蔽问题不知道要跑多久才会暴露。

5.3 后续可以继续扩展的方向

Jev模式用顺之后，我已经在规划几个更进阶的用法：按时间段的动态权重，比如白天高峰本地模型权重调低防止过载，夜间批量任务权重调高；还有灰度发布，新模型先挂到低权重位置，观察一段时间的质量反馈后再逐步加权重；以及多租户的财务报告，通过网关日志把每个团队的Token消耗按月汇总，做内部成本分摊。

Jev模式给我最大的感受是：它把"请求该走哪个上游"这件事从代码逻辑中解脱了出来，变成运行时可调整的配置。以后模型供应商涨价、出新版本、服务不稳定，我只需要在1Panel里改策略，业务侧完全无感。这种不在代码层面反复折腾的体验，对运维来说真的是一种解放。