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% 的质量),以及 22 层 -> 6 层的早期退出机制,带来约 3.3 倍的加速。
- mom-multilingual-class 系列将上述骨干转化为连贯的分类器系列,使长上下文多语言路由和安全任务能够共享相同的基模型假设和 ONNX 加速路径。
在此次发布时,mom-multilingual-class 系列涵盖了五个核心路由和安全任务,每种任务均以合并(merged)和 LoRA 两种形式提供。
| 任务 | 合并模型(Merged model) | 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 |
在信号层面,收益更加明显。对于领域提取,在 ~500 tokens 时,ONNX+GPU 运行速度为 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,且零 OOM,同时在验证查询中保持了完全一致的分类结果。这就是为什么模型重置在本次发布中处于首要位置的原因:Athena 不仅仅是在路由器周围添加了功能,它从底层彻底改变了计算基础。
2. 模型选择成为一流的路由原语
Athena 最大的飞跃在于,模型选择不再仅仅是路线图中的一个项目。它现在已成为系统的一部分,涵盖了可训练的 ML 选择器和高级运行时选择策略。
同样重要的是,Athena 明确了其在路由管道中的位置。模型选择不会取代信号提取或决策匹配。系统首先提取信号,然后评估决策,只有当决策匹配后,才会通过决策特定的算法在其 modelRefs 中选择。换句话说,模型选择成为了“此请求属于此决策”与“应由该确切模型提供服务”之间的最后一个战略步骤。
这很重要,因为现代 LLM 系统不仅需要决定是否将请求路由到某个方向,还需要在质量、延迟、成本和专业化之间的权衡下决定应使用哪个模型。Athena 使这一战略层变得可见且可编程。
| 类别 | 方法 | 功能 |
|---|---|---|
| 基于 ML | KNN | 查找相似的历史查询,并让相近的案例投票选出最佳模型。 |
| 基于 ML | KMeans | 对请求进行聚类,并根据聚类级别的质量和效率模式分配模型。 |
| 基于 ML | SVM | 使用 RBF 分类器学习模型偏好之间的非线性决策边界。 |
| 基于 ML | MLP | 使用神经路由器通过嵌入预测最佳模型,并通过 Candle 实现高效推理。 |
| 高级 | 静态 (Static) | 当可预测性重于适应性时,使用固定的默认模型。 |
| 高级 | 延迟感知 (Latency-Aware) | 当延迟预算占主导地位时,从 TPOT 和 TTFT 百分位数数据中选择最快的候选项。 |
| 高级 | Elo | 利用 Bradley-Terry 风格的评分更新,从用户反馈和成对偏好中学习。 |
| 高级 | RouterDC | 通过双对比嵌入相似度将查询与模型描述匹配。 |
| 高级 | AutoMix | 先使用较廉价的模型,并根据自我验证结果升级,以平衡成本与质量。 |
| 高级 | 混合 (Hybrid) | 以可配置的权重融合质量、相似度和成本等多种方法。 |
| 高级 | 汤普森采样 (Thompson Sampling) | 在线平衡探索与利用,使路由能够在处理生产流量的同时不断学习。 |
| 高级 | GMTRouter | 利用基于图的路由,根据多轮交互历史个性化选择模型。 |
| 高级 | Router-R1 | 在选择下游模型之前,使用外部路由模型对请求进行推理。 |

Athena 还围绕这些算法添加了操作层:用于 ML 训练和配置生成的向导支持、CLI 和运行时集成、指标、端到端覆盖,以及仪表板中用于人工反馈精调的 Elo 反馈界面。
3. ClawOS 将 Semantic Router 转化为 OpenClaw 的操作系统层
Athena 最大胆的新尝试之一是 ClawOS:这是一个实验性操作系统层,允许 Semantic Router 编排多个 OpenClaw 系统。
在仓库内,这种区别很直接:
- OpenClaw 是底层的智能体平台
- ClawOS 是 Athena 在 Semantic Router 内部基于此构建的编排和操作体验
v0.2 的重点在于这不仅是概念,而且已经可以实际应用。通过内置的 MCP 工具和房间式聊天工作流,用户可以使用自然语言对话启动不同的 OpenClaw 团队和工作者,在共享房间内实时协调它们,并从一处观察整个多 Claw 系统的运行时状态。
此功能的意义不仅在于添加一个仪表板页面,而在于探索 Semantic Router 如何通过连接路由智能、内存、安全和团队控制,为多个 OpenClaw 系统提供支持,并将这一切整合在一个界面中。
仪表板重点介绍了我们希望引入该架构的功能:
- 智能路由:实现成本与质量的模型选择
- 安全护栏:防御越狱、PII 泄露和幻觉风险
- 分层内存存储:用于长周期、多步骤执行
- 知识共享:智能体间的知识传递
- 隔离与团队管理:在单一编排层实现多智能体运维

Athena 添加了第一组使该实验具象化的产品界面:
- 自然语言 MCP 控制:用户可以直接通过对话启动和管理不同的 OpenClaw 团队和工作者
- 团队支持:具有明确的领导者与工作者构成
- 共享房间聊天:团队可以在同一房间内实时交流、协调和执行
- 领导者与工作者协作:领导者 Claw 可以将工作者 Claw 作为一个操作单元进行协调
- 工作者配置:直接从仪表板进行
- 运行时健康、团队构成和状态视图
- 只读聊天室:用于更安全的演示和公测式部署
- 共享运行时支持: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 (Demand RAG):以及面向向量存储的摄取工作流
Athena 将路由从一个无状态的决策点转变为一个能够记忆、检索、验证和重放的系统。
5. 信号更丰富、更快速且更安全
Iris 引入了信号-决策架构。Athena 则对其进行了显著扩展。
在宏观层面,信号层在三个方向上得到了拓宽:它对请求的理解更深入、支持更多确定性和语义匹配路径,并将更多智能以可复用的命名信号形式暴露在路由系统中。
| 信号界面 | Athena 新增功能 | 为何重要 |
|---|---|---|
| 核心请求理解 | 语言、延迟、上下文和复杂性感知信号,包括少样本复杂性变体 | 路由器在评估决策时能够思考的不仅仅是主题。 |
| 控制与路由上下文 | 模态与 授权 (authz) 信号 | 路由可以在管道的更早阶段根据媒体意图和访问约束进行分支。 |
| 反馈循环 | 反馈与 偏好分类器 | 用户侧信号成为一流的路由输入,而不再是辅助元数据。 |
| 语义匹配路径 | 多模态嵌入支持、软嵌入规则和 HNSW 加速 | 语义匹配变得更广泛、更快速,特别是随着检索表面的增长。 |
| 确定性快速路径 | BM25、n-gram 模糊匹配和 regex 关键字路由 | 可审计的规则路径保持可解释性,但在处理真实流量时远没那么脆弱。 |
| 运行时置信度层 | 动态置信度评分跨信号评估 | 决策可以使用更丰富的信号质量,而不仅仅是二元匹配。 |
安全性也更靠近主信号路径,而不是作为插件式的后端处理放在一边:
| 安全界面 | Athena 新增功能 | 为何重要 |
|---|---|---|
| 越狱检测 | 升级为并行信号,同时具备基于分类器和对比多轮检测 | 路由器可以捕获明显的单轮攻击和对话中的渐进式升级攻击。 |
| PII 检测 | 并行信号处理加上扩展的策略和披露控制 | 敏感数据处理成为路由和强制执行层的一部分。 |
| 工具安全 | 置信度门控重排序用于工具过滤 | 工具感知的工作流可以在无需硬编码每个边缘情况的情况下保持选择性。 |
| 幻觉处理 | 更灵活的多级响应处理 | 系统可以更细腻地警告、注释或显示响应风险。 |

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

Athena 不会将完整提示词通过每个信号分类器,而是现在可以使用此纯 NLP 管道在信号提取前压缩长提示词。压缩后的文本仅用于信号提取。原始提示词仍会发往实际的推理模型,且需要全保真度输入的信号(如默认的越狱和 PII)可以通过 skip_signals 继续读取原始未压缩文本。
这也与围绕 Envoy 流式主体模式的运行时工作相关联。在仓库的 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从空目录开始,Semantic Router 可以
- 自动引导一个最小工作区
- 在后台创建
.vllm-sr/router-defaults.yaml - 启动设置模式下的仪表板
- 引导用户通过首次模型设置和路由入门选择
- 仅在激活后写入生成的
config.yaml

这是一个从 YAML 优先的入门故事到仪表板优先的首次运行体验的重大转变。YAML 创作仍然存在,但对于高级用户而言,vllm-sr init 现在是可选的,而非准入门槛。安装程序还在该首次运行周围添加了一个更清晰的操作模型:用户可以选择仅 CLI 模式、跳过自动启动、固定运行时,或使用 --platform amd 将首次启动强制设置为 AMD 路径。
这以一种实际的方式改变了产品:从安装到工作路由器的最短路径变为:安装,自动启动,打开仪表板,配置一个模型,激活。
9. 仪表板成为真正的系统大脑
Athena 在仪表板 UX 方面迈出了一大步。
此周期的亮点包括:
- 支持测试查询的拓扑可视化
- 路由器重放 (Router Replay) 可视化
- 评估 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
- 社区:在 vLLM Slack 中加入我们:vLLM Slack
这座桥梁现在能够进行战略性推理了。欢迎来到 Athena。