📌 项目地址：superlinked/sie | ⭐ 3,008 颗星 | 🔧 Python | 📜 未标注
📌 项目地址：superlinked/sie | ⭐ 3,008 | Python | PyPI 包名
sie-sdk
问题在哪
搭过 Agent 系统的人多半遇到过这个局面：embedding 一个服务，文档解析一个服务，安全审核再一个，生成又调另一个。每个任务一个模型服务器，GPU 分配、监控、API 风格各管各的。任务越多，这层越碎。
SIE（Superlinked Inference Engine）把这层收拢成一个自托管集群：一个 API 服务 Agent 需要的开源模型，官方称支持 100+，按需加载。
它把 Agent 的五类任务全包了
| 任务 | 作用 | 模型 |
|---|---|---|
| 搜索 | embedding、匹配、重排 | bge-m3, splade-v3, colbertv2, qwen3-reranker |
| 文档转 Markdown | PDF、Office、扫描件 | lightonocr, glm-ocr, mineru, paddleocr-vl, docling |
| 结构化输出 | Schema 校验的 JSON | gliner2, nuner-zero, qwen3.6-27b |
| 内容安全 | 带概率的安全判定，自己定阈值 | granite-guardian-2b |
| Agent 循环 | 规划、工具调用、流式输出 | qwen3.6-27b |
完整目录在 packages/sie_server/models/ 下。embedding 和检索模型经过 MTEB 基准测试，检索这块的选择不是拍脑袋定的。
四个我觉得关键的设计
OpenAI 兼容 API。 提供 /v1/embeddings、/v1/chat/completions、/v1/completions、/v1/responses。从 OpenAI 或其他兼容服务迁移，改动基本就是 base URL。
按需加载 + LRU 淘汰。 多个模型同时驻留，不常用的自动换出。显存有限但任务种类多的场景下，不用为每个模型单独规划 GPU。这是它和“每个模型一个容器”方案最大的运维差异。
K8s 部署配置直接给了。 仓库自带 Helm 配置，包括负载均衡网关、KEDA 自动扩缩容、Grafana 面板。定位是生产部署，不是本地玩玩。
只替换模型层，不动编排层。 官方集成列表里有 LangChain、LlamaIndex、Haystack、DSPy、CrewAI，向量库这边有 Chroma、Qdrant、Weaviate、LanceDB。你现有的编排代码不用重写。
和 vLLM / Ollama 的区别
这两个解决的是“把一个 LLM 跑起来”。SIE 解决的是“把一个 Agent 的全部模型依赖跑起来”。差异具体在两处：一是模型类型，reranker、OCR、GLiNER 类 NER、SigLIP 多模态嵌入这些链路上的小模型都在目录里；二是部署形态，网关加自动扩缩容是仓库自带的，单机方案不管这些。
反过来说，如果你只需要服务一个 LLM，SIE 是过度设计，vLLM 更合适。
从源码开发
先装 mise，然后在仓库根目录：
./tools/init.sh
这会初始化版本化的 Python、Rust、Node.js、Helm 工具链。常用任务都通过 mise 跑：
mise run test
mise run lint
mise run typecheck
mise run serve
mise run rust-check
mise run rust-test
mise run gateway-test
mise run server-sidecar-test
Python workspace 用仓库根部的 lock 文件，包成员在 pyproject.toml 里显式声明。原生音频是可选构建：装好 cmake 后执行 mise exec -- uv sync --frozen --project . --all-packages --all-extras。
Quickstart 的具体启动命令以官方文档为准，README 里链接了 Docs、Quickstart、API Reference 和 Models 四份文档。
一句话判断
3008 颗星、K8s 配置齐全、OpenAI 兼容——SIE 的目标用户很明确：要在自己云上私有化整条 Agent 推理链路的团队。如果你的 Agent 已经依赖五六个不同类型的模型服务，值得花半天试试。