LFM2.5-DSpark 推理速度最高提升 3.2 倍
今天，我们发布 LFM2.5 系列中三款模型的 DSpark 草稿模型检查点：LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B。这些模型新增了 speculative decoding 路径，只需略微增加内存占用，就能大幅提升解码速度，同时保持输出质量不变：
- 更快的推理速度：GPU 上吞吐量最高提升 3.18 倍，端侧最高提升 2.87 倍。
- 推动端侧 agentic 推理：LFM2.5-2.6B 的函数调用延迟平均降低 57%。
- 首日支持 llama.cpp 和 SGLang：兼容 LFM 的 DSpark 集成已在上游开源。
DSpark 如何工作
传统的 LLM 推理解码阶段通常受内存带宽限制。大部分延迟并非来自高强度计算，而是将权重从 DRAM 流式加载到 SRAM。Speculative decoding 通过轻量级草稿模型生成候选 token，再由目标模型在一次前向传播中统一验证，从而让所有待验证 token 共享权重加载开销，解决了这一问题。
多年来，业界提出了多种 speculative decoding 方法，其中最具代表性的包括 EAGLE-3、DFlash，以及最新的 DSpark。DSpark 由三个部分组成：
- DFlash 风格的并行骨干网络：以目标模型的上下文特征为条件，在一次前向传播中为所有草稿 token 生成 hidden state。
- 轻量级串行头部网络：将相邻 token 建模为 Markov chain，引入 token 间依赖，从而提高后续位置的接受率。
- 基于置信度调度的验证器：预测每个 token 的保留概率；当验证成本高于收益时，剪除低置信度的后缀。
训练与架构
我们采用 DSpark 的训练方案，并扩大数据规模、丰富数据类型，涵盖 SFT、聊天、代码和函数调用数据。根据消融实验结果，首批 draft model 采用了简化的纯注意力架构，包含 5 层，block size 为 9。每个 draft model 都在完整数据集上训练 15 个 epoch，最终选择接受率最高的 epoch，而不是损失最低的 epoch。
最终得到的 draft model 规模都比较小，每个约含 3 亿参数。
| 组件 | LFM2.5-1.2B-Instruct | LFM2.5-8B-A1B | LFM2.5-2.6B |
|---|---|---|---|
| Decoder stack（5 层） | 241.2M | 241.2M | 241.2M |
| Hidden-state projection | 21.0M | 21.0M | 21.0M |
| Markov head | 33.6M | 65.5M | 65.5M |
| Norms + confidence head | 27.5k | 27.5k | 27.5k |
| 总计 | 295.7M | 327.7M | 327.7M |
质量一致性
在贪心解码下，只有当 draft token 与目标模型的分布一致时，才会被接受。若被拒绝，则由目标模型生成的 token 替代。因此，最终输出序列在设计上与基线贪心解码完全一致，基准测试的准确率（pass@1 或 exact match）也不会发生变化。
CPU 和 GPU 上的推理加速
我们的 LFM2.5 DSpark draft model 从发布首日起就支持 llama.cpp（该实现基于官方代码库构建，并使用我们运行的实验性 Metal kernel）和 **SGLang（**该实现基于 SGLang 官方的 DSpark 实现构建）。
我们在搭载 M4 Max 的 MacBook Pro 上，使用 FP16 GGUF 权重和最多 256 个输出 token，通过 llama.cpp 和 Metal 测量设备端吞吐量；同时在单张 80 GB H100 上使用 BF16，通过 SGLang 测量 GPU 吞吐量。两种配置都采用 DSpark block size 9、batch size 1 和温度 0，并在五个基准数据集上进行评测。
这三款 drafter 模型都显著提升了吞吐量，无论是在大型加速器（H100）上，还是在边缘设备（M4 Max MacBook）上运行，效果都很明显。
对于LFM2.5-2.6B，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 |
| 平均值 | 4.81 | 2.67x 323 → 864 tok/s | 2.27x 61 → 139 tok/s |
在各种多工具场景中，DSpark 让 LFM2.5-2.6B 的延迟平均降低了 57%。
对于LFM2.5-1.2B-Instruct，不同数据集的接受率差异更大，因此加速效果也会随底层文本分布变化，最高可相差 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 |
| 平均值 | 5.02 | 2.10x 656 → 1384 tok/s | 2.54x 138 → 350 tok/s |
对于 LFM2.5-8B-A1B，其接受率高于两款稠密模型，但在设备端平均提升仅为 18%。这主要是因为 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 |
| 平均值 | 6.95 | 2.54x 418 → 1074 tok/s | 1.18x 90 → 106 tok/s |
如何使用 LFM2.5-DSpark
要使用 SGLang 运行 DSpark 草稿模型，需要安装支持 LFM2 目标模型的 DSpark 版本 SGLang（参见 PR #31041）。启动目标模型时附加草稿模型：
python -m sglang.launch_server \
--model-path LiquidAI/LFM2.5-2.6B \
--speculative-algorithm DSPARK \
--speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark \
--speculative-draft-attention-backend flashinfer \
--disable-radix-cache --mem-fraction-static 0.75 --port 30000
然后访问 OpenAI 兼容的端点 http://localhost:30000/v1。block size 从 draft 模型的 config.json 中读取；基线测试使用不带这三个 --speculative-* 参数的同一条命令。
使用 llama.cpp 运行时，需要使用对应的 llama.cpp 构建版本（PR#27383）。
llama-server -m LFM2.5-2.6B-F16.gguf \
-md LFM2.5-2.6B-DSpark-F16.gguf \
--spec-type draft-dspark --spec-draft-n-max 10 --spec-draft-n-min 0 \
-fa on -ngl 99
block size 从 sidecar 元数据中读取（n-max 不会超过该值）。推测解码是严格一致的：目标模型会验证每个候选 token，因此 greedy 输出与仅运行目标模型时完全一致；每次响应的 timings 中会报告 draft_n 和 draft_n_accepted。
开始使用
DSpark draft 模型的 checkpoint 已在 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
期待看到你用它构建出精彩的应用。
引用
引用本文时，请使用以下参考文献或 BibTeX：
Liquid AI，《LFM2.5-DSpark：从 H100 到 MacBook，推理速度最高提升 3.2 倍》，Liquid AI Blog，2026 年 8 月。
@article{liquidAI2026dspark,
author = {Liquid AI},
title = {LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook},
journal = {Liquid AI Blog},
year = {2026},
note = {www.liquid.ai/blog/lfm2.5-dspark},
}