热点精选Hugging Face Blog新闻

LFM2.5-DSpark：从 H100 到 MacBook 推理速度提升最高 3.2 倍

5 小时前huggingface.co模型开源AI评分：70/100

Liquid AI 发布 LFM2.5-DSpark 投机解码草案模型，针对 LFM2.5 系列实现最高 3.2 倍推理加速。该方案结合 DFlash 风格并行主干、马尔可夫链顺序头和置信度调度验证器，在 H100 上平均提速 2.67 倍，在 M4 Max MacBook 上平均提速 2.27 倍，并将函数调用延迟降低 57%。草案模型约 3 亿参数，已开源并支持 llama.cpp 和 SGLang。

推理速度提升高达 3.2 倍：LFM2.5-DSpark

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

DSpark 的工作原理

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

多年来，学界提出了多种推测方法，其中最著名的包括 EAGLE-3、DFlash，以及最新的 DSpark。DSpark 结合了三个组件：

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

训练与架构

我们遵循 DSpark 的方案，但使用了更大、更多样化的数据混合，涵盖 SFT、聊天、代码和函数调用数据。根据我们的消融实验，草稿模型的首个版本是简化的仅注意力模型，包含 5 层和大小为 9 的块。对于每个草稿模型，我们在整个数据集上运行了 15 个 epoch，并选择了接受率最高而非损失最低的 epoch。

由此产生的草稿模型相对较小，每个模型约有 3 亿参数。

组件	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

质量一致性

在贪婪解码下，草稿词元只有在与目标模型的分布匹配时才会被接受。若被拒绝，则由目标模型自身的词元取而代之。因此，生成的序列在构造上与基线贪婪解码完全一致，基准测试准确率（pass@1 或精确匹配）保持不变。

CPU 和 GPU 上的推理加速

我们为 LFM2.5 推出的 DSpark 草稿模型首发即支持 llama.cpp（实现基于官方代码库构建，我们使用实验性的 Metal 内核运行）和 SGLang（实现基于 SGLang 官方的 DSpark 实现构建）。

我们使用 llama.cpp 和 Metal 在 M4 Max MacBook Pro 上测量端侧吞吐量，使用 FP16 GGUF 权重，最多生成 256 个输出词元。我们使用 SGLang 在单个 H100 80 GB GPU 上以 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.06 倍 326 → 1000 tok/s	2.25 倍 61 → 137 tok/s
HumanEval	4.54	2.56 倍 326 → 835 tok/s	2.63 倍 61 → 161 tok/s
MBPP	4.71	2.64 倍 326 → 861 tok/s	2.11 倍 62 → 132 tok/s
GSM8K	4.32	2.22 倍 312 → 693 tok/s	2.36 倍 60 → 143 tok/s
MT-Bench	5.07	2.87 倍 325 → 933 tok/s	1.99 倍 62 → 123 tok/s
平均值	4.81	2.67 倍 323 → 864 tok/s	2.27 倍 61 → 139 tok/s

在各种多工具场景中，DSpark 将 LFM2.5-2.6B 的延迟平均降低了 57%。

对于 LFM2.5-1.2B-Instruct，我们观察到数据集接受率的差异更大，因此加速比根据底层文本分布的不同，波动幅度最高可达 52%。

对于 LFM2.5-8B-A1B，与两个稠密模型相比，接受率有所提高，但在端侧我们仅获得了平均 18% 的提升。这一差距源于 llama.cpp 的 Metal 后端中当前 MoE 实现的限制，以及验证 k 个词元会激活更多专家，从而比单步解码产生更多权重流量的事实。

如何使用 LFM2.5-DSpark

使用 SGLang 运行 DSpark 草稿模型需要一个支持 LFM2 目标 DSpark 的 SGLang 构建版本（PR #31041）。启动目标模型并附加草稿模型：

然后用以下命令查询兼容 OpenAI 的端点 http://localhost:30000/v1。块大小从草稿模型的 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，因此贪心解码的输出与仅使用目标模型时完全一致；每次响应的计时会报告 draft_n / draft_n_accepted。

快速开始

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

我们非常期待看到你的成果。

引用

如需引用，请使用以下参考文献或 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},
}

阅读原文