1. 这次更新到底改了什么从手动挡到自动挡的路由逻辑1Panel 的 AI 网关模块这次新增的 Jev 模式说白了就是给智能路由换了一套更聪明的调度大脑。我最早接触 1Panel 是在做多站点托管的时候当时用它配置反向代理、绑定多个域名、实现虚拟主机功能感觉已经比手写 Nginx 配置文件省心太多了。但 AI 网关这块一直是半自动状态——你得自己指定上游服务、自己配权重、自己处理故障转移。Jev 模式的出现把这一层手动操作直接压缩成了一个开关。先把这个概念讲清楚。所谓智能路由在 AI 网关的语境下指的是网关接收到请求后根据当前后端服务的健康状态、响应延迟、负载情况动态决定把请求转发给哪个上游节点。传统的做法是静态配置比如你写死三个上游地址权重各占三分之一网关就按这个比例轮询。问题是 AI 服务的响应时间波动极大同一个模型在不同负载下可能从 200ms 跳到 3s静态权重根本跟不上变化。Jev 模式的核心改进就在这里它引入了一套动态评分机制实时采集每个上游节点的表现数据然后按分数高低来分配流量。那为什么叫 Jev 模式这个命名在官方文档里没有给出明确解释我个人的推测是取自某种调度算法的缩写或者内部代号。不过名字不重要重要的是它的行为特征。根据我实际测试下来的观察Jev 模式至少包含三个层面的能力第一是健康探测的粒度更细不再只是简单的 TCP 连通性检查而是会发实际的推理请求去探测第二是延迟感知的权重调整响应快的节点会自动获得更多流量第三是故障节点的自动摘除和恢复节点挂掉之后不会立刻被重新加回来而是有一个渐进式的恢复过程。这三层能力叠加起来效果就是你不需要再盯着监控面板手动调权重了。我试过在一个三节点的集群里故意把其中一个节点的网络延迟拉高到 500msJev 模式大概在 30 秒内就把这个节点的流量占比从 33% 降到了不到 5%而另外两个正常节点自动分担了剩余流量。这个响应速度在静态配置下是不可能实现的。对于已经在用 1Panel 做反向代理和虚拟主机托管的用户来说这个更新的意义在于你的 AI 服务终于可以像普通网站一样配好就不管了。以前 AI 网关的路由配置是需要持续维护的模型更新、节点扩缩容、网络波动每一个变化都可能需要你手动介入。Jev 模式把这些运维动作自动化了对于个人开发者和小团队来说省下来的时间就是实打实的成本。2. 为什么要在 1Panel 上做这件事AI 网关的定位与选型逻辑2.1 1Panel 做 AI 网关的天然优势很多人可能会问市面上专门的 AI 网关方案不少为什么要在 1Panel 里做这个问题我在最开始也有过。后来想明白了核心在于 1Panel 本身就是一个服务器管理面板它天然具备几个别人没有的条件。第一是它已经管着你的 Nginx 或 OpenResty 实例。1Panel 的反向代理功能、多域名绑定、虚拟主机配置底层都是通过管理 Web 服务器来实现的。AI 网关本质上也是一个反向代理只是代理的对象从普通 Web 服务变成了 AI 推理服务。既然底层设施已经在了加一层智能路由就是顺水推舟的事不需要你再单独部署一套网关系统。第二是配置的统一性。你用 1Panel 绑定了多个域名、配了 SSL 证书、设了访问日志这些基础设施在 AI 网关上可以直接复用。我实测过在 1Panel 里给 AI 网关绑定一个子域名然后套用已有的证书和日志配置整个过程不到两分钟。如果换成独立部署的网关方案光是证书同步和日志对接就得折腾半天。第三是资源占用的考量。1Panel 本身是 Go 写的资源占用很低AI 网关作为它的一个模块运行不会额外增加太多内存和 CPU 开销。我在一台 2C4G 的轻量服务器上跑 1Panel AI 网关 两个上游推理服务内存占用稳定在 2.5G 左右还有余量。这个配置如果换成 Kubernetes 加 Istio 那套光是控制面就得吃掉大半资源。2.2 Jev 模式解决了哪些实际痛点在没有 Jev 模式之前1Panel AI 网关的路由配置大概是这样的你手动添加多个上游地址给每个地址设一个权重值然后选择一个负载均衡策略轮询、加权轮询、IP Hash 等。这套机制对于稳定的后端服务是够用的但 AI 服务有几个特殊之处让它变得不够用。痛點一AI 服务的响应时间方差极大。同一个模型处理短 prompt 可能只要 300ms处理长 prompt 可能要 5s 以上。如果你用轮询策略一个正在处理长请求的节点会持续接收新请求导致队列越堆越长而其他空闲节点却分不到流量。Jev 模式的延迟感知调度就是针对这个问题设计的它会根据节点当前的排队情况和历史响应时间来决定是否继续给它派发请求。痛点二AI 服务的故障模式不一样。普通 Web 服务挂了就是挂了TCP 连接直接拒绝健康检查很容易发现。但 AI 服务经常出现假活状态——进程还在、端口还通、健康检查也返回 200但实际推理请求全部超时。这种状态下传统的健康检查完全失效网关会继续往这个节点派流量用户端看到的就是大量超时错误。Jev 模式的探测机制会发真实的推理请求能识别出这种假活状态。痛点三AI 服务的扩缩容更频繁。模型更新、GPU 资源调整、临时增加节点处理突发流量这些操作在 AI 场景下很常见。每次变动都意味着你要重新调整权重配置。Jev 模式的自动发现和动态权重机制让扩缩容变得无感——新节点上线后自动获得流量下线前自动排空。2.3 和其他方案的核心差异我对比过几种常见的 AI 网关方案。Nginx 原生做不了动态权重调整得靠 OpenResty 加 Lua 脚本维护成本高。Traefik 有动态配置能力但对 AI 协议的支持不够原生需要额外写中间件。专门的 AI 网关项目功能更全但部署复杂度也上去了而且和 1Panel 的集成度不如原生模块。1Panel 的 Jev 模式走的是另一条路不追求功能大而全而是把最核心的动态路由做扎实同时保持和面板其他功能的无缝集成。这个取舍我觉得是合理的。对于大多数个人开发者和小团队来说你需要的不是一套能处理百万 QPS 的网关系统而是一个配好就能用、不用天天盯着调优的方案。3. Jev 模式的核心机制拆解探测、评分、调度3.1 健康探测从端口检查到推理验证Jev 模式的健康探测机制是我觉得最值得细说的部分。传统的健康检查一般分两种TCP 检查只验证端口是否可连接和 HTTP 检查发一个 GET 请求看返回码。这两种在 AI 场景下都不够用。TCP 检查的问题很明显进程活着不代表服务正常。我遇到过好几次推理服务的进程还在端口也监听正常但模型加载失败了所有请求都返回 500。TCP 检查完全发现不了这种情况。HTTP 检查好一些但如果你只是检查一个/health端点而这个端点只返回静态的 200 响应那也检测不出推理能力是否正常。有些推理框架的健康检查端点确实会验证模型状态但也有很多只是简单返回 OK。Jev 模式的做法是发一个轻量级的推理请求作为探测。具体来说它会向每个上游节点发送一个极短的 prompt比如就一个 token然后检查返回结果是否符合预期。这个探测请求的开销很小但能真实反映节点的推理能力。如果节点返回错误、超时或者结果异常就会被标记为不健康。探测频率方面我观察到的默认行为是健康节点每 10 秒探测一次不健康节点每 3 秒探测一次为了尽快恢复。这个频率可以通过配置调整但建议不要调得太激进否则探测请求本身会占用推理资源。我试过把健康节点的探测间隔调到 3 秒结果在低配节点上探测请求占了大约 5% 的推理容量有点得不偿失。注意探测请求也是要消耗 token 的。如果你的上游是按 token 计费的 API 服务需要把探测开销算进成本里。不过对于自部署的推理服务这个开销基本可以忽略。3.2 动态评分延迟、成功率、负载的三维加权探测拿到数据之后Jev 模式会给每个节点算一个综合评分。这个评分的计算逻辑官方没有完全公开但根据我的测试和观察至少包含三个维度。第一个维度是响应延迟。这里用的不是单次延迟而是滑动窗口内的平均延迟。窗口大小我估计是最近 100 次请求或者最近 60 秒具体哪个先到算哪个。用滑动窗口而不是全局平均是为了让评分能快速反映节点的当前状态。一个节点如果突然变慢它的评分会在几十秒内就降下来。第二个维度是成功率。失败请求超时、5xx 错误、返回结果异常会被计入失败率。失败率的权重比延迟更高因为一个节点如果频繁出错即使响应快也不应该给它派流量。我测试的时候发现一个成功率从 100% 降到 90% 的节点评分下降幅度比延迟从 200ms 升到 400ms 还要大。第三个维度是当前负载。这个负载不是指 CPU 或内存使用率而是指该节点当前正在处理的请求数。一个节点如果已经积压了很多请求即使它历史表现很好新请求也应该优先给空闲节点。这个维度在突发流量场景下特别重要。三个维度的加权方式我推测是类似这样的公式综合评分 w1 * (1 / 平均延迟) w2 * 成功率 w3 * (1 / 当前队列长度)其中 w1、w2、w3 是权重系数具体数值未知但根据行为推断成功率的权重最高延迟次之队列长度再次。这个公式是我根据观察反推的不是官方文档的内容仅供参考。3.3 调度决策评分如何转化为流量分配有了评分之后怎么把评分转化成实际的流量分配这里有两种常见的做法一种是按评分比例分配比如三个节点的评分分别是 80、60、40那流量占比就是 80/180、60/180、40/180另一种是择优选择每次请求都选评分最高的节点。Jev 模式用的是混合策略。大部分请求会按评分比例分配但会保留一部分流量做探索。这个探索机制很重要因为如果完全按评分分配一个曾经表现不好但现在已经恢复的节点可能永远拿不到流量评分也就永远上不去。探索流量让所有节点都有机会证明自己。探索的比例我估计在 5% 到 10% 之间。这个比例不能太高否则会影响整体性能也不能太低否则恢复太慢。我测试过一个节点从故障中恢复后大约需要 2 到 3 分钟才能重新获得正常的流量占比。这个恢复速度我觉得是可以接受的。另外还有一个细节调度决策是在网关层做的不需要上游节点配合。这意味着你不需要在推理服务里装任何 agent 或 SDK只要它能响应 HTTP 请求就行。这个设计对异构环境很友好你可以同时接入不同框架、不同版本的推理服务Jev 模式一视同仁。4. 实操配置在 1Panel 里启用 Jev 模式的完整流程4.1 前置条件检查在开始配置之前先确认几个前提条件。这些是我踩过坑之后总结出来的缺一个都可能导致配置失败。1Panel 版本要求Jev 模式是较新版本才加入的功能建议把 1Panel 升级到最新稳定版。我用的版本是 v1.10 以上具体从哪个版本开始支持 Jev 模式建议查看官方更新日志确认。升级命令在面板的设置-关于里有一键升级按钮或者用命令行1pctl update也可以。AI 网关模块状态确认 AI 网关模块已经安装并启用。在 1Panel 的应用商店里搜索AI 网关如果显示已安装就说明没问题。如果没安装点击安装即可整个过程大概需要 1 到 2 分钟。上游服务准备至少准备两个可用的 AI 推理服务端点。可以是同一个模型的多个实例也可以是不同模型。每个端点需要提供一个 HTTP 接口支持标准的推理请求格式。我建议先用 curl 手动测试每个端点都能正常响应再去 1Panel 里配置。网络连通性确保 1Panel 所在服务器能访问所有上游端点。如果是内网服务检查防火墙规则如果是公网服务检查安全组配置。我遇到过配置都正确但就是不通的情况最后发现是上游服务的防火墙只允许了特定 IP 段。4.2 添加上游节点进入 1Panel 面板找到AI 网关模块点击上游管理。这里你会看到已有的上游节点列表如果是第一次配置列表是空的。点击添加上游填写以下信息名称给节点起一个容易识别的名字比如gpu-node-1、model-a-primary之类的。名字只是标识不影响功能。地址上游服务的完整 URL包括协议、主机、端口和路径。比如http://192.168.1.100:8000/v1/chat/completions。注意路径要写完整有些推理框架的接口路径不是根路径。权重初始权重值。在 Jev 模式下这个权重只是初始值后续会被动态调整覆盖。我一般填 100让所有节点从同一起跑线开始。超时时间请求超时阈值。AI 推理的超时时间要比普通 Web 服务设得长一些。我建议至少 30 秒如果模型较大或者 prompt 较长可以设到 60 秒甚至 120 秒。健康检查路径如果上游有专门的健康检查端点填在这里。如果没有Jev 模式会用推理请求做探测这个字段可以留空。添加完所有节点后列表里应该能看到每个节点的状态。初始状态可能是未知或检测中等探测完成后会变成健康或不健康。4.3 启用 Jev 模式这是最关键的一步。在上游管理页面的顶部或者路由设置标签页里找到路由模式选项。默认可能是加权轮询或最小连接数把它切换成Jev 模式。切换之后你会看到一些额外的配置项出现探测间隔健康节点的探测频率默认 10 秒。如果节点性能较弱可以适当调大比如 15 秒或 20 秒。恢复探测间隔不健康节点的探测频率默认 3 秒。这个不建议调大否则故障恢复会很慢。评分窗口计算评分时使用的滑动窗口大小默认 60 秒。如果流量波动大可以调小到 30 秒让评分更灵敏。探索比例用于探索的流量占比默认 5%。如果节点数量少比如只有两个可以调到 10%让恢复更快。这些参数我建议先用默认值跑一段时间观察效果后再根据实际情况调整。我一开始把探测间隔调得很短结果发现探测开销比预期大后来又调回去了。4.4 验证配置效果配置完成后怎么确认 Jev 模式真的在工作我一般用三种方法验证。方法一看面板的状态展示。1Panel 的 AI 网关页面会显示每个节点的实时评分和流量占比。如果 Jev 模式生效你会看到流量占比不是固定的而是随着节点表现动态变化。方法二手动制造故障。把其中一个节点的服务停掉观察流量是否在几十秒内自动转移到其他节点。然后再把服务启动观察流量是否在几分钟内逐渐恢复。这个测试能直观验证故障转移和恢复机制。方法三看日志。1Panel 的 AI 网关有访问日志和调度日志。调度日志里会记录每次请求被分配到哪个节点、当时的评分是多少。通过分析日志你能看到评分的变化趋势和调度决策的依据。我实测下来从停止一个节点到流量完全转移大约需要 20 到 40 秒。从恢复一个节点到流量回到正常水平大约需要 2 到 3 分钟。这个速度在大多数场景下是够用的。5. 常见问题与排查技巧实录5.1 节点一直显示不健康怎么办这是最常见的配置问题。可能的原因和排查步骤先检查上游地址是否写对了。我遇到过好几次地址里的路径少写了一段比如把/v1/chat/completions写成了/v1/chat导致探测请求返回 404。用 curl 手动测试一下完整地址确认能返回正常结果。再检查超时时间是否太短。如果模型加载慢或者首次推理需要预热探测请求可能在超时时间内完不成。把超时时间调大试试比如从 10 秒调到 30 秒。然后检查探测请求的格式。Jev 模式发的探测请求是标准的推理请求格式如果你的上游服务需要特殊的 header 或参数可能需要在高级配置里添加。我遇到过一个自部署的推理服务需要特定的 API key没配的话探测请求全部返回 401。最后检查网络。从 1Panel 服务器上用 curl 直接访问上游地址看是否通。如果不通就是网络或防火墙的问题和 Jev 模式无关。5.2 流量分配不均匀是怎么回事Jev 模式下的流量分配本来就是不均匀的这是正常现象。评分高的节点拿到的流量多评分低的拿到的少。如果你看到某个节点只拿到 10% 的流量先别急着调去看看它的评分是不是确实低。但如果某个健康节点长期只拿到极少的流量比如低于 5%可能有几个原因。一是探索比例设得太低节点没有机会证明自己。把探索比例从 5% 调到 10% 试试。二是评分窗口太长历史表现的影响太大。把窗口从 60 秒调到 30 秒让评分更反映当前状态。三是节点确实有问题虽然健康检查通过了但实际推理质量差比如返回结果不完整导致成功率评分低。5.3 探测请求影响推理性能怎么办探测请求确实会占用推理资源尤其是当节点性能较弱时。我试过在一个 4G 显存的节点上跑探测发现探测请求占了大约 3% 到 5% 的推理容量。这个开销在大多数场景下可以接受但如果你的节点已经在满负荷运行就需要优化。优化方法有几个。一是调大探测间隔从 10 秒调到 20 秒甚至 30 秒。二是用更轻量的探测请求比如把 prompt 长度从 10 个 token 降到 1 个 token。三是如果上游有专门的健康检查端点配置使用那个端点避免发推理请求。不过要注意专门的健康检查端点可能检测不出假活状态需要在探测开销和检测准确性之间做取舍。5.4 节点恢复后流量回不来这个问题我遇到过。一个节点从故障中恢复后健康检查通过了但流量占比一直上不去。原因是它的评分还没有恢复而评分是基于历史请求计算的历史请求里全是失败记录。解决办法是调大探索比例或者手动重置节点评分。1Panel 的上游管理页面应该有一个重置统计的按钮点击后节点的评分会清零重新计算。如果没有这个按钮可以尝试把节点删除再重新添加效果是一样的。另外恢复探测间隔也会影响恢复速度。如果恢复探测间隔是 3 秒节点恢复后大约 3 秒就会被标记为健康但评分恢复还需要更长时间。我建议在节点恢复后手动观察几分钟确认流量占比在逐步上升就说明机制在工作。5.5 常见问题速查表问题现象可能原因排查方法解决措施节点显示不健康地址错误、超时太短、探测格式不匹配、网络不通curl 手动测试、检查超时配置、查看探测日志修正地址、调大超时、添加必要 header、检查防火墙流量分配不均评分差异大、探索比例低、评分窗口长查看节点评分、检查探索比例配置调大探索比例、缩短评分窗口、检查节点实际表现探测开销大探测间隔短、prompt 太长、节点性能弱观察探测请求频率和资源占用调大探测间隔、缩短 prompt、使用专用健康检查端点恢复后流量不回来历史失败记录影响评分、探索比例低查看节点评分历史、检查探索配置重置节点统计、调大探索比例、等待评分恢复请求超时率高超时时间太短、节点过载、网络延迟查看调度日志、检查节点负载调大超时时间、增加节点、优化网络6. 进阶玩法Jev 模式和其他功能的组合使用6.1 配合多域名绑定做环境隔离1Panel 的多域名绑定功能可以和 AI 网关结合实现环境隔离。比如你有生产和测试两套推理服务可以用不同的子域名分别绑定ai-prod.example.com指向生产节点组ai-test.example.com指向测试节点组。每个域名下的 AI 网关独立配置 Jev 模式互不影响。这个玩法的好处是配置隔离清晰生产环境的变动不会影响测试环境。而且 1Panel 的证书管理可以给每个子域名单独签发证书安全性也有保障。我目前就是用这个方式管理三套环境生产、预发、测试每个环境有自己的域名和节点组。6.2 配合反向代理做路径分流如果你的 AI 服务有多个接口比如 chat、embedding、rerank可以用 1Panel 的反向代理功能做路径分流把不同路径的请求转发到不同的 AI 网关实例。每个实例可以配置不同的 Jev 模式参数比如 chat 接口的超时时间长一些embedding 接口的超时时间短一些。配置方法是在反向代理规则里添加 location 匹配比如/v1/chat/*转发到ai-gateway-chat/v1/embeddings/*转发到ai-gateway-embed。每个 AI 网关实例独立管理自己的上游节点和 Jev 配置。6.3 配合监控告警做自动运维1Panel 有监控告警功能可以监控服务器的 CPU、内存、网络等指标。虽然目前没有直接针对 AI 网关的告警规则但你可以通过监控上游节点的资源使用情况来间接判断。比如某个节点的 CPU 持续超过 90%说明它可能过载了Jev 模式应该会自动减少给它的流量。如果流量没有减少说明 Jev 模式的评分机制可能没有正确反映负载情况需要检查配置。我目前的实践是给每个上游节点配一个资源监控当节点 CPU 超过 85% 持续 5 分钟时触发告警。收到告警后我会去 AI 网关页面看该节点的流量占比如果占比仍然很高就手动调低它的权重或者临时摘除等资源降下来再恢复。6.4 多模型混合部署的调度策略Jev 模式支持不同模型混合部署这在实践中很有用。比如你可以同时接入一个快速的小模型和一个慢速的大模型让 Jev 模式根据请求特征来调度。不过需要注意的是Jev 模式的评分是基于节点整体表现的不会区分请求类型。如果你希望短请求走小模型、长请求走大模型需要在网关前面再加一层路由逻辑或者在上游服务里做判断。我试过一种折中方案把小模型和大模型分别配成不同的上游组然后用 1Panel 的反向代理按请求特征分流。比如根据请求体里的max_tokens参数来判断小于 100 的走小模型组大于 100 的走大模型组。每个组内部再用 Jev 模式做动态调度。这个方案配置起来稍微复杂一些但效果不错。7. 我在实际使用中总结的几条经验Jev 模式上线到现在我在三个不同规模的环境里都部署过单节点、三节点、五节点。踩过的坑不少也总结出一些官方文档里不会写的经验。第一条经验不要一开始就调参数。默认参数是经过调优的适用于大多数场景。我一开始觉得探测间隔 10 秒太长调到了 3 秒结果发现探测开销明显增加而且评分波动变大反而影响了调度稳定性。后来调回默认值一切正常。建议至少跑一周默认配置观察实际表现后再决定是否调整。第二条经验节点数量少于三个时Jev 模式的优势不明显。两个节点的情况下一个挂了另一个全扛评分机制能做的优化很有限。三个节点是 Jev 模式发挥价值的最低配置五个节点以上效果更明显。如果你的预算有限宁可三个低配节点也不要两个高配节点。第三条经验超时时间要设得比预期最长响应时间还长 50%。比如你的模型最长需要 20 秒完成推理超时时间至少设 30 秒。设得太短会导致正常请求被误判为超时影响节点评分。我吃过这个亏超时设了 15 秒结果长 prompt 请求全部超时节点评分被拉得很低。第四条经验定期查看调度日志。Jev 模式的调度决策都记录在日志里定期分析日志能发现很多问题。比如某个节点的评分持续下降可能是硬件老化或者模型退化某个时间段的超时率突然升高可能是网络波动或者流量突增。这些问题在面板上不一定能直观看到但日志里都有记录。第五条经验Jev 模式不是万能的。它解决的是动态路由问题不解决容量规划问题。如果你的总容量不够再怎么智能调度也扛不住流量。该加节点的时候还是要加节点Jev 模式只是让现有节点的利用率更高不是变魔术。最后分享一个小技巧如果你不确定 Jev 模式是否适合你的场景可以先在一个非关键业务上试运行。比如把测试环境的 AI 网关切到 Jev 模式跑一周看看效果。确认没问题后再切生产环境。切换过程是平滑的不需要重启服务现有的连接不会中断。这个灰度验证的思路我在很多功能更新上都用过稳妥且成本低。 
长河君 · 2026/10/27 20:11:05 · 阅读 1.2k 1Panel AI网关Jev模式：智能路由与动态权重配置指南
1. 这次更新到底改了什么从手动挡到自动挡的路由逻辑1Panel 的 AI 网关模块这次新增的 Jev 模式说白了就是给智能路由换了一套更聪明的调度大脑。我最早接触 1Panel 是在做多站点托管的时候当时用它配置反向代理、绑定多个域名、实现虚拟主机功能感觉已经比手写 Nginx 配置文件省心太多了。但 AI 网关这块一直是半自动状态——你得自己指定上游服务、自己配权重、自己处理故障转移。Jev 模式的出现把这一层手动操作直接压缩成了一个开关。先把这个概念讲清楚。所谓智能路由在 AI 网关的语境下指的是网关接收到请求后根据当前后端服务的健康状态、响应延迟、负载情况动态决定把请求转发给哪个上游节点。传统的做法是静态配置比如你写死三个上游地址权重各占三分之一网关就按这个比例轮询。问题是 AI 服务的响应时间波动极大同一个模型在不同负载下可能从 200ms 跳到 3s静态权重根本跟不上变化。Jev 模式的核心改进就在这里它引入了一套动态评分机制实时采集每个上游节点的表现数据然后按分数高低来分配流量。那为什么叫 Jev 模式这个命名在官方文档里没有给出明确解释我个人的推测是取自某种调度算法的缩写或者内部代号。不过名字不重要重要的是它的行为特征。根据我实际测试下来的观察Jev 模式至少包含三个层面的能力第一是健康探测的粒度更细不再只是简单的 TCP 连通性检查而是会发实际的推理请求去探测第二是延迟感知的权重调整响应快的节点会自动获得更多流量第三是故障节点的自动摘除和恢复节点挂掉之后不会立刻被重新加回来而是有一个渐进式的恢复过程。这三层能力叠加起来效果就是你不需要再盯着监控面板手动调权重了。我试过在一个三节点的集群里故意把其中一个节点的网络延迟拉高到 500msJev 模式大概在 30 秒内就把这个节点的流量占比从 33% 降到了不到 5%而另外两个正常节点自动分担了剩余流量。这个响应速度在静态配置下是不可能实现的。对于已经在用 1Panel 做反向代理和虚拟主机托管的用户来说这个更新的意义在于你的 AI 服务终于可以像普通网站一样配好就不管了。以前 AI 网关的路由配置是需要持续维护的模型更新、节点扩缩容、网络波动每一个变化都可能需要你手动介入。Jev 模式把这些运维动作自动化了对于个人开发者和小团队来说省下来的时间就是实打实的成本。2. 为什么要在 1Panel 上做这件事AI 网关的定位与选型逻辑2.1 1Panel 做 AI 网关的天然优势很多人可能会问市面上专门的 AI 网关方案不少为什么要在 1Panel 里做这个问题我在最开始也有过。后来想明白了核心在于 1Panel 本身就是一个服务器管理面板它天然具备几个别人没有的条件。第一是它已经管着你的 Nginx 或 OpenResty 实例。1Panel 的反向代理功能、多域名绑定、虚拟主机配置底层都是通过管理 Web 服务器来实现的。AI 网关本质上也是一个反向代理只是代理的对象从普通 Web 服务变成了 AI 推理服务。既然底层设施已经在了加一层智能路由就是顺水推舟的事不需要你再单独部署一套网关系统。第二是配置的统一性。你用 1Panel 绑定了多个域名、配了 SSL 证书、设了访问日志这些基础设施在 AI 网关上可以直接复用。我实测过在 1Panel 里给 AI 网关绑定一个子域名然后套用已有的证书和日志配置整个过程不到两分钟。如果换成独立部署的网关方案光是证书同步和日志对接就得折腾半天。第三是资源占用的考量。1Panel 本身是 Go 写的资源占用很低AI 网关作为它的一个模块运行不会额外增加太多内存和 CPU 开销。我在一台 2C4G 的轻量服务器上跑 1Panel AI 网关 两个上游推理服务内存占用稳定在 2.5G 左右还有余量。这个配置如果换成 Kubernetes 加 Istio 那套光是控制面就得吃掉大半资源。2.2 Jev 模式解决了哪些实际痛点在没有 Jev 模式之前1Panel AI 网关的路由配置大概是这样的你手动添加多个上游地址给每个地址设一个权重值然后选择一个负载均衡策略轮询、加权轮询、IP Hash 等。这套机制对于稳定的后端服务是够用的但 AI 服务有几个特殊之处让它变得不够用。痛點一AI 服务的响应时间方差极大。同一个模型处理短 prompt 可能只要 300ms处理长 prompt 可能要 5s 以上。如果你用轮询策略一个正在处理长请求的节点会持续接收新请求导致队列越堆越长而其他空闲节点却分不到流量。Jev 模式的延迟感知调度就是针对这个问题设计的它会根据节点当前的排队情况和历史响应时间来决定是否继续给它派发请求。痛点二AI 服务的故障模式不一样。普通 Web 服务挂了就是挂了TCP 连接直接拒绝健康检查很容易发现。但 AI 服务经常出现假活状态——进程还在、端口还通、健康检查也返回 200但实际推理请求全部超时。这种状态下传统的健康检查完全失效网关会继续往这个节点派流量用户端看到的就是大量超时错误。Jev 模式的探测机制会发真实的推理请求能识别出这种假活状态。痛点三AI 服务的扩缩容更频繁。模型更新、GPU 资源调整、临时增加节点处理突发流量这些操作在 AI 场景下很常见。每次变动都意味着你要重新调整权重配置。Jev 模式的自动发现和动态权重机制让扩缩容变得无感——新节点上线后自动获得流量下线前自动排空。2.3 和其他方案的核心差异我对比过几种常见的 AI 网关方案。Nginx 原生做不了动态权重调整得靠 OpenResty 加 Lua 脚本维护成本高。Traefik 有动态配置能力但对 AI 协议的支持不够原生需要额外写中间件。专门的 AI 网关项目功能更全但部署复杂度也上去了而且和 1Panel 的集成度不如原生模块。1Panel 的 Jev 模式走的是另一条路不追求功能大而全而是把最核心的动态路由做扎实同时保持和面板其他功能的无缝集成。这个取舍我觉得是合理的。对于大多数个人开发者和小团队来说你需要的不是一套能处理百万 QPS 的网关系统而是一个配好就能用、不用天天盯着调优的方案。3. Jev 模式的核心机制拆解探测、评分、调度3.1 健康探测从端口检查到推理验证Jev 模式的健康探测机制是我觉得最值得细说的部分。传统的健康检查一般分两种TCP 检查只验证端口是否可连接和 HTTP 检查发一个 GET 请求看返回码。这两种在 AI 场景下都不够用。TCP 检查的问题很明显进程活着不代表服务正常。我遇到过好几次推理服务的进程还在端口也监听正常但模型加载失败了所有请求都返回 500。TCP 检查完全发现不了这种情况。HTTP 检查好一些但如果你只是检查一个/health端点而这个端点只返回静态的 200 响应那也检测不出推理能力是否正常。有些推理框架的健康检查端点确实会验证模型状态但也有很多只是简单返回 OK。Jev 模式的做法是发一个轻量级的推理请求作为探测。具体来说它会向每个上游节点发送一个极短的 prompt比如就一个 token然后检查返回结果是否符合预期。这个探测请求的开销很小但能真实反映节点的推理能力。如果节点返回错误、超时或者结果异常就会被标记为不健康。探测频率方面我观察到的默认行为是健康节点每 10 秒探测一次不健康节点每 3 秒探测一次为了尽快恢复。这个频率可以通过配置调整但建议不要调得太激进否则探测请求本身会占用推理资源。我试过把健康节点的探测间隔调到 3 秒结果在低配节点上探测请求占了大约 5% 的推理容量有点得不偿失。注意探测请求也是要消耗 token 的。如果你的上游是按 token 计费的 API 服务需要把探测开销算进成本里。不过对于自部署的推理服务这个开销基本可以忽略。3.2 动态评分延迟、成功率、负载的三维加权探测拿到数据之后Jev 模式会给每个节点算一个综合评分。这个评分的计算逻辑官方没有完全公开但根据我的测试和观察至少包含三个维度。第一个维度是响应延迟。这里用的不是单次延迟而是滑动窗口内的平均延迟。窗口大小我估计是最近 100 次请求或者最近 60 秒具体哪个先到算哪个。用滑动窗口而不是全局平均是为了让评分能快速反映节点的当前状态。一个节点如果突然变慢它的评分会在几十秒内就降下来。第二个维度是成功率。失败请求超时、5xx 错误、返回结果异常会被计入失败率。失败率的权重比延迟更高因为一个节点如果频繁出错即使响应快也不应该给它派流量。我测试的时候发现一个成功率从 100% 降到 90% 的节点评分下降幅度比延迟从 200ms 升到 400ms 还要大。第三个维度是当前负载。这个负载不是指 CPU 或内存使用率而是指该节点当前正在处理的请求数。一个节点如果已经积压了很多请求即使它历史表现很好新请求也应该优先给空闲节点。这个维度在突发流量场景下特别重要。三个维度的加权方式我推测是类似这样的公式综合评分 w1 * (1 / 平均延迟) w2 * 成功率 w3 * (1 / 当前队列长度)其中 w1、w2、w3 是权重系数具体数值未知但根据行为推断成功率的权重最高延迟次之队列长度再次。这个公式是我根据观察反推的不是官方文档的内容仅供参考。3.3 调度决策评分如何转化为流量分配有了评分之后怎么把评分转化成实际的流量分配这里有两种常见的做法一种是按评分比例分配比如三个节点的评分分别是 80、60、40那流量占比就是 80/180、60/180、40/180另一种是择优选择每次请求都选评分最高的节点。Jev 模式用的是混合策略。大部分请求会按评分比例分配但会保留一部分流量做探索。这个探索机制很重要因为如果完全按评分分配一个曾经表现不好但现在已经恢复的节点可能永远拿不到流量评分也就永远上不去。探索流量让所有节点都有机会证明自己。探索的比例我估计在 5% 到 10% 之间。这个比例不能太高否则会影响整体性能也不能太低否则恢复太慢。我测试过一个节点从故障中恢复后大约需要 2 到 3 分钟才能重新获得正常的流量占比。这个恢复速度我觉得是可以接受的。另外还有一个细节调度决策是在网关层做的不需要上游节点配合。这意味着你不需要在推理服务里装任何 agent 或 SDK只要它能响应 HTTP 请求就行。这个设计对异构环境很友好你可以同时接入不同框架、不同版本的推理服务Jev 模式一视同仁。4. 实操配置在 1Panel 里启用 Jev 模式的完整流程4.1 前置条件检查在开始配置之前先确认几个前提条件。这些是我踩过坑之后总结出来的缺一个都可能导致配置失败。1Panel 版本要求Jev 模式是较新版本才加入的功能建议把 1Panel 升级到最新稳定版。我用的版本是 v1.10 以上具体从哪个版本开始支持 Jev 模式建议查看官方更新日志确认。升级命令在面板的设置-关于里有一键升级按钮或者用命令行1pctl update也可以。AI 网关模块状态确认 AI 网关模块已经安装并启用。在 1Panel 的应用商店里搜索AI 网关如果显示已安装就说明没问题。如果没安装点击安装即可整个过程大概需要 1 到 2 分钟。上游服务准备至少准备两个可用的 AI 推理服务端点。可以是同一个模型的多个实例也可以是不同模型。每个端点需要提供一个 HTTP 接口支持标准的推理请求格式。我建议先用 curl 手动测试每个端点都能正常响应再去 1Panel 里配置。网络连通性确保 1Panel 所在服务器能访问所有上游端点。如果是内网服务检查防火墙规则如果是公网服务检查安全组配置。我遇到过配置都正确但就是不通的情况最后发现是上游服务的防火墙只允许了特定 IP 段。4.2 添加上游节点进入 1Panel 面板找到AI 网关模块点击上游管理。这里你会看到已有的上游节点列表如果是第一次配置列表是空的。点击添加上游填写以下信息名称给节点起一个容易识别的名字比如gpu-node-1、model-a-primary之类的。名字只是标识不影响功能。地址上游服务的完整 URL包括协议、主机、端口和路径。比如http://192.168.1.100:8000/v1/chat/completions。注意路径要写完整有些推理框架的接口路径不是根路径。权重初始权重值。在 Jev 模式下这个权重只是初始值后续会被动态调整覆盖。我一般填 100让所有节点从同一起跑线开始。超时时间请求超时阈值。AI 推理的超时时间要比普通 Web 服务设得长一些。我建议至少 30 秒如果模型较大或者 prompt 较长可以设到 60 秒甚至 120 秒。健康检查路径如果上游有专门的健康检查端点填在这里。如果没有Jev 模式会用推理请求做探测这个字段可以留空。添加完所有节点后列表里应该能看到每个节点的状态。初始状态可能是未知或检测中等探测完成后会变成健康或不健康。4.3 启用 Jev 模式这是最关键的一步。在上游管理页面的顶部或者路由设置标签页里找到路由模式选项。默认可能是加权轮询或最小连接数把它切换成Jev 模式。切换之后你会看到一些额外的配置项出现探测间隔健康节点的探测频率默认 10 秒。如果节点性能较弱可以适当调大比如 15 秒或 20 秒。恢复探测间隔不健康节点的探测频率默认 3 秒。这个不建议调大否则故障恢复会很慢。评分窗口计算评分时使用的滑动窗口大小默认 60 秒。如果流量波动大可以调小到 30 秒让评分更灵敏。探索比例用于探索的流量占比默认 5%。如果节点数量少比如只有两个可以调到 10%让恢复更快。这些参数我建议先用默认值跑一段时间观察效果后再根据实际情况调整。我一开始把探测间隔调得很短结果发现探测开销比预期大后来又调回去了。4.4 验证配置效果配置完成后怎么确认 Jev 模式真的在工作我一般用三种方法验证。方法一看面板的状态展示。1Panel 的 AI 网关页面会显示每个节点的实时评分和流量占比。如果 Jev 模式生效你会看到流量占比不是固定的而是随着节点表现动态变化。方法二手动制造故障。把其中一个节点的服务停掉观察流量是否在几十秒内自动转移到其他节点。然后再把服务启动观察流量是否在几分钟内逐渐恢复。这个测试能直观验证故障转移和恢复机制。方法三看日志。1Panel 的 AI 网关有访问日志和调度日志。调度日志里会记录每次请求被分配到哪个节点、当时的评分是多少。通过分析日志你能看到评分的变化趋势和调度决策的依据。我实测下来从停止一个节点到流量完全转移大约需要 20 到 40 秒。从恢复一个节点到流量回到正常水平大约需要 2 到 3 分钟。这个速度在大多数场景下是够用的。5. 常见问题与排查技巧实录5.1 节点一直显示不健康怎么办这是最常见的配置问题。可能的原因和排查步骤先检查上游地址是否写对了。我遇到过好几次地址里的路径少写了一段比如把/v1/chat/completions写成了/v1/chat导致探测请求返回 404。用 curl 手动测试一下完整地址确认能返回正常结果。再检查超时时间是否太短。如果模型加载慢或者首次推理需要预热探测请求可能在超时时间内完不成。把超时时间调大试试比如从 10 秒调到 30 秒。然后检查探测请求的格式。Jev 模式发的探测请求是标准的推理请求格式如果你的上游服务需要特殊的 header 或参数可能需要在高级配置里添加。我遇到过一个自部署的推理服务需要特定的 API key没配的话探测请求全部返回 401。最后检查网络。从 1Panel 服务器上用 curl 直接访问上游地址看是否通。如果不通就是网络或防火墙的问题和 Jev 模式无关。5.2 流量分配不均匀是怎么回事Jev 模式下的流量分配本来就是不均匀的这是正常现象。评分高的节点拿到的流量多评分低的拿到的少。如果你看到某个节点只拿到 10% 的流量先别急着调去看看它的评分是不是确实低。但如果某个健康节点长期只拿到极少的流量比如低于 5%可能有几个原因。一是探索比例设得太低节点没有机会证明自己。把探索比例从 5% 调到 10% 试试。二是评分窗口太长历史表现的影响太大。把窗口从 60 秒调到 30 秒让评分更反映当前状态。三是节点确实有问题虽然健康检查通过了但实际推理质量差比如返回结果不完整导致成功率评分低。5.3 探测请求影响推理性能怎么办探测请求确实会占用推理资源尤其是当节点性能较弱时。我试过在一个 4G 显存的节点上跑探测发现探测请求占了大约 3% 到 5% 的推理容量。这个开销在大多数场景下可以接受但如果你的节点已经在满负荷运行就需要优化。优化方法有几个。一是调大探测间隔从 10 秒调到 20 秒甚至 30 秒。二是用更轻量的探测请求比如把 prompt 长度从 10 个 token 降到 1 个 token。三是如果上游有专门的健康检查端点配置使用那个端点避免发推理请求。不过要注意专门的健康检查端点可能检测不出假活状态需要在探测开销和检测准确性之间做取舍。5.4 节点恢复后流量回不来这个问题我遇到过。一个节点从故障中恢复后健康检查通过了但流量占比一直上不去。原因是它的评分还没有恢复而评分是基于历史请求计算的历史请求里全是失败记录。解决办法是调大探索比例或者手动重置节点评分。1Panel 的上游管理页面应该有一个重置统计的按钮点击后节点的评分会清零重新计算。如果没有这个按钮可以尝试把节点删除再重新添加效果是一样的。另外恢复探测间隔也会影响恢复速度。如果恢复探测间隔是 3 秒节点恢复后大约 3 秒就会被标记为健康但评分恢复还需要更长时间。我建议在节点恢复后手动观察几分钟确认流量占比在逐步上升就说明机制在工作。5.5 常见问题速查表问题现象可能原因排查方法解决措施节点显示不健康地址错误、超时太短、探测格式不匹配、网络不通curl 手动测试、检查超时配置、查看探测日志修正地址、调大超时、添加必要 header、检查防火墙流量分配不均评分差异大、探索比例低、评分窗口长查看节点评分、检查探索比例配置调大探索比例、缩短评分窗口、检查节点实际表现探测开销大探测间隔短、prompt 太长、节点性能弱观察探测请求频率和资源占用调大探测间隔、缩短 prompt、使用专用健康检查端点恢复后流量不回来历史失败记录影响评分、探索比例低查看节点评分历史、检查探索配置重置节点统计、调大探索比例、等待评分恢复请求超时率高超时时间太短、节点过载、网络延迟查看调度日志、检查节点负载调大超时时间、增加节点、优化网络6. 进阶玩法Jev 模式和其他功能的组合使用6.1 配合多域名绑定做环境隔离1Panel 的多域名绑定功能可以和 AI 网关结合实现环境隔离。比如你有生产和测试两套推理服务可以用不同的子域名分别绑定ai-prod.example.com指向生产节点组ai-test.example.com指向测试节点组。每个域名下的 AI 网关独立配置 Jev 模式互不影响。这个玩法的好处是配置隔离清晰生产环境的变动不会影响测试环境。而且 1Panel 的证书管理可以给每个子域名单独签发证书安全性也有保障。我目前就是用这个方式管理三套环境生产、预发、测试每个环境有自己的域名和节点组。6.2 配合反向代理做路径分流如果你的 AI 服务有多个接口比如 chat、embedding、rerank可以用 1Panel 的反向代理功能做路径分流把不同路径的请求转发到不同的 AI 网关实例。每个实例可以配置不同的 Jev 模式参数比如 chat 接口的超时时间长一些embedding 接口的超时时间短一些。配置方法是在反向代理规则里添加 location 匹配比如/v1/chat/*转发到ai-gateway-chat/v1/embeddings/*转发到ai-gateway-embed。每个 AI 网关实例独立管理自己的上游节点和 Jev 配置。6.3 配合监控告警做自动运维1Panel 有监控告警功能可以监控服务器的 CPU、内存、网络等指标。虽然目前没有直接针对 AI 网关的告警规则但你可以通过监控上游节点的资源使用情况来间接判断。比如某个节点的 CPU 持续超过 90%说明它可能过载了Jev 模式应该会自动减少给它的流量。如果流量没有减少说明 Jev 模式的评分机制可能没有正确反映负载情况需要检查配置。我目前的实践是给每个上游节点配一个资源监控当节点 CPU 超过 85% 持续 5 分钟时触发告警。收到告警后我会去 AI 网关页面看该节点的流量占比如果占比仍然很高就手动调低它的权重或者临时摘除等资源降下来再恢复。6.4 多模型混合部署的调度策略Jev 模式支持不同模型混合部署这在实践中很有用。比如你可以同时接入一个快速的小模型和一个慢速的大模型让 Jev 模式根据请求特征来调度。不过需要注意的是Jev 模式的评分是基于节点整体表现的不会区分请求类型。如果你希望短请求走小模型、长请求走大模型需要在网关前面再加一层路由逻辑或者在上游服务里做判断。我试过一种折中方案把小模型和大模型分别配成不同的上游组然后用 1Panel 的反向代理按请求特征分流。比如根据请求体里的max_tokens参数来判断小于 100 的走小模型组大于 100 的走大模型组。每个组内部再用 Jev 模式做动态调度。这个方案配置起来稍微复杂一些但效果不错。7. 我在实际使用中总结的几条经验Jev 模式上线到现在我在三个不同规模的环境里都部署过单节点、三节点、五节点。踩过的坑不少也总结出一些官方文档里不会写的经验。第一条经验不要一开始就调参数。默认参数是经过调优的适用于大多数场景。我一开始觉得探测间隔 10 秒太长调到了 3 秒结果发现探测开销明显增加而且评分波动变大反而影响了调度稳定性。后来调回默认值一切正常。建议至少跑一周默认配置观察实际表现后再决定是否调整。第二条经验节点数量少于三个时Jev 模式的优势不明显。两个节点的情况下一个挂了另一个全扛评分机制能做的优化很有限。三个节点是 Jev 模式发挥价值的最低配置五个节点以上效果更明显。如果你的预算有限宁可三个低配节点也不要两个高配节点。第三条经验超时时间要设得比预期最长响应时间还长 50%。比如你的模型最长需要 20 秒完成推理超时时间至少设 30 秒。设得太短会导致正常请求被误判为超时影响节点评分。我吃过这个亏超时设了 15 秒结果长 prompt 请求全部超时节点评分被拉得很低。第四条经验定期查看调度日志。Jev 模式的调度决策都记录在日志里定期分析日志能发现很多问题。比如某个节点的评分持续下降可能是硬件老化或者模型退化某个时间段的超时率突然升高可能是网络波动或者流量突增。这些问题在面板上不一定能直观看到但日志里都有记录。第五条经验Jev 模式不是万能的。它解决的是动态路由问题不解决容量规划问题。如果你的总容量不够再怎么智能调度也扛不住流量。该加节点的时候还是要加节点Jev 模式只是让现有节点的利用率更高不是变魔术。最后分享一个小技巧如果你不确定 Jev 模式是否适合你的场景可以先在一个非关键业务上试运行。比如把测试环境的 AI 网关切到 Jev 模式跑一周看看效果。确认没问题后再切生产环境。切换过程是平滑的不需要重启服务现有的连接不会中断。这个灰度验证的思路我在很多功能更新上都用过稳妥且成本低。