Vela Router 模型
概览
Vela 1.0 是面向智能路由的专用模型家族。Router 注册表包含 Vela 307M Encoder 基座、任务分类器、检索与重排模型以及多模态嵌入模型，每个版本都固定到不可变的 revision。
| 模型 | 作用 |
|---|---|
| Encoder | 适配新路由任务的共享基座 |
| Domain | 识别 14 类请求主题 |
| Guard | 检测提示注入和越狱攻击 |
| Safety / Shield | 可选的不安全内容分类器 |
| Hazard | 识别 12 类独立内容风险 |
| PII | 提取 17 类个人信息实体 |
| FactCheck | 判断请求是否需要事实核查 |
| Feedback | 四类反馈及中性 NO_FEEDBACK 类别 |
| Modality | 从文本请求判断文本、图像或混合输出意图 |
| Embedding | 多语言检索和语义匹配 |
| Reranker | 为查询与文档对计算相关性 |
完整模型名由 Vela-1.0-Encoder-307M 和任务后缀组成。Modality 从文本请求判断所需的输出模态。FactCheck 判断是否需要核查，并不验证回答的事实真伪。
公开模型集合还包括检查回答证据支持情况的 Halu，以及生成文本、图像和音频嵌入的 Omni Nano / Omni Mini。Halu 已接入 Router 的专用幻觉检测，Omni 已接入多模态嵌入；见检查回答依据和图像与音频。完整模型家族见 Vela 1.0 发布公告。
解决什么问题
共享模型家族提供任务专用信号与检索组件，并明确模型身份、输入预算和服务策略。
何时使用
使用 Vela 执行内置路由任务，或从共享 Encoder 适配新任务 。根据实际工作负载的质量和时延要求选择输入长度与表示大小。
Omni checkpoints
9 月 19 日发布的版本通过独立的文本、图像和音频编码器生成共享空间中的嵌入。模型运行时支持将这两个 checkpoint 加载为多模态嵌入部署。
| Checkpoint | 总参数量 | 输出维度 | 文本上限 | 文本基座与读出 |
|---|---|---|---|---|
| Omni Nano | 163.8M（163,771,288） | 384 | 512 tokens | 冻结的 GIST-small；CLS 读出 |
| Omni Mini | 1.36B（1,361,475,288） | 768 | 32,768 tokens | Qwen3-Embedding-0.6B；末 token Matryoshka 读出 |
参数量包含全部模态分支，包括新增的 CLAP 音频分支；整数和运行统计量 buffer 不计入参数。Nano 保留 CLS 读出及恒等投影；Mini 对最后一个非 padding token 的完整 1024 维状态归一化，取前 768 维后再次归一化。
Mini 默认使用适合跨模态比较的共享文本模式。纯文本任务可向 encode_text 传入 task= 或自定义 instruction=，二者互斥。检索预设要求指定 role="query" 或 role="document"，文档不添加前缀。32,768-token 预算包含指令前缀和特殊 token；超限默认报错，只有显式设置 truncate=True 才截断。Nano 保留 512-token 上限并拒绝超长输入。带指令的 English 评测使用固定的官方任务指令，不是搜索通用预设得到的结果。
两者都接收不超过 30 秒、保留原始采样率的 PCM，可为单声道或 channels-first 数组。传入真实采样率后，两个分支分别从原始波形生成 Whisper 的 16 kHz 输入与 CLAP 的 48 kHz 输入。存在更高采样率 PCM 时，不应先降采样到 16 kHz。CLAP 读取按端点分布、每段最多十秒的窗口，聚合归一化向量，经冻结的 TRAIN 统计量标准化及已训练的残差映射后，加到保留的未归一化 Whisper 仿射输出上，最后做 L2 归一化。文本/图像路径保留，音频路径经过新的训练与评测。
最新模型卡将路由与跨模态检索能力分别与原始 small和原始 large模型对比。分数范围为 0–100，每格表示原始模型 → 当前模型：
| 指标 | 原始 small → Nano | 原始 large → Mini |
|---|---|---|
| Banking77，accuracy | 70.42 → 87.99 | 75.78 → 86.56 |
| MASSIVE English，accuracy | 65.95 → 81.97 | 72.31 → 80.96 |
| COCO，图像 → 文本，R@1 | 40.83 → 60.87 | 42.53 → 67.44 |
| COCO，文本 → 图像，R@1 | 30.18 → 55.82 | 35.04 → 61.60 |
| LibriSpeech，音频 → 文本，R@1 | 4.21 → 16.12 | 56.99 → 86.14 |
| LibriSpeech，文本 → 音频，R@1 | 9.58 → 20.34 | 78.58 → 94.90 |
双方使用相同的留出评测集，这些已知测试集在不同版本间复用，文本上限统一为 128 tokens。分类使用有标签 TRAIN 数据构建的原型；检索使用完整候选池和全部匹配正例。该协议不同于官方 MTEB 分类探针，完整指标和不确定性见下方链接的评测文档。
完整 MTEB 2.21.0 面板以 Mean(TaskType) 为主要指标，Mean(Task) 为补充指标。原始 small/large 模型尚未按这些完整面板协议评测。
| 面板与模式 | Mean(TaskType) | 全局排名 | 不大于该尺寸的排名 | 距该尺寸内最佳分数 | Mean(Task) |
|---|---|---|---|---|---|
| Nano · English v2，41 个任务 · 默认文本 | 60.78 | 66/188 | 5/75 | 0.61 pp | 64.88 |
| Mini · English v2，41 个任务 · 官方指令文本 | 64.68 | 38/188 | 10/134 | 3.78 pp | 70.38 |
| Nano · MAEB audio-only，19 个任务 · 默认音频 | 52.34 | 19/64 | 6/27 | 3.51 pp | 43.59 |
| Mini · MAEB audio-only，19 个任务 · 默认音频 | 54.87 | 12/64 | 5/50 | 2.85 pp | 47.77 |
排名汇总 9 月 17 日注册表快照与当前 Vela 模型，包括单模态专用模型，已报告的评测协议存在差异。尺寸上限按全模型总参数量计算。两个 Vela 模型都不在这两个完整面板的观测前沿上，两种聚合指标下均如此。单任务优势包括 Nano 的 IMDb 91.95 accuracy、NMSQA 62.90 max AP，以及 Mini 的 Mridingham 68.14 accuracy、SIBFLEURS 39.07 accuracy；这些任务级前沿不能证明整体榜单领先。
Nano 的 English 分数通过未改变的冻结文本路径保留。Mini 的带指令 English 评测使用固定的官方指令，并重新运行了匹配的原始文本对照：Mean(TaskType) 从 58.79 提升到 64.68，38 个任务提升、3 个下降。该指令模式不能替代跨图像/音频比较中的默认共享模式。两个新音频路径均重新评测；虽然音频聚合分数提升，语音与文本检索仍有退步。实际测量身份、全部任务和退步项见固定版本的 Nano 评测、Mini 评测及指令模式匹配对照。这些面板不代表完整多语言或图像覆盖，也不证明时延或内存表现。
默认值与输入预算
未配置模型时，内置 Domain、Guard、Safety、PII、FactCheck、Feedback、Modality 和幻觉检测信号在 Vela 2.0 0.3B 上运行，兼容问题按部署、输入和执行阶段合并；一次 API 调用不等于整个请求只执行一次 forward（见选择模型）。语义 Embedding 和 Reranker 使用 Vela 1.0。内置 Vela 1.0 Hazard deployment 需要显式绑定；目录中存在它不代表自动启用 Safety 到 Hazard 的级联。在 global.model_catalog.system 中写明 Vela 1.0 任务模型即可选择该专用模型。只有 recipe 实际需要的模型才会加载；Encoder 基座用于训练，不作为额外路由信号加载。
运行 Vela 1.0 任务模型且未设置阈值的模块使用 Guard 0.5、FactCheck 0.95、Feedback 0.7。NO_FEEDBACK 不产生反馈匹配。Safety 独立于 Guard，有害内容不必同时被判断为提示词攻击。Hazard 使用与模型产物绑定的逐标签阈值，单一阈值不能代表它的发布决策策略。
输入预算取决于任务、加载的模型和部署策略；0 不代表无限上下文。Embedding 默认采用 22 层、768 维和 full_context: false。经过验证支持 32K 的模型可显式设置 32,768 tokens（含特殊 token）及 overflow: reject。PII 和 Guard 也可使用重叠窗口；完整文本预算与窗口参数应遵循各 任务指南。被拒绝的输入不会静默缩短。
配置
每个 Vela 模型都运行在模型运行时中，因此默认配置无需任何设置。以下片段把 Domain 绑定到一个显式的 CPU deployment，输入预算为 32K。请将其加入已包含 providers、signals 和 decisions 的配置。
routing:
model_bindings:
domain_classifier:
deployment: vela-domain
contract: label_distribution.v1
global:
model_catalog:
deployments:
vela-domain:
provider: model_runtime
artifact: vllm-sr/Vela-1.0-Encoder-307M-Domain
device: cpu
input:
max_tokens: 32768
overflow: reject
其他分类器使用相同的 deployment 与 consumer binding 结构。PII 返回 token_spans.v1，Embedding 使用 embedding.v1，Reranker 使用 relevance_scores.v1。运行时从模型包读取每个模型的架构，因此这些 binding 不需要 adapter。完整契约见与路由器一起运行。
Hazard 使用独立分类契约 label_scores.v1，并通过 SHA-256 固定 operating_point.json。该策略绑定权重、tokenizer、重叠窗口和十二个阈值。Decision 选择标签，不覆盖这些阈值；参考配置包含完整示例。
PII 的重叠扫描、Hazard 的窗口策略与整段文本分类不同。应按任务选择输入策略，并使用应用中的实际输入长度测量时延。
推理引擎与硬件
模型运行时用 PyTorch 在 CPU、CUDA 或 ROCm 上运行 Vela。支持的输入长度是容量上限，不是时延保证。长输入在少核 CPU 上可能超过请求截止时间；请按实际输入长度和并发测量，选择足够的 CPU 容量或 GPU，而不是假设延长超时就能解决容量不足。Profiles 在精确与速度之间取舍，选择模型列出每个模型的开销。
Vela AMD 配方把全部十个任务模型放在 AMD GPU 上，并保留发布的运行策略。--platform rocm 选择 AMD 镜像及设备访问，不会让所有模型自动使用 GPU，也不会覆盖显式 CPU 部署。见 AMD ROCm。
早期版本通过 Candle、ONNX Runtime、MIGraphX 或 OpenVINO 运行 Vela，并用 head 选择导出的 ONNX 计算图。这些 provider 已移除；模型仓库仍保留 ONNX 导出供其他工具使用。vllm-sr config migrate 会改写旧的 deployment，见从原生绑定迁移。
各模型卡片列出支持的输入长度、用法及可比评测结果。公开对比以此前的 mmBERT 家族为基线，使用匹配数据；质量分数、最大可接受输入长度和推理性能衡量的是不同属性。
验证真实路由与重排
使用 Vela AMD 配方时，下载并验证完整配置，再选择 AMD 镜像启动。按配方模型卡片说明连接已有的 vLLM 后端：服务名为 vela-default，地址为 vllm:8000。
curl --fail --location --output vela-amd.yaml \
https://raw.githubusercontent.com/vllm-project/semantic-router/main/config/recipes/vela-amd/config.yaml
vllm-sr config validate --config vela-amd.yaml
vllm-sr serve --platform rocm --config vela-amd.yaml
Route Preview 返回实际信号值、决策和逐信号时延。输入应保持在配方的 8K 分类器预算内：
curl --fail 'http://localhost:8080/api/v1/routing/preview?trace=true' \
-H 'Content-Type: application/json' \
-d '{"model":"vela-auto","text":"Help me debug this Python program."}' \
| jq '{decision_result, signal_confidences, signal_values, signal_errors, metrics, eval_trace}'
使用 entrypoint 声明的公共模型名。请求前检查 /ready，并查看响应中的信号值与求值轨迹。
重排发生在路由后的 vectorstore RAG 插件中。按神经重排绑定 rag.reranker 并启用 rerank，通过已入库文档和真实聊天请求验证。请求 trace 记录候选数、reranker 身份、相关性分数和重排时延；routing Preview 不执行 RAG 插件。
保留旧部署
显式指定的旧模型路径和别名仍指向原仓库。复现旧分类器时，应同时选择匹配的 mapping、阈值和输入策略。升级 Vela 不会重写显式模型选择。
Embedding 权重或表示发生变化时，向量空间也随之变化。响应缓存和 memory 按表示身份隔离数据；已有 vector store 需要兼容的 embedding 或重新索引，不会静默接管或删除旧数据。详见存储与工具。