他发现推理才是AI的真瓶颈，于是干了一件没人愿意干的事

我们都在追更大的模型、更快的训练，却忽略了一个更“脏更累”的问题：模型在真实世界里到底怎么跑。Superlinked 的 Filip Makraduli 用一次亲身踩坑，揭开了小模型推理基础设施的巨大空白。

一个自信工程师，被“推理”当头一棒

Filip Makraduli 不是新人。他写过深度技术文章，讲 Flash Attention，讲模型是 compute-bound 还是 memory-bound，自认为已经把模型性能这件事“想清楚了”。直到一篇 Substack 文章被读者指出：你漏掉了最关键的一环——推理（Inference）。

这个反馈很残酷，也很真实。训练、微调、架构优化，这些都在“实验室”里完成；而推理，发生在生产环境，要面对 GPU 调度、路由、排队、自动化这些工程师最头疼的问题。Filip 承认，这正是自己的盲区。于是他做了一个不太学术、但极其工程化的决定：不再只研究，而是亲手去造。

他加入了 Superlinked，一个以基础设施见长的团队，目标只有一个：搞清楚小模型在真实世界里，如何被高效地运行。

为什么小模型，反而成了 Agent 工作流的关键

在 Agent 和复杂工作流里，大家几乎都撞过同一堵墙：context rot。上下文越长，模型质量越差。Chroma 的那篇论文已经把这件事说得很直白，但真正的问题是——你怎么解决？

Filip 给出的答案并不“性感”：用小模型做前处理。用小模型去清洗、压缩、重组上下文，再把处理后的结果交给大模型或 Agent。包括 AI 搜索、文档处理、工具调用，本质上都是在做同一件事：管理上下文。

你当然可以用代码、用 grep，但问题在于——当数据先被小模型结构化之后，你的传统工具会变得更好用，而不是被取代。这不是对抗，而是叠加。这也是为什么社区越来越多地把小模型当成 Agent 的“前置器官”。

“多上 GPU”是最懒、也最错的推理方案

谈到推理，最常见的误区只有一句话：算力不够，就加 GPU。

但在小模型世界里，这几乎是灾难。Embedding 模型、reranker、NER 模型，往往只占用几个 GB 显存。如果你给每个模型配一张 GPU，结果只有一个：大量显存空转，GPU 在发呆。

Superlinked 的判断是：小模型推理的核心能力，不是更快，而是“能切换”。热插拔（hot-swap）模型，把多个小模型塞进同一张 GPU，根据请求动态调度，才是真正提高利用率的方式。

这听起来像是基础设施的细节，但它直接决定了你能不能在成本可控的前提下，把小模型真正用起来。

推理的“阴阳”：模型支持 × 基础设施

Filip 用了一个很东方的比喻：推理的 yin and yang。

“阴”是模型支持。Hugging Face 上已经有数百万开源模型，而且数量和质量都在快速增长。如果你的推理系统不能快速支持这些模型，那你的基础设施再优雅，也毫无意义。

“阳”是基础设施本身。Superlinked 把推理抽象成三个原语：encode、score、extract。在这之上，是路由、队列、负载管理。这不是炫技，而是为了让模型调用在高并发、真实流量下依然可控。

这两者缺一不可：只支持模型，没有工程能力，是玩具；只有工程，没有模型广度，是空壳。

Sie：一次“没人想做”的开源尝试

最终的产物，是 Sie——Superlinked 开源的小模型推理引擎。

它不只开源了模型推理代码，还把集群层一并交出来，让你不用从 GPU 采购、部署、调度这些现实问题开始踩坑。对 Filip 来说，这是一次补课；对行业来说，这是在补一个长期被忽视的基础设施空白。

这不是发布会意义上的“盛大发布”，更像一次工程师之间的摊牌：小模型不会自己跑，必须有人把这些脏活累活做完。

总结

这场分享最重要的价值，不在于某个具体框架，而在于一个认知转变：AI 的瓶颈，正在从“能不能训出来”，转向“能不能跑得起来”。如果你在做 Agent、AI 搜索或复杂工作流，小模型推理不是优化项，而是地基。

接下来值得你思考的是：你的系统里，有没有被“大模型光环”掩盖的小模型需求？你的 GPU，是真的忙，还是在空转？谁先把这些问题解决，谁就会在下一波 AI 工程化里，跑得更稳。

关键词： 小模型推理， AI Agent， GPU 利用率， 开源模型， 模型部署

事实核查备注： 需要核查：1）Sie 是否为 Superlinked 官方开源推理引擎名称；2）Hugging Face 模型数量为“数百万”这一时间点描述；3）Chroma 关于 context rot 的论文结论表述；4）encode/score/extract 是否为其 API 的正式三原语。