模型合议（Model Ensembles）：多个低成本模型，合成一个更好的答案

更新时间 6/17/2026

为一个困难的问题挑选模型，本质上是一场赌博。前沿模型准确，但又贵又慢；便宜的模型快，却时常一本正经地答错。大多数团队只能二选一，然后接受这个取舍。

模型合议（Model Ensemble） 让你不必再选。今天我们在 AISIX AI 网关 中推出模型合议——一种新的虚拟模型类型：它把同一个问题并行发给多个模型，再由一个“评审”模型把它们的答案综合成一个。你像调用任何普通模型一样调用它，剩下的交给网关。

什么是模型合议？

模型合议是一个对调用方可见的模型名：它把一次 /v1/chat/completions 请求并行分发给一组配置好的**合议组（panel）模型，再用一个评审模型（judge）**把它们的答案综合成最终的唯一响应。分发与综合全部在网关服务端完成——你的客户端只发一次请求、收一个答案，走的还是你已经在用的 OpenAI 兼容 API。

术语含义
合议组（panel）并行、各自独立作答的一组模型。两个或更多，可混用不同厂商。
评审模型（judge）读取合议组的所有答案，并写出调用方最终收到的那个答案。
合议模型把“合议组 + 评审”绑定在一起、对外可见的别名。客户端按名字调用，永远看不到合议组。

它是 AISIX 中的第三种虚拟模型，与直连模型（direct，一个别名 → 一个上游）和路由模型（routing，一个别名 → 由策略选中的一个目标）并列。区别在于：路由模型每次请求只挑一个模型，而合议模型会调用全部模型并把结果合成。这正是网关从“代理”走向 智能编排器 的体现，而不止于转发。

为什么多个便宜模型能胜过一个昂贵模型

合议背后的道理很朴素：相互独立却一致的答案，更可能是对的；而当它们分歧时，评审模型可以裁决——保留某个模型给出的、有充分依据的洞见，丢掉另一个模型臆造的内容。在困难的推理和研究型问题上，一组更小、更便宜的模型经评审综合后，可以逼近你原本要为单个前沿模型支付的答案质量。

这把一个采购决策，变成了一个配置决策：

  • 降低单模型的方差与盲区。 没有任何单一模型是瓶颈。某个模型“发挥失常”会被其余模型投票否决，并被评审模型纠正。
  • 对困难任务交叉验证。 不同模型用不同路径得到答案；它们之间的共识，比任何单一思维链都是更强的信号。
  • 把钱花在刀刃上。 用三个便宜模型加一个便宜评审，替代一个高端模型——同样的 OpenAI 兼容调用，不一样的成本/质量平衡点。

它不是免费的。一个 N 成员的合议，每次请求会产生 N + 1 次上游调用，因此比单个直连模型更贵、延迟更高——首 Token 延迟（TTFT）大致是 max(合议组延迟) + 评审时间。合议适用于高价值、能容忍延迟的流量，即答案质量比省下最后几分钱、几毫秒更重要的场景——而不是自动补全或输入联想。

自合议：用一个厂商密钥获得多样性

你并不需要和多家厂商签约才能受益。自合议（self-ensemble） 是把同一个模型用不同的采样参数调用多次——每个合议成员有自己的 temperature 和 seed——于是一个厂商密钥就能产生一个多样化的合议组，再由评审模型统一裁决。这是上手合议成本最低的方式：把合议组指向一个你已经在用的模型，改变采样参数，再加一个评审。

工作原理

  1. 客户端向合议模型的名字发送一次请求——一个普通的 OpenAI 兼容对话调用。
  2. 网关把提示词并行分发给每个合议成员，并应用各自的 temperature/seed。
  3. 当足够多的成员作答后（见 min_responses），网关用原始请求加上合议组的答案构造一个综合提示词，并调用评审模型。
  4. 调用方收到评审模型综合后的唯一答案——以合议模型的名字返回，绝不暴露某个合议成员。

对任何要把它接入应用或 Agent 的人来说，有两条契约很重要：

  • 对外身份保持不变。 response.model 始终是合议模型的别名——绝不会是某个合议成员、评审模型，或上游厂商的原始模型 id。合议组的构成是实现细节；综合后的答案永远不会提及是哪些模型产生的。
  • 用量是真实的聚合成本。 响应里的 usage 对象是每次合议组调用加评审的总和——所以你看到的成本反映了整个扇出过程（它的 prompt_tokens 会有意地超过你实际发送的量）。若要更细的分析，网关还会为每个子调用各发一条用量事件，标注为 panel 或 judge，这样单次请求的明细会出现在你的日志里。

流式同样支持：合议组在服务端汇聚后，评审模型的 token 流式返回给调用方——所以你能在扇出之上保留流式体验。

几行配置即可

一个合议引用已有的直连模型：一个合议组、一个评审，再加几个参数。通过 AISIX Admin API：

1{
2  "display_name": "council-of-three",
3  "ensemble": {
4    "panel": [
5      { "model": "kimi-k2",      "temperature": 0.7 },
6      { "model": "deepseek-v3",  "temperature": 0.7 },
7      { "model": "gemini-flash", "temperature": 0.9 }
8    ],
9    "judge": { "model": "deepseek-v3" },
10    "min_responses": 2,
11    "timeout_ms": 45000
12  }
13}
字段作用
panel[].model合议组调用的一个直连模型（重复填同一个即为自合议）。
panel[].temperature / seed每个成员的采样参数——多样性的来源；会覆盖请求里的 temperature。
judge.model综合出最终答案的模型。以固定的低温度（约 0.2）运行以保持输出稳定；可选的 synthesis_prompt 覆盖默认模板。
min_responses评审运行前需要多少个合议组答案。只要达到这个数量，请求就能容忍某个缓慢或失败的成员。
timeout_ms每个合议成员和评审的单次调用超时。

在 AISIX Cloud 中，你可以在控制台的 Models 页面搭出同样的东西——一个合议组选择器、一个评审选择器，以及每个成员的参数——并且每个合议成员和评审都各自保留自己的限流，所以一个合议不会悄悄地以 N 倍速率烧掉某个厂商的配额、绕过你配置的上限。之后调用方就像使用任何其他模型名一样使用 council-of-three。

v1 交付范围

模型合议现已可用——在 AISIX Cloud 和开源版 AISIX 网关上都可使用。这个首版有几条有意为之的边界：

  • 仅支持对话补全。 合议运行在 /v1/chat/completions 上。携带 tools（或强制 tool_choice）的请求会被 400 拒绝——把一次工具调用广播给 N 个模型，会得到 N 个客户端无法调和的冲突结果。工具类请求请用直连或路由模型。
  • 仅限直连模型。 合议成员和评审必须是同一环境中的直连模型；合议不能嵌套在合议或路由组里。
  • 配置驱动。 合议组由运维方维护；不支持按请求覆盖合议组。客户端只能通过模型名选择一个合议。

常见问题

在 AI 网关里，什么是模型合议？

它是一个虚拟模型：把一个提示词同时发给多个 LLM（合议组），再用另一个 LLM（评审）把它们的答案合并成一个。扇出与综合都在网关服务端完成，所以客户端只发一次 OpenAI 兼容请求、收到一个答案。

合议会比只调用一个模型更贵吗？

会。一个 N 成员的合议会产生 N + 1 次上游调用（合议组加评审），因此更贵、延迟更高。网关会上报聚合用量，使成本透明。请把合议用于高价值、能容忍延迟的提示，而不是高并发的廉价流量。

我能用一个厂商密钥跑合议吗？

能——这就是自合议。把合议组用不同的 temperature/seed 多次指向同一个模型，你就能得到一个多样化的合议组和一个经评审裁决的答案，无需接入新厂商。

合议的 token 用量和成本怎么计？

面向客户端的 usage 对象是每次合议组调用加评审的总和，所以 prompt_tokens 和 total_tokens 反映了完整的扇出。网关还会为每个子调用各发一条用量事件（标注 panel 或 judge），供你在日志里看单次请求的明细。

合议模型是 OpenAI 兼容的吗？

是。你通过标准的 /v1/chat/completions API 按模型名调用它，得到一个标准的对话补全——包括流式。无需改 SDK；合议组和评审对调用方不可见。

合议和模型路由 / 故障转移有什么区别？

路由和故障转移每次请求只挑一个目标（一个主选，或主选失败时的备选）。合议会调用每一个合议成员，并把它们的答案综合成一个。路由优化的是韧性和流量调度；合议优化的是答案质量。

开始使用

模型合议是 AISIX AI 网关 的一部分。定义一个合议组和一个评审，把你已有的 OpenAI 兼容客户端指向合议模型的名字，然后在你最难的提示上，把综合后的答案和你现有的单模型方案对比一下。

延伸阅读

微信咨询

获取方案