GPUStack 决策路由实战：用 Jev 让网关自动选模型

GPUStack v2.3.0rc2 预览了一项值得动手实测的高级路由能力——通过 Jev 决策服务为请求选择合适的生成模型。本文完整走通这条链路：先理解决策模型的角色，再部署两个私有模型、接入 DeepSeek 与 Jev，最后用不同难度的任务验证网关的实际选择。

决策模型究竟做什么

理解决策路由的第一步，是分清两类模型的职责。生成模型负责回答问题，决策模型负责提供选模型的依据。

举个直观的例子：“把 Good morning 翻译成中文”和“设计一套跨区域支付系统”需要的能力完全不同。前者一个小模型足以胜任，后者则可能需要更强的模型去推理故障处理与一致性问题。

Jev 接收请求内容、候选模型及其能力描述，通过 TypeSafe Choice 接口返回结构化的选择依据。GPUStack 网关据此选定模型，再把请求转发给对应的生成服务——最终答案仍然来自 Qwen3 或 DeepSeek^广告。

这意味着配置决策路由的核心，是把每个候选模型适合处理哪类任务描述清楚。决策模型不会替管理员确立业务质量标准；能力描述越贴近真实负载，选择结果就越容易验证。

Jev 在网关层解决的问题

GPUStack 原有的模型路由能把多个目标放在一个入口后面。固定权重回答的是“每个模型应该分到多少流量”，适合灰度发布和流量分配。Jev 决策路由更进一步，回答的是“这个请求该交给哪个模型”。

对于一个同时处理文本和代码的助手，理想的分工大致如下：

任务类型	本策略中的候选
短翻译、字段抽取、事实问答、基础算术	私有 Qwen3-8B
受约束的算法实现、SQL、局部代码调试	私有 Qwen3-32B
复杂并发代码、跨区域系统设计	外部 DeepSeek

应用只需使用一个路由名，分工则由管理员在 GPUStack 侧维护。增删候选、调整任务边界都不影响应用的调用方式。这正是决策模型的网关级价值：把任务分类集中到路由策略中，让不同模型各司其职。至于这是否真能提升质量或降低成本，仍需用真实负载验证——本文先验证任务路由是否按配置执行。

固定权重路由与决策路由在架构上的区别值得细说。固定权重路由（如加权轮询）是一种无状态的流量分配机制：它在请求到达之前就已经确定了分配比例，不感知请求内容。这适合 A/B 测试或金丝雀发布，但无法区分"一个简单翻译"和"一个复杂系统设计"之间的能力差异。决策路由则是有状态感知的：每个请求的内容都会被发送给决策服务，由决策服务动态评估哪个候选模型最适合处理该请求。这种模式的代价是每次请求多一次外部调用（到 Jev），带来额外延迟，因此适合对质量或成本分级有明确需求的场景，而非所有路由场景都适合引入决策服务。

准备模型与外部服务

先准备三个负责生成答案的候选，再接入负责决策的 Jev。

通过 GPUStack 部署 Qwen3-8B 与 Qwen3-32B-W8A8，两者都应显示 1/1 可用副本，并各发一次推理请求确认能正常回答。

接着在 Providers 中添加 DeepSeek：选择 DeepSeek 类型，填入 API key 并测试连通性，本次测试使用的生成模型为 deepseek-flash。

再添加 Jev：选择 TypeSafe Decision Service (Jev)，端点设为 https://api.typesafe.ai，填入 TypeSafe API key，决策模型使用 jev-latest。

至此职责已清晰分离——Qwen3 和 DeepSeek 是路由目标，负责生成答案；Jev 是决策服务，负责提供帮助网关选目标的依据。

配置决策路由

创建名为 demo-smart 的路由，把两个私有部署和 DeepSeek 模型作为普通路由目标加入。应用只需请求 demo-smart。

在基础信息中选择 Policy，启用 Decision Service Routing，选中 Jev provider routing-jev，决策模型填 jev-latest。

本次测试把三个普通流量权重都设为 0，决策贡献权重设为 20，便于观察 Jev 的作用。决策贡献权重是对分数的相对影响，而非流量百分比。

能力描述必须精确匹配

接下来定义决策指令与模型评估标准，二者共同回答两个问题：整体选择原则是什么，每个候选适合哪些任务。

设置项	本测试核心内容
决策指令	优先选择能完成任务的最低成本候选：简单任务给 8B，中等任务给 32B，复杂任务给 DeepSeek
8B 能力描述	适合短翻译、抽取、事实问答、短摘要、基础算术，上下文预算 8,192 tokens
32B 能力描述	适合 SQL、算法实现、局部调试，上下文预算 16,384 tokens
DeepSeek 能力描述	适合复杂推理、带测试的并发代码、分布式架构设计

能力描述里的键名必须与真实候选模型名一致：route-local-qwen3-8b、route-local-qwen3-32b、deepseek-flash。不要使用路由别名或 provider 名，否则无法映射到候选。此外，8B 低档、32B 中档、DeepSeek 高档的成本假设也是配置的一部分，本测试并未计算硬件摊销或 API 费用。

一个路由，验证三种模型选择

本节所有测试都走同一个路由 demo-smart。九个测试输入是九个问题而非九个路由，只有问题内容在变，model 字段始终不变，我们观察网关是否按配置的分工选中 8B、32B 或 DeepSeek。

先写下预期结果

从三个代表性输入入手：短翻译预期走 8B，受约束的区间合并代码走 32B，跨区域支付系统设计走 DeepSeek。先记录预期，可以避免看到答案后再反向解释选择。

发请求并保留头与答案

用 API 做正式测试以便追踪所选模型。创建 GPUStack 推理 key，把请求体保存为 request.json，model 字段设为 demo-smart。发送请求时同时保存响应头到 response.headers、答案到 response.json。

后续测试只改 messages 里的问题，并为代码或长回答调大 max_tokens——区间合并用 1,024 tokens，系统设计用 1,536 tokens。

按请求 ID 回溯实际模型

从响应头读取 x-gpustack-request-id，再用它定位对应的 Higress 日志条目，检查 upstream_cluster 确认转发目标、ai_log.model 确认模型名。本测试中 model-2-6.static 对应 8B，model-3-7.static 对应 32B，provider-1.dns 对应 DeepSeek。

这里有个关键认知：证据是“一个请求 ID + 其响应 + 匹配的访问日志”三者的组合。HTTP 200 只能证明请求成功，并不能证明选中了哪个模型。

Higress 是阿里云^广告开源的云原生 API 网关，基于 Envoy 构建，GPUStack 将其作为处理 AI 推理流量的网关层。在本文架构中，GPUStack 负责管理模型部署与路由策略配置，并将策略同步给 Higress；实际的请求转发、插件执行（包括调用 Jev 决策服务）和负载均衡都发生在 Higress 侧。upstream_cluster 字段是 Envoy/Higress 记录实际转发目标的标准字段，其命名规则由 GPUStack 在同步配置时生成（如 model-2-6.static），与路由 UI 中显示的候选序号对应。这也是为什么日志追踪是验证路由选择的唯一可靠手段——HTTP 响应本身不携带"由哪个上游模型生成"的信息。

实测结果全部命中

除三个代表性输入外，还测试了事实问答、抽取、算术、SQL 等任务，九个输入全部通过 demo-smart：

测试输入	预期模型	实际模型
法国首都	8B	8B
Good morning 短翻译	8B	8B
从文本抽取城市	8B	8B
计算 2+2	8B	8B
受约束区间合并代码	32B	32B
PostgreSQL 聚合查询	32B	32B
分析修复异步锁死锁	32B	32B
跨区域订单支付系统设计	DeepSeek	DeepSeek
带测试的异步 LRU 缓存	DeepSeek	DeepSeek

九个请求全部返回 HTTP 200、finish reason 为 stop，实际模型与预期全部吻合。翻译、区间合并、系统设计三个任务各以非流式方式重复三次，模型选择保持稳定；流式版本也选中了相同模型。这证明配置的任务分工可以在单一入口后面落地。

选对模型不等于答案可用

为判断这套分工是否有具体依据，我们用相同输入和预算把翻译、抽取、算术、区间合并任务同时发给三个候选。代码任务要求正确合并区间、不修改输入、对非法区间抛出 ValueError，生成代码在隔离环境中执行。

验收项	8B	32B	DeepSeek
短翻译、城市抽取、2+2	全对	全对	全对
合并结果、空输入、端点相接	通过	通过	通过
不修改原始输入	失败	通过	通过
对非法区间抛 ValueError	失败	通过	通过

8B 修改了原始输入并漏掉非法区间检查，32B 与 DeepSeek 都满足约束。这为“把受约束算法实现路由到 32B”提供了具体证据，但并不能确立模型能力的通用排名。值得警惕的是，DeepSeek 生成的异步缓存代码虽通过三个自带测试，日志里却仍残留未处理的 Future 异常——更强模型的输出同样需要独立验证。

Jev 失败时会发生什么

模型选择依赖 Jev 返回有效的决策依据。如果 Jev 不可达、超时或返回无效结果，决策插件不发布排名意见，网关继续后续的选择与转发流程，这就是 fail-open 行为。

在一条隔离的失败测试路由中，我们配置了不可达的 Jev 端点而保持三个候选健康。日志出现 publishing no rank，DeepSeek 恰好作答，最终返回 HTTP 200。这说明决策失败后处理可以继续，但并不意味着失败总会路由到 DeepSeek。

另一个约 79 KB 的输入则未成功：Jev 返回 400 且无排名意见，请求进入 32B 后又因上下文预算不足返回 400。当没有决策排名时，网关无法保证选中满足任务要求的模型。此外，一条试图指示系统忽略策略、强行选 DeepSeek 的翻译提示仍走了 8B，但答案并不满足要求——这再次说明模型选择与答案质量必须分开评估。

回到网关，走完完整调用路径

经过配置与验证，GPUStack 与网关的职责分工就更清晰了。GPUStack 管理候选模型、providers 与路由策略，并把配置同步到 Higress。请求到达网关后，插件准备候选信息，决策插件调用 Jev 取选择依据，网关选定上游目标后再转发给私有模型或 DeepSeek。

Jev 调用与生成调用是两条不同的路径：Jev 参与模型选择，Qwen3 或 DeepSeek 生成答案。若决策调用未产生有效依据，请求可能继续，但不再保证选中预期模型。

插件如何使用 Jev 结果

从内部看，插件准备候选与任务描述、调用 Jev、把返回的模型概率转换为候选分数，再交由负载均衡 finisher 聚合分数并选定上游。相关流程基于决策插件源码 commit 790256e。需要注意，图中的概率与置信度仅用于说明计算过程，并非实测响应；置信度调整的是决策意见的影响力，而非答案正确的概率。

对应用而言，入口始终是 demo-smart；对管理员而言，工作是维护候选模型的能力边界，并持续用代表性任务验证选择。这正是决策路由的价值：把“该交给哪个模型”的决定放进网关，让多模型专精成为可配置、可测试的策略。

本次验证共覆盖 36 个请求（9 个不同输入走同一路由、12 个同任务基线、6 次重复、3 个流式请求、6 个失败或策略控制用例），路由与传输各自达标，答案质量单独评估。本文聚焦 v2.3.0rc2 引入的能力，使用开发环境测试，未包含持续并发测试或成本收益分析。

TypeSafe Choice（Jev 所实现的接口）是一种结构化决策接口，其设计目标是让 AI 决策的输出可被程序直接消费，而非生成自由文本。与直接让 LLM 输出"选模型 A"相比，结构化接口能够返回每个候选的概率分布或置信度分数，便于下游系统进行加权聚合。GPUStack 的决策插件将这些分数与候选模型的基础权重合并，再由负载均衡 finisher 确定最终上游目标。置信度并不代表"答案正确的可能性"，而是代表决策服务对"该模型是最合适选择"这一判断的把握程度——置信度越高，决策意见对最终得分的拉动越大，但被选模型给出的答案是否满足业务要求，仍需独立验证。