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

今天，我们发布了 DSpark [1] 草稿模型检查点，涵盖 LFM2.5 系列中的三个模型：LFM2.5-1.2B-Instruct、最近发布的 LFM2.5-2.6B 以及 LFM2.5-8B-A1B。这些模型增加了一条推测解码路径，以极小的内存增加换取大幅的解码加速，同时不改变输出质量。草稿模型在 GPU 上吞吐量提升最高达 3.18 倍，在设备端最高达 2.87 倍。

这是 Liquid Foundation Models（LFM）推测解码模型的首次公开发布。我们相信，将模型架构与推测方法协同设计以建模真实世界的推理特性，将是未来模型设计的关键部分。

适用于 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B 的 DSpark 草稿模型今日已在 Hugging Face 上发布。此外，兼容 LFM 的 DSpark 集成已在 llama.cpp 和 SGLang 上游开源。请查看模型卡了解如何运行它们。

DSpark 的工作原理

LLM 推理中的解码阶段传统上受内存带宽限制。大部分延迟来自将权重从 DRAM 流式传输到 SRAM，而非密集计算。无论是 NVIDIA H100 等强大的 GPU，还是 MacBook 或 iPhone 等边缘设备，都是如此。

推测解码通过使用轻量级草稿模型生成候选 token 来解决这一问题。随后目标模型在一次前向传播中验证所有候选 token，从而在所有被验证的 token 之间分摊加载权重的成本。

多年来，人们提出了多种推测方法，其中最著名的包括 EAGLE-3 [2]、DFlash [3]，以及最近的 DSpark，后者结合了三个组件：

DFlash 风格的并行主干，以目标模型的上下文特征为条件，对块执行一次前向传播，为 k 个草稿 token 中的每一个生成隐藏状态和基础 logits。
轻量级顺序头，建模为相邻 token 之间的马尔可夫链，将每个位置的 logits 偏向于与其前一个采样 token 一致的延续。这增加了草稿 token 之间的依赖关系，而 DFlash 方法中不存在这种依赖，从而提高了后续位置的接受率。
置信度调度的验证器：一个单独的头预测每个草稿 token 的接受概率，条件是所有先前 token 均被接受；硬件感知调度器会剪除低置信度的后缀，只要验证它们的批量容量成本超过其价值。

训练

我们遵循 DSpark 配方，并扩展了数据混合，以在更大、更多样化的数据集组上进行训练。我们的最终语料库混合了 SFT、聊天、代码和函数调用数据。

为了找到最优设置，包括最优层数、块大小和模型架构，我们在完整训练数据集的子集上进行了消融实验。对于草稿模型的第一个版本，我们使用了简化的仅注意力草稿模型。在整个消融过程中，我们最终确定使用 5 层、块大小为 9。对于每个草稿模型，我们在整个数据集上运行了 15 个 epoch。

对于每个 epoch，我们都在目标基准上测量了验证损失和接受率。图 1 显示，这三个模型的表现并不相同：对于 LFM2.5-1.2B-Instruct，接受率在各个 epoch 中持续提升，与验证损失的下降紧密同步。LFM2.5-2.6B 在前几个 epoch 有所提升，随后进入平台期，其接受率在损失停止下降之前就已趋于平缓。LFM2.5-8B-A1B 最不稳定，验证损失随 token 增多而下降，但并未带来接受率的提升。

图 1：训练 token 过程中的平均接受长度与验证损失

结论是，验证损失对于 LFM2.5-1.2B-Instruct 草稿模型来说是一个有用的实时信号，但对于更大的草稿模型，在我们关心的基准接受率停止变化之后，验证损失仍在继续改善。因此，对于最终发布的检查点，我们选择接受率最高的 epoch，而不是基于损失来选择。

由此得到的草稿模型相对较小，每个约 300M 参数，如表 1 所示。我们训练了每个模型，并完全在 AMD 硬件上使用 Liquid AI 的训练框架运行了所有消融研究。

组件	LFM2.5-1.2B-Instruct	LFM2.5-8B-A1B	LFM2.5-2.6B
解码器堆栈（5 层）	241.2M	241.2M	241.2M
隐藏状态投影	21.0M	21.0M	21.0M
Markov 头	33.6M	65.5M	65.5M
归一化 + 置信度头	27.5k	27.5k	27.5k
总计	295.7M	327.7M	327.7M

表 1：草稿模型大小。嵌入和 LM 头与目标模型绑定，不由草稿模型承载。

质量对等

在贪心解码下，草稿 token 只有在与目标模型的分布匹配时才会被接受。一旦被拒绝，目标模型自己的 token 就会取而代之。因此，按构造来说，输出的序列与基线贪心解码完全相同，所以基准准确率（pass@1 或精确匹配）保持不变。

更快的推理

面向 LFM2.5 的 DSpark 草稿模型在发布首日即获得整个推理生态系统的支持：

llama.cpp — 用于高效边缘推理的 GGUF 检查点
SGLang — 面向生产吞吐量的 GPU 加速服务

SGLang 实现基于官方 SGLang 的 DSpark 实现构建，llama.cpp 则基于官方代码库构建，我们使用实验性 metal 内核运行它。

我们使用 llama.cpp 和 Metal 在 M4 Max MacBook Pro 上测量设备端吞吐量，采用 FP16 GGUF 权重，批大小为 1，温度为 0，最多输出 256 个 token。我们使用 SGLang 在单张 H100 80 GB 上以 BF16 测量 GPU 吞吐量，批大小为 1，温度为 0。两种配置均使用 DSpark 块大小 9，并在五个基准数据集（MATH500、GSM8K、HumanEval、MBPP、MT-Bench）上进行评估。

表 2 展示了 LFM2.5-2.6B 的吞吐量结果。无论是大规模加速器（H100）还是边缘部署（M4 Max MacBook），在各类数据集上吞吐量都有明显提升。MacBook 上的加速尤其显著，因为它将用户可享受的交互性水平提升到了远超大多数专有云模型所能提供的吞吐量（约 ~140 tok/s，具体取决于数据集）。

数据集	接受率（满分 10）	H100 上的加速	M4 Max 上的加速
MATH500	5.42	3.06x 326 → 1000 tok/s	2.25x 61 → 137 tok/s
HumanEval	4.54	2.56x 326 → 835 tok/s	2.63x 61 → 161 tok/s
MBPP	4.71	2.64x 326 → 861 tok/s	2.11x 62 → 132 tok/s
GSM8K	4.32	2.22x 312 → 693 tok/s	2.36x 60 → 143 tok/s
MT-Bench	5.07	2.87x 325 → 933 tok/s	1.99x 62 → 123 tok/s
Mean	4.81	2.67x 323 → 864 tok/s	2.27x 61 → 139 tok/s

表 2：LFM2.5-2.6B 的接受率与加速（DSpark block 9，bs=1，temp=0，SGLang 在 1xH100 上 vs llama.cpp + Metal 在 M4 Max 上）

我们为 LFM2.5-2.6B 设定的主要目标是使其成为首个可行的端侧智能体模型。在智能体工作负载中，模型在每次工具调用前都会进行推理，而用户需要全程等待。这正是推测执行收益最大的地方。在图 2 中，我们通过在 BFCL 数据集 [4] 上测试函数调用来展示对延迟的最终影响。在各种多工具场景中，DSpark 平均将延迟降低了 57%。

图 2：在 M4 Max MacBook Pro 上使用 FP16 GGUF 权重、批大小为 1、温度为 0 时的 BFCL 函数调用延迟。

我们使用与 LFM2.5-1.2B-Instruct 相同的测试设置。在表 3 中，我们展示了 LFM2.5-1.2B-Instruct 的吞吐量结果。请注意，与 2.6B 模型不同，1.2B 是一个非推理模型。对于 1.2B，我们观察到数据集接受率的方差要大得多，因此根据底层文本分布的不同，加速幅度差异可高达 52%。

数据集	接受率（满分 10）	H100 上的加速	M4 Max 上的加速
MATH500	6.02	2.56x 668 → 1712 tok/s	2.62x 140 → 366 tok/s
HumanEval	5.31	2.26x 664 → 1499 tok/s	2.87x 136 → 389 tok/s
MBPP	5.52	2.37x 667 → 1578 tok/s	2.74x 137 → 375 tok/s
GSM8K	4.34	1.67x 624 → 1041 tok/s	2.73x 140 → 381 tok/s
MT-Bench	3.90	1.66x 657 → 1091 tok/s	1.72x 137 → 237 tok/s
Mean	5.02	2.10x 656 → 1384 tok/s	2.54x 138 → 350 tok/s

表 3：LFM2.5-1.2B-Instruct 的接受率与加速（DSpark 5L，block 9，bs=1，temp=0，SGLang 在 1xH100 上 vs llama.cpp + Metal 在 M4 Max 上）

对于 LFM2.5-8B-A1B，推理变得更具挑战性。与两个稠密模型相比，接受率有所上升（8B-A1B 也是一个思考模型），但观察到的真实世界加速并未反映这一点。虽然在 GPU 上我们平均可以实现 2.54x 的合理吞吐量提升，但在边缘设备上我们仅获得 18% 的提升，如表 4 所示。这是由于 llama.cpp 的 Metal 后端中当前的 MoE 实现，以及验证 k 个 token 会激活更多专家，从而比单次解码步骤产生更多权重流量。这将是后续工作的主题，我们出于透明性公布这些数字。

数据集	接受率（满分 10）	H100 上的加速	M4 Max 上的加速
MATH500	8.27	3.18x 428 → 1362 tok/s	1.21x 93 → 112 tok/s
HumanEval	7.02	2.58x 426 → 1100 tok/s	1.12x 91 → 101 tok/s
MBPP	6.93	2.64x 426 → 1122 tok/s	1.09x 89 → 97 tok/s
GSM8K	4.02	1.29x 385 → 496 tok/s	1.44x 90 → 129 tok/s
MT-Bench	8.52	3.02x 426 → 1288 tok/s	1.04x 87 → 90 tok/s
Mean	6.95	2.54x 418 → 1074 tok/s	1.18x 90 → 106 tok/s

表 4：LFM2.5-8B-A1B 的接受率与加速（DSpark 5L，block 9，bs=1，temp=0，SGLang 在 1xH100 上对比 llama.cpp + Metal 在 M4 Max 上）

交互性

这些加速并非仅限于 batch size=1 的场景。考虑聚合系统吞吐量与不同并发级别下单个用户所体验到的吞吐量之间的权衡，也就是所谓的交互性。

随着并发级别的提高，算术强度随之增加，逐渐从内存受限过渡到计算受限的状态。目标模型必须验证的草稿 token 进一步放大了算术强度的增长。两者共同作用，缩小了运行 DSpark 的模型与基线模型之间的累计加速差距。

所有测试均在 SGLang 上使用单张 H100 运行，未使用置信度调度的验证器。DSpark 的置信度头可以动态裁剪每个请求需要验证的 token 数量，但在我们的实验中，它丢弃的 token 所付出的代价超过了节省的计算量，因此我们改为使用固定的验证窗口。

对于 LFM2.5-2.6B，在 block size 为 9 时，性能在 bs=128 附近趋于收敛，具体取决于底层任务的分布。

图 3：LFM2.5-2.6B 在 SGLang 上的交互性

对于 LFM2.5-1.2B-Instruct，交互性略好一些，即使在 batch size 为 128 时 DSpark 也是明显的赢家，如图 4 所示。

LFM2.5-8B-A1B 的高接受率很好地体现在图 5 所示的交互性图中。在所有数据集和并发级别下，DSpark 都优于基础模型，即使在接受率相对较低的数据集（如 GSM8K）上也是如此。其根本原因在于，批处理和推测会激活模型中相同的更大一部分，因此在更高并发下基线也要付出这部分代价，开销便不再计入推测的账上。

开始使用

DSpark 草稿模型已在 Hugging Face 上以 Safetensors 和 GGUF 格式提供

Safetensors：LFM2.5-2.6B-DSpark、LFM2.5-1.2B-Instruct-DSpark 和 LFM2.5-8B-A1B-DSpark
GGUF：LFM2.5-2.6B-DSpark-GGUF、LFM2.5-1.2B-Instruct-DSpark-GGUF、LFM2.5-8B-A1B-DSpark-GGUF

借助 LFM2.5，我们正在实现让 AI 随处运行的愿景。这些模型：

开放权重 —— 下载、微调和部署均无限制。
第一天就快 —— 首日即支持 llama.cpp（所报告的数字是使用此 PR 中的实验性内核实现的）和 SGLang
一个家族 —— 三种规模让你根据部署需求在准确率与占用空间之间进行权衡。

参考文献

[1] Cheng et al. (2026). DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation. https://arxiv.org/abs/2607.05147

[2] Li et al. (2025). EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test. https://openreview.net/forum?id=4exx1hUffq

[3] Chen et al. (2026). DFlash: Block Diffusion for Flash Speculative Decoding. https://arxiv.org/abs/2602.06036

[4] Patil 等人（2025）。Berkeley Function Calling Leaderboard（BFCL）：从工具使用到大型语言模型的智能体评估。https://proceedings.mlr.press/v267/patil25a.html

引用

引用时，请使用以下参考文献或 BibTeX：

Liquid AI，“LFM2.5-DSpark：从 H100 到 MacBook 推理速度最高提升 3.2 倍”，Liquid AI 博客，2026 年 8 月。