完整文档索引见 llms.txt。 在任意 URL 后追加 `.md` 即可查看该页面的 Markdown 版本。
多模型推理流水线
多模型推理流水线是一种由多个模型协同工作、共同产出一个结果的系统。 你不会让单个模型包办一切，而是将工作拆分为多个阶段。 每个阶段都聚焦于特定任务，例如 retrieval、OCR、classification、 generation 或 post-processing。
这不同于在单个端点后面运行一个模型。它也不同于 pipeline parallelism, 后者是把一个模型拆分到多个设备上。这里的核心问题不是如何分布一个模型， 而是如何设计、部署和运营一个由多个模型在同一请求路径中协作的系统。
多模型流水线长什么样
最直观的理解方式是把它看作一条流水线。但在现实中，许多系统看起来更像是 一张 inference graph，而不是一条直线。有些阶段会并行运行， 有些请求会分叉到不同的下游路径，有些阶段则是可选的。
不同模式意味着不同权衡。
顺序流水线
这是最直接的搭建方式。每个阶段的输出都会传给下一个阶段。
Input → Stage A → Stage B → Stage C → Output
顺序流水线在概念上很简单，但延迟会逐层累加。如果每个阶段耗时 50 ms， 那么四个阶段在最终生成步骤开始之前，就很容易累积出数百毫秒的端到端延迟。
并行 fan-out / fan-in
在这种模式中，一个请求会同时发送给多个模型， 然后再对它们的输出进行合并、投票或评分。
示例包括：
- 集成预测（ensemble predictions）
- 运行多个候选生成器并选择最佳结果
- 在同一张图像上同时进行目标检测与分割
并行 fan-out 可以提升质量或覆盖范围，但也会增加总计算消耗。 即使延迟仍在可接受范围内，单请求成本也可能迅速上升。
条件路由
在这种模式中，前面的某个阶段会决定接下来发生什么。
示例包括：
- 一个小型 classifier 只把困难请求发送给更大的模型
- 一个语言检测器选择正确的下游模型
- 一个安全过滤器拦截或重定向不安全输入
这种方式可以节省成本并控制延迟，但前提是路由器足够可靠。 错误的早期决策会把请求送入错误路径，从而损害质量。
多模态流水线
这类系统会混合不同的数据类型，因此也会涉及不同类型的模型。
示例包括：
- Image encoder → language model
- Speech model → language model → moderation model
- Document parser → table extractor → language model
这里的核心挑战通常不只是模型质量， 而是如何在阶段之间传递并规范化中间数据，同时不制造瓶颈或脆弱接口。
为什么多模型流水线很重要
许多生产级 AI 应用本质上并不是单模型问题。一个大模型通常可以把多个任务都做得 还不错，但这并不意味着它就是每个阶段的最佳选择。
更契合的能力分工
不同模型针对不同任务做了优化。
- OCR 模型针对从噪声图像或 PDF 中提取文本做了优化。
- Embedding 模型针对语义检索做了优化。
- Reranker 针对相关性打分做了优化。
- 更小的 classifier 或 guard model 往往已经足以胜任路由、过滤或审核。
- 更大的生成模型则更适合保留给最终推理或响应综合。
这种分工通常比强迫单个模型覆盖所有阶段更有效。
更契合的硬件分配
并不是每个阶段都值得使用同样的硬件。
轻量级预处理或校验阶段可能在 CPU 上就能很好运行。 而 vision encoder、reranker 或大型生成器则可能需要 高性能 GPU。有些阶段很适合做 batch， 另一些则对延迟极其敏感，应尽量保持小而快。
这使团队能够把每个阶段放到最匹配其工作负载的硬件上， 而不是为了最昂贵的阶段而对整个流水线过度配置。
独立扩缩容
不同阶段通常具有不同的流量画像。retriever 可能运行成本低， 但会命中每一个请求；而大型生成器运行成本高，且可能只在过滤后的部分流量上运行。 当每个阶段都是独立可部署单元时，它就可以依据自己的信号 （queue depth、GPU utilization、concurrency）进行扩缩容， 而不是被最慢的组件绑定在一起。
更低的单请求成本
多阶段流水线为成本节省创造了空间，而这通常不是单模型容易复制的：
- 廉价的 classifier 或 router 可以只把困难请求发送给更大、更昂贵的模型。
- 轻量阶段可以运行在 CPU 或更小的 GPU 上。
- 更小的专用模型可以在狭窄任务上替代通用 LLM （例如 extraction、classification、moderation）。
但前提是流水线调优得当，否则这些节省并不会自然出现。 设计糟糕的流水线很容易比单体模型成本更高。
更快的迭代速度
多模型系统的模块化程度更高。如果 retrieval 阶段表现不佳， 你可以替换或重新调优它，而无需改动 generation 阶段。 如果最终模型太昂贵，你也可以在不重设计其余系统的情况下测试更小的替代方案。 这种局部迭代能力，正是团队采用 inference graph 而不是单体服务的原因之一。
什么时候不该使用多模型流水线
这个方向很容易被过度工程化。如果单个模型已经能满足需求，那就保持简单。 只有当额外阶段能带来明确价值时，它们才有意义。
在将工作负载拆成多个阶段之前，先问自己：
- 每个阶段是否都在解决一个单模型无法很好解决的独立问题？
- 这条流水线在质量、成本或可控性上的提升，是否足以证明新增复杂性是值得的？
- 延迟预算能否容纳额外的跳转和排队点？
- 随着模型演进，阶段之间的接口能否保持稳定？
- 独立扩缩容究竟真的能省钱，还是只会带来更多运维开销？
模型组合会带来真实成本：
- 需要部署更多服务
- 阶段之间需要维护更多契约
- 需要投入更多 observability 工作
- 会出现更多故障模式
- 需要进行更多端到端层面的调优
应先从满足需求的最小架构开始，只有当某个阶段明确证明自己有价值时， 再把它加进去。
示例架构
下面是一些非常适合采用多模型推理流水线的具体模式。
RAG 流水线
一个常见的 RAG 路径如下：
Query → Embed → Retrieve → Rerank → Generate → (Optional) Verify
每个阶段都有清晰职责：
- embedding 模型负责找到相似内容
- retriever 负责缩小搜索空间
- reranker 负责提升相关性
- generator 负责将这些证据转化为响应
- 最后的 verifier 或 citation checker 负责降低幻觉风险
文档 AI 流水线
一个文档工作流可能如下所示：
Document image → OCR → Layout extraction → Classify → Summarize → Structured Output
如果准确性、格式或可追溯性很重要，这种流程很难被单个模型替代。 OCR 和 layout extraction 与 summarization 是非常不同的任务。 其代价在于，大型中间产物可能会跨多个阶段流动，因此 payload 设计很重要。 如果输出需要直接交给另一个系统， structured outputs 可以让这种交接更易于维护。
多模态助手
多模态应用可能会先将图像、音频和文本分别送入独立 encoder， 然后再由下游语言模型使用组合后的信号。
这类系统通常是硬件专用化的典型案例。语音阶段、图像阶段和语言阶段 可能具有截然不同的运行时画像与扩缩容需求。
单模型 vs. 多模型流水线
不存在放之四海皆准的赢家。正确选择取决于哪一种约束对你最重要。
| 维度 | 单模型 | 多模型流水线 |
|---|---|---|
| 简单性 | 更简单 | 组成部分更多 |
| 延迟 | 通常更低 | 往往更高 |
| 硬件灵活性 | 有限 | 更高 |
| 独立扩缩容 | 有限 | 更强 |
| 专业化能力 | 有限 | 更强 |
| 运维负担 | 更低 | 更高 |
| 单阶段实验 | 更难 | 更容易 |
经验法则如下：
- 如果一个模型已经能满足产品需求，就先从一个模型开始。在决定组合多个模型之前， 先了解如何 选择合适的模型。
- 只有在阶段确实有帮助时才增加它们
- 尽可能保持阶段数量最少
常见问题
每个 RAG 系统都应该被视为多模型流水线吗？
从概念上说，是的，因为 retrieval、reranking 和 generation 是独立阶段。 但在运维上不一定如此。有些团队会把这些阶段封装在一个服务边界后面， 并将其视为一个可部署单元。关键在于，即使抽象看起来很简单， 你也要理解阶段级别的瓶颈。
所有阶段都应该放在一个服务里吗？
不一定。一个服务可以减少跳转延迟，并简化本地协调。 但如果不同阶段需要不同硬件、扩缩容策略、发布节奏或故障隔离， 那么拆分为多个服务会更合适。
多模型流水线能降低推理成本吗？
当小型专用模型能在大模型运行前完成过滤或路由， 或不同阶段能更高效地使用更便宜的硬件时，它们可以降低成本。 但设计糟糕的流水线也很容易起到相反效果。
这与 agentic workflow 有什么不同？
二者都会串联多个模型调用，但多模型流水线通常是你预先设计好的、相对固定的图。 而 agent 会动态决定调用哪些工具或模型、调用多少次，以及按什么顺序调用。 agent 可以看作是流水线这一思路的超集，具备更高灵活性， 但延迟和成本的波动也更大。如果你希望无论采用哪种方式， 阶段之间的接口都保持可预测， function calling 和 structured outputs 通常都是解决方案的一部分。