vLLM 语义路由器引入 Fusion：从「选一个模型」到「组合一支团队」

起因：为什么现在聊「多模型协作」？

过去几年，部署 AI 系统的核心问题是「选哪个模型」。但随着模型生态爆炸式增长——有便宜快速的小模型、擅长推理的大模型、本地部署的私有模型、以及各种云端 API——生产系统面对的已经不是一道单选题，而是一个组合优化问题。vLLM 语义路由器（Semantic Router）团队最近发布的 Fusion 原语，正是试图把「用多个模型协作回答一个问题」这件事工程化、策略化、可观测化。

而 OpenRouter 刚刚在同一方向上做了公开验证：在 DRACO 深度研究基准上，用多个模型组成面板（panel）再综合答案的 Fusion 配置，跑赢了任何单一模型。这不是实验室的玩具实验，而是线上服务的真实信号。这说明模型组合正在从离线研究 idea 变成可用的线上服务模式。

拆解：Fusion 到底做了什么？

Fusion 的流程可以拆成四步，非常直观：

1. Panel（评审团）：把同一个请求发给多个模型，让它们各自独立生成答案。注意「独立」是关键——不是把第一个模型的回答塞给第二个模型，而是并行地各自跑一遍。

2. Judge（裁判）：用一个裁判模型来分析这些答案之间的共识、矛盾、各自的独到见解和盲区。你可以把它理解为一个「元评审」，它不直接回答问题，而是评估回答的质量。

3. Synthesis（综合）：基于裁判的分析，生成一个最终的、面向用户的答案。

4. Trace（追踪）：记录哪些模型参与了、裁判做了什么判断、最终是怎么综合的。这一步对运维和调优至关重要。

但这里有一个关键区别：Fusion 不是一个固定的 API 端点，不是一个你调了就永远走多模型路径的东西。它是 vLLM 语义路由器里的一个可编程策略。路由器会根据请求的信号（复杂度、领域、安全要求等）来决定：这个请求值不值得走 Fusion 路径？如果只是个简单问题，直接扔给便宜快速的单模型就够了。只有当多模型协作确实有价值时，才启动 Fusion。这就是所谓的「模型质量不只是 checkpoint 的属性，更是服务系统的属性」。

趋势洞察：模型组合正在成为一等公民

这件事揭示了一个更深层的趋势：AI 推理正在从「选模型」走向「编排模型」。

想想看，传统做法是你选定一个模型，然后所有请求都打到这个模型上。但实际上，不同的请求适合不同的模型——简单翻译用小模型就够了，复杂推理需要大模型，敏感数据要走本地模型。vLLM 语义路由器的方向就是让路由本身变得智能：不只是负载均衡，而是语义级别的智能调度。

Fusion 把这个思路又推进了一步：不只是在多个模型之间选一个最好的，而是让多个模型都跑一遍，然后综合出比任何单个模型都更好的答案。这有点像人类的专家委员会制度——不是让一个专家做所有决定，而是让一群专家各自发表意见，再由一个主持人综合判断。

OpenRouter 的 DRACO 数据很有说服力：Fusion: Fable 5 + GPT-5.5（Opus 4.8 综合）拿到 69.0%，而单跑 Claude Fable 5 只有 65.3%。这个提升不是来自更好的模型，而是来自更好的模型组合策略。

实用价值：对开发者意味着什么？

如果你在做 AI 产品，这个方向值得持续关注。短期内，你可能不需要自己实现 Fusion，但需要开始思考：你的系统是不是只绑定了一个模型？你的路由逻辑是不是足够智能？你有没有能力在需要的时候用多模型协作来提升质量？

对于已经在用 vLLM 的团队来说，Fusion 提供了一个把模型组合工程化的路径——它把 panel、judge、synthesis 这些环节都变成了可配置、可观测的原语，而不是需要你自己拼接的 ad-hoc 逻辑。

反常识的一点：很多人直觉上认为多模型协作一定会大幅增加延迟和成本。但实际上，由于 Fusion 只在路由器判断「值得」时才启动，大部分请求仍然走快速的单模型路径。真正增加开销的只是那些复杂、高价值的请求——而这恰恰是你最不希望出错的场景。用合理的成本换取更高的质量上限，这可能才是正确的权衡方式。

原文地址: Beyond One Model: Fusion in vLLM Semantic Router