LiquidAI 发布 LFM2.5-DSpark 草稿模型，推理提速最高 3.2 倍

8 月 20 日，LiquidAI 发布了面向 LFM2.5 系列的 DSpark 草稿模型权重，涉及 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B 三款模型。草稿模型本身约 3 亿参数，作用是配合主模型做推测解码，用很小的额外显存换大幅解码加速。

这批权重已上传 Hugging Face，同时 DSpark 集成以开源形式合入 llama.cpp 与 SGLang，属于发布当天即可上手使用的状态。

大模型生成时，每吐一个 token 都要把权重从显存搬到计算单元，瓶颈往往不在算力而在内存带宽。推测解码的思路是：先用一个轻量草稿模型快速猜出后面几个 token，再让主模型一次性验证整批猜测，这样权重只搬运一次，却换来多个 token。

DSpark 是这类方法里的新方案，它把 DFlash 式的并行主干、马尔可夫链式的顺序头和一个按置信度裁剪的验证器组合在一起，接受率比早期方法更高。对不懂底层原理的普通用户，可以简单理解为：同样的模型、同样的回答质量，生成速度更快。

官方给出的数据是：GPU 上吞吐最高提升约 3.18 倍，端侧设备上最高约 2.87 倍。对 LFM2.5-2.6B 而言，函数调用场景的平均延迟下降 57%，这对端侧 Agent 应用是直接影响。

更关键的是，DSpark 在贪心解码下不改变输出内容——草稿被拒绝时主模型会用自己的 token 顶上，因此基准测试分数与原始模型一致。也就是说这次的提速不靠牺牲质量换。

三份草稿权重分别命名为 LFM2.5-1.2B-Instruct-DSpark、LFM2.5-2.6B-DSpark 与 LFM2.5-8B-A1B-DSpark，均已发布在 Hugging Face 的 LiquidAI 组织下。llama.cpp 与 SGLang 的 DSpark 集成也已开源合入上游主仓。

对本地部署用户，这意味着从 H100 到 MacBook 这类设备都能按各自硬件条件启用推测解码路径；集成是模型架构与推测方法一起设计的，后续 LFM 模型很可能默认带这类加速。

推测解码领域此前最受关注的是 EAGLE-3 和 DFlash。DSpark 在 DFlash 并行主干基础上，加了基于马尔可夫链的顺序头，让相邻草稿 token 之间产生依赖，提高靠后位置的接受率；再加一个预测每个 token 存活概率的验证头，当验证成本大于收益时会主动剪掉低置信度的后缀。

LiquidAI 这次还公开了训练细节：草稿模型用注意力简化架构、5 层结构，训练 15 个 epoch 后按接受率而非损失挑最优 checkpoint。对做推理优化的团队，这些细节有参考价值。

最直接的受益者是本地部署 LFM2.5 的开发者：不换模型、不改输出质量就能获得可观的速度提升。做端侧 Agent 的团队值得重点测试函数调用延迟的下降幅度。

下一步可以关注 DSpark 是否会被推广到更大的 LFM 模型，以及 llama.cpp、SGLang 之外更多推理框架的跟进支持。

本文由 AI 潮汐编辑部基于官方公告与公开资料整理，补充了行业影响、适用场景和行动建议，帮助你在阅读原文前先理解这条信息为什么重要。

原始来源：https://www.liquid.ai/blog/lfm2.5-dspark

如发现事实、价格或链接有误，可通过 联系我们 提交更正。