多模型推理流水线
多模型推理流水线(pipeline)是一个由多个模型协作产生一个结果的系统。与其让单个模型包办一切,你不如把工作拆分成多个阶段。每个阶段专注于一个特定任务,比如检索、OCR、分类、生成或后处理。
这与在单个端点后面运行一个模型不同。它也不同于流水线并行(pipeline parallelism)——后者是把一个模型拆分到多个设备上。在这里,核心问题不是如何分布一个模型,而是如何设计、部署和运维一个让多个模型在单条请求路径上协作的系统。
多模型流水线是什么样子的
最简单的想象方式是把它当作一条流水线。然而,许多真实系统看起来更像一张推理图(inference graph),而不是一条直线。有些阶段并行运行。有些请求分支到不同的下游路径。有些阶段是可选的。
不同的模式意味着不同的权衡。
顺序流水线
这是最直接的设置。每个阶段都馈入下一个阶段。
Input → Stage A → Stage B → Stage C → Output
顺序流水线在概念上很简单,但它们的延迟会累加。如果每个阶段耗时 50 毫秒,四个阶段很容易在最终生成步骤开始之前就变成几百毫秒的端到端延迟。
并行扇出 / 扇入
在这种模式中,一个请求同时发送给多个模型。然后它们的输出会被合并、投票或评分。
示例包括:
- 集成(ensemble)预测
- 运行多个候选生成器并选择最佳结果
- 在同一张图像上结合目标检测与分割
并行扇出可以提高质量或覆盖率,但它会增加总计算量。即使延迟保持在合理范围,每次请求的成本也会快速上升。
条件路由
在这种模式中,早期阶段决定接下来发生什么。
示例包括:
- 一个小型分类器只把困难请求发送给更大的模型
- 一个语言检测器选择正确的下游模型
- 一个安全过滤器阻止或重定向不安全的输入
这可以节省成本并保护延迟,但前提是路由器必须可靠。一个糟糕的早期决策可能把请求送错路径并损害质量。
多模态流水线
这些系统混合不同的数据类型,因此也混合不同的模型类型。
示例包括:
- 图像编码器 → 语言模型
- 语音模型 → 语言模型 → 审核模型
- 文档解析器 → 表格提取器 → 语言模型
这里的关键挑战通常不仅仅是模型质量,而是如何在各阶段之间移动和规范化中间数据,而不制造瓶颈或脆弱的接口。
为什么多模型流水线很重要
许多生产 AI 应用实际上并不是单模型问题。一个大型模型往往可以相当不错地完成多项任务,但这并不意味着它是每个阶段的最佳选择。
更好的能力匹配
不同的模型针对不同的任务进行优化。
- OCR 模型针对从嘈杂图像或 PDF 中提取文本进行了调优。
- 嵌入(embedding)模型针对语义检索进行了调优。
- 重排器(reranker)针对相关性评分进行了调优。
- 较小的分类器或护栏(guard)模型往往足以胜任路由、过滤或审核。
- 较大的生成式模型最适合留给最终推理或响应合成。
这种分工往往比强迫一个模型在每个阶段都硬撑更有效。
更好的硬件匹配
并非每个阶段都值得使用相同的硬件。
一个轻量级的预处理或校验阶段可以在 CPU 上运行得很好。一个视觉编码器、重排器或大型生成器可能需要高性能 GPU。有些阶段很适合批处理,而另一些对延迟高度敏感,应该保持小而快。
这让团队可以把每个阶段放在与其工作负载相匹配的硬件上,而不是围绕最昂贵的阶段过度配置整个流水线。
独立扩展
不同的阶段通常有不同的流量特征。一个检索器可能运行成本低,但每个请求都会被命中;而一个大型生成器成本高昂,可能只在过滤后的一部分流量上运行。当每个阶段都是独立可部署的单元时,它就可以根据自身的信号(队列深度、GPU 利用率、并发数)进行扩展,而不是与最慢的组件耦合在一起。
更低的每次请求成本
多阶段流水线为单模型难以复制的成本节约创造了空间:
- 一个便宜的分类器或路由器可以把只有困难的请求发送给更大、更贵的模型。
- 轻量级阶段可以在 CPU 或更小的 GPU 上运行。
- 较小的专用模型可以替代通用 LLM 来处理窄任务(提取、分类、审核)。
这些节约只有在流水线调优良好的情况下才会显现。一个设计糟糕的流水线很容易比一个单体大模型花费更多。
更好的迭代速度
多模型系统更模块化。如果检索阶段表现不佳,你可以在不改变生成阶段的情况下替换或重新调优它。如果最终模型太贵,你可以在不重新设计系统其余部分的情况下测试一个更小的替代方案。这种局部迭代是团队采用推理图而不是单体服务的原因之一。
什么时候不该使用多模型流水线
这很容易被过度设计。如果单个模型已经满足你的需求,那就保持简单。额外的阶段只有在它们带来明确价值时才有意义。
在把工作负载拆分成多个阶段之前,问问自己:
- 每个阶段是否解决了一个单模型无法足够好地解决的独特问题?
- 流水线是否在质量、成本或控制上带来足够大的改进,以证明增加的复杂性是值得的?
- 延迟预算能否吸收额外的跳数与排队点?
- 随着模型演进,阶段之间的接口能否保持稳定?
- 独立扩展真的能省钱,还是只会制造更多运维开销?
模型组合是要付出真实代价的:
- 需要部署更多服务
- 阶段之间有更多约定
- 需要更多可观测性工作
- 更多故障模式
- 端到端层面需要更多调优
从满足需求的最小架构开始,然后只在阶段明确证明其价值时才添加。
示例架构
这里有几个多模型推理流水线非常契合的具体模式。
RAG 流水线
一条常见的 RAG 路径看起来像这样:
Query → Embed → Retrieve → Rerank → Generate → (Optional) Verify
每个阶段都有明确的角色:
- 嵌入模型找到相似内容
- 检索器缩小搜索空间
- 重排器提高相关性
- 生成器把证据转化为响应
- 最终的验证器或引用检查器降低幻觉风险
文档 AI 流水线
一个文档工作流可能看起来像这样:
Document image → OCR → Layout extraction → Classify → Summarize → Structured Output
当准确性、格式或可追溯性很重要时,很难用单个模型替代这个流程。OCR 和版面提取与摘要总结是非常不同的任务。权衡之处在于,大型中间产物可能会跨多个阶段移动,所以载荷设计很重要。如果输出需要直接馈入另一个系统,结构化输出(structured outputs)可以让这种交接更易于维护。
多模态助手
一个多模态应用可能将图像、音频和文本分别路由到各自的编码器,然后由下游的语言模型使用合并后的信号。
这些系统往往是硬件专用化的典型例子。语音阶段、图像阶段和语言阶段可能具有非常不同的运行时特征和扩展需求。
单模型 vs. 多模型流水线
没有放之四海而皆准的赢家。正确的选择取决于哪个约束最重要。
| 维度 | 单模型 | 多模型流水线 |
|---|---|---|
| 简单性 | 更简单 | 更多活动部件 |
| 延迟 | 通常更低 | 通常更高 |
| 硬件灵活性 | 有限 | 更高 |
| 独立扩展 | 有限 | 更强 |
| 专用性 | 有限 | 更强 |
| 运维负担 | 更低 | 更高 |
| 单阶段实验 | 更困难 | 更容易 |
作为经验法则:
- 如果单个模型已经满足你的产品需求,就从一个模型开始。在决定组合多个模型之前,先学会如何选择合适的模型。
- 当阶段明确有帮助时再添加
- 尽可能保持阶段数量最少
常见问题(FAQ)
每个 RAG 系统都应该被视为多模型流水线吗?
从概念上讲,是的,因为检索、重排和生成是独立的阶段。从运维上讲,不总是。有些团队把这些阶段打包在一个服务边界后面,把它们当作一个可部署单元。重要的是理解阶段级瓶颈,即使抽象看起来很简单。
所有阶段都应该放在一个服务里吗?
不总是。单个服务可以减少跳转延迟并简化本地协调。当不同阶段需要不同的硬件、扩展策略、发布节奏或故障隔离时,独立的服务更好。
多模型流水线能降低推理成本吗?
当小的专用模型在大型模型运行之前过滤或路由请求时,或者当不同阶段更有效地使用更便宜的硬件时,它们可以降低成本。然而,糟糕的流水线设计很容易适得其反。
这与智能体(agentic)工作流有何不同?
两者都串联了多次模型调用,但多模型流水线是你在事前设计好的、基本固定的图。智能体则动态决定调用哪些工具或模型、调用多少次、以什么顺序。智能体是流水线思想的超集,具有更多灵活性,也在延迟和成本上有更多波动。如果你希望任何一种设置的阶段接口保持可预测,函数调用(function calling)和结构化输出(structured outputs)往往就是解决方案的一部分。