跳到正文
北京时间
原文
Hugging Face：Blog（RSS）·· 2026-08-21精选AI 评分61

Hugging Face 发布 LFM2.5 系列 DSpark 草稿模型，推理速度最高提升 3.18 倍

Up to 3.2x Faster Inference with LFM2.5-DSpark

AI 导读

Hugging Face 发布 LFM2.5 系列三款模型的 DSpark 草稿模型检查点，通过投机解码在不改变输出质量的前提下，GPU 吞吐最高提升 3.18 倍，端侧最高 2.87 倍。草稿模型约 300M 参数，LFM2.5-2.6B 函数调用延迟平均降低 57%，已开源支持 llama.cpp 和 SGLang。

推荐理由

约300M参数的draft模型换最高3.18倍吞吐，贪心输出不变，LFM2.5-2.6B在M4 Max达139 tok/s，本地agent门槛被拉低。

正文 · AI 翻译

今天，我们发布了 DSpark 草稿模型检查点，涵盖 LFM2.5 系列中的三个模型：LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B。这些检查点增加了一条投机解码路径，以极小的内存增长换取大幅解码加速，同时不改变输出质量：

  • 更快的推理：在 GPU 上吞吐量提升最高达 3.18 倍，在端侧设备上最高达 2.87 倍。
  • 迈向端侧智能体推理：LFM2.5-2.6B 的函数调用延迟平均降低 57%
  • 首日支持 llama.cpp 和 SGLang：兼容 LFM 的 DSpark 集成已在上游开源

DSpark 如何工作

LLM 推理中的解码阶段传统上受内存带宽限制。大部分延迟来自将权重从 DRAM 流式传输到 SRAM，而非密集计算。投机解码通过使用一个轻量级草稿模型生成候选 token，然后让目标模型在一次前向传播中验证所有这些 token，从而将权重加载的成本分摊到所有被验证的 token 上，以此解决该问题。

多年来，业界提出了多种投机方法，其中最突出的包括 EAGLE-3、DFlash，以及最近的 DSpark，后者结合了三个组件：

  • DFlash 风格的并行主干网络，以目标模型的上下文特征为条件，在一次前向传播中为所有草稿 token 生成隐藏状态。
  • 一个轻量级顺序头，建模为相邻 token 之间的马尔可夫链，用于添加 token 间依赖关系，从而提高后续位置的接受率。
  • 一个置信度调度的验证器，它预测每个 token 的存活概率，并在验证成本高于其节省的成本时，剪除低置信度的后缀。

训练与架构

我们遵循 DSpark 方案，使用了更大且更多样化的数据混合，涵盖 SFT、chat、code 和 function-calling 数据。基于我们的消融实验，草稿模型的第一个版本是简化版的纯注意力草稿模型，具有 5 层和一个大小为 9 的块。对于每个草稿模型，我们在整个数据集上运行了 15 个 epoch，并选择接受率最高的 epoch，而非损失最低的 epoch。

由此得到的草稿模型相对较小，每个大约 ~300M 参数。

组件 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
马尔可夫头 33.6M 65.5M 65.5M
归一化层 + 置信度头 27.5k 27.5k 27.5k
总计 295.7M 327.7M 327.7M

质量持平

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

在 CPU 和 GPU 上的推理加速

我们为 LFM2.5 打造的 DSpark 草稿模型在发布首日即支持 llama.cpp（实现基于官方代码库构建，我们以实验性 metal 内核运行）以及 **SGLang**（实现基于 DSpark 的官方 SGLang 实现构建）。

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

这三个草稿模型在大规模加速器（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

然后查询位于 http://localhost:30000/v1 的 OpenAI 兼容端点。块大小从草稿模型的 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

块大小从 sidecar 元数据中读取（n-max 会被钳制到该值）。投机解码是精确的：目标模型会验证每一个候选 token，因此贪心输出等同于仅使用目标模型；每个响应的 timings 报告 draft_n / draft_n_accepted。

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

我们迫不及待想看到你构建的作品。

引用

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

Liquid AI，《LFM2.5-DSpark：从 H100 到 MacBook 最高实现 3.2 倍推理加速》，Liquid AI 博客，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},
}

来源：Hugging Face：Blog（RSS） · huggingface.co

#推理#模型发布#部署/工程