SIE：当一个推理引擎决定把100多个模型装进一个集群里

如果你最近在琢磨怎么给自己的AI Agent接上搜索、重排序、实体提取、内容审核这些能力，大概率会被一个现实问题绊住，那就是每加一个功能就要多起一套模型服务，GPU资源零零散散地被切开，运维成本蹭蹭往上涨。Superlinked团队做的这个开源项目SIE（Superlinked Inference Engine），本质上就是冲着这个痛点来的。它想做的事情很直接，把Agent背后需要的所有小模型，塞进同一个推理集群，用一套API管起来，还不用为每一路模型单独开一台服务器。

项目定位，它到底想解决什么问题

先说清楚一个背景。现在市面上大部分LLM推理框架，比如vLLM、SGLang，思路都是把一个巨大的模型摊到很多张GPU上跑，追求的是单模型的极致吞吐。但Agent场景恰恰是反过来的问题，你要在一张GPU上同时伺候好几个小模型（编码器、重排序器、抽取器），而且这些模型还要能快速地换着来跑。这是一个完全不同的工程命题。

SIE给出的答案是抽象出四个统一的原语（primitive），不管背后用的是PyTorch、SGLang、Flash Attention还是Apple MLX，对外都长成一样的接口：

Encode，把文本或图片编码成向量，用于语义搜索和RAG
Score，对查询与文档的配对打分，做检索结果的精排
Extract，从非结构化文本里抽取实体和结构化信息
Generate，跑开源LLM完成文本生成

这四件事拼起来，基本覆盖了一个Agent运转所需要的全部推理工作。

架构长什么样，为什么号称GPU利用率能到89%

SIE的部署形态是一个Kubernetes集群，核心是一个无状态的gateway，把所有请求丢进同一个队列，后面的worker pod从队列里拉活，攒成完整的batch，再在多个模型之间共享GPU资源。

这里有个挺有意思的设计对比。传统方案（vLLM、SGLang、TEI、llm-d等）用的是先路由再打批 （route-then-batch）的思路，路由器盲目地把请求分发给某个worker，各个worker队列深浅不一，批次大小凑不整齐，官方给出的benchmark显示这种模式GPU利用率大概只有51%。SIE反过来做先打批再路由（pool-then-batch），所有sidecar从同一个池队列里取活，天然就把不同大小的请求打包得更均匀，利用率提升到89% 。

用一张图理一下这套调度逻辑：

flowchart LR A[客户端请求] --> B[Gateway 无状态网关] B --> C[集群级共享队列] C --> D[Worker Pool: agent-realtime] C --> E[Worker Pool: nightly-pipeline] C --> F[Worker Pool: eval-suite] D --> D1[PyTorch: bge-reranker-v2-m3] D --> D2[Candle: embeddinggemma-300m] D --> D3[SGLang: Qwen3-0.6B] E --> E1[PyTorch: PaddleOCR-VL] E --> E2[Candle: granite-embedding-r2] F --> F1[PyTorch: colbertv2.0]

每个worker pool可以绑定不同的硬件规格，比如实时Agent池挂3张L4，夜间批处理池挂4张H100，评测池挂2张RTX PRO 6000，按任务的延迟敏感度和吞吐需求分开配置。

除此之外，模型是按需加载的，配合LRU淘汰策略，GPU显存满了就把最久未用的模型换出去。官方举例，一张24GB显存的L4能同时驻留好几个标准模型，具体数量取决于模型大小和批处理设置，但整个模型目录始终是可寻址的，调用哪个模型就临时加载哪个。

五大任务与配套模型，SIE到底能干什么活

SIE把自己的能力拆成了五类任务，每类任务背后都配了一组可以互相替换的模型，具体清单挂在仓库的packages/sie_server/models/目录下。

任务	做什么	代表模型
搜索（Search）	编码、匹配、重排序，把最相关的上下文找出来	bge-m3、splade-v3、colbertv2、qwen3-reranker
文档转Markdown	PDF、Office文件、扫描件转成干净的markdown	lightonocr、glm-ocr、mineru、paddleocr-vl、docling
结构化输出	抽取或生成符合schema的JSON	gliner2、nuner-zero、qwen3.6-27b
内容审核	给出安全性判断的概率值，自己设阈值	granite-guardian-2b
Agent循环	用开源LLM规划步骤、调用工具，支持流式输出	qwen3.6-27b

模型目录页面还提供了按基准测试排序的功能，比如搜索类模型可以按NDCG@10这个指标横向比较。这个指标简单说就是衡量搜索结果排序质量的一个分数，把排在前面的相关结果给更高权重，公式大致是

$NDCG@10= DCG@10IDCG@10 NDCG@10 = \frac{DCG@10}{IDCG@10}$ NDCG@10=IDCG@10DCG@10

其中 $DCG@10DCG@10$ DCG@10是实际排序下前10个结果的折损累积收益， $IDCG@10IDCG@10$ IDCG@10是理想排序（最相关的结果全部排在最前面）下的同一个值，两者相除就得到一个0到1之间的相对分数，越接近1说明排序越接近完美。

从模型目录里挑几个有代表性的看一下量级和成本差异：

模型	参数规模	NDCG@10	延迟	每百万token成本
Qwen/Qwen3-Embedding-0.6B	596M	---	---	---
NovaSearch/stella_en_1.5B_v5	1.5B	0.4215	258ms	$0.017
Qwen/Qwen3-Embedding-4B	4.0B	0.4121	464ms	$0.039
Linq-AI-Research/Linq-Embed-Mistral	7.1B	0.4192	818ms	$0.075
Alibaba-NLP/gte-Qwen2-7B-instruct	7.6B	0.4055	846ms	$0.063

有意思的是，1.5B的stella模型跑出了0.4215的分数，比好几个7B级别的大模型还高，延迟只要258毫秒，成本也压到最低。这也是SIE想传递的一个核心信息，检索这类任务不一定非要堆参数量，选对模型比选大模型更重要。

和其他方案比，SIE的差异化在哪

官方文档里直接摆了一张对比表，把自己和HuggingFace的TEI、以及OpenAI API放在一起看：

维度	SIE	TEI（HuggingFace）	OpenAI API
自托管	支持	支持	不支持
单GPU多模型共享	支持	不支持（一台服务器一个模型）	不适用
覆盖任务	编码+打分+抽取+生成	仅编码	仅编码+生成
支持模型数	100+	视情况	有限
开源	是	是	否
按token计费	不需要	不需要	需要

这张表其实透露出SIE最想差异化竞争的两个点，一是覆盖任务更全，不只是做embedding；二是多模型共享GPU的能力，这在Agent场景里省下的资源和运维成本是实打实的。首页给出的数据也印证了这个思路，跟text-embedding-3比，gte-multilingual在AWS EKS的L4实例上能便宜50倍；跟Cohere的rerank-3.5比，bge-m3在MTEB AskUbuntu上快2.7倍；而Qwen3.6-27B这种开源模型跑Agent智能指数评测，能达到GPT-5.1的96% 。

上手体验，从一条curl命令开始

SIE的接口设计走的是OpenAI兼容路线，意味着如果你现有代码已经在调/v1/embeddings或/v1/chat/completions，理论上换个base_url就能迁移过来，不用改业务逻辑。

本地起服务，macOS或Linux上装好Python 3.12之后：

shell 复制代码

pip install "sie-server[local]" && sie-server serve

Linux上有NVIDIA GPU的话，直接拉Docker镜像跑：

shell 复制代码

docker run --gpus all -p 8080:8080 \
  -v sie-hf-cache:/app/.cache/huggingface \
  ghcr.io/superlinked/sie-server:latest-cuda12-default

服务起来之后，验证一下：

shell 复制代码

curl http://localhost:8080/readyz   # 期望返回 ok

第一次调用某个模型会触发权重下载，进度会打在服务端终端里，后续调用就直接走缓存了。生成embedding的调用方式跟OpenAI的写法几乎一模一样：

shell 复制代码

curl http://localhost:8080/v1/embeddings \
  -H 'Content-Type: application/json' \
  -d '{"model": "sentence-transformers/all-MiniLM-L6-v2", "input": "Hello world"}'

值得一提的是，Docker镜像是按依赖组合分包的，比如LightOnOCR和GLM-OCR这两个OCR模型需要用transformers5这个镜像变体，普通的default镜像不会带这两个模型，这样做是为了避免不同模型家族之间的依赖冲突互相打架。

开发环境搭建走的是mise这套工具链管理方案，仓库根目录跑一句./tools/init.sh就能把Python、Rust、Node.js、Helm的版本环境全部装好，后续测试、lint、类型检查都有对应的mise任务命令。

生态整合与商业化路径

SIE不是孤立存在的东西，它跟一堆检索和Agent框架都做了打通，包括LangChain、LlamaIndex、Haystack、DSPy、CrewAI，向量数据库这一侧接了Chroma、Qdrant、Weaviate、LanceDB 。几家向量数据库的创始人也在官网给了背书，比如Chroma的Jeff Huber提到SIE给他们补上了指令跟随型重排序器和关系抽取器的能力，Qdrant的Andre Zayarni则说现代搜索就是把最好的索引、打分、排序模型组合起来，SIE让你能自托管这一整套。

商业模式上摆了三条路，一是自托管 ，永久免费，Docker、Helm、Terraform全套部署脚本都有，甚至支持air-gapped（离线隔离网络）环境用镜像快照安装；二是托管服务 ，Superlinked公司帮你扛GPU配额、自动扩缩容、模型调优，号称零数据留存，目前对部分项目开放免费额度申请；三是Agent插件，直接嵌入现有Agent技术栈，把文档解析、抽取、摘要、问答这些活从大厂模型的账单里挪出去，还能在敏感数据触达第三方模型之前先做脱敏，这条路目前还在排队等候名单阶段。

License方面用的是Apache-2.0，仓库星标接近3000，代码库里能看到conformance（一致性测试）、deploy（部署配置）、examples（示例）、packages（核心包）等目录分工，工程化程度看得出是按生产级别在打磨的。

写在最后

SIE这个项目挑的切入点挺聪明，它没有去跟vLLM、SGLang这些巨头正面竞争大模型推理这条赛道，而是盯准了Agent生态里那些容易被忽略、但数量众多的小模型调度问题。把encode、score、extract、generate四件事统一到一套原语和一个集群里，配合pool-then-batch的调度设计，确实是从工程角度给出了一个务实的答案。如果你正在搭建一个需要搜索、OCR、结构化抽取、内容审核多种能力拼在一起的Agent系统，又不想为每个环节单独起服务，这个项目值得拉下来跑跑看。

参考资料

superlinked/sie GitHub仓库

What is SIE? - Superlinked Docs

Model catalog - Superlinked

Superlinked 官网首页