Splash：把推理引擎「围着模型造」，Mac 上本地跑 Qwen3.8-27B 解码快 2 倍

做本地大模型推理的人大概都习惯了这样的取舍：想要通用，就得容忍引擎为了兼容几十种模型而背上的通用开销；想要快，就得自己去折腾量化、vLLM/MLX 参数、编译工具链。Inco AI 在 2026 年 9 月开源的 Splash，选择了另一条路——不给模型做通用的模型动物园，而是反过来，把整个引擎围着它要服务的那个模型来造。

它的 GitHub 仓库上线三天就冲到 450+ 星：

• 仓库：github.com/incoai/splash
• 发布公告：inco.ai/blog/splash
• 许可：Apache-2.0（模型权重另算）

一句话说清楚它想干什么

大多数推理引擎的目标是「能跑任何模型」，为此保留大量通用路径。Splash 反其道而行：kernel、draft 模型、内存规划全部为它所服务的模型单独定制。README 里的原话是「built around the model」，作者把这句话当成整个设计哲学：

The runtime, scheduler, cache, and API are shared. Everything else is rebuilt per model.

（运行时、调度器、缓存和 API 是共享的；其余一切针对每个模型重建。）

也就是说，通用部分只有一层薄薄的骨架，真正决定性能的部分——融合 kernel、草稿模型、内存预算——全部是为特定模型「量体裁衣」的。代价是它现在只支持极少数模型，官方现成支持两个：

• incoai/Qwen3.8-27B-Splash（27B，4-bit，附带 DFlash 2 draft，17.4 GB）
• incoai/Qwen3.6-35B-A3B-Splash（MoE，4-bit，附带 DFlash 2 draft，20.9 GB）

在 Mac 上跑起来有多简单

Splash 面向 Apple Silicon，需要 M3 或更新的机器、macOS 26.4 及以上、至少 36 GB 统一内存（官方推荐 48 GB 以上），以及 Homebrew。装了以后两条命令就能起来：

brew install incoai/tap/splash
splash serve --model incoai/Qwen3.8-27B-Splash

第一次运行会自动下载并校验模型包、检查可用内存，然后在 127.0.0.1:8000 上开始服务。看到 Ready 之后，可以直接打开浏览器里的内置聊天页，也可以让已经装好的编码 agent 连上来：

splash opencode    # 或 splash claude / splash codex / splash hermes

它没有配置文件，唯一的可调项是一些「上限」类参数，比如 --max-memory 28G、--max-context 100K，用来给同时开着的编辑器、浏览器留出内存空间。设计上刻意不做手动调优——因为调优这件事已经被引擎在启动时自动做完了。

性能：48 GB 的 M5 Pro 上，解码快一倍

按官方在 48 GB M5 Pro 上、用 NVIDIA SPEED-Bench 的编码任务集（最长 32K token，输出上限 1024 token）实测，Splash 相对次快的引擎：

它强调的一点很值得注意：上下文越长，领先优势越大。对 agent 场景来说，这意味着「已经聊了几万 token 的会话」跑得比别的引擎上的「全新会话」还快。在 32K 时，Qwen3.6-35B-A3B 仍有 143 tok/s、Qwen3.8-27B 有 54 tok/s。

官方也直说了对比口径：所有引擎跑在同一台机器上、各自用推荐设置，因此这是端到端的对比，反映的是「为模型专门化」的整体效果，而不是某个单点优化的功劳。对比对象包括 oMLX、Lily、uzu 和 Ollama。

技术内核：三件事撑起这个速度

1. DFlash 2：投机解码是默认路径，不是可选项

Splash 里 投机解码（speculative decoding）就是解码路径本身，没有「开不开」这一说。每个受支持的模型都自带一个为它训练的 DFlash 2 草稿模型：草稿一次提出一个 token 块，然后由目标模型一次前向并行验证整块。

围绕草稿模型，引擎做了三件协同的事：

• 解码步作为整体执行：在输出不受 schema 约束时，Splash 把「起草、验证、接受、状态更新」作为一个单元提交，而不是一步步来，这样草稿带来的加速能真正传到 API，而不是消耗在每步的调度开销上。
• 投机发生在 batch 内部：每个请求携带自己的草稿状态，随被接受的 token 推进，因此投机与并发、缓存复用是协同而非互斥的。
• 长上下文下草稿依然小：草稿用滑动窗口注意力；长 prefill 时只计算生成和前缀快照需要的草稿状态，草稿内存不随上下文无限增长。

2. 形状定制的 kernel，由「内核 agent」自动生成

prefill 和 decode 是完全不同的负载：prefill 跑大 batch，草稿验证跑小块。Splash 给每种负载、按模型的精确维度分别写 4-bit 矩阵乘和注意力 kernel。手工写和调优不现实，所以这些 kernel 由 Inco 内部的 kernel agents 自动生成，包括：

• 直接读 8-bit KV cache 并在 query head 与验证 token 间复用的 decode kernel；
• 把循环状态留在片上（on-chip）的 GDN prefill kernel；
• 为 MoE 模型路由专家准备的专用 kernel。

全部预编译发布，带 GPU 家族/核心数/负载的预设——用户不需要 Xcode，不需要编译工具链，本机什么都不用调。

3. 按机器算出来的内存规划

对给定模型，权重和草稿大小固定，每个请求每 token 的状态开销也已知，于是 Splash 在启动时就算出内存预算：Metal 推荐的工作集上限减去这些成本。以 Qwen3.8-27B 为例，15 GiB 权重 + 1.2 GiB 草稿，之后才轮到 KV cache。如果模型装不进可用内存，启动会打印一份内存预算明细然后停止，而不是跑到一半崩掉。

调度上，Splash 按到达顺序批处理请求，并平衡 prefill 与 decode；注意力状态放在按前缀索引的分页 KV cache 里，共享前缀的请求直接复用页面而不是重算。对混合模型，它还会在前缀边界快照 Gated DeltaNet（GDN）状态，让缓存复用覆盖到循环层。内存吃紧时可以回收缓存状态、动态调整调度。

API 兼容性：三种主流协议都认

Splash 同时说 OpenAI Chat Completions（/v1/chat/completions）、OpenAI Responses（/v1/responses）和 Anthropic Messages（/v1/messages），都支持流式、工具调用、JSON Schema 输出、图像输入、内联 PDF。此外还有两个「只做判断、不做生成」的端点：

• POST /v1/systemone：接受 TypeSafe System One 的请求/响应形状（noul / choice / score 三类问题），兼容官方 typesafe-sdk（已验证 0.7.0）；
• POST /v1/judgments：对 SemIf 风格的选项行打分，返回原始 option logits（不跑生成，零 completion token）。

还有 /tokenize 和 /apply-template，可以在不跑推理的前提下拿到 token id 和渲染后的 prompt，方便做 prompt 预算和调试。

它甚至内置了 LM Studio 整合：LM Studio Bionic 把 Splash 作为一等推理引擎集成，在 Settings → Runtime 里下载即可。

谁适合用它

Splash 的取舍非常明确：

适合：手里是 M3/M4/M5 且内存 36 GB 起的 Mac，想在本地用 Qwen3.8-27B / Qwen3.6-35B-A3B 跑编码 agent，追求「开箱即用 + 单机最快解码」的人。

不适合：需要跑很多不同模型、需要 Windows/Linux/CUDA、或者需要自己转换任意 Hugging Face 权重的人。它的 README 说得很直白——普通 MLX 或 Transformers checkpoint 不能直接用，必须是 Splash package 格式；新架构需要引擎侧支持。也没有通用的多模型运行时、没有回退路径。

换句话说，Splash 不是又一个「万能推理服务器」，而是一台为少数几个模型专门调的赛车。它赌的是：对本地 agent 这类高频、长上下文、单机场景来说，「一个模型跑到极致」比「什么模型都能跑」更有价值。这笔账划不划算，取决于你的场景有多窄——但对 Mac 上的编码 agent 用户来说，这个方向确实很有说服力。

项目地址：https://github.com/incoai/splash