多模型协同:如何实现模型之间的协同和集成

单个模型跑通 demo 不难，难的是上线后遇到某类任务效果不稳、某家接口限流或变慢、成本越滚越高。这时候通常不是换一个更强的模型，而是把几个模型编排成一条链路。这篇讲常见协同模式、路由判断依据、集成时要盯的几项指标，以及一版可以照着走的落地顺序，最后给一份出问题时的排查清单。

单个模型跑通一个 demo 不难，难的是上线以后开始出各种意料之外的问题：某类任务效果一直不稳，某一家的接口偶尔限流或者整体变慢，账单一个月比一个月高。这时候很多人的第一反应是换一个更强的模型，但更常见的正确做法，是把几个模型编排成一条链路，各管各的一段。

这篇讲的是多模型协同的工程做法：什么时候该上、有哪几种主流编排模式、路由判断依据怎么定、集成层要盯哪几项指标、以及一版可以照着走的落地顺序和排查清单。全程只讲判断标准和动作，具体数字不写死，需要时去站内对应页面看当时的情况。

先判断你到底该不该上多模型

多模型协同不是默认选项，它是为了解决具体问题才引入的复杂度。上来就拆成五个模型互相调用，往往先把自己拖垮。先看有没有下面这三种信号，再决定要不要动。

• 信号一：单一模型在某个子任务上反复翻车，比如长文档摘要还行、但结构化字段抽取总是漏项，换提示词也压不下去。
• 信号二：单一供应商的限流或可用性直接影响到线上，一次波动就整条业务不可用。
• 信号三：不同任务对成本和延迟的要求差得远，用同一个模型既浪费又不够快。

反过来也有明确不适用的场景：任务类型很单一而且效果已经达标；团队手上还没有稳定的评测手段，改了什么好不好根本看不出来；调用量太小，运维这条链路的成本比省下来的还高。这几类情况下，把单模型的提示词和参数调好，收益更大。

主流编排模式：串行、并行、投票与级联

编排模式基本就那几种，关键是根据场景选对，而不是全上。下面这张表把四种模式的适用场景、代价和不太适用的情况对照一下，选之前先看一眼。

串行流水线是最容易上手的：上一个模型的输出经过校验，再作为下一个的输入。并行加聚合适合「宁可慢也要稳」的场景。级联的思路是先走便宜快的模型，达不到阈值再升级，能省掉大部分高成本调用。投票则靠多模型结论的一致度判断可信度，代价最大。

• 先用串行把链路跑通，验证每个环节的输出格式稳定。
• 再引入级联，定义清楚什么条件下升级到更强的模型。
• 投票类模式最后再考虑，先用离线评测确认它真的能提升判断质量。
• 任何模式都要在链路上留观测点，否则出问题不知道是哪一段。

路由怎么定：按任务、按长度还是按质量档位

路由是多模型协同里最容易做乱的一块。常见做法是先按最粗的维度分流，再在每一路内部做细分。三种常见路由键：任务意图分类的结果、输入长度是否超出某一档上下文、是否需要严格的结构化输出。

1. 先写规则路由用明确的判断条件分流，比如意图分类命中某类就走某个模型。规则路由跑通之前不要考虑学习型路由。
2. 再考虑软路由用一个小模型做意图分类，把分类结果作为路由依据。前提是分类本身的准确率你测过。
3. 给每条路由写兜底路由判定失败、或者目标模型不可用时，明确走哪个默认模型，别让请求悬在那里。
4. 集中管理配置所有路由规则放到一个配置文件里，别散落在各个业务模块，换模型时才会省事。

判断依据里最容易忽略的是「不适用」：如果任务类型本身就模糊、边界不清，规则路由会频繁误判，这时候要么先把任务分类做扎实，要么干脆退回到单一模型加好后处理。

集成层怎么搭：统一接口、配置与日志

协同一旦超过两个模型，各家字段名、鉴权方式、错误码都不一样，业务代码里到处是 if-else。解决办法是做一层薄封装：对外只暴露统一的入参出参，把差异都收在这一层。

统一接口

对外只认一套请求和响应结构，供应商差异在封装层内部消化。

配置化模型标识

模型、版本、参数写进配置，换模型时只改配置，业务代码不动。

结构化日志

每次调用记请求标识、命中的路由、实际模型、耗时、用量、是否走了兜底。

站内参考

去 /stacks/frameworks 和 /stacks/agent-apis 看现成的框架与接口清单，能省掉不少重复造轮子。

日志字段这件事别省。至少要能回答：这次请求走了哪条路由、实际调用了哪个模型、花了多久、用了多少 token、有没有触发兜底。没有这几个字段，后面链路变慢或者变贵，你只能猜。

成本与延迟：多模型的账怎么算

每多一次调用，就多一份延迟和费用。级联和投票这两种模式尤其要算清楚：省下的钱到底抵不抵得上多出来的开销。算账的时候别凭感觉，把每条路径的用量和单价乘出来对照。

• 按场景设延迟预算：交互式问答和离线批处理能容忍的等待时间差很多，路由策略要跟着分。
• 级联模式先估升级比例，比例太高等于全量走贵模型，反而更贵。
• 投票模式默认成本成倍增长，除非判断质量确实需要，否则不要上。
• 用站内 /tools/model-cost-calculator 先把账估一遍，再决定路由怎么切。

有一点必须提醒：具体单价和用量数据是变动的，这里不写死任何数字。要对比当时的实际价格，去 /official-api 和 /usage 核对当时的数字，别拿几个月前的旧数做决策，那比不算账还危险。

失败兜底与可观测性：路由挂了怎么办

多模型链路的失败种类比单模型多，笼统地「加重试」解决不了问题。先把失败分类，不同类用不同策略，再谈监控。

重试要设上限并加退避，限流时连续重放只会让情况更糟。跨供应商做兜底，要提前把参数和数据格式映射好，否则切过去请求直接报错，兜底等于没有。

• 给链路上每个环节单独记成功率，同时看整条链路的成功率，才能定位是哪一段拖后腿。
• 区分单模型故障和路由判定错误：前者是可用性问题，后者是策略问题，处理方式不同。
• 用 /tools/quality-monitor 与 /ai-status 看长期趋势，别只盯单次报警。
• 兜底触发比例本身就是个信号，长期偏高说明主路径选得不对。

上线顺序与验收清单

多模型协同不要一次性全上，按下面的顺序推进，每一步都有可验证的产物。没通过这一步就先别往下走。

1. 跑单模型基线在真实样本上分别跑每个候选模型，拿到每个子任务的效果和延迟基线。没有基线，后面没法判断协同到底有没有用。
2. 先上串行链路把最明确的依赖关系做成串行流水线，验证每个环节输出格式稳定、错误能归因。
3. 再引入级联在串行链路上叠加级联，明确升级阈值，观察升级比例是否在合理范围。
4. 最后考虑投票只有在判断质量确实不足、且延迟和成本可以接受时，才引入投票类模式。
5. 留回退开关配置里留一个能一键切回单模型的开关，新路由出问题时不用改代码重发。

验收看四项指标：链路整体成功率、P95 延迟、单请求平均成本、兜底触发比例。这四项的具体目标值不写死，依据业务场景和站内当时的数据来定，去 /usage 和 /tools/model-cost-calculator 对照当时的数字。

换模型与迁移时要注意的几件事

协同链路上换掉任意一个模型，影响都不止那一个环节。除了常规的迁移动作，还有几件协同特有的事要做。

• 换模型后重跑整条链路的评测样本，接口兼容不代表输出风格和格式兼容。
• 检查提示词模板是否还和新模型匹配，为旧模型调过的提示词直接搬过去常常出问题。
• 确认许可证与商用边界，跨供应商组合时逐家核对，参考 /safety 和站内模型库的授权信息。
• 验证路由判定是否仍然成立，换了模型以后原来的升级阈值可能已经不合适。

迁移的整体思路站内已有文章讲过，这里只补协同场景特有的部分：路由和兜底策略要跟着模型一起迁移，别只换了模型标识就以为完事了。判断标准是——换完之后，链路整体成功率、延迟和兜底比例这三项没有明显退化。