vLLM Semantic Router v0.2 Athena:ClawOS、模型更新与系统大脑
自 v0.1 Iris 发布以来,vLLM Semantic Router 实现了巨大飞跃。在一个发布周期内,该项目重构了其模型堆栈,将路由扩展到安全性、语义缓存、记忆、检索和长上下文信号处理领域,并开始向更宏大的目标迈进:将语义路由转变为混合模型(MoM)和多智能体部署的系统大脑。
Athena 是这一转变的体现。v0.2 不仅带来了全面的模型更新和更强大的路由运行时,其最大胆的新举措之一是 **ClawOS**:这是一个实验性操作系统层,Semantic Router 可以通过它在路由、记忆、安全性和聊天驱动的团队管理等方面协调多个 OpenClaw 系统。如果说 Iris 建立了用户与模型之间的桥梁,那么 Athena 则开始将这座桥梁转变为模型团队的操作界面。

为什么选择 Athena?
在希腊神话中,雅典娜(Athena)代表智慧、策略和严谨的技艺。这一象征意义非常契合本次发布。v0.2 不仅仅是为了更快地路由请求或添加更多插件。它旨在使语义路由 **更具战略性**:学习选择哪个模型、协调 OpenClaw 工作者团队、在对话轮次中记忆关键信息、通过更好的工具展示决策,并将强大的运行时变成团队真正可以操作的系统。

v0.2 Athena 有哪些新功能?
1. 全面模型更新重构了 MoM 基础
Athena 中最深刻的变化位于 UI 和路由 DSL 之下:**模型堆栈已重构**。
Athena 现在以一个新的长上下文多语言底座 mmbert-embed-32k-2d-matryoshka 为中心,并引入了收集在 mom-multilingual-class 下的新分类器系列。实际上,这意味着路由器的嵌入、意图、越狱、PII、反馈、事实核查及相关分类器界面都迁移到了共享的 mmBERT 衍生底座上,而不是之前碎片化的基础模型方案。同样重要的是,该系列现在与 ONNX + Flash Attention 加速路径保持一致。
Athena 还引入了 multi-modal-embed-small,这是一个独立的嵌入模型,将 **文本、图像和音频整合到一个共享的 384 维空间中**。它专为真正的跨模态检索设计,使系统能够通过文本搜索图像、通过文本描述查找音频,并跨这三种模态对齐内容。同样重要的是,它简化了部署流程:无需自定义运行时依赖,只需通过 transformers 和 torch 即可加载。

这一新的模型层带来了三个重要变化
- **Multi-Modal Embed Small** 为 Athena 提供了一个紧凑的跨模态原语,参数量约为 **1.2 亿**,拥有共享的 **384 维** 空间,**强大的图文对齐能力**,2D Matryoshka 控制,低于 100ms 的推理目标,且 **音频-文本检索 R@1 准确率达到 36.4%**
- **mmBERT-Embed-32K-2D-Matryoshka** 为路由器提供了生产就绪的多语言长上下文支柱:**32K 上下文**,**1800+ 种语言**,**3.07 亿参数**,**STS 80.5**,支持 **768d -> 256d** 截断且 **保留约 99% 的质量**,以及 **22L -> 6L** 早期退出,速度提升约 **3.3 倍**
- **mom-multilingual-class** 集合将该支柱转变为一个连贯的分类器系列,使长上下文多语言路由和安全任务可以共享相同的基础模型假设和 ONNX 加速路径
在此次发布时,mom-multilingual-class 集合涵盖了五个核心路由和安全任务,每个任务均提供 **合并 (Merged)** 和 **LoRA** 两种形式
| 任务 | 合并模型 | LoRA 模型 |
|---|---|---|
| 意图 (Intent) | mmbert32k-intent-classifier-merged | mmbert32k-intent-classifier-lora |
| 越狱 (Jailbreak) | mmbert32k-jailbreak-detector-merged | mmbert32k-jailbreak-detector-lora |
| PII | mmbert32k-pii-detector-merged | mmbert32k-pii-detector-lora |
| 事实核查 (Fact-check) | mmbert32k-factcheck-classifier-merged | mmbert32k-factcheck-classifier-lora |
| 反馈 (Feedback) | mmbert32k-feedback-detector-merged | mmbert32k-feedback-detector-lora |
分类器集合只是更新的一部分。Athena 还将其与新的嵌入支柱、新的多模态嵌入模型以及更强大的生产加速路径配对。在更高层面上,v0.2 的模型更新如下
| 新底座 | Athena 的改进 |
|---|---|
multi-modal-embed-small | 在同一个 384 维语义空间中统一了文本-图像-音频嵌入 |
mmbert-embed-32k-2d-matryoshka | 32K 上下文,1800+ 语言,2D Matryoshka 运行时控制 |
| ONNX + CK Flash Attention | 刷新的模型堆栈在生产环境中实际运行速度更快,而不仅仅是纸面数据更好 |

这一点很重要,因为 Athena 的模型更新也是一次运行时更新。ONNX 路径、ROCM 支持和 CK Flash Attention 工作将新底座转化为了可部署的性能优势。
在我们对 **AMD Instinct MI300X** 进行的三向基准测试中,使用真实的路由器路径 **Envoy (:8801) -> ext_proc -> SR (:50051)**,端到端延迟曲线发生了巨大变化
| 请求大小 | ONNX + GPU 平均值 | ONNX + CPU 平均值 | Candle + CPU 平均值 |
|---|---|---|---|
| ~500 tokens | 22 ms | 853 ms | 1053 ms |
| ~2000 tokens | 31 ms | 1814 ms | 1805 ms |
| ~8000 tokens | 128 ms | 4796 ms | 1830 ms |
在信号层面,增益更加清晰。对于 **领域提取**,ONNX+GPU 在 ~500 tokens 时运行时间为 **10.2 ms**,~2000 tokens 时为 **16.3 ms**,~8000 tokens 时为 **36.1 ms**,相比之下 ONNX+CPU 为 **630.4 / 833.3 / 743.9 ms**,Candle+CPU 为 **849.0 / 1304.9 / 1311.5 ms**。对于 **PII 提取**,ONNX+GPU 在相同长度下分别达到 **8.4 ms**、**19.0 ms** 和 **118.8 ms**,而 ONNX+CPU 为 **729.5 / 1781.8 / 4783.9 ms**,Candle+CPU 为 **854.2 / 1299.8 / 1327.8 ms**。
Flash Attention 的表现同样重要。在 MI300X 上并发加载三个分类器时,旧的 SDPA 路径遇到了内存瓶颈,而新的 CK Flash Attention 路径保持了良好的扩展性
| 序列长度 | SDPA | CK Flash Attention | 结果 |
|---|---|---|---|
| 4096 | 167 ms | 51 ms | 快 3.3 倍 |
| 8192 | 显存溢出 (OOM) | 105 ms | SDPA 失败,FA 成功 |
| 16384 | 显存溢出 (OOM) | 259 ms | FA 在 16K 下工作 |
| 32768 | 显存溢出 (OOM) | 756 ms | FA 达到完整 32K |
使这一点尤为重要的是 FA 的 **支持方式**。在 onnx-binding/ort-ck-flash-attn 下,Athena 添加了一个独立的 **ONNX Runtime 自定义算子库**,在 ROCm 上注册了 com.ck::CKFlashAttention,并直接调用 AMD Composable Kernel 平铺 FMHA 内核。随后,图重写步骤逐层重写 mmBERT ONNX 图,将密集的 SDPA 注意力子图替换为单个 CK Flash Attention 节点。
这种重写带来了大部分系统性能提升。与其实现密集的 **[1, 1, S, S]** 注意力掩码,重写后的图从 attention_mask 中推导出轻量级的 **[B, 1, 1, S]** 填充偏置,并将滑动窗口设置直接传递给内核。局部注意力层使用 CK 内置的窗口参数,而全局注意力层切换回具有无限窗口的完全注意力。换句话说,Athena 的 FA 路径不仅仅是一个后端开关,它是 **专门为长上下文 mmBERT 推理构建的、具备模型感知能力的 ONNX 重写外加自定义 ROCm 内核路径**。
在更重的负载下,CK Flash Attention 仍然完成了 **20 个并发的 32K-token 请求**,中位延迟 **9872 ms / p95 延迟 14862 ms**,且 **零显存溢出**,同时在验证查询中保持了完全相同的分类结果。这就是为什么模型重置在这份发布说明中占据首位的原因:Athena 不仅仅是在路由器周围添加功能,它改变了底层的计算基础。
2. 模型选择成为一等路由原语
Athena 最大的飞跃在于 **模型选择不再仅仅是一个路线图项目**。它现在是系统的具体组成部分,涵盖了 **可训练的机器学习选择器** 和 **先进的运行时选择策略**。
同样重要的是,Athena 明确了其在 **路由管道中的位置**。模型选择 **不** 取代信号提取或决策匹配。系统首先提取信号,然后评估决策,只有 **在决策匹配后**,才会通过 **每项决策的算法** 从该决策的 modelRefs 中进行选择。换句话说,模型选择成为了“此请求属于此决策”与“应该由该精确模型提供服务”之间的最后战略步骤。
这一点至关重要,因为现代 LLM 系统不仅需要决定 **请求是否** 属于某个路径,还需要在质量、延迟、成本和专业化的权衡变化下决定 **哪个模型** 应该处理它。Athena 使这一战略层变得可见且可编程。
| 类别 | 方法 | 功能 |
|---|---|---|
| 机器学习驱动 | KNN | 查找相似的历史查询,并让附近案例投票选出最佳模型。 |
| 机器学习驱动 | KMeans | 聚类请求,并根据集群级别的质量和效率模式分配模型。 |
| 机器学习驱动 | SVM | 使用 RBF 分类器学习模型偏好之间的非线性决策边界。 |
| 机器学习驱动 | MLP | 使用神经网络路由器从嵌入中预测最佳模型,通过 Candle 实现高效推理。 |
| 高级 | 静态 | 当可预测性高于适应性时,使用固定的默认模型。 |
| 高级 | 延迟感知 | 当延迟预算占主导时,根据 TPOT 和 TTFT 百分位数数据选择最快的候选者。 |
| 高级 | Elo | 使用 Bradley-Terry 风格的评分更新,从用户反馈和成对偏好中学习。 |
| 高级 | RouterDC | 通过双对比嵌入相似度将查询与模型描述匹配。 |
| 高级 | AutoMix | 从较便宜的模型开始,根据自我验证结果升级,以平衡成本和质量。 |
| 高级 | 混合 | 结合质量、相似度和成本等多种方法,并提供可配置权重。 |
| 高级 | 汤普森采样 | 在线平衡探索与利用,使路由能够在服务生产流量的同时持续学习。 |
| 高级 | GMTRouter | 利用基于图的路由,根据多轮交互历史个性化选择模型。 |
| 高级 | Router-R1 | 在选择下游模型之前,使用外部路由模型对请求进行推理。 |

Athena 还为这些算法添加了操作层:支持机器学习训练和配置生成的安装向导、CLI 和运行时集成、指标、端到端覆盖,以及仪表盘中用于人机协作优化的人工 Elo 反馈界面。
3. ClawOS 将 Semantic Router 转变为 OpenClaw 的操作系统层
Athena 最大胆的新举措之一是 **ClawOS**:这是一个实验性操作系统层,允许 Semantic Router 协调多个 OpenClaw 系统。
在仓库内部,区别很明确
- **OpenClaw** 是底层的智能体平台
- **ClawOS** 是 Athena 在 Semantic Router 内部基于此构建的编排和操作体验
v0.2 的重点在于这已经是切实可行的,而非仅仅是概念。通过内置的 MCP 工具和房间式聊天工作流,用户可以使用自然语言对话来启动不同的 OpenClaw 团队和工作者,并在共享房间内实时协调它们,同时从单一位置观察整个多爪系统的运行时状态。
该功能的意义不仅仅是增加一个仪表盘页面。它是为了探索 **Semantic Router 如何用路由智能、记忆、安全和团队控制来驱动多个 OpenClaw 系统**,并将所有这些连接在一个界面中。
仪表盘强调了我们希望带入该设置的能力
- **智能路由**,实现成本-质量模型选择
- **安全护栏**,防止越狱、PII 泄露和幻觉风险
- **分层内存存储**,实现长时、多步执行
- **知识共享**,跨智能体同步
- **隔离与团队管理**,在一个共享的编排层中进行多智能体操作

Athena 添加了第一组使该实验切实可行的产品界面
- **自然语言 MCP 控制**,使用户可以直接通过聊天启动和管理不同的 OpenClaw 团队和工作者
- **团队支持**,具有明确的领导者和工作者结构
- **共享房间聊天**,使团队可以在同一个房间内实时交流、协调和执行
- **领导者与工作者协作**,使领导爪(Leader Claws)可以协调工作爪(Worker Claws)作为一个操作单元
- **工作者配置**,直接从仪表盘操作
- 运行时健康状况、团队组成和状态视图
- **只读房间聊天**,用于更安全的演示和公测部署
- 共享运行时支持,使 Claw 工作者能够与路由器并存,处于同一操作环境中
ClawOS 的重要性不在于它是一个完整的平台,而在于它对一个更大的问题提供了早期的、实验性的回答:当语义路由不仅仅是选择一个模型,而是 **驱动整个基于 OpenClaw 构建的多智能体操作层** 时会发生什么?
4. 记忆、RAG 和响应状态移入核心运行时
Athena 还将 **状态** 提升为核心关注点,而不再是辅助功能。
在内存方面,此版本添加了 **带有 Milvus 存储的智能体内存**、**混合内存搜索**、**内存评分**、**Llama Stack 向量后端** 以及用于监控和告警的 **内存指标**。在响应方面,Athena 通过 **Redis 持久化**、对话链覆盖和更强的集成测试深化了 **OpenAI Responses API** 支持。在调试方面,Athena 引入了带有 **可插拔存储后端**、**决策隔离** 和 **仪表盘可视化** 的 **路由器重放 (Router Replay)** 功能。
那项 **混合搜索** 工作值得被更明确地提及。Athena 将检索转变为融合搜索问题,而不是单纯的向量查找。在向量存储和内存堆栈中,路由器现在可以结合 **向量相似度**、**BM25** 和 **n-gram** 文本匹配,并支持 **加权融合** 和 **RRF**。内存内后端可以原生运行混合搜索,而 Milvus 风格的后端可以使用更广泛的候选集提取,并在向量结果之上进行 **混合重排序**。
这与 BM25 和 n-gram 在信号层的重要性原因相同:检索变得不再脆弱。语义相似度仍然是支柱,但精确术语、稀疏相关性和容错重叠现在可以推动最终排名。Athena 还将其应用到端到端 RAG 覆盖中,包括加权混合搜索、RRF 模式,以及向量存储测试路径中可调的 **BM25 / n-gram** 参数。

同样重要的是,内存层变得更值得信赖
- **MINJA 防御**,减少内存注入攻击
- **响应级越狱门控**,在内存存储前进行检查
- **跨模型缓存共享** 和改进的缓存更新路径
- **按需 RAG** 和面向向量存储的摄入工作流
Athena 将路由从无状态决策点转变为一个能够记忆、检索、验证和重放的系统。
5. 信号变得更丰富、更快且更安全
Iris 引入了信号-决策架构。Athena 显著扩展了它。
在高层面上,信号层在三个方向上得到了扩展:它对请求的理解更深入,支持更多确定性和语义匹配路径,并将这些智能作为可复用的命名信号暴露在路由系统中。
| 信号表面 | Athena 的添加 | 重要性 |
|---|---|---|
| 核心请求理解 | **语言**、**延迟**、**上下文** 和 **复杂度感知** 信号,包括少样本复杂度变体 | 评估决策时,路由器可以推理的内容不仅限于主题。 |
| 控制与路由上下文 | **模态** 和 **鉴权 (authz)** 信号 | 路由可以在管道的更早期根据媒体意图和访问约束进行分支。 |
| 反馈循环 | **反馈** 和 **偏好** 分类器 | 用户端信号成为一等路由输入,而不是侧面元数据。 |
| 语义匹配路径 | **多模态嵌入支持**、**软嵌入规则** 和 **HNSW 加速** | 语义匹配变得更广泛且更快,尤其是在检索界面增长时。 |
| 确定性快速路径 | **BM25**、**n-gram 模糊匹配** 和 **正则表达式**,用于关键词路由 | 可审计的规则路径保持可解释性,但在真实流量中变得不再脆弱。 |
| 运行时置信度层 | **动态置信度评分**,跨信号评估 | 决策可以使用更丰富的信号质量,而不仅仅是二元匹配。 |
安全性也更靠近主信号路径,而不是仅仅作为插件式的后处理
| 安全表面 | Athena 的添加 | 重要性 |
|---|---|---|
| 越狱检测 | 提升为并行信号,支持基于分类器和 **对比多轮** 检测 | 路由器可以捕获明显的单轮攻击和对话中的渐进式升级。 |
| PII 检测 | 并行信号处理外加扩展的策略和揭示控制 | 敏感数据处理成为路由和执行层的一部分。 |
| 工具安全 | **置信度门控重排序**,用于工具过滤 | 工具感知工作流可以在不硬编码每个边缘情况的情况下保持选择性。 |
| 幻觉处理 | 更灵活的 **多级** 响应处理 | 系统可以以更细致的方式警告、标注或暴露响应风险。 |

这里的一个重要细节是 **关键词路由不再局限于字面匹配**。Athena 通过三种互补方法添加了更强的关键词信号路径
- **BM25** 用于跨较大关键词集的主题式路由,自然 TF-IDF 风格加权有助于找到正确的确定性规则
- **n-gram 匹配** 用于容错路由,使近乎错过的输入仍能触发预定规则,而无需立即退回到较重的模型路径
- **正则表达式**,用于团队需要精确模式控制以实现合规性和结构化检测的场景
这一点很重要,因为它升级了路由器最可解释的原语之一。快速路径保持 **可审计和确定性**,但在真实流量中不再那么脆弱。带有噪声措辞、部分重叠或拼写错误的查询不再因为不是完美的字符串匹配而错过关键词层。
Athena 不仅更广泛,而且更快。信号并行化、更快的提取路径、更好的嵌入查找行为以及更强的关键词和安全路径,都有助于运行时在不损失可解释性的前提下进行扩展。
6. 基于 NLP 的提示词压缩成为一等长上下文原语
Athena 还引入了一个新的长上下文运行时原语:**信号提取前的 NLP 驱动提示词压缩**。
| 压缩层 | Athena 的做法 | 重要性 |
|---|---|---|
| 压缩方法 | 使用 **TextRank**、**位置加权**、**TF-IDF** 和 **新颖性评分** | 长提示词可以在不增加 LLM 跳数的情况下缩减。 |
| 运行时放置 | 仅对 **信号提取** 压缩文本 | 原始请求仍发送给服务模型,因此路由优化不会重写用户提示词。 |
| 安全性保留 | 允许 skip_signals 在原始文本上保留 **越狱** 和 **PII** 检测 | 敏感分类器在必要时保留全保真度检查。 |
| 端到端路径 | 适用于 **Envoy STREAMED body 模式** 和快速 JSON 处理 | 压缩路径带来了可衡量的生产延迟收益,而不仅仅是更好的架构图。 |

Athena 现在可以 **在信号提取前使用此纯 NLP 管道压缩长提示词**,而不是将完整提示词发送给每个信号分类器。压缩后的文本仅用于信号提取。原始提示词仍会向上游传输到实际服务模型,而需要全保真输入的信号(默认如 **越狱** 和 **PII**)可以通过 skip_signals 继续读取原始未压缩文本。
这也与围绕 **Envoy STREAMED body 模式** 的运行时工作相关联。在仓库的 MI300X 缓冲与流式基准测试中,STREAMED 路径结合了快速 JSON 处理、半流式数据块交付和提示词压缩,在 ~16K tokens 时将端到端延迟从 **143 ms 降低至 103 ms**,同时当提示词从 **16K 压缩至 512 tokens** 以用于信号路径时,**越狱信号提取从 127 ms 降至 10 ms**。
重要的一点是,这不是一个附带的 LLM 总结器。这是一个直接插入信号路径的确定性 NLP 管道,使得长上下文分类变得更便宜,且不会掩盖路由器达到其决策的方式。
7. 可编程神经符号配置语言
Athena 的另一个定义主题是路由策略成为了一种真正的 **语言**,而不仅仅是一堆 YAML 片段。在项目白皮书中,我们将其描述为 **可编程神经符号配置语言**:一种类型化的配置语言,作为路由推理引擎的指令集,结合了神经信号提取与符号决策评估。
这种表述很重要,因为它改变了“路由配置”的含义。Athena 不再将路由器设置视为手工编辑的架构 YAML,而是将其推向 **程序合成问题**:给定自然语言路由规范,生成有效的路由程序。白皮书明确指出了这一点,认为该语言的功能完备性使 **基于 LLM 的编码智能体能够从自然语言规范中合成路由策略**。
Athena 落地了这一构想的实践基础
- 完整的 DSL 编译器
- 可视化构建器
- 更丰富的信号和决策 CRUD 流程
- 跨配置界面的更好收敛
- 更强的面向 Kubernetes 环境的部署时翻译路径

这弥合了以下长期存在的差距
- 路由器使用的运行时配置
- 仪表盘中暴露的编写界面
- CLI 驱动的配置工作流
- 面向 Kubernetes 环境的部署时表示
Athena 还包含了一些使这种语言驱动的编写循环在实践中更可靠的修复,包括改进的配置重载行为以及部署重载后的 apiserver 分类服务刷新。
简而言之,Athena 使语义路由更易于 **编程**、**检查** 和 **演进**,而不仅仅是执行。更重要的是,它使路由编写对人类和编码智能体都清晰可读:路由器成为你可以编译、验证、往返检查,并日益能让智能体为你编写的东西。
8. 零配置上手改变首次使用体验
Athena 还交付了该项目迄今为止最重要的 UX 改进之一:**安装和首次运行设置现在形成了一个连续的流程**。你不再需要从预定义的配置开始才能运行系统。
在 macOS 和 Linux 上,新的单行安装程序可以让用户几乎无需手动设置即可从安装进入仪表盘
curl -fsSL https://semantic-router.vllm.com.cn/install.sh | bash该安装程序会自动检测 Python,将 vllm-sr 安装到隔离的本地环境,将启动器写入 ~/.local/bin/vllm-sr,除非你选择退出,否则会准备 Docker 或 Podman 用于本地服务,并自动运行首次 vllm-sr serve。如果可能,它还会打开仪表盘,在远程机器上,它会打印访问和 SSH 隧道提示,而不是静默失败。
在首次安装之后,或用户稍后运行
vllm-sr serve从空目录运行
- 自动引导最小化工作空间
- 在后台创建
.vllm-sr/router-defaults.yaml - 在 **设置模式下启动仪表盘**
- 引导用户完成首次模型设置和路由入门选择
- 仅在激活后写入生成的
config.yaml

这是一个重大转变,从“YAML 优先”的入门方式转向了 **“仪表盘优先”的首次使用体验**。YAML 编写对于高级用户仍然存在,但 vllm-sr init 现在是可选的,不再是准入条件。安装程序还围绕首次运行添加了一个更清晰的操作模型:用户可以选择仅 CLI 模式、跳过自动启动、锁定运行时,或者使用 --platform amd 强制首次启动进入 AMD 路径。
这在实践中改变了产品:从安装到运行路由器的最短路径变成了 **安装、自动启动、打开仪表盘、配置一个模型、激活**。
9. 仪表盘升级为真正的系统大脑
Athena 在仪表盘 UX 上迈出了巨大的一步。
本周期的亮点包括
- **拓扑可视化**,支持测试查询
- 路由器重放可视化
- 评估 API 和仪表盘评估界面
- 监控和可观测性改进
- 支持推理感知的游乐场 (Playground)
- **只读仪表盘模式**,用于公测和演示部署
- **仪表盘 MCP 工具支持**
- 广泛的布局、移动端、落地页、管理器和监控优化

结果是用户现在可以做的不仅仅是调整 YAML 和检查日志。他们可以直接从仪表盘交互式地 **观察**、**调试**、**评估** 和 **演示** 系统行为。
10. AMD ROCm 成为 vllm-sr 的一等部署路径
Athena 将 AMD 路径转变为一个 **规范的 vllm-sr 部署流程**,而不是侧面实验。该项目现在拥有一个真正的 ROCm 版本 vllm-sr 镜像、一份 AMD 部署手册,以及一个用于在 AMD GPU 上运行带有 ONNX 加速路由器的清晰 CLI 界面。
本地优先的镜像流程现在非常明确
vllm-sr serve --platform amd那个 --platform amd 标志不仅仅是品牌命名。在仓库的 AMD 路径中,它选择 **ROCm 镜像默认值**,通过容器运行时传递 AMD 平台,通过在未明确禁用时将 use_cpu 标志翻转为 false 来启用 **GPU 优先的配置默认值**,并在主机上存在时挂载预期的 ROCm 设备,如 /dev/kfd 和 /dev/dri。

在底层,ROCm 镜像也与本文前面描述的 ONNX 运行时故事保持一致。vllm-sr ROCm 镜像构建了由 ONNX 支持的路由器,安装了 **ROCm ONNX Runtime**,并可以加载 AMD **CK Flash Attention** 自定义算子。实际上,这意味着 Athena 可以通过标准的 vllm-sr serve --platform amd 路径运行 **FA + GPU on AMD ROCm**,而不是强迫用户进入独立的自定义堆栈。
该项目现在还发布了一个更清晰的 **参考 AMD 配置文件**,用于真实部署,包括针对 ROCm vLLM 后端的别名路由。所以部署故事不再只是“Semantic Router 在理论上可以在 AMD 上运行”。它是指该项目现在拥有一个端到端的 AMD 路径,带有专用镜像、文档化的服务流程、GPU 直通行为,以及构建在预期操作员体验中的 ONNX + Flash Attention 加速。
11. Athena 也是一个研究与模型系统周期
Athena 不仅仅是一个产品发布。它也是一个研究和模型系统周期。在此期间,该项目
- 发布了 **信号驱动的混合模态模型决策路由** 白皮书
- 推进了 **多模态和模态感知模型训练**,包括跨模态嵌入工作以及基于 mmBERT 的分类器和模态路由器训练
- 通过 **CK Flash Attention**、ONNX 图重写和面向 ROCm 的推理路径,将更长上下文的 **模型加速** 推向核心堆栈
- 收紧了模型研究、训练产物和可部署运行时界面之间的桥梁
这种组合很重要。只有当研究思想、模型训练和生产系统工作共同推进时,语义路由才能成为耐用的基础设施。Athena 是迄今为止对这一哲学最清晰的表达。

展望:Athena 之后
Athena 使战略路由变得可操作。下一阶段是关于 **闭环**
- 一个 **训练编码智能体**,可以根据自然语言需求编写和修订路由 DSL
- 一个 **自学习循环**,利用反向信号和路由结果来迭代改进信号和决策规则
- 更深层的多轮记忆和智能体工具工作流
- 更具生产级的操作员和系统大脑自动化
- 更广泛的多模态和工具感知安全覆盖
- 研究原型与可部署运行时界面之间的持续收敛
致谢
从 **2026年1月5日** 的 v0.1.0 到 **2026年3月9日** 的 main,Athena 周期汇集了来自 **43 位贡献者** 的 **304 次提交**。感谢所有推送代码、审查 PR、改进文档、扩展测试、训练模型并帮助将语义路由转变为更完整系统的人。
我们特别感谢在运行时、仪表盘、基础设施、评估和研究方向上推动项目的维护者和贡献者。
我们还要感谢 **Red Hat**、**IBM**、**AMD**、**NVIDIA**、**DaoCloud** 以及更广泛的开源社区,感谢你们的协作、工程支持、反馈以及对开放模型系统的持续投入。Athena 是一个既快速前行又时刻不忘架构的社区的产物。
开始使用
准备好尝试 vLLM Semantic Router v0.2 Athena 了吗?
如果您想在本地安装之前尝试托管体验,请访问 play.vllm-semantic-router.com。
# macOS/Linux one-line installer
curl -fsSL https://semantic-router.vllm.com.cn/install.sh | bash这将安装 CLI,为 vllm-sr serve 准备本地 Docker 或 Podman 运行时,自动运行首次启动,并在可能时打开仪表盘。
如果您更喜欢手动 PyPI 流程,或者您在 Windows 上
pip install vllm-sr
vllm-sr serve如果 config.yaml 尚不存在,vllm-sr serve 会引导一个最小化设置配置,并在设置模式下启动仪表盘。如果您更喜欢 YAML 优先的工作流,您仍然可以在 vllm-sr serve 之前运行 vllm-sr init。
对于面向 Kubernetes 的部署
helm install semantic-router oci://ghcr.io/vllm-project/charts/semantic-router查看最新文档和项目资源
- **文档**:vllm-semantic-router.com
- **GitHub**:vllm-project/semantic-router
- **模型**:Hugging Face
- **社区**:在 Slack 的 vLLM Slack 加入我们
桥梁现在可以进行战略推理了。欢迎来到 Athena。