如何在单张 GPU 上服务 5 个模型（100% 开源）

真正的人工智能流水线很少只运行一个模型。本文展示如何通过一个服务层，在单张 GPU 上同时服务一个 SLM、一个 OCR 模型、一个 NER 模型、一个重排序器和一个目标检测器。

小模型正在改变 AI 系统的构建方式。

生产级 AI 系统正在从“一个大型模型做所有事”转向“多个较小模型，各司其职”。

一个解析文档，下一个提取字段，第三个对搜索结果重排序，一个视觉模型读取图像，最后一个模型负责生成。

在模型层面，这样做通常能显著降低成本。

但模型只是推理账单的一部分。你仍然需要 GPU 来运行它，需要内存来保持加载，还需要一个服务层来对经过它的请求进行批处理和调度。

如果你不想自己运维这套基础设施，你可以把它交给托管服务商。

当你希望快速起步时，这确实有效，但账单会随着你的成本与供应商使用量挂钩而不断增长。而且你还放弃了对自己能运行哪些模型以及数据流向哪里的控制。

对于需要在模型、数据和基础设施上拥有更强控制力的团队来说，自托管是自然的选择。

虽然单个小模型在自托管中很容易满足，但真实的业务问题很少止步于一个模型。

专用模型被设计成只把一件狭窄的事情做好。你需要多个模型，每个处理自己那部分工作，然后拼接成一条完整的业务流水线。

现在，基础设施必须让所有这些模型保持可用并服务它们。

你通过改用小模型省下了钱。而服务它们的方式可能把这笔节省又还回去。

今天，我们来理解为什么会这样，以及究竟怎样才能把小模型服务好。

如何阅读本文

分为两半：先讲 GPU 服务实际是如何工作的，然后是一条端到端运行的流水线。

想要代码？直接跳到“用真实文档验证”。五个调用可独立运行。

但前半部分是你可以在任何地方复用的内容。内存分配、批处理与填充浪费、队列隔离、加载与驱逐策略：这些才是决定你 GPU 账单的参数，无论你最终跑的是哪个引擎。了解它们，是“选择”一套服务栈和“继承”一套服务栈之间的区别。

注意，共享一张 GPU 并不意味着五个模型同时驻留内存。模型按需加载，内存不足时被驱逐。

接下来要讲的内容：

• 多模型流水线中的服务工具。 vLLM 和 TEI 各自解决什么问题，以及为什么五个阶段会碎片化地分布在三个服务器上。

• 标准服务工具的问题。 专用 GPU 或共享 GPU、你为之付费的空闲时间，以及决定这一切的内存旋钮。

• 小模型服务栈需要什么。 在点名任何工具之前，先列出四个需求。

• Superlinked Inference Engine。 三个原语，以及底下发生的五件事。

• 用真实文档验证。 一份洪水保险理赔，依次经过 docling、GLiNER2、重排序器、Grounding DINO 和 Qwen3.5。

• 自己运行。 Notebook、配置，以及如何在单张或两张 GPU 上放置模型。

多模型流水线中的服务工具

大多数生产级智能体系统并不是只跑在一个模型上。它们使用多个较小的专用模型，每个处理一种不同的计算类型。

因为这些模型的工作方式不同，服务层通常也会随工作负载而变化。

两个常见例子是 vLLM 和 TEI。

LLM 是一个接一个地生成 token，而每个新 token 都需要访问之前 token 的信息。这段历史被保存在一种叫做 KV cache 的结构中。

vLLM 围绕高效管理这段内存而构建，使用一种称为 PagedAttention 的技术，让 GPU 能够处理大量生成请求，而不会浪费大块内存。

嵌入模型和重排序器没有这个问题。它们一次性读取输入，然后返回一个向量或一个相关性分数；不存在逐 token 的生成过程。

这正是 Hugging Face 的 Text Embeddings Inference（TEI）所适用的场景。

它专为嵌入和重排序工作负载而构建，这些场景中请求可以通过简单的批处理来处理，而不需要生成阶段所用的 KV-cache 机制。

然后还有一切不属于这两类的负载。

文档解析、OCR，以及许多视觉或抽取模型都不符合上述任何一种服务模式。因此，Docling、Grounding DINO 和 GLiNER 这类模型通常最终被放在各自的自定义服务器后面。

这就是多模型流水线最终变得碎片化的原因。你有一个模型跑在 vLLM 上，另一个跑在 TEI 上，其余则通过自定义 API 处理。

以一份正在走审核流程的洪水保险理赔为例：

读取文档 → 提取理赔细节 → 匹配正确的保单条款 → 检查洪水损坏照片 → 撰写摘要

在碎片化方案下，这五个工作负载通常会变成多个独立管理的服务组件。

标准服务工具的问题

一旦智能体流水线开始使用多种模型类型，多框架的服务问题也会变成硬件问题。

尽管流水线依赖于 vLLM、TEI 和自定义服务器的组合，而且每个工具在其擅长领域都表现出色，但真正的挑战在于决定这些模型实际应该在哪里、以何种方式运行。

这留下了两种实际可行的安排方式：给每个服务栈分配一张自己的 GPU，或者把几个模型放在同一张卡上。

不幸的是，在当今标准的 AI 服务工具下，这两种方案都不太干净利落。

1. 给每个模型一张专属 GPU

最简单的方案是给每个服务栈一张属于自己的 GPU。不需要管理资源共享，每个服务都能获得它所需的硬件。

vLLM 在一张 GPU 上处理主 LLM，TEI 获得另一张用于嵌入和重排序，而你的文档处理、NER 和视觉模型则各自拥有专用 GPU。

虽然这种方案在运维上可行，但问题在于 GPU 成本和利用率。

以我们之前的洪水保险理赔流水线为例，工作按以下顺序进行。

关键在于，单个理赔是顺序通过这些阶段的，因此每张专用 GPU 都有大量时间在等待轮到自己。

跨多个理赔时，这些工作负载可以重叠，但这仍然不意味着每张专用 GPU 都能一直保持良好利用。

因此，如果每个阶段都有自己的专用 GPU，那么当重排序器运行时，运行文档解析器的 GPU 就处于空闲状态。然后，当 LLM 运行时，重排序器又在等待。

这张空闲的 GPU 并不会被释放或转交给其他任务。服务进程仍然运行在它上面，因此硬件在整个过程中始终被分配给这一个阶段，无论它是否在做任何事。

这是一个实实在在的预算问题，因为 GPU 基础设施是按你持有的时间付费的，而不是按 GPU 实际计算的秒数付费的。

此外，这些专用模型中有许多足够小，根本不需要一整张专用 GPU。

一个抽取模型、重排序器或小型视觉模型只会用到 L4 GPU 24 GB 内存的一小部分，同时还有大量时间在等待工作。

因此，增加更多 GPU 会让账单变高，同时每张卡上还有容量被闲置。

还记得你的流水线最初是从多个专用模型开始的吗？当你添加更多步骤时，每一项新能力都会要求自己的服务进程和另一张专用 GPU，很快你就会发现硬件数量失控。

你改用更小的模型是为了减少每个任务所需的硬件。而现在，硬件数量却随着你添加的每个新任务而增长。

2. 在单张 GPU 上容纳多个模型

从成本角度看，另一个选项看起来要好得多：把其中几个模型放在同一张 GPU 上。

当模型能放进 GPU 内存时，就没有根本理由让每个模型都拥有自己的 GPU。例如，一张 L4 有 24 GB 内存，足以同时容纳几个小模型。

难点不在于把模型塞进卡里，而在于让多个独立服务进程高效共享这张卡。

一个服务进程通常围绕它启动时所针对的模型来构建。它管理该模型的内存、请求和批处理，却不知道同一张 GPU 上其他进程在做什么。

以 vLLM 为例。它的 --gpu-memory-utilization 设置默认值为 0.92，这定义了该实例允许使用多少 GPU 内存。

在它旁边再运行另一个服务进程，第二个进程并不会自动知道 vLLM 用了多少内存，也不知道哪些内存可以安全地提供给它。

现在试着把 vLLM、TEI，以及你的自定义解析、抽取和视觉服务器全部打包到同一张 GPU 上。

你在真正了解实际流量之前，就要手动决定每个进程应该获得多少内存：

• 给某个进程太少空间或卡内存。 一个长文档或突发批处理可能会让某个模型超出其限制。当这种情况发生时，它不仅是自己失败，还可能拖垮共享这张 GPU 的所有其他模型。

• 给某个进程太多空间或卡内存。 这部分内存在其他模型那里就不可用了，即使它自己正空闲着。

当流量在不同阶段之间移动时，情况会变得更糟。文档解析器可能收到一波突发工作，而重排序器几乎什么都没做。片刻之后，重排序器又可能成为流水线中最繁忙的部分。

但内存分配并不会随工作负载移动。而内存只是问题的一部分。

每个服务进程还有自己的队列和批处理逻辑。它们中没有一个能看到其他模型中等待工作的全貌。因此，没有一个统一的调度器来决定整个 GPU 应该如何被使用。

一个进程的队列可能为空，而另一个进程正在积压工作，但空闲进程不能简单地把自己的未用容量交给另一个进程。

这就是把标准服务工具放在同一张 GPU 上的真正局限。硬件可以共享，但服务进程仍然在独立运作。

选择：专用 GPU 还是共享 GPU

目前，我们有两种方式来运行多模型流水线：

• 专用 GPU 更简单，但硬件与流水线是按 1:1 扩展的。

• 共享 GPU 能更高效地利用硬件，但需要某种机制来协调卡上的模型。

对于这条流水线，我们选择第二种方案，因为它更匹配我们的工作负载。

由于所使用的模型都很小，而且它们的工作负载不会同时达到峰值，因此显然有机会让它们共享同一张 GPU，而不是为每一个模型都保留一张单独的卡。

为此，我们的服务层需要把 GPU 当作一个共享资源来管理。

那么，要让共享 GPU 真正生效，服务层需要做什么？

小模型服务栈需要什么

首先，退一步，不要急着找另一个框架，而是理解我们希望这个理想服务器做到的事情。

• 第一个需求是广度。服务器必须能在同一个 API 后面运行嵌入、重排序器、OCR、视觉、抽取和生成。

• GPU 利用率是第二个问题。而事实证明，这需要的不仅仅是一个好的调度器。因为要把不同长度的请求打包进一次前向计算而不浪费算力，引擎必须能够控制它所服务的每一种架构的批处理和注意力路径。

• 模型内存也需要跟随流量。它应该随着流量的移动而加载和驱逐模型，让繁忙的模型保持加载，让空闲的模型退出。这样，模型就不会像冷启动的无服务器 worker 或填充过度的 vLLM 实例那样占着内存不放。

• 服务层还必须表现得像生产基础设施一样，具备路由、自动扩缩、监控和 GPU 池。这一点很重要，因为像 vLLM 这样的裸运行时只是引擎。它本身无法在多个副本之间分散负载，也无法随着流量变化增加或移除 GPU。

• 而且添加一个新副本应该是配置变更，而不是重新部署。

如今，开发者必须从头开始构建所有这些内容，花费数月时间做定制工程，因为不同的模型家族在底层运行方式完全不同。

• Qwen 模型以不同方式处理位置和注意力。

• ColBERT 模型为每个 token 返回一个向量。

• 重排序器只返回一个分数，完全不返回向量。

构建一个能容纳所有这些形态、并能把其中任何一个打包进完整批处理的引擎，是一项关键工作。这也是为什么这之前并不存在一个开源包。

开源解决方案：Superlinked Inference Engine

所有这些问题的解决方案都在开源 Superlinked Inference Engine（SIE） 中实现。

SIE 是一个开源推理引擎，以生产集群的形式运行，用于共享基础设施上的多模型流水线。

它通过统一 API 支持 100 多个模型，因此不同类型的模型可以通过同一个服务层运行，而不需要各自独立部署。

统一 API 很有用，但更大的优势是协调能力。SIE 可以围绕同一个 GPU 池来管理这些模型。

它作为一个集群运行在你自己的云环境中，并且正是为我们在前面描述的那种多模型流水线而构建的：多个不同类型的小模型，在共享 GPU 上一个接一个地运行。

对于我们讨论的洪水保险理赔场景中的这类工作负载，SIE 将多个核心原语暴露为：

• extract 在这条流水线中承担三项不同工作： 将理赔表单和保单文档转换为干净的 markdown（docling） 从文本中抽取带有标签的字段，如姓名、保单号和日期（gliner） 在理赔照片中找出带有标签的洪水损坏类别（grounding-dino）

• 解析、实体抽取和视觉检测这三项真正不同的任务，使用的是同一个 extract 接口。底层的模型可以不同，但服务接口不必不同。

• score 使用 bge-reranker 根据查询对保单分块进行重排序，并返回排序后的列表。

• generate 把迄今为止收集到的一切——已解析文档、抽取字段、保单条款和照片分析——整合起来，使用 Qwen3.5 生成最终审核意见。

在旧方案下，TEI 可以处理重排序阶段，但仍然剩下四个阶段需要单独服务。

解析、实体抽取、视觉检测和生成都需要各自的服务配置。

而一个 SIE 集群就能运行全部五个阶段，无需为其中任何一个单独搭建服务栈。它让我们拥有五个阶段、三个原语、一个共享服务层。

API 只是可见的部分。真正有趣的活儿发生在它底下，在那里 SIE 必须实际协调这些模型在共享 GPU 上运行。

1. 模型只在需要时才加载

我们使用标准服务工具时遇到的第一个问题是内存。

如果多个模型共享一张 GPU，我们不能让所有模型一直保持加载状态，然后指望内存能自己搞定。服务层需要决定哪些模型真正值得占用卡上的空间。

SIE 在请求真正需要某个模型时才加载它。

• 当 GPU 内存变得紧张时，SIE 会驱逐最近最少使用的模型，为另一个模型腾出空间。

• GPU 不再永久绑定到某个模型。它变成了一个共享池，随着流量在流水线中移动，不同模型可以使用它。

2. 一个队列看到所有工作

第二个问题是共享资源池中的协调。

在独立的服务进程下，每个模型只能看到自己的请求。文档服务器不知道重排序器在等什么，重排序器也不知道抽取服务在做什么。

SIE 把工作放到一个共享队列后面。

• 网关把请求发布到这个公共池中，worker 在准备好运行时从中拉取。

• 这给了服务层一个跨模型的工作负载视图，而不是强迫每个进程各自做调度决策。