vLLM Semantic Router v0.3 Themis：从信号到有状态生产路由

vLLM Semantic Router v0.3 Themis: From Signals to Stateful Production Routing

二〇二六年六月五日 · 英文原文

摘要

vLLM Semantic Router v0.3（代号 Themis）发布，标志着语义路由进入有状态、可观测的生产阶段。该版本在 v0.2 基础上新增超过 350 次提交，核心变化包括：规范化的 v0.3 配置契约、会话感知智能体路由（SAAR）、投影层将信号证据转化为策略区间、协议兼容性扩展至 Anthropic /v1/messages、仪表盘升级为运维控制台、长上下文路由优化、硬件后端拓宽至 Intel OpenVINO 及 AMD ROCm。在 RouterArena 排行榜上，vLLM-SR 以 75.4 加权 Arena Score 重返第一。

vLLM Semantic Router v0.3，代号 Themis，标志着语义路由进入有状态、可观测、可投入生产环境处理真实 AI 流量的阶段。

前两个版本奠定了基石。Iris 让路由决策变得可组合。Athena 重建了模型基础，并将路由器扩展到内存、安全、模型选择、长上下文信号处理、OpenClaw 编排以及 AMD ROCm 部署。Themis 迈出了下一步：让这些能力更易于操作、更易于检查、更不易误用。

自 v0.2.0 以来，该项目在路由器核心、CLI、仪表盘、DSL、Kubernetes、协议兼容性、模型选择、安全、回放和发布就绪方面增加了超过 350 次提交。v0.3 最大的价值不在于单一功能，而在于将这些部分整合为一个稳定的契约：

信号变为投影，投影驱动决策，决策选择算法，算法选择模型。

该契约现在一致地体现在路由器、CLI、仪表盘、DSL、Helm chart 以及面向运维人员的部署界面中。

图 1：Themis 将信号、策略、操作器和模型后端转化为一个可检查的路由控制平面。

为什么是 Themis？

Themis 代表着秩序、规则和判断。这正是本次发布的恰当象征。

语义路由只有在运维人员能够回答以下基本问题时，在生产环境中才有用：

哪些信号被触发了？
哪个决策被匹配了？
哪个模型选择算法运行了？
哪个模型被选中了？
哪个安全或回放插件改变了路径？
哪个配置版本产生了这种行为？
同一个策略能否在本地、通过仪表盘以及在 Kubernetes 中部署，而不会变成三个不同的系统？

Themis 就是要让这些答案变得明确。v0.3 保留了 Athena 的雄心，但为运行时、API 表面和操作工作流设定了更强的边界。

图 2：本次发布的价值不在于一个孤立的功能，而在于稳定契约、检查、操作、服务、长上下文和验证之间的联系。

v0.3 Themis 的新特性

1. 规范的 v0.3 配置契约

Themis 最重要的变化是新的规范配置结构：

version: v0.3
listeners: []
providers: {}
routing: {}
global: {}

在 v0.3 之前，用户可能会遇到本地 Docker、仪表盘生成的配置、Helm values、CRD、示例和旧文档之间重叠的布局。Themis 使 config.yaml 成为稳态文件，并在所有地方围绕相同的顶层架构对齐系统。

这次清理也移除了 vllm-sr init。新的流程更简单：

在空目录中使用 vllm-sr serve 进行仪表盘优先的设置
对于 YAML 优先的工作流，直接编写规范的 config.yaml
使用 vllm-sr config migrate --config old-config.yaml 迁移旧文件
使用 vllm-sr config import 导入支持的提供商清单

这是一个破坏性变更，但对于一个 1.0 之前的路由器来说，这是正确类型的破坏性变更：更少的配置方言，更清晰的所有权，以及更持久的公共契约。

配置路径在边缘也更为严格。v0.3 会警告未知的 YAML 字段，确保规范配置加载有测试覆盖，将 Python CLI 模型与现代 Pydantic 配置对齐，并更明确地限制分类器资产。目标很简单：拼写错误和陈旧的配置形状应该在它们变成静默的路由漂移之前被捕获。

图 3：本地 YAML、CLI、仪表盘和 Kubernetes 现在都收敛到相同的规范 v0.3 配置结构上。

2. 信号、投影、决策、算法、模型

Themis 使路由器的思维模型更加明确：

层	拥有的内容
信号	从请求、响应、工具、语言、领域、上下文、模态、身份或安全分类器中提取证据
投影	将原始证据标准化为策略就绪的概念，例如验证、紧急程度、反馈或平衡
决策	使用优先级和可解释条件匹配命名的路由策略
算法	在匹配的决策内部从候选模型中选择
模型	通过选定的后端别名或提供商服务请求

这一点很重要，因为 v0.3 增加了足够的路由智能，以至于隐式行为不再可接受。路由器现在拥有更丰富的信号族、投影轨迹、先进的模型选择算法和响应端插件。Themis 使这些表面保持可编程，同时不会将路由策略变成隐藏的应用程序代码。

当前的信号目录足够广泛，不仅可以描述最新的用户提示，还可以描述安全态势、工具循环、用户角色、多模态意图、对话形状、结构化事件和可重放的知识库证据：

信号族	捕获的内容	典型用途
`authz`	来自用户或组上下文的角色和主体绑定	高级/管理员路由，策略门控模型
`complexity`	来自学习或组合信号的推理难度	升级复杂合成和多步推理
`context`	估计的上下文窗口需求	长上下文路由，成本和延迟决策
`conversation`	消息和工具循环形状	多轮、活跃工具使用、开发者消息、大量非用户上下文
`domain`	学习或配置的领域标签	商业、法律、健康、计算机科学路由
`embedding`	针对候选锚点的语义相似度，包括文本/图像/音频查询模态	支持意图、临床意图、多模态请求匹配
`event`	结构化事件元数据、严重性、操作码和时间紧急程度	事件、支付、审计或操作事件路由
`fact_check`	请求是否需要事实核查	升级法律、医疗或事实性声明
`jailbreak`	提示注入和越狱证据，包括历史感知扫描	安全路由和响应端护栏
`kb`	知识库组或标签匹配	隐私政策、限制、前沿推理、本地标准路由
`keyword`	字面、模糊、BM25 或 n-gram 关键词证据	快速路由守卫、紧急关键词、敏感词
`language`	检测到的语言及可配置置信度	区域感知路由和多语言模型选择
`modality`	AR、扩散或混合文本/图像执行需求	选择纯文本、图像生成或多模态路径
`pii`	敏感实体策略，包括历史感知扫描	编辑、拒绝/允许决策、隐私路由
`preference`	用户风格或行为偏好示例	简洁回答、详细回答、领域特定风格
`reask`	重复或改写的用户轮次	检测先前轮次中可能的不满
`structure`	正则表达式、计数、序列或密度特征	多个问题、编号工作流、格式密集型提示
`user_feedback`	用户表示答案错误或需要澄清	从不满中恢复或路由到更强模型

投影输出使用 type: projection 引用，但它们是派生的路由表面，而不是另一个原始信号族。这种区别很重要：信号提取证据，而投影将证据转化为命名的策略区间，例如 support_fast、support_balanced 或 support_escalated。

v0.3 的主要新增内容不仅仅是更多的信号名称。该版本使信号变得可组合：conversation 信号可以检测智能体请求形状；event 信号可以路由操作负载；embedding 规则可以查询非文本模态；投影输出可以将嘈杂的证据转化为策略就绪的区间。

仪表盘拓扑视图、DSL 编辑器、编译器/反编译器和运行时指标都已更新，以理解这些 v0.3 表面，而不是静默地丢弃或隐藏它们。

策略编写表面也更强大。路由 DSL 获得了冲突检测、SIGNAL_GROUP、TEST 和 TIER 编写结构、自然语言到 DSL 的管道、EMIT retention 和动态工具检索支持。这对生产团队很重要，因为 Themis 策略不仅仅是解析后的 YAML；它们是带有测试、保留输出和更安全生成路径的可审查路由程序。

图 4：路由契约现在作为一个从请求证据到信号、投影、决策、算法、模型和回放的管道可见。

3. 会话感知的智能体路由

Themis 包含了第一个生产就绪版本的 会话感知智能体路由（Session-Aware Agentic Routing，SAAR）。

单轮路由问的是：

哪个模型应该处理这个提示？

智能体路由还必须问：

现在在这个会话内切换模型安全吗？

SAAR 增加了路由器拥有的会话内存、围绕工具循环的硬锁、提供商状态可移植性检查、空闲和决策漂移重置边界、切换经济性以及可重放的诊断。它保留了正常的语义路由管道，但用会话连续性规则包裹了模型选择。

这对于编码智能体和长周期工具循环尤其重要。工具结果通常应该返回给请求该工具的模型。提供商管理的 continuation id 不应发送到不同的物理后端。一个长预热会话不应仅仅因为最新的用户消息很短就丢弃前缀局部性。

Themis 使这些约束成为模型选择策略的一部分，而不是要求每个应用程序重新发现它们。

图 5：SAAR 通过结合路由器拥有的会话内存、硬锁、可移植性检查、切换经济性和回放诊断，保持多轮智能体会话的稳定。

关键的设计选择是 SAAR 不会取代语义路由。它在模型选择的最后一英里增加了一个有状态的守卫：

conversation 信号识别多轮形状、活跃工具使用、开发者消息和大量非用户上下文。
session_aware 选择在考虑质量差距、切换边际、停留偏差、前缀局部性和剩余轮次先验后，评估模型切换是否值得。
硬锁在活跃工具循环或提供商状态延续期间阻止不安全的切换。
路由器拥有的内存可以检索和存储路由本地的事实、偏好和上下文，而无需暴露单独的会话状态 DSL。
回放记录保留了会话停留、切换或重置的原因。

路由器内存是会话感知选择的有状态补充。内存插件可以在用户或会话范围内保留事实、偏好和检索到的上下文；session_aware 随后可以避免将每一轮都视为孤立的请求。在实践中，这意味着智能体可以保持有用的连续性，而无需将每个请求永久固定到最昂贵的模型。

参考策略形状有意采用普通的 YAML：

routing:
  signals:
    conversation:
      - name: active_tool_use
        feature:
          type: count
          source:
            type: assistant_tool_cycle
        predicate:
          gte: 1
 
  decisions:
    - name: agentic_session_route
      rules:
        operator: AND
        conditions:
          - type: conversation
            name: active_tool_use
      algorithm:
        type: session_aware
        session_aware:
          base_method: hybrid
          tool_loop_hard_lock: true
          context_portability_hard_lock: true
          prefix_cache_weight: 0.20
          handoff_penalty_weight: 1.0
      plugins:
        - type: memory
          configuration:
            enabled: true
            retrieval_limit: 6
            auto_store: true
            hybrid_search: true

这是 Themis 对智能体工作负载最重要的部分：路由器现在可以推理连续性，而不仅仅是分类。

4. 投影将证据转化为策略

信号是原始证据。投影是 Themis 将这些证据转化为命名的、稳定的策略概念的地方。

没有投影，一个复杂的策略必须在许多决策中重复低层信号细节：确切的 embedding 规则名称、复杂度阈值、上下文边界和知识库分数。有了投影，路由器可以一次性计算原始证据，推导出可重用的输出，例如 support_fast 或 support_escalated，并让决策基于这个派生概念进行路由。

Themis 支持三种核心投影模式：

partitions 从一个互斥族中选择一个胜出者，例如竞争的支持意图。
scores 将声明的信号或知识库指标组合成一个连续值。
mappings 通过校准的阈值将这些值转化为策略区间。

对于需要多个派生输出的策略，v0.3 还增加了 multi_emit 投影映射。这让单个投影步骤可以发出多个命名的路由概念，同时仍然在回放中保留可追溯性。

图 6：投影将嘈杂的信号证据转化为决策可以直接引用的命名输出。

一个紧凑的示例如下：

routing:
  signals:
    embeddings:
      - name: technical_support
        threshold: 0.75
        aggregation_method: max
        candidates:
          - installation guide
          - troubleshooting steps
      - name: account_management
        threshold: 0.72
        aggregation_method: any
        candidates:
          - password reset
          - billing information
    context:
      - name: long_context
        min_tokens: 32K
        max_tokens: 256K
 
  projections:
    partitions:
      - name: support_intents
        semantics: exclusive
        members:
          - technical_support
          - account_management
        default: technical_support
    scores:
      - name: request_difficulty
        method: weighted_sum
        inputs:
          - type: embedding
            name: technical_support
            weight: 0.18
            value_source: confidence
          - type: context
            name: long_context
            weight: 0.18
    mappings:
      - name: request_band
        source: request_difficulty
        method: threshold_bands
        outputs:
          - name: support_fast
            lte: 0.20
          - name: support_escalated
            gte: 0.45
 
  decisions:
    - name: escalated_support_route
      rules:
        operator: AND
        conditions:
          - type: projection
            name: support_escalated

投影轨迹也与回放记录一起存储，因此仪表盘不仅可以解释哪个信号被触发，还可以解释哪个派生的策略区间导致了最终的路由。

5. 协议兼容性成为发布表面

v0.3 将路由器的兼容性边界扩展到基本的 OpenAI Chat Completions 之外。

本周期内的协议工作包括：

通过内部请求信封支持原生 Anthropic /v1/messages 入口
使用 OpenAI SSE 翻译的 Anthropic 流式传输
自定义 Anthropic 上游路由和工具调用支持
非流式路径的出站 Anthropic 响应发送
从请求路径头进行协议检测
session-id 镜像和头传递控制
解释协议翻译何时有损的响应头
Responses API 工具轨迹保真度和 OpenAI SDK 对齐的消息处理
OpenAI reasoning-effort 变异修复
身份编码的上游响应，以避免透明的解压缩意外
更强的 Responses API 状态和持久化路径

目标不是让每个提供商看起来都一样。目标是让翻译变得明确、可观察且足够安全，以便像 auto 这样的逻辑路由模型可以位于多个提供商协议之前，而不会让运维人员感到意外。

6. 仪表盘成为运维控制台

Themis 仪表盘不仅仅是一个配置编辑器。

v0.3 周期加强了首次运行设置流程、拓扑图、基于回放的洞察、日志、状态页面、评估流程、认证行为和模型清单表面。运维人员可以在不离开仪表盘的情况下导入配置文件、验证它、激活它、发送测试提示、检查信号路径、读取路由器日志和验证回放记录。

图 7：仪表盘成为一个实用的运维控制台，用于设置、拓扑检查、日志、沙盒测试、回放和模型健康。

值得注意的仪表盘改进包括：

内置路由模式和缺失模型补全
显示匹配信号、投影、决策和模型的拓扑试运行路径
通过仪表盘代理进行路由器回放和聚合洞察
自然语言 DSL 构建器和评估流程修复
沙盒中的文件附件
当认证服务无法初始化时的认证失败关闭行为
具有影子、激活和回滚状态的策略版本生命周期
针对用户提供的 fetch/open-web 请求的更安全日志和 URL 编辑
多语言内容的 UTF-8 安全显示处理
更精简的生产路由外壳和更小的后端运行时依赖
仪表盘感知的模型列表和状态表面

结果是更好的本地和远程运维工作流：首次运行的设置模式、用于策略检查的拓扑、用于操作的日志/状态以及用于真实流量的洞察。

7. CLI 和部署更可预测

Themis 还加强了 vllm-sr 作为受支持的操作接口。

CLI 现在具有更清晰的运行时边界和更有用的命令：

vllm-sr serve
vllm-sr serve --algorithm latency_aware
vllm-sr serve --algorithm session_aware
vllm-sr serve --platform amd
vllm-sr serve --platform nvidia
vllm-sr chat
vllm-sr eval
vllm-sr model list
vllm-sr config migrate --config old-config.yaml

本地 vllm-sr serve 在 Linux、macOS 和 WSL2 上仍然是基于 Docker 的工作流。AMD ROCm 仍然是经过发布验证的 GPU 路径，而 --platform nvidia 为已经配置了 NVIDIA 容器运行时的用户增加了本地 NVIDIA Docker 透传的人体工程学。原生 Windows Docker 服务现在会以明确的支持消息被拒绝，而不是在稍后以不太明显的方式失败。

CLI 还增加了更好的检查和冒烟测试命令。vllm-sr model list 显示已配置的模型清单，vllm-sr chat 提供一次性补全路径，vllm-sr eval 执行路由器评估端点，VLLM_SR_DNS 允许本地容器在企业或实验室网络需要时加入自定义 DNS 环境。

在 Kubernetes 上，v0.3 对齐了 Helm、发布默认值、OpenShift 部署修复、多个 IntelligentRoute 协调行为、CRD 模态契约、可选的 Gateway API HTTPRoute 入口以及 AgentGateway 安装指南。对于发布操作，Themis 还从模糊的 latest 假设转向明确的工件契约、升级和回滚文档以及发布检查。

8. 安全、回放、内存和检索更值得信赖

Athena 将许多这些能力引入了路由器。Themis 强化了它们。

关键的运行时修复和改进现在分为三组：

回放和可观测性

路由器回放 PostgreSQL 插入正确性，以便仪表盘洞察不会静默地保持为空
投影轨迹与回放记录一起存储，以获得更好的可解释性
响应端越狱和回放路径收紧

存储和检索

Qdrant 向量搜索提供商支持
Valkey 缓存、向量存储和内存后端支持，包括 TLS 和搜索模块预检查
Redis 和 Responses API 存储默认值，更好地匹配真实的本地和 Kubernetes 部署
混合缓存重建预分配减少
流式 Redis 语义缓存正确性和有界流式块内存行为
将 O(N) 缓存 LRU 读取路径替换为基于常量时间列表的实现
BM25 和 n-gram 分类缓存，以避免放大工作
混合 HNSW 入口点传播修复
跨回放、缓存、内存和向量存储路径的共享 Milvus 生命周期处理

运行时和安全加固

跨先前用户轮次的历史感知 PII 和越狱信号扫描
模型切换门修复，用于先前模型填充
extproc 后台路径中的 goroutine panic 恢复
选择随机性中的并发竞态修复
配置回滚版本的路径遍历保护
跨 Python、Go、Rust 和前端表面的依赖安全更新

这是发布中不那么引人注目的部分，但这正是 Themis 的用途：使系统在真实流量、长提示、回放存储和运维驱动的配置更改下更安全。

9. 长上下文路由变得更便宜

Themis 增加了三个重要的长上下文控制。

首先，上下文 token 估计现在可以从观察到的响应使用中学习在线校准比率，因此当精确 token 化不可用时，上下文敏感的路由可以改进。回退保持保守，但路由器可以随时间适应真实流量。

其次，原生 mmBERT embedding 路径现在限制了内存，而不会将长输入变成静默的截断问题。针对长输入内存问题的 #2007 原生绑定修复以查询块的形式处理 attention，而不是为整个序列实例化一个密集的 attention 张量。这使长上下文信号对路由器保持可用，同时使绑定在更大的提示下可用。

图 8：长上下文路径通过分块 mmBERT attention 工作来保留信号并限制原生内存。

第三，提示压缩成为信号提取的命名配置文件表面：

配置文件	预期用途
`default`	通用路由的平衡压缩
`coding`	保留类似代码和实现密集的句子
`medical`	保留临床相关细节
`security`	保留安全和策略证据
`multi_turn`	保留对话连续性

压缩路径有意限定在信号评估范围内。原始用户提示仍然会发送到选定的服务模型，除非决策拥有的插件明确更改它。这种分离防止路由优化静默地重写用户意图。

10. 硬件后端路径拓宽

Themis 将路由器拥有的模型执行故事扩展到默认本地路径之外。

拓宽后的地图区分了四条路径：用于服务 vLLM 后端的 NVIDIA CUDA 和 AMD ROCm，用于路由器拥有的分类器和 embedding 推理的 Intel OpenVINO，以及用于开发和冒烟测试的 CPU/本地执行。

在 Intel 基础设施上，v0.3 为语义路由器增加了初始的 OpenVINO 绑定。新的绑定为 ModernBERT 序列分类、token 分类和 embedding 推理提供了原生 C++ 和 Go 集成，并带有比较 OpenVINO 和 Candle 在分类器和 embedding 工作负载上行为的基准入口点。

这是一个后端和绑定里程碑，而不是全面的生产对等声明。它为贡献者和硬件合作伙伴提供了一条具体路径，以在 Intel OpenVINO 上验证语义路由器的内部分类器和 embedding 模型，同时保留 Themis 其余部分使用的相同路由契约。

图 9：Themis 拓宽了硬件后端地图，同时跨 NVIDIA CUDA、AMD ROCm、Intel OpenVINO 和 CPU/本地路径保持一个路由控制平面。

Athena 中引入的 AMD 部署路径仍然是 v0.3 发布契约的一部分。

参考流程仍然是：

vllm-sr serve --platform amd

对于真实的 AMD 部署，该项目维护了 deploy/recipes/balance.yaml 配置文件，该文件通过 ROCm vLLM 后端暴露多个服务别名，并通过与 CPU/本地路径相同的信号、投影、决策和模型选择管道路由它们。

作为发布就绪的一部分，Themis 在 AMD ROCm 栈上进行了验证，包括：

一个暴露预期服务别名的 ROCm vLLM 后端
使用参考平衡配置文件进行仪表盘设置导入、验证和激活
路由器健康检查和 Envoy OpenAI 兼容的 /v1/models
针对编码/调试请求的拓扑试运行
针对编码、数学和法律提示的直接 Envoy chat completions
仪表盘代理 chat completions
路由器回放列表和聚合洞察 API

图 10：AMD 发布路径将服务、仪表盘导入、路由器健康检查、模型列表、ROCm 后端服务和路由请求验证为一个流程。

这个端到端路径很重要，因为语义路由器旨在成为跨异构推理栈的控制平面，而不仅仅是一个本地开发工具。

11. RouterArena SOTA 刷新

Themis 还带来了一个外部排行榜信号：在为此发布更新捕获的 RouterArena 快照中，vLLM-SR 在 RouterArena 排行榜上重返 #1。

在该公开的 RouterArena 排行榜快照中，vLLM-SR 以 75.4 的加权 Arena Score 排名第一，领先于 Sqwish Router、AgentForge Router、Nadir Router 和其他已发布的路由基线。同一快照报告 vLLM-SR 的准确率为 76.0，每 1K 查询成本为 $0.11，鲁棒性为 73.1。

图 11：RouterArena 排行榜快照显示 vLLM-SR 在加权 Arena Score 上重返 #1。

这不能替代发布测试，但它是对项目方向有用的外部检查。Themis 改进了路由策略、成本感知选择、协议兼容性和操作可追溯性，同时使路由器在独立路由器基准测试中保持竞争力。

自 v0.2 以来的变化

从高层次来看，v0.2 到 v0.3 的差异如下：

领域	Themis 价值
API 和配置	跨本地、仪表盘、Helm 和运维路径的规范 v0.3 契约
路由器核心	更丰富的信号、投影、响应状态、回放、安全和选择算法
模型选择	会话感知、多因素、延迟感知、RL 驱动、混合和其他算法表面
协议	更强的 OpenAI 和 Anthropic 兼容性，具有明确的翻译行为
仪表盘	设置、拓扑、状态、日志、洞察、回放、认证和模型清单加固
CLI	更清晰的服务模式、模型检查、聊天/评估命令、配置迁移、平台边界
部署	AMD ROCm 路径、OpenVINO 绑定、NVIDIA 本地透传人体工程学、Helm/OpenShift/Gateway API 修复、发布工件契约
存储和检索	Valkey、Qdrant、Redis、Milvus、回放、缓存、内存和向量存储生命周期加固
可靠性	分块 mmBERT attention、UTF-8 安全显示处理、安全日志记录、流式缓存正确性、回放正确性、并发修复

这是 Themis 的核心故事：路由器能力更强，但在正确的地方也受到更多约束。

开始使用

对于 macOS 或 Linux：

curl -fsSL https://vllm-semantic-router.com/install.sh | bash

对于手动安装：

pip install vllm-sr==0.3.0
vllm-sr serve

如果当前目录不包含 config.yaml，vllm-sr serve 会以设置模式启动仪表盘。对于 YAML 优先的用户，直接创建规范的 v0.3 配置或迁移旧文件：

vllm-sr config migrate --config old-config.yaml
vllm-sr serve --config config.yaml

对于 AMD ROCm：

vllm-sr serve --platform amd

对于本地 NVIDIA Docker 透传：

vllm-sr serve --platform nvidia

对于 Kubernetes：

helm install semantic-router oci://ghcr.io/vllm-project/charts/semantic-router

查看项目资源：

文档：vllm-semantic-router.com
GitHub：vllm-project/semantic-router
参考 AMD 配置文件：deploy/recipes/balance.yaml
模型：Hugging Face

展望未来：v0.4 Hermes

下一个版本的代号是 Hermes。

Themis 使契约足够稳定以供操作。Hermes 应该使路由器更快地改进、更容易评估，并在真实工作负载下更安全地适应。Hermes 的核心目标是 自我改进的路由器。这个循环是经过深思熟虑的：在 GPU 规模下运行自动研究以提升路由器性能，使用路由器评估调整 DSL 配方，然后将验证过的证据反馈到代码库和编码器模型微调中。最高价值的工作是：

自我改进的路由器作为 Hermes 核心目标：在 GPU 规模性能研究、DSL 配方调整以及代码库加编码器模型微调之间形成闭环。每个生成的更改仍然必须是可审查、可重放、可版本化和可安全回滚的。
SAAR 作为智能体路由层：继续收紧模型切换经济性、工具循环连续性、提供商状态可移植性、回放诊断和路由器内存集成。
评估作为发布门禁：构建系统级和信号级评估，以便每个信号、投影、算法、插件和仪表盘路径都可以在发布前针对代表性流量进行重放。
CLI 优先设计：确保每个语义路由器操作都可以通过 vllm-sr 形成闭环，包括配置编写、迁移、服务、检查、评估、回放、策略生命周期、仪表盘导入/导出和发布冒烟测试。
更好的路由器自有模型：提高路由器自身使用的模型的准确性和延迟，包括 embedding、分类器、多模态和安全信号模型。
更有用的信号：添加更丰富的请求、响应、工具、模态、身份、新鲜度、延迟、成本和运行时健康信号，而无需将 DSL 变成应用程序代码。
运维人员调试循环：使假设分析路由、策略回放、评估驱动调优和轨迹比较成为仪表盘的一等公民工作流。

图 12：Hermes 围绕一个自我改进的路由器展开，该路由器连接 GPU 规模性能研究、DSL 配方调整、路由器评估、代码库更新和编码器微调。

致谢

从 v0.2.0 到 v0.3.0，Themis 周期包含了来自 80 多位贡献者作者身份 的超过 350 次提交。感谢每一位审查代码、改进文档、训练模型、加固测试、修复发布阻塞问题以及推动路由器走向更稳定生产形态的人。

我们特别感谢来自研究机构和大学的合作者，包括 MBZUAI、麦吉尔大学、Mila 和莱斯大学，感谢他们在路由器评估、模型研究和 AI 系统方面的贡献与合作。

我们还感谢更广泛的 vLLM、AMD、Intel、Meta、Red Hat、Microsoft、Google、IBM、NVIDIA、Hugging Face、NASA、Nutanix、DaoCloud 和开源社区在运行时系统、模型服务、模型研究和生产 AI 基础设施方面的持续合作。

欢迎来到 Themis：从信号到有状态的生产路由。

译自 vLLM · 官方博客 · 录于二〇二六年六月五日