OpenRouter 把多模型投票这件事，塞进了 API 的一个参数里。一个提示词同时打给 1 到 8 个面板模型，judge 把它们的共识与分歧拎出来，最后交给你指定的调用模型落笔成稿。这套叫 Fusion 的复合推理系统，本质上是把"先问一圈再决定"这条人类早就摸熟的路子，固化成了基础设施。听起来简单，但魔鬼全在成本表和延迟曲线上。
一个提示词，同时问八个人
先说清楚它到底在做什么，因为"多模型"这三个字已经被用滥了，从路由到集成到投票，各说各话。
面板模型之间是互相看不见的
第一轮完全并行。八个模型各自拿到同一个提示词，各自独立作答，谁也看不到谁写了什么。这一点是整个设计的地基。如果改成串行，让第二个模型读第一个的答案再补充，成本会变成线性叠加，而且错误会像接力棒一样传下去——第一个模型的偏见会被后面所有人继承并放大。
并行则意味着每个回答都是一份独立样本。样本之间的差异，才是后面所有分析要吃的原料。
judge 更像个编辑，不是裁判
这是最容易被误读的一环。judge 不负责给最终答案，它做的是对比：哪些结论大家异口同声，哪些地方各执一词，分歧具体卡在哪个环节。
让 judge 直接拍板其实更省事，但那会造出一个新的单点——它自己也会错，而且它的错误没有第二道校验。把分歧全貌原封不动交给调用模型，等于把决策权还给那个你本来就在用、也最信任的模型。它现在多了一样东西：知道自己可能在哪儿翻车。
为什么是 1 到 8 这个区间
一个模型的面板毫无意义，那就是普通调用。两个能看出差异，但样本太薄，一次偶然的分歧就能带偏判断。三个是性价比的拐点，也是默认配置。
再往上加，收益掉得很快。主流模型吃的是高度重叠的语料，架构思路也趋同，它们撞在同一堵墙上的概率远比想象中高。第八个模型带来的增量信息，往往还不如把 judge 的提示词写细一点。
真正的收益不在共识里
三个模型同时答错的概率没那么低
很多人对多模型的第一反应是"投票取多数，少数服从多数"。但如果所有模型犯的是同一种错——比如同一个过时的 API 用法、同一段被广泛误读的论文结论——投票只会让你对这个错误更有信心。
所以 Fusion 把重心压在分歧识别上。共识部分基本可以快速带过，真正需要调用模型花力气处理的，是那几个互相矛盾的点。这也是它跟简单多数表决最本质的区别：不是找最响的那个声音，而是标记出哪里有问题。
DRACO 上的两个数字
在 DRACO 深度研究基准上，预算面板跑到 64.7%，前沿面板是 69.0%。这五个百分点的差距比绝对值更有意思。
它说明面板的质量天花板是由模型本身决定的，Fusion 是个放大器，不是补丁。拿便宜的模型凑一个八人面板，不会自动逼近前沿模型的单次回答。想往上走，还是得往面板里放更好的模型，或者换更强的 judge。
什么时候它几乎白花钱
有标准答案、有唯一正确解的任务，多模型的价值会被迅速榨干。格式转换、简单的信息抽取、结构化输出，一个够用的模型做一次就够了，跑八次纯属烧钱。
它真正起作用的地方，是那些"没有标准答案但有优劣之分"的任务——深度研究、方案权衡、长链条推理，以及需要跨领域知识拼接的复杂问题。这些任务里，不同模型的训练偏好会实打实地变现成分歧。
四到五倍的钱，两到三倍的等待
把账算实在
默认三模型面板，成本大约是单次完成的四到五倍，延迟两到三倍。为什么不是三倍成本？因为多了 judge 这一步的调用，还有最后的融合生成，这些都不便宜。
延迟更值得细看。理论上三个模型并行，耗时应该等于最慢的那个加上 judge 和融合的时间，大约两倍出头。实测落在两到三倍之间，差距来自排队、限流和不同厂商各自的响应抖动。
延迟往往比钱更贵
成本是可以预算的，延迟不行。在交互式产品里，两倍延迟意味着用户从"等一下"变成"这玩意儿卡住了"。三倍延迟意味着这个功能只能放进异步任务，做不了对话框里的实时回复。
这是 Fusion 落地时最硬的约束。不少团队算完钱觉得能接受，跑完延迟才发现产品形态得整个改。
三个省钱的抓手
别开满。把面板压到两三个，把省下的预算投给更强的 judge，通常比堆八个平庸模型更划算。
别全开。Fusion 没必要成为所有请求的默认路径。用一层轻量路由先判断请求复杂度，只让真正复杂的那些走复合推理，剩下的照常单次调用。这一刀切下来，整体成本曲线能压得很平。
别忘记缓存。同一批面板模型对相似提示词的回答高度重复，缓存命中率往往比预期高。
放进工程里，它是什么形状
适合它的三类活
深度研究类查询，需要交叉验证事实、拼接多源信息，分歧本身就是信号。高风险决策支持，比如合同条款分析、技术选型评估，错一次的代价远超几倍的 token 费用。还有开放式创作与方案设计，多个模型的不同切入角度本身就是产出的一部分。
不适合它的那些场景
实时对话、高频低价值的批处理、格式严格的结构化抽取——这三类占了生产环境请求量的大头，也恰恰是 Fusion 最不划算的地方。把复合推理当成默认开关，是最容易犯的错。
接下来该卷什么
现在这套机制的瓶颈不在模型数量，在 judge 的判断力。怎么把"共识"和"分歧"描述得更精确，怎么让调用模型知道该信谁多一点，这些提示工程层面的空间远没挖完。
另一个方向是动态面板。根据提示词的内容实时决定叫哪几个模型上场——代码问题叫这几个，医学问题叫那几个。这比固定八人面板聪明得多，也更省钱。多模型推理这条路上，真正的竞争可能才刚刚开始，而胜负手未必是谁能接入更多模型，而是谁更懂得在什么时候少叫几个人。
