引言

给大模型应用增加一个统一入口，看起来只需要代理几个接口。但当模型数量、Agent数量和调用成本上来以后，问题会逐渐变成：简单问题能不能用便宜的模型？复杂任务什么时候升级？同一个会话是否应该一直使用同一个模型？这些判断应该由业务、网关还是模型服务负责？

围绕这些问题，对vLLM Semantic Router和Higress做了一次梳理。两者都有路由能力，但关注的层次不同：一个侧重理解请求并选择模型，一个侧重统一接入和流量治理。职责不先讲清楚，两个组件叠在一起，只会多出一套规则和一个排障入口。

本文整理自“澄清难度路由职责”的讨论，以方案分析为主，部署部分仅介绍组合思路，不作为已经完成联调的安装教程。

资料核对日期：2026-10-20。历史讨论涉及Semantic Router v0.3；核对时官方最新发布已为v0.4.0，Higress为v2.2.5。下文涉及具体字段时附对应文档，实际配置应与选定版本保持一致。

先把三个问题拆开

请求难不难、应该用哪个模型、最终请求发到哪个节点，是三个不同的问题。

层次	需要回答的问题	输出示例
请求判断	任务属于什么领域？推理要求高不高？上下文是否复杂？	领域标签、复杂度信号、难度分数
模型决策	在成本、质量、约束和会话状态下选谁？	某个模型或模型能力路径
流量执行	这个模型的哪个实例能接收请求？	某个可用后端节点

比如“查询一个Java方法的用法”和“分析一个跨服务事务的一致性方案”，都可能归到编程领域，但适合的模型不一定相同。反过来，同一个模型可以有多个副本，选定模型以后，仍然需要负载均衡。

这里的Small / Medium / Large只表示我们为模型池定义的能力档位，不是项目内置的统一命名，也不等于参数规模的绝对排序。某个专用小模型在特定任务上可能更合适。

两个组件各负责什么

vLLM Semantic Router

根据请求信号、策略和上下文，在配置好的候选模型中选择合适的模型路径。

它的核心是模型决策。请求进入以后，可以提取规则、语义、领域、上下文、复杂度等信号，再通过策略形成决策。官方的Projection说明把信号、派生分数和映射结果分开，使“如何计算”和“如何选路”能够分别维护。

注意名称上的区别：vLLM是推理引擎，vLLM Semantic Router是路由项目。部署Semantic Router，不代表同时启动了所有物理模型；后端模型服务仍需要单独准备。CLI说明

Higress

为AI应用提供统一入口，并通过网关及插件能力管理访问、协议、流量和运行治理。

它更贴近企业入口：谁能调用、使用哪个身份、允许多少流量、如何代理模型接口、如何记录调用。具体能力需要按插件和部署配置启用，不能把“安装网关”理解为所有治理功能自动生效。Higress官方介绍

这不是说Higress只能机械转发。它有AI意图识别等能力，也允许扩展插件。需要比较的是：我们的目标是否能直接映射到现有能力，还是需要自己实现一套难度评分与会话决策。

功能点对比

关注点	vLLM Semantic Router	Higress	选型时要看什么
设计重心	请求理解与模型选择	统一入口与AI流量治理	当前真正缺少哪一层
多模型接入	配置候选模型及后端绑定	模型代理与供应商接入	API、鉴权和模型名称是否匹配
规则与语义信号	作为路由策略的输入	可用路由规则、意图识别及插件	有意图分类不等于有难度评分
连续难度分数	有Score Projection等对应抽象	需核对具体插件，或接入评分服务	分数来源、量纲和校准方式
分数到模型档位	可用Mapping与Decision组织	可接收决策结果后按规则执行	模型选择权由谁持有
会话中的保持与切换	有`session_aware`模型选择策略	传统节点亲和与自定义扩展需分别看	固定模型还是固定节点
后端节点负载均衡	与所用数据面及部署配置配合	网关流量治理能力	选模型之后怎样选副本
鉴权、限流和配额	按所用模块与部署核对	有相应网关和AI插件	哪一层统一计量与拒绝
故障处理	模型候选与路由策略的一部分	重试、故障转移等网关治理	避免两层各自重试
可观测	关注路由决策及其证据	关注入口流量、用量与运行状态	能否串联一次完整请求
Agent接入	提供兼容的模型API入口	提供统一代理入口	不要只测一条普通问答

这张表比较的是职责和能力组织方式，不是“支持/不支持”的永久清单。项目持续演进，不能因为历史对话中没看到某项能力，就推断它永远不存在。

难度分数到底表达什么

难度不是提示词长度

长文本可能只要求提取一个字段；很短的问题也可能需要复杂证明。领域、上下文长度、工具使用、输出约束都能提供线索，但没有任何一个线索天然等于难度。

工程上可以先用低成本规则处理明确请求，再让语义或复杂度判断处理剩余流量。讨论中使用的L1 / L2 / L3是方案分层的简称，不是两个项目共有的标准接口。只有确实需要更高成本的判断时，再引入下一层。

连续Score需要单独设计

Semantic Router的Scores文档提供weighted_sum，可以组合不同信号。输入既可以是是否命中，也可以是置信值或原始数值，具体取决于信号暴露的数据。

下面只是业务概念示例，不是可直接粘贴到项目中的配置：

request + context
       ↓
signals
       ↓
difficulty_score
       ↓
score band
       ↓
candidate models

需要注意两个细节：

加权和不自动落在0～1或0～100。 原始输入的范围、负权重和归一化都要明确；“73分”只有在评分口径确定后才有意义。
加权和不自动产生连续精度。 如果输入只有几个布尔值，结果仍然只会落在有限的组合上。给它取名为连续Score，并不会增加信息量。

我们可以为了业务展示把分数划成简单、中等、复杂，但阈值要在自己的样本上确定。不能直接把别人的示例阈值当作生产结论。

分数与Confidence不是一回事

difficulty_score回答“按这套标准有多难”；confidence需要进一步说明“对哪个判断有多确定”。它可能指分类器置信度，也可能指映射结果离阈值有多远，二者不能混用。

官方Mappings文档提供阈值映射，并介绍了sigmoid_distance校准：根据分数到边界的距离产生映射置信值。这个值不是模型回答正确率，也不是未经评估就成立的统计保证。

举个我们自己定义的例子：若复杂档位从70分开始，69.9和70.1虽然落在两侧，但都在边界附近。合理的方案需要考虑边界样本如何处理，而不是仅凭0.2分差就认定请求发生了本质变化。

Session粘滞究竟固定什么

固定节点，不等于固定模型

Higress的Cookie亲和性说明描述的是让相关请求落到同一个后端节点。这适用于需要节点亲和的服务，但不能直接推出“整个Agent会话始终选择同一档模型”。

亲和目标	示例	解决的问题
后端节点	同一个模型的副本A	节点状态或缓存局部性
模型	一直选择`model-a`	模型切换与上下文兼容
模型档位	保持在高能力候选池	能力级别稳定
Provider	保持在某个供应商	供应商侧状态与接口约束

这几项需要分别定义。固定一个网关或Router副本，也不等于固定了模型或供应商。

稳定，不是永远不允许切换

讨论里真正关心的是：同一个Agent Session可以连续完成任务，同时在需要时提高模型能力，而不是每轮重新选出一个完全不同的模型。

Semantic Router的session_aware在匹配决策的modelRefs中选择模型，并考虑保持、切换、工具循环和状态可迁移性等因素。它不替代选定模型内部的节点负载均衡，也不会自动成为应用的对话记忆系统。

因此，下面是我们期望评估的行为，不是所有配置下都保证发生的结果：

第1轮：普通问答             → 轻量模型
第2轮：继续同一任务         → 保持，避免无意义切换
第3轮：需要更强推理         → 评估是否可升级
工具调用尚未完成           → 按策略锁定模型
任务结束或会话超时         → 按策略重新选择

这里还有一个容易漏掉的边界：会话策略要在当前候选集和兼容性约束内工作。 如果不同难度Decision只各自配置一个模型，就不能仅凭启用session_aware，认定它会跨所有Decision任意保持和升级。候选集、Decision漂移与重置行为需要一起验证。

Session ID只提供身份

对于Chat Completions等调用，可以显式传递稳定的x-session-id。同一会话保持一致，不同租户与会话避免冲突。不要把敏感信息直接放进标识，也不要把每轮变化的Request ID当成长期Session ID。会话身份说明

标识本身不保存完整聊天历史。客户端仍需按API契约传递消息或续接状态；使用previous_response_id等供应商状态时，还要确认这些状态是否允许跨模型迁移。

多副本部署同样需要单独设计状态一致性。给Router增加副本，并不意味着其会话状态天然共享；节点亲和可以是部署策略的一部分，但不能替代持久化、故障恢复和跨副本一致性的验证。

两个组件一定要一起部署吗

不一定。首先确认缺的是治理、智能决策，还是两者都缺。

方案	适用情况	主要代价
只用Semantic Router	核心是模型选择，已有入口治理或暂时不需要完整网关	仍需评估入口、身份、配额等要求
Higress加自定义决策能力	已标准化使用Higress，路由策略较简单	评分、会话和决策证据可能需要自行维护
Higress加Semantic Router	既需要统一企业入口，也需要相对独立的模型决策	多一层代理与配置，排障和延迟都要评估

组件越多并不代表架构越完整。如果只有两个固定模型、一条明确规则，先把这条规则跑好，比引入一套复杂评分系统更实用。

组合部署的职责边界

Higress在前，Semantic Router在后

对已有企业网关、又希望引入独立模型决策层的场景，可以考虑：

Agent经过Higress统一治理后进入Semantic Router进行模型决策的分层架构

请求先通过Higress完成入口控制，再进入Semantic Router的对外HTTP入口，由后者选择模型后端。图中的箭头是主请求方向，响应沿链路返回。

这是一种基于职责划分的组合设计，不等于官方已经提供了任意版本Higress的一键集成包。 Semantic Router的Istio Gateway示例使用ExtProc集成，不能因为Higress也基于Envoy，就直接套用其中的资源清单。

需要区分两条路线：

HTTP串联：把Semantic Router完整服务栈的HTTP入口作为Higress上游，先验证协议透传和职责划分。
数据面深度集成：直接在Higress数据面调用外部处理服务，涉及ExtProc支持、过滤器顺序和路由重算，需要单独实现与验证。

不要把ExtProc的gRPC端口当作OpenAI HTTP接口配置到网关里。这两个入口的协议和用途不同。

模型选择只保留一个主要责任方

Higress的model-router可以提取请求中的model供后续路由使用。这和根据请求难度选择模型是两件事。

在上述分层方案里，可以让Higress将某个逻辑模型入口交给Semantic Router，由Semantic Router统一决定物理模型。不要同时让两边维护一份难度阈值和升级规则，否则出现差异时，很难判断哪一层的选择才是最终结果。

供应商凭据也要按实际调用路径管理：如果物理模型由内层Router直接调用，不能假设外层Higress会自动接管每个供应商的鉴权、连接池与故障转移。确实需要另一层出口代理时，应画成独立链路，避免回到同一入口形成循环。

流量经过，不代表所有信息都能看见

Higress看到的可能是逻辑模型名，而实际物理模型由内层确定。入口审计需要同时关联逻辑入口、最终模型、请求ID和Session ID；不能仅根据入口参数统计物理模型分布。

Token配额也需要核对真实usage，尤其是流式响应。若网关看不到用量字段、供应商计费口径不同，或者内层发生重试，计量结果可能与账单不同。不能因为请求经过网关，就认为精确配额和费用归集自然成立。

Agent只改BaseURL就够了吗

如果Agent使用兼容的API子集，调整BaseURL确实可以降低接入成本。但“能请求”与“业务行为兼容”之间，还有不少内容需要验证。

以Chat Completions为例，接入时至少明确这几项：

BaseURL        → 网关入口及正确的 /v1 路径
API Key        → 企业入口的身份凭据
model          → 部署中实际配置的逻辑模型入口
x-session-id   → 稳定且隔离的会话标识
messages       → 按协议传递所需历史与工具消息

这里没有给出固定的model别名，是因为别名属于实际部署契约，不能把文档某个版本中的auto或其他命名当作所有环境的默认值。

普通文本问答通过以后，还要验证stream、工具调用、结构化输出、错误码、取消请求和超时。使用Responses或Anthropic协议时，应按对应API重新验证，不从Chat Completions的结果外推。