LFM2.5-2.6B-DSpark：让Liquid端侧智能体运行速度提升2.3倍的328M草稿模型

除了Liquid AI之外，还没有人在自己的硬件上运行过LFM2.5-2.6B-DSpark并发布过相关数据。这是讨论该模型时最诚实的起点，因为它的全部意义就在于一项性能声明：它不是更好的2.6B模型，而是一个328M参数的草稿模型，位于2.6B智能体模型LFM2.5-2.6B之前，为其提出待验证的token，从而使智能体的运行速度提高约一倍，且不改变其输出。

LFM2.5-2.6B-DSpark 于2026年8月20日发布，随附 Hugging Face 上的技术文章和 Liquid 自家博客上的配套博文，是 Liquid 当天发布的一小系列投机解码草稿检查点中的旗舰模型。下方速度栏中的所有数据均由供应商测量，尚未经过独立确认；仓库、格式和框架支持中的一切内容均可直接查阅核实。

一句话概括 DSpark 是什么

推测解码的技巧在于，用一个廉价的草稿模型先于真实模型运行：草稿模型猜测接下来的一小批词元，目标模型在单次前向传播中检查整个批次，并保留其认同的词元。当猜测正确时，你只需一次计算就能推进多个词元，因此吞吐量得以提升，而无需改动目标模型的权重。DSpark——这项技术最初由 DeepSeek 研究人员于 2026 年 7 月提出，并已部署在 DeepSeek-V4 中——是面向小型端侧模型调优的该技巧的一个版本。Liquid 称之为置信度调度推测解码，它由三个关键组件构成：一个并行骨干网络，在一次前向传播中为所有草稿词元生成隐藏状态；一个轻量级的顺序头，用于建模相邻词元之间的依赖关系，使接受率不会在块的后半段崩塌；以及一个验证器，当检查低置信度后缀的成本超过其节省时，会将其剪除。

最后这一点正是 DSpark 与普通起草模型的不同之处：它并不总是将完整块推入验证流程。当草稿自身的置信度表明某个后缀不太可能被接受时，它就会截短该块，省下浪费的计算开销。草稿块包含九个 token，因此目标端每次最多验证十个。

起草人：数字解读

LFM2.5-2.6B-DSpark 检查点是一个 0.3B 参数、仅含注意力机制的草稿模型：包含五个完整注意力层（隐藏层大小 2,048，分组查询注意力，具有 32 个查询头和 8 个键值头）、128K token 词表、秩为 256 的马尔可夫头和一个置信度头。Liquid 在 AMD 硬件上，于指令、对话、代码和函数调用数据的混合数据集上训练了 15 个 epoch，并根据最高接受率（而非最低损失）来挑选 epoch。

这个接受率是决定草稿模型价值的数字。在批次大小为 1、温度为 0 的五个基准测试中，LFM2.5-2.6B-DSpark 在 H100 上平均每个解码步骤接受 4.83 个令牌，在 M4 Max 上接受 4.42 个——大约一半的块被接受，两倍加速正是由此而来。

标记的加速

以下所有数据均来自 Liquid AI 自身的测量——在单块 H100 80GB 上以 BF16 运行 SGLang，以及在 M4 Max MacBook Pro 上通过 Metal 后端以 FP16 GGUF 运行 llama.cpp，批大小为 1，温度为 0——截至撰写本文时，这些数据均未经任何独立方复现：

• H100 平均 — 2.67×，从 323 到 864 tokens/s。按基准测试：MATH500 3.06×，HumanEval 2.56×，MBPP 2.64×，GSM8K 2.22×，MT-Bench 2.87×。

• M4 Max 平均 — 2.27×，从61到139 tokens/s。按基准：MATH500 2.25×，HumanEval 2.63×，MBPP 2.11×，GSM8K 2.36×，MT-Bench 1.99×。

• 工具调用——在多工具函数调用场景中，平均延迟降低了{{1}}57%{{/1}}。

• 家族背景 — 家族中最大的草稿模型 LFM2.5-8B-A1B-DSpark 在 H100 上最高达到 3.18× 加速，1.2B 草稿模型在 M4 Max 上最高达到 2.87×；上文提到的 2.6B 数据则处于中游水平。

关于这些数字，除了平均值之外，还有两点值得关注。首先，它们是在温度为 0、batch size 为 1 的条件下测得的——这是有利于推测的配置，也是交互式端侧智能体工作大多所处的配置。一致性保证在这里同样成立：推测解码会验证每一个提议的 token，因此在贪婪解码下，生成的文本与目标模型单独生成的结果完全一致。其次，随着并发度的提高，差距会缩小：在单个 H100 上，Liquid 报告称 DSpark 的优势在 batch size 约为 128 时趋于收敛，因此草稿模型对交互式和工具密集型工作负载来说是延迟上的胜利，而非提升满载服务器原始吞吐量的银弹。

什么是已确认的，什么是未确认的

{{1}}确认属实，即该仓库是公开且可核查的：{{/1}}{{2}}草稿模型以 Safetensors（BF16）和 GGUF 格式发布；{{/2}}{{3}}它与后训练版的 LFM2.5-2.6B 配对使用，而非基础版；{{/3}}{{4}}llama.cpp（含实验性 Metal 内核）和 SGLang 在发布首日即在上游获得支持；{{/4}}{{5}}其采用 Liquid 的 LFM 开放许可证 v1.0 授权；{{/5}}{{6}}而且——对任何围绕它规划的人来说这一点很重要——模型卡声明没有任何推理提供商为其提供服务，因此这是一个需要自行运行的组件。{{/6}}

尚未确认：加速效果能否在其他硬件和配置上复现（Liquid 之外还没有人发表过测量结果）、草稿模型在采样而非贪心解码下的表现如何，以及 57% 的工具调用延迟数据在 Liquid 所使用的基准测试框架之外的真实智能体框架中是否仍然成立。这些都不是指控——发布才刚一天——但它们决定了一个数字是仅仅有前景，还是已经得到验证。

运行它

在 SGLang 中，你使用支持 DSpark 的构建，针对目标模型启动服务器，并指定草稿模型：投机算法为 DSPARK，草稿模型路径指向 LiquidAI/LFM2.5-2.6B-DSpark，块大小从草稿模型的 config.json 中读取。在 llama.cpp 中，你加载目标 GGUF，并将草稿 GGUF 作为草稿模型，同时将 spec 类型设置为 draft-dspark，块大小从 sidecar 元数据中读取。这两个集成都已上游化，因此无需 fork——只需使用一个足够新的构建即可包含它们。

何时值得添加

LFM2.5-2.6B-DSpark 大约0.3GB的额外内存开销，是在你真正按照Liquid设计的使用场景部署2.6B智能体时才体现价值的——即在手机、笔记本电脑或边缘设备上，运行交互式或工具调用工作负载，这些负载受延迟约束且使用贪心解码。这正是2.27倍端侧加速和57%工具调用延迟降低发挥作用的使用场景。如果你在服务器上以高批量提供服务（加速比趋于1倍），或者工作负载在温度大于0的情况下运行（此时报告的数据不再适用），那么这个模型就不那么有吸引力了。另外，如果你使用的是该系列中的8B-A1B变体，请注意这个边界情况：目前其端侧加速只有约1.18倍，因为在llama.cpp的Metal后端中验证草稿token会激活更多专家模块——Liquid已将此标记为已知问题。

DSpark 不会改变 2.6B agent 的运行位置——从设计上讲，它是一个自托管方案，将与你已经在调用的托管模型并肩运行。本地草稿模型与十几个 API 端点的组合，正是路由层存在所要消解的那种管道复杂性：一个 API key 覆盖 200+ 模型，当提供商性能下降时自动故障转移，提供商挂牌价格以 0% 加价直接传递。这样一来，2.6B 级 agent 的本地与托管成本对比就能保持清晰可读，而不是只能待在电子表格里。

今天阅读 LFM2.5-2.6B-DSpark 的正确方式是：将其视为一个附在真实、可下载、可运行的检查点之上的、前景可观但由供应商测量且尚未经独立验证的速度声明。如果你在设备端部署 2.6B agent，草稿模型尝试起来成本很低，移除也很容易——在 SGLang 命令中添加两个投机解码标志，保持贪心解码，并在相信 2.3× 之前，用你自己的工作负载进行测量。代码仓库就在那里；独立验证是待办事项。