Superfluid：为多智能体而生的本地LLM推理服务器

当本地AI从「一个人聊天」变成「八个智能体抢一张显卡」

本地大模型的使用场景正在发生结构性变化。过去的本地推理需求简单——用户打开终端，和大模型来回对话，一次一个请求。现在的情况完全不同：一个智能体夜间整理邮件，一个监测健康数据，一个负责比价购物，用户还要在这中间随时插话提问。八个智能体加一个人类，共用一台笔记本的算力。

问题在于，今天主流的本地推理服务器——llama-server、Ollama、mlx_lm.server——都是为数据中心机架的吞吐量设计的，没有优先级调度，没有断点恢复。你的提问排在已经在跑的批次后面等；进程重启，所有会话一起消失。

Superfluid 试图解决这个问题。它是一个 Apache-2.0 开源协议的本地 LLM 推理服务器，核心定位是单机多智能体推理。

交互请求不该排在批量任务后面

Superfluid 最核心的设计决策是调度层面的：交互式请求会在下一个调度周期抢占批量工作，而不是排在它后面。

这个差异在真实负载下非常明显。Superfluid 团队用八个智能体各自处理 7.5k token 文档，随后在第二秒发出一个聊天请求——Superfluid 用 0.36 秒给出回答，同样的模型跑在 llama-server 上超过 10 秒还没吐出第一个 token。30 倍的首 token 延迟差距。

这不是模型层面的优化，而是服务架构层面的取舍。数据中心的推理服务器追求总吞吐量最大化，牺牲单个请求的响应速度是可以接受的；但个人设备上的多智能体场景里，人类用户的交互请求必须优先，否则「本地AI助手」的体验根本立不住。根据官方测试数据，八个智能体在跑时，聊天请求的首 token 延迟为 1.5 秒，而 llama-server 需要 291 秒、Ollama 需要 380 秒、mlx_lm.server 需要 612 秒。

**首 token 延迟（TTFT）**是衡量交互式推理体验的关键指标，指从客户端发出请求到收到第一个生成 token 的时间间隔。它由两部分构成：排队等待时间与 prompt 的 prefill 计算时间。在多智能体并发场景下，GPU 通常被长任务的批处理占满，新来的交互请求若采用先到先服务（FCFS）或连续批处理（continuous batching）策略，就会被塞进当前或下一个批次尾部，等待数十秒甚至数分钟。这也是 llama-server 等方案 TTFT 极长的根本原因——它们追求的是总吞吐，而非单请求的公平性与响应性。抢占式调度则允许高优先级请求打断正在进行的批次，在该调度周期立即获得算力，代价是牺牲部分批处理效率。对个人设备上「人类等不起、智能体可以等」的负载结构而言，这一取舍是合理的。

每个 token 先写日志再发送

Superfluid 的第二个关键设计围绕容错：每个 token 在发送给客户端之前先写入日志。这意味着推理进程被 kill 或服务器重启后，会话能从断点继续，不会丢数据。

官方给出的实测结果：推理 worker 在流式输出中途被杀死后，Superfluid 在 1.8 秒内恢复服务；Ollama 同样 1.8 秒恢复但流被截断；llama-server 和 mlx_lm.server 直接没有这个能力。

对一个需要 7×24 运行多个智能体的本地环境来说，「重启即丢会话」是致命的。Superfluid 把持久化放进了核心路径，而不是作为可选插件。

**Write-Ahead Logging（WAL，预写日志）**是数据库领域保证持久性与崩溃一致性的经典机制：在真正应用变更之前，先把操作记录追加到日志中。Superfluid 把这一思想搬到 token 流式输出上——每个 token 先落盘成日志，再发给客户端。这样即使 worker 崩溃，恢复进程也能通过重放日志得知已生成到哪个位置，从而从断点继续。相比之下，普通流式推理的 token 只存在于内存缓冲区，进程一死，缓冲内容随之丢失，客户端只能收到被截断的流。WAL 会带来额外的写盘开销，但通过批量刷盘（fsync 策略）可以将其压到很低。对需要 7×24 运行、且会话状态不可重建的多智能体环境来说，这项开销换来的可恢复性往往是值得的。

一套 API 覆盖三种运行时

Superfluid 同时支持 OpenAI、Anthropic 和 Ollama 三种 API 协议，底层对接三种推理运行时：llama.cpp 用于 GGUF 模型，MLX 用于 MLX 目录，BaseRT 引擎用于 .base 模型包。

这意味着同一个服务端实例，可以直接接管 Claude Code、Codex、Cline、OpenCode、Ollama CLI 等各类客户端的请求：

superfluid launch claude --model unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_M

它还有一个共享前缀缓存的优化：32 个请求共用同一段 4k token 的系统提示词时，Superfluid 的缓存命中率达到 97%，与 Ollama 持平，而 mlx_lm.server 为 0%。多个智能体共享同一 system prompt 的场景下，这个优化直接省掉了重复的 prefill 计算。

**前缀缓存（prefix caching）**是一种针对大模型 prefill 阶段的优化。由于 Transformer 推理中 prompt 前面若干 token 的计算结果只依赖这些 token 自身，可在多个请求间复用。多智能体场景下，所有智能体常共享同一段很长的 system prompt（例如 4k token 的工具说明与角色设定），若每个请求都重新计算这段前缀，会浪费大量算力。前缀缓存将这段 KV 缓存在显存或内存中，命中后直接跳过其 prefill。命中率越高，节省越明显；Ollama 与 Superfluid 在此场景均能达到 97%，而逐个处理请求的 mlx_lm.server 命中率为 0%，意味着它每次都要重算整段系统提示词。对于并发运行多个智能体的设备，前缀缓存几乎是刚需。

把多台设备拼成一台推理机器

Superfluid 内置了多设备推理能力。一台机器作为头节点，其他机器通过 token 认证加入：

superfluid fleet token
superfluid serve unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_M --http 0.0.0.0:8453 --fleet-listen 0.0.0.0:8454

节点侧执行 superfluid node join 后会自动发现头节点、拉取模型，通过 token 加密的链路提供服务。调度策略是整会话分配——一个会话完整地放在某个节点上，只有采样后的 token 回传到头节点。节点中途挂掉，会话会被替换，且不会重复投递 token。

不同节点可以跑不同运行时：Mac 上用 BaseRT，旁边的 Linux 机器用 llama.cpp，对上层客户端完全透明。

**整会话分配（whole-session placement）**是分布式推理调度的一种策略：将一个会话的全部请求固定路由到同一节点，而不是把单次请求拆散到多台机器上做张量并行或流水线并行。它的好处在于，节点只需在本地维护该会话的 KV 缓存，节点间通信仅限采样后 token 的回传，带宽需求极低，也避免了逐 token 跨节点同步的高延迟。代价是负载均衡粒度较粗、单节点故障会中断整个会话，需要额外的会话迁移或替换机制来兜底。Superfluid 选择这一策略，正是因为其目标场景——多台个人设备通过普通网络互联——难以承受高带宽的跨机张量同步，而整会话分配在低带宽下仍能稳定工作。

性能取舍的边界

需要客观看待的一点是：Superfluid 的服务层本身不引入额外开销。在单请求和八并发请求下，通过 Superfluid 调用的 llama.cpp 与直接用 llama-server 的 tokens/s 持平。Superfluid 对 MLX 请求做了批处理，效率高于 mlx_lm.server 逐个处理的方式。

换句话说，Superfluid 的收益主要来自调度、缓存和容错，而不是计算加速。在单智能体、低并发的场景下，它和现有方案差异不大；只有当你同时跑多个智能体、或者需要长时间稳定运行时，架构层面的差异才会显现出来。

如果你想在自己的机器上验证这些数据，安装和启动只需要两行命令：

curl -fsSL https://superfluid.sh/install.sh | sh
superfluid serve unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_M

项目地址在 github.com/basecompute/superfluid，支持 macOS（Apple silicon）和 Linux（x86-64、arm64）。