Router的作用被低估了？vLLM这个神器，让单次调用背后藏了一支模型协作小队
所有人都在翘首期盼下一个SOTA模型的降临，但真正值得关注的变量，此刻正悄悄发生在模型调用的前端。
过去这一年，Router不再是那个单纯“把请求分给某个模型”的转发袋。它已经进化成了模型推理层的核心“总指挥”。
如今，它的职责任务延伸到了三个关键维度：
- ：什么场景必须调用前沿闭源模型，什么时候开源SOTA模型能胜任，而本地小模型又能在哪些任务上无缝兜底？
降低成本
- ：一旦请求落入法律、医疗、金融、未成年人隐私或企业机密等敏感地带，系统能否自动切换到更严格的模型，甚至启动更强力的过滤、审查、确认，乃至上升到人工介入？
安全防护
- ：哪些请求意图应该留在终端设备（比如AI PC上部署的本地模型）进行低延迟处理，哪些必须升级到云端，让更加强大的模型接手？
云边协同
这三条线，早已突破了传统路由的转发语义，延伸出了真正的“系统智能”。
vLLM社区推出的Semantic Router，正是在这三条线上更进一步。团队的核心认知是：Router不止是选择模型，它完全可以在不改变用户模型权重、不要求每个Agent团队都自建一套Graph的前提下，通过一次普通的Model API调用，在内部组织出一支有边界、有预算、有验证、有回退机制的“模型协作小队”。
图 1：router 正在从“模型选择层”变成“能力构造层”。
最近日本AI公司Sakana的Fugu项目引起了不少讨论，它其实就是这个理念的一个商业化版本：用户面对的是一个虚拟模型，而实际后台运作的是一组模型的动态协作。
vLLM Semantic Router团队从2025年初就开始布局智能路由方向，并且坚持开源构建。他们推出的Micro-Agent方案，正是为了解决这类问题。
用户端，依然只调用一个模型：
{
"model": "vllm-sr/auto",
"messages": [{"role": "user", "content": "..."}]
}
但在这个稳定的model名称背后，Router会根据意图智能地选择路由配方——把请求扇出到多个worker、收集quorum、判断分歧、合成答案、修复输出格式，最终返回一个标准的OpenAI-compatible response。
这一切协作，调用起来却像调用一个普通模型一样简单。
Looper：把Micro-Agent放入Serving Runtime
在vLLM Semantic Router处理请求的过程中，Looper就是Micro-Agents的运行时环境。
当请求进入Router时，它本质上仍然是一条普通的chat completion。Router会从多个角度抽取异构的语义信号，把这些离散信号投影为task shape、difficulty、risk、contract pressure等可用于策略判断的低维向量，然后基于这些向量命中决策，最终进入不同的路由算法。
这个算法，可以是匹配最适合当前任务的单模型，也可以是一个多模型协作的Loop。
当前Looper的模式共有五类：
- ：基于置信度的自动升级。先尝试便宜或参数较小的候选模型，再评估其输出置信度，不够就向上升级。
Confidence
- ：一次性让多个候选模型参与，并利用评级感知的权重进行聚合。
Ratings
- ：面向高方差推理的重复混合模型推理。发起并行推理，等待采集到足够多的有效结果，再做综合合成。
ReMoM
- ：panel、judge、finalizer模式。多个独立答案不是简单投票，而是被整理成一致性、矛盾点、独特洞察等证据形态。
Fusion
- ：有角色、有计划、有验证器的Micro-Agent动态工作流模式。可以调度出planner/worker/verifier/finalizer等动态角色，去解决一个复杂问题。
Workflows
图 2：looper 在 router 内部运行 micro-agents，同时保持外部 Model API 不变。
团队在设计中做了克制的工程化实现。不同的Looper算法需要综合控制预算、拓扑、并发、超时、重试、回退、输出契约和可观测性，确保路由过程中的可靠与稳定。
当然，不同Looper算法各有适用场景，收益也各不相同：
Confidence：只把升级成本花在真正难的问题上
Confidence是成本感知型循环。它先用较小或较便宜的候选模型生成答案，再判断这个答案是否足够可信。置信信号可以来自token-level log probability、logprob margin、hybrid score、self-verification，也可以是类似AutoMix风格的entailment verifier。
如果分数超过阈值，Router直接返回。否则，Router才升级到下一个候选模型。
这样，“是否升级”就从应用层的隐式逻辑，变成了Router的显式策略。阈值、失败行为、停止条件都可以被配置、观测和复现。
图 3：Confidence 把模型升级变成可度量的 stopping policy。
Ratings：硬上限约束下的并行质量控制
Ratings是受控集成型循环。它会并行启动多个候选模型，但受限于配置中的max_concurrent上限。这样，一次路由可以吸收多个模型的视角，又不会把每个请求都变成无限制的扇出。
Router收集成功的返回，按照评级感知权重聚合结果，并按预定义策略处理失败。它适合A/B-style评估、集成策略，以及运营商已经掌握候选模型质量信号的场景。
图 4：Ratings 让多候选执行保持有界，并把评分信号纳入聚合。
ReMoM：有契约的广度探索
ReMoM适用于高推理方差的任务模式。它先展开广度采样，让多个worker独立产生证据；然后通过minimum-success quorum判断是否有足够的有效材料；最后，由合成模型合并证据，并修复成目标输出格式。
它远不止是“三个模型投票”。更准确地说，它是一条包含quorum、synthesis和fallback的服务路径。
如果合成环节失败，但前面已经积累了有效证据，Router不需要直接返回失败。它可以平稳地回退到最佳有效证据，仍然返回一个正常的API响应。
图 5：ReMoM 把 breadth、quorum、synthesis 和 fallback 都变成 serving-time controls。
Fusion：把分歧转化为信号的模式
Fusion的假设更微妙：有时候最有价值的不是平均答案，而是分歧的结构本身。
多个panel的答案会被整理成证据图。哪些地方一致、哪些地方冲突、哪些回答提供了独特洞察，这些都会交给judge和finalizer。最终用户仍然只看到一个答案，但Router内部已经利用分歧做了一次质量增强。
这类循环在处理hard reasoning、expert judgment、exact-answer任务时尤其有用。最危险的失败不是模型犹豫，而是模型非常自信地犯错。
图 6：Fusion 不隐藏分歧，而是把分歧转化成证据。
Workflows：有边界的Micro-Agent模式
Workflows是最接近Agent的形态，也是最需要边界约束的。
planner可以制定计划，但只能选择已经被许可的worker模型。计划必须能够被校验。每一步都必须有max steps、max parallel、timeout和error policy。finalizer必须把结果收敛到output contract里。
这意味着Router可以表达planner、patcher、verifier、finalizer这些角色，而不要求应用层自己维护一套脆弱的agent stack。
图 7：Workflows 给 router 一个受约束的角色系统，而不是一个无边界的 autonomous agent。
Auto Recipe：一个模型名称，多种循环
vllm-sr/auto的设计理念，不是让用户“永远跑最强的loop”，而是让Router根据语义和上下文，选择对当前请求来说最合适的协作模式。
difficulty、risk、format pressure、latency、cost这些属性，不是prompt里的注释，而是routing facts。它们可以决定这次请求应该走Confidence、Ratings、ReMoM、Fusion、Workflows，还是一个回退路径。
图 8：Auto Recipe 用 signals 选择 collaboration pattern，同时保持单一 model identity。
Loop是万能的吗？
团队做了一轮评估后，最明确的发现是：没有一个Loop能在所有benchmark上都做到最优。
一个更准确的结论是：
最好的Loop是由task shape决定的。
GPQA-Diamond需要保证multiple-choice contract的严格性。LiveCodeBench需要可运行的代码、对隐藏测试的鲁棒性、以及准确的输入输出格式。Humanity's Last Exam则需要处理好分歧、长推理和精确答案。而SWE类型的任务，天然就需要planner、patcher、verifier、finalizer这样的角色分工。
所以说，vllm-sr/auto的真正价值不是把所有请求都拖进昂贵的协作中，而是提前感知请求的形状，再选择与之匹配的recipe。
图 9：不同 benchmark 对应不同 recipe，router 用 signals 和 projections 选择合适的协作路径。
在团队的实验中，这些shape是显式写进路由策略的：
GPQA-Diamond使用严格的ANSWER: X contract，避免synthesis把选项格式改乱。
LiveCodeBench会识别constraints、starter code、standard input、float tolerance、timeout risk和hidden-test risk。
HLE会识别formal reasoning、disagreement risk、long context和exact-answer pressure，再选择更深的ReMoM、更小的Fusion或fallback。
这也就是为什么router-side model collaboration绝不是简单的prompt engineering。Prompt只是其中一层。
真正的recipe还包括model pool、roles、reasoning effort、concurrency、quorum、timeout、synthesis model、fallback policy、output contract和observability labels。
三个实验：分数不是全部，但足够说明趋势
团队将当前的recipe放到三个高难benchmark上进行了实验：LiveCodeBench、GPQA-Diamond、Humanity's Last Exam。结果都相当不错：
图 10：VSR Closed / VSR Hybrid 在三个 hard eval 上的 scorecard。
VSR Closed指recipe全部使用闭源商业化模型。
VSR Hybrid指recipe混合开源和闭源模型，并在高风险判断、修复、合成或回退时使用更强的闭源模型。（在成本上，相比全部使用闭源模型有明显优势）
实验表明：hybrid model collaboration可以形成一个比底层任何单次调用都更强的统一Mixture-of-Models。它能接近、匹配甚至超过SOTA单模型的baseline，也能持平甚至超过Fugu商业版Collaborative Model的表现，同时始终维持一个干净的Model API接口。
用户看到的，就是一个模型名称。而系统在背后控制着路由配方，可以在不改动客户端的情况下快速接入新能力。开源模型和闭源模型，也能在同一个Router的指挥下参与协作。
Model Serving的边界，正在被改变
过去的serving stack是被动的：收到model name，把请求发给backend。
下一代的serving stack是主动的。它会问自己一系列问题：
这个请求有哪些特征？
它处在quality、cost、latency、safety哪个波段上？
单模型是否足够？
如果不够，应该运行哪种collaboration算法？
哪个output contract绝对不能破坏？
provider慢了、错了、格式坏了，该怎么回退？
如何给用户一个干净反馈，同时保留完整的trace？
这不是应用层的胶水代码。这是基础设施本身。
Micro-agent进入Router，是因为Router天然就站在Agent和Model之间。它掌握着一切路由所需的语义信息以及系统状态（KVCache、Load），充当系统的大脑去智能路由和调度模型，最终以OpenAI-compatible API的兼容语义暴露出去。
下一轮模型竞赛，必然还会有更强的大模型出现。但与此同时，也会出现更强大的Router：知道什么时候该省钱，什么时候该做安全升级，什么时候该留在边端，什么时候该去云端，什么时候把一次普通的API调用变成一支小而纪律严明的模型协作队伍。
这才是vLLM Semantic Router团队真正专注的方向。
