【免费下载链接】semantic-router
An open, programmable decision layer for models and compute.
应用不应在“最佳模型”每次更替时重写集成逻辑。vLLM Semantic Router v0.4（代号 Hermes）为应用提供一个稳定的虚拟模型名，由 Router 从一个经过资格校验的后端池中选出模型、交付答案，并持续度量这次选择是否真的带来了改进。读完本文，你可以掌握 Hermes 的三条主线：Vela 1.0 / Decision 1.0 两族开源路由模型、MoM（Mixture-of-Models）虚拟模型与五种内置 recipe 的实际配置形态，以及 Signal → Projection → Decision → Algorithm → Model 这条可检验路由路径上各阶段的具体行为与源码级依据。
一、Hermes 的三处关键推进
相对上一个版本 v0.3 Themis（该版本把路由做成了有状态、可检查的系统），Hermes 完成了从“可观察”到“可改进”的跨越，官方将其概括为三步：
- 打开模型底座。Vela 负责理解请求（请求是什么、需要什么上下文、返回结果是否有风险）；Decision 负责让软件基于证据和标准做出下一个选择。
- 给应用一个名字。一个虚拟模型映射到一个隔离的 MoM recipe；在这层抽象之下，Router 可以选择单个后端、在需要时升级（escalate），或运行有边界的模型协作。
- 度量整条路由。请求必须能经受协议转译、长会话和后端故障；随后用 sr-bench 把“被路由后的体验”与单个模型在同一批任务上做对比。
按发布文档的口径，自 Themis 以来该项目累计 982 次提交、130 位贡献者，其中 107 位为首次贡献者。
二、两个开源模型家族：Vela 1.0 与 Decision 1.0
Vela 1.0：在选模型之前理解工作负载
路由的前提是识别请求在要求什么。Vela 1.0 首发 14 个开源模型，随后加入 Shield（KR-Labs 贡献），家族达到 15 个模型，每个模型承担“理解请求、寻找上下文、校验返回结果”中的一个具体任务：
| 模型 | 任务类型 | 作用 |
|---|---|---|
| Vela-1.0-Encoder-307M-Domain | 分类 | 识别请求主题，用于专家路由。 |
| Vela-1.0-Encoder-307M-Feedback | 分类 | 识别纠正、澄清等用户反馈。 |
| Vela-1.0-Encoder-307M-Modality | 分类 | 判断请求需要文本、图像还是两者兼有。 |
| Vela-1.0-Encoder-307M-FactCheck | 分类 | 标记需要外部事实知识或检索的请求。 |
| Vela-1.0-Encoder-307M-Guard | 分类 | 发现提示注入与越狱（jailbreak）尝试。 |
| Vela-1.0-Encoder-307M-Safety | 分类 | 检测不安全内容。 |
| Vela-1.0-Encoder-307M-Hazard | 多标签分类 | 对不同的内容风险类别分别打分。 |
| Vela-1.0-Encoder-307M-Shield | 多任务分类 | 在一个编码器中同时给出请求侧与响应侧的安全信号。 |
| Vela-1.0-Encoder-307M-PII | 词元分类 | 定位敏感片段，支持隐私感知处理。 |
| Vela-1.0-Encoder-307M-Halu | 词元分类 | 标记回答中未被所提供证据支撑的片段。 |
| Vela-1.0-Encoder-307M-Embedding | 语义相似度 | 生成用于检索与聚类的多语言向量。 |
| Vela-1.0-Encoder-307M-Reranker | 重排序 | 把最相关的检索段落排到前面。 |
| Vela-1.0-Omni-Nano | 多模态嵌入 | 为文本、图像、音频生成紧凑嵌入。 |
| Vela-1.0-Omni-Mini | 多模态嵌入 | 更大共享空间 + 带指令的文本检索。 |
| Vela-1.0-Encoder-307M | 掩码语言建模 | 作为专用微调的多语言底座。 |
Hermes 同时把 Vela 接进了运行中的 Router：选定的文本模型直接作为路由信号源，Halu 出现在参考配置中，Omni 则提供多模态嵌入的可选原生路径。仓库内的 Vela Router Models 文档给出了注册表中的模型角色表、Omni Nano/Mini 的参数与输入预算细节（例如 Nano 文本上限 512 token、Mini 32,768 token，以及 MTEB 完整面板上的分数与排名的诚实说明）。
Decision 1.0：让“选择本身”成为开放模型
系统还需要决定“接下来发生什么”。Decision 1.0 发布 6 个开源权重模型，直接对应用提供的候选项打分：选一个选项（Choice）、判断一个条件（Noul）、对一个有序评分标准打分（Score），返回软件可以使用和检查的概率分布。
| 模型 | 适用场景 | 输入预算 |
|---|---|---|
| Decision-1.0-Kai-0.6B | 紧凑的通用路由、条件与动作选择 | 1,024 tokens |
| Decision-1.0-Lex-0.6B | 客服、发票、故障、agent 轨迹等运营工作流 | 1,024 tokens |
| Decision-1.0-Eos-0.8B | 最小的混合解码器，支持更长证据 | 16,384 tokens |
| Decision-1.0-Sol-2B | 长上下文决策的更大容量 | 16,384 tokens |
| Decision-1.0-Nox-4B | 组合条件、应用规则、选择动作 | 16,384 tokens |
| Decision-1.0-Lux-9B | 发布套件中整体结果最强的最大模型 | 16,384 tokens |
两点需要准确理解边界：其一，Decision 1.0 与 Router 内部正在运行的 Decision 阶段（规则 + 优先级/置信度策略）是两个不同概念，前者是独立发布的模型家族；其二，官方在发布文档中明确说明，Decision 模型与 vLLM Semantic Router 的原生集成是“下一步”，当前模型与接口已可用，但尚未成为 Router 内置组件。架构上，Kai/Lex 走基于 Vela 的三路双向编码器，Eos/Sol/Nox/Lux 基于 Qwen3.5 文本骨干（Gated DeltaNet + 全注意力）加共享候选头；在发布的 54 任务评测（3,766 个计分决策）中，Lux-9B 总分 76.94，领先展示中的开源参考模型，Nox-4B 73.09，而托管的 Jev 参考为 81.05——评测矩阵把结果拆分为 decisions、composition、reading、inference、transfer 五个维度，便于按能力挑选模型。
三、更可靠的路由路径：从 Signal 到 Plugin
Themis 让 Signal → Projection → Decision → Algorithm → Model 这条路径变得可检查；Hermes 让路径上的证据、选择与模型执行更可靠，并让 Route plugin 围绕选定的路径增加行为。
信号（Signals）：看到更多请求与回答
- 识别到达的内容：输入模态信号无需推理调用即可检测文本/图像/音频部分；有界的 metadata 规则可使用应用的路由提示，但授权仍来自可信身份。
- 把模型证据带入策略：可复用的 classifier 信号接受本地或外部分类器及其标签分数；complexity 可用外部打分器；Vela 的 Safety 与 Hazard区分“宽泛内容风险”与“具体风险类别”，不再把所有安全问题都当作提示攻击。
- 有意识地检查长内容：Guard 与 PII 可以在有界、重叠的窗口内扫描被接纳的文本，而不是只看第一切片；幻觉检测同样可以扫描长回答。关键约束是：某个窗口失败不会变成“干净”的结果，且配置的文档预算仍然限制可扫描范围。
- 观察返回内容：响应阶段 jailbreak 与 hallucination 信号记录在 Replay 中。幻觉检测把回答与所提供的事实依据（grounding context）比对——没有证据就无法验证；对流式输出，观察发生在完成之后，因此无法收回已发送的字节。
失败路径与正向检测同样重要：分类器出错时结果保持 unknown；依赖该信号的加权投影会保留分数（withhold），而不是把缺失值当作 0 并产生误导性的“低风险”区间。
决策（Decisions）：多条路由匹配时，为什么这一条赢
Hermes 把 Themis 已有的 rules、tiers、priority/confidence 策略中的困难情形显式化：
| 步骤 | Router 的行为 |
|---|---|
| 1. Match（匹配） | 求值 AND、OR、NOT 规则。若最终结果仍为 unknown，on_unknown 可以跳过该路由、匹配该路由或让请求失败。 |
| 2. Set the boundary（定边界） | 较低 tier 优先。在选中的 tier 内，条件匹配排在无条件 catch-all 之前。 |
| 3. Rank the matches（排序） | routing.strategy 在该 tier 内用 priority 或 confidence。confidence 仅在“每个非 catch-all 匹配都有同一种类的、可比较的实测分数”时生效；否则整个池子回退到 priority。 |
| 4. Explain the result（解释） | Preview 与 Replay 展示策略、tier、证据是否可比较，以及胜者击败下一名的具体原因。 |
仓库文档 Decisions 总览给出了更完整的可验证依据：三值逻辑中分类器失败按 Unknown 求值（NOT Unknown 仍为 Unknown，False AND Unknown 为 False）；on_unknown 可选 no_match / match / fail_request，后者返回 503 与 decision_unresolved 错误码；证据分数分种类——分类器概率（domain/classifier/safety/preference）、向量相似度（embedding/reask/kb）、依赖后端的分数（complexity/jailbreak）——且只有“恰好一个证据叶子产生分数”的决策才可比。发布文档特别强调：关键词命中只是策略门，不是 100% 置信度；领域概率也不能与嵌入相似度互换。把这些数值分开，让接近的决策更可信任、更可改进。针对提示攻击，安全路由可以覆盖客户端钉住的模型，把请求送入合格的受保护路径。
算法（Algorithms）：选一个模型，或协调多个
决策匹配后，其 algorithm 只能看到该决策自己的候选。Hermes 把“按上下文、协议、声明的任务能力过滤模型”放在打分之前；一条要求最小候选池的路由在池子不足时会失败，而不是悄悄运行更小的面板或级联。
| 路径 | Hermes 亮点 |
|---|---|
| 选一个（Select one） | Hybrid 可按决策调参。新的实验性 prompt selector让一个辅助模型从合格候选名中选择，辅助调用失败时有有界回退（回退到第一个有效候选）。 |
| 跨模型协作（Work across models） | 新的实验性 Fusion：面板 + 裁判，带可用响应法定人数（quorum）与可配置回退；recipe 拥有 analysis_mode（separate/one_call/none）、min_successful_responses 等策略。新的实验性 Workflows 分配有界角色，并可恢复工具驱动的工作。 |
| 精化既有路径 | Confidence 记录每次尝试的结果、耗时与 token 用量；ReMoM 增加轮次超时与可选的成功响应法定人数。 |
这些是不同的取舍：选择器返回一个合格模型；Looper 可以运行有界的级联或扇出。到底何时值得付出额外工作，由 recipe 决定。
插件（Plugins）：塑造选定路由
Themis 已有 Memory、RAG、Replay 与缓存；Hermes 增加路由本地行为，并让既有插件更安全：
| 插件 | 变化 |
|---|---|
| Context Compression | 新的可选长历史/工具输出处理，有定义的变换顺序；保护指令与工具调用对，除非显式开启截断，否则保留当前用户轮次。 |
| Shadow Dispatch | 新的有界、采样式单模型请求副本送往候选模型，不影响在线回答。Replay 记录完成/失败的 shadow 调用；回答质量仍需单独评测。 |
| Response Cache | 精确与语义复用现在检查请求兼容性（历史、工具、格式、模型、recipe）；否定检查与可选验证器失败会把可疑命中转为未命中。 |
| Router Memory | 响应侧抽取可异步持久化有用事实，并报告写入成功、失败或被丢弃。 |
| Tool Selection | 语义工具过滤改为批量并缓存工具嵌入，不再对相同工具 schema 反复编码。 |
Shadow Dispatch 在仓库文档中有完整的参数契约（配置示例与默认值）：sample_rate 默认 1.0、max_concurrency 默认 2、max_queue_depth 默认 8、timeout_seconds 默认 30，且每个 shadow 调用必然落为 completed / failed / dropped / sampled_out 之一——慢的、不可用的 shadow 端点不能改变主响应或其延迟。
四、MoM V1：五种 recipe，一个虚拟模型名
“应用命名它想要的服务，recipe 决定如何提供它。”MoM V1 的五个公开模型名各自解析到隔离的 recipe，操作者连接自己的合格后端后选择目标：
| 公开模型 | Recipe 目标 |
|---|---|
vllm-sr/mom-v1-blend | Balance：平衡日常质量、延迟与成本（决策：simple、medium、reasoning） |
vllm-sr/mom-v1-lite | Lite：日常服务保持经济，定向升级（economy、tools、reasoning） |
vllm-sr/mom-v1-flash | Flash：偏重响应式对话与流式（fast、tools、reasoning） |
vllm-sr/mom-v1-ultra | Ultra：保留更强的回答与审查路径（simple、reasoning、review、agent） |
vllm-sr/mom-v1-vault | Vault：面向隐私的策略，使用操作者批准的后端（private、sensitive、guard） |
仓库中的实际配置证据
上述五个名字不是文档概念，仓库里可以找到完整实现。config/recipes/built-in/v0.4/catalog.yaml 声明 catalog_version: v0.4、channel: release，默认模型为 vllm-sr/mom-v1-blend，并以 entrypoint: vllm-sr/mom-v1-* 的形式登记了全部五个资产；config/recipes/built-in/v0.4/mom-v1/config.yaml 则是每个决策的信号、投影、规则与算法的完整定义，规模达数千行。几个值得注意的实现细节（均可在 MoM V1 Model Card 与配置中核对）：
- 信号层：balance recipe 用
consequential/informational两个多语言嵌入原型计算care_margin投影，用difficulty复杂度信号（hard_above: 0.025、easy_below: -0.08双阈值）区分简单/中等/困难任务，再叠加deliberate、verify、answer_repair等多语言正则关键词与结构守卫（例如被引号包裹的修正请求不触发升级）。 - 算法层：每个决策用
multi_factor算法，quality 因子绑定版本化质量索引（如vllm-sr/reasoning@1.0.0，on_missing: exclude），objective 用 lexicographic 策略按 quality→latency→cost→load 排序，且on_no_candidates: fail——没有合格候选时显式失败。 - 会话保护：v0.4 内置初始化开启
global.router.learning.protection（scope 为 conversation，默认 300 秒空闲超时），在线自适应adaptation.enabled默认关闭；发送稳定的x-session-id/x-conversation-id头可在工具循环中保持模型不切换。 - 评估契约：probes.yaml 覆盖多语言请求、反例、优先级冲突、工具、图像、保留会话与长输入；CONFORMANCE.md 给出 conformance 命令。文档明确提醒：决策正确并不证明被分配模型能真正服务该请求。
多模型协作的边界
“选一个”与“协调多个”是刻意分开的能力。Accuracy（Ultra）通常只选一个强模型：显式请求获取新的独立评估才触发 review（两个响应比对与合成）；显式请求把工作委托给多个 worker 才触发 agent（至多三步、两个并行 worker）——仅要求一个 worker 不构成扇出授权，长上下文或主题标签也不触发多模型执行。Vault 则在所有路径上禁用客户端工具、Router 记忆、响应缓存与新 Responses 对象写入，guard 决策对检测到的提示攻击即时响应（无需后端分配），Guard/PII/Hazard 分诊各有 32,768 token 输入预算，超出即 fail closed（Preview 返回 HTTP 503 + signal_errors），且默认 Hazard 部署运行在 CPU 上——长输入的分诊延迟需要自行实测。
一个支撑请求穿过一个虚拟模型的图景是：常规轮次直达响应式后端；不确定的答案经 Confidence 升级；更难的任务让多个模型协作，但对客户端仍只返回一个响应。这些协作运行在 Router 的有界 Micro-Agent 运行时中：Confidence 升级、Ratings 为每个成功候选返回一个可识别答案、ReMoM 探索多轮推理、Fusion 裁判一个面板、Workflows 分配受限角色——各自使用与形态匹配的阈值、并发上限、超时与失败规则。
五、用 sr-bench 证明“更好的路由”
MoM 的价值必须由“在代表性任务上做得更好，且成本与延迟可见”来证明。sr-bench 1.0让 MoM 入口点与单个模型在同一批冻结任务上、通过用户实际调用的端点竞争。仓库文档给出可操作的全流程：
-
任务规模：九个基准（mmlu-pro、gpqa-diamond、hle、livecodebench、scicode、terminal-bench-2.1、simpleqa-verified、arc-agi-2、tau3）分 smoke/quick/standard 三档，standard 与 quick 不相交；运行
vllm-sr benchmark catalog查看已安装适配器。 -
计划与运行（见 plan-and-run）：从带数据集
path+sha256的清单开始，vllm-sr benchmark plan --manifest candidate.yaml --output frozen.json vllm-sr benchmark run --manifest frozen.json --detach --idempotency-key iteration-1 vllm-sr benchmark runs vllm-sr benchmark show RUN_ID vllm-sr benchmark report RUN_ID --output report.json -
证据边界：成本比较要求提供完整四桶价格并设
cost_policy: require_priced（默认），未知用量永远不会变成 0 或“省钱”的证据；评分器版本冻结在每个 plan 中，benchmark regrade RUN_ID可对保存的答案做版本化重评而不重新生成。 -
与公开榜单的分工：Open Intelligence Index 与 Arena收集的是已发布模型的结果；sr-bench 度量的是你部署的这一套 MoM。
这给团队一个实用循环：改 recipe → 跑同一批工作 → 把质量、成本、延迟放在一起看。
六、七个 Workgroup 是发布的一部分
技术随新的共建方式一起成长。七个公开 Workgroup 都有章程与明确的 Epic 所有权，每周清单展示贡献者可以认领的工作：
| Workgroup | Themis 基础 | Hermes 亮点 |
|---|---|---|
| Developer Experience & Ecosystem | CLI 与 Dashboard 一套配置 | 从安装到可解释在线请求的引导路径 |
| Enterprise & Environment | 可检查的运维 | 更强的管理控制与更清晰的部署支持 |
| Router Models & Inference Runtime | 模型驱动的信号 | 共享模型资源与有界推理路径 |
| MoM & Routing | 决策选择后端 | 稳定虚拟名、五个 MoM recipe、有界 Micro-Agent 协作 |
| Agentic & Context | 会话感知路由 | 更安全的上下文变换、记忆结果与可选切换证据 |
| Data Plane & Networking | 多协议路径 | 共享编解码、图像路由与有界恢复 |
| Evaluation & Quality | Replay 解释选择 | 冻结任务的 MoM 对比与更清晰的证据边界 |
各组的落地细节同样值得展开：
- 开发者体验：引导式安装流发现运行中的 Router、检查配置、Preview 决策并 Probe 真实后端；Dashboard 连接模型、recipe、入口点与 Playground；安装器新增 Podman 选项。Preview 告诉你策略会选择哪条路由，Probe 验证后端真的能给出答案——这一区分让首次部署更可信。
- 企业与环境：路由级权限检查、身份处理、敏感字段脱敏强化管理 API；Dashboard 增加 CSRF 与 origin 检查；托管数据服务获得按栈凭证；部署矩阵让“维护中/支持/实验”表面可见。生产部署仍需自行配置访问与后端选择。
- Router 模型与推理运行时：Vela 任务模型作为证据、Halu 参考配置、Omni 多模态可选路径；可选的 LettuceDetect v2 端点标记有依据回答中的无支撑片段；资源清单让 recipe 复用物理 Router 模型并保持消费者可见；可配置推理并发与队列防止小模型工作压垮请求路径，OpenVINO、Apple Metal、RISC-V CPU 路径获得针对性支持。
- 数据面：共享编解码让 Chat Completions、Responses、Anthropic Messages 走通缓冲与流式两条路径；图像生成请求可路由到具备图像能力的后端；可选的跨模型回退在上游错误后尝试另一个合格后端，但在流已提交或工具副作用可能已发生时立即停止。
- Agentic 与上下文：上下文变换有了定义顺序，保护关键指令与工具交互、裁剪低价值材料；响应侧 Router Memory 报告异步写入结果；可选的近期结果门在切换模型前考虑短窗口会话结果与冷却，默认关闭。
贡献者的路径是三步：在 Workgroup 章程中找到方向并选一个可用 issue；带着 Workgroup 与评审人认领并交付一个聚焦变更；通过实质性贡献与评审后的名册更新成长为成员。发布同时欢迎了 11 位新 Committer 与 3 位新 Maintainer，并记录了 2026-09-26 快照中 61 位构建者、83 份 Workgroup 申请。
七、三步上手：从一个模型名开始
- 启动 Router：按安装文档（website 文档站 installation 章节）启动，连接你自己的模型端点；内置 recipe 的快速起点是
vllm-sr serve，随后在 Dashboard 的 Models 中连接并验证推理端点。 - 发布 recipe：以 Flash 或 Balance 等 recipe 发布一个虚拟模型入口点，用 Preview 查看它将选中哪个决策与后端；给每个单模型决策至少分配一个声明了能力、上下文窗口与最大输出限制的合格模型（Accuracy 的
review/agent需要两个不同 worker）。 - 发真实请求并度量：Probe 验证后端交付，然后用 sr-bench 把你的路由策略与单个模型在同一批冻结任务上对比。
八、前瞻：v0.5 Ariadne
在希腊神话中，阿里阿德涅的线是穿越迷宫的路径。v0.5 的“线”就是一个真实任务穿过模型、工具与长会话所走的路由——目标是保持这条路由的连贯性，并度量它是否导向了更好的结果。七个 Workgroup 的 v0.5 方向：
| Workgroup | v0.5 Ariadne 方向 |
|---|---|
| Developer Experience & Ecosystem | 帮助开发者从首个被路由请求走到可检查、可评估的 recipe 变更 |
| Enterprise & Environment | 通过版本化激活与回滚让模型与策略变更更安全可运维 |
| Router Models & Inference Runtime | 提升 Vela 与 Decision 模型质量，降低请求路径上 Decision 推理成本 |
| MoM & Routing | 走向可移植、版本化的 MoM——把池子、recipe 与评估证据一起携带，便于比较与共享 |
| Agentic & Context | 为长时 agent 工作优化上下文，同时保留任务所需的指令、工具状态与会话历史 |
| Data Plane & Networking | 让 /v1/messages、/v1/chat/completions、/v1/responses 走向 GA，覆盖其流式、工具、错误与回退路径的完整端到端 |
| Evaluation & Quality | SR Bench 2.0：评估完整 agent 工作流、多轮会话与变化输入/后端故障下的鲁棒性 |
稳定的名字属于应用；变化的池子、权衡与证据则对操作者始终可见——这正是 Hermes 想要建立的边界，也是 Ariadne 将要沿着的那条线。
【免费下载链接】semantic-router
An open, programmable decision layer for models and compute.
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
