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

DSpark 如何工作：#how-does-dspark-work 训练与架构：#training-and-architecture 质量一致性：#quality-parity CPU 和 GPU 上的推理加速：#inference-speed-up-on-cpu-and-gpu 如何使用 LFM2.5-DSpark：#how-to-use-lfm25-dspark 快速开始：#get-started 引用：#citation 今天，我们发布了 LFM2.5 系列的三个模型的 DSpark 草稿模型检查点：LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B。这些模型增加了一条推测解码路径，通过极小的内存增量换取巨大的解码加速，同时不改变输出质量：

LLM 推理中的解码阶段传统上受到内存限制。大部分延迟来自将权重从 DRAM 流入 SRAM，而不是密集计算。推测解码通过使用轻量级草稿模型生成候选 token，然后让目标模型在单次前向传播中验证所有 token，从而将加载权重的成本分摊到所有验证的 token 上。

多年来，已提出多种推测方法，其中最著名的是 EAGLE-3：https://huggingface.co/papers/2503.01840、DFlash：https://huggingface.co/papers/2602.06036，最近的是 DSpark：https://huggingface.co/papers/2607.05147，它结合了三个组件：

：https://cdn-uploads.huggingface.co/production/uploads/644249b08443bce4c9890a0f/QSig7XupRwDH70cDopwv2.png

我们遵循 DSpark 配方，使用覆盖 SFT、聊天、代码和函数调用数据的更大且更丰富的数据混合。根据我们的消融实验，草稿模型的初始版本为简化的仅注意力草稿模型，具有 5 层和 9 个块。对于每个草稿模型，我们在整个数据集上运行了 15 个 epoch，并选择具有最高接受率而不是最低损失的 epoch。

最终的草稿模型相对较小，每个模型约 ~300M 参数。

在贪婪解码下，只有当草稿 token 与目标模型的分布匹配时才会被接受。若被拒绝，则由目标模型自身的 token 替代。因此，生成的序列在构建上与基线贪婪解码完全相同，因此基准准确性（pass@1 或完全匹配）保持不变。

我们的 DSpark 草稿模型针对 LFM2.5 提供了开箱即用的 llama.cpp 支持（日一支持）（实现基于官方代码库：https://github.com/ggml-org/llama.cpp/pull/27383，我们使用实验性 Metal 内核运行：https://github.com/ggml-org/llama.cpp/pull/27441），以及 **SGLang**（实现基于 DSpark 官方 SGLang 实现：https://github.com/sgl-project/sglang/pull/31041）。

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

三种草稿模型在大规模加速器（H100）和边缘部署（M4 Max MacBook）上均能显著提升吞吐量。

对于 LFM2.5-2.6B，MacBook 上的加速尤其明显，因为它将用户的交互体验水平远远超越大多数专有云模型所提供的吞吐量（约 ~140 tok/s，具体取决于数据集）。

在各种多工具场景下，DSpark 平均减少 LFM2.5-2.6B 的延迟 57%。

：https://cdn-uploads.huggingface.co/production/uploads/644249b08443bce4c9890a0f/RTL-W6OBn97nMW7gkkT-e.png

对于 LFM2.5-1.2B-Instruct，我们观察到数据集接受率变化很大，因此加速效果根据底层文本分布可能变化高达 52%。

对于 LFM2.5-8B-A1B，与两个密集模型相比，接受率提高，但在设备端平均仅提升 18%。这一差距是由于 llama.cpp Metal 后端当前的 MoE 实现，以及验证 k 个 token 会激活更多专家，从而产生比单次解码步骤更多的权重流量。

使用 SGLang 运行 DSpark 草稿模型需要具有 LFM2 支持的 SGLang 构建（PR #31041：https://github.com/sgl-project/sglang/pull/31041）。启动目标时附上草稿：

然后在 http://localhost:30000/v1 查询兼容 OpenAI 的端点。块大小从草稿的 config.json 中读取；基线为不加三个 --speculative-* 标志的相同命令。

使用 llama.cpp 运行它们需要相应的 llama.cpp 构建（PR#27383：https://github.com/ggml-org/llama.cpp/pull/27383）。

块大小是从 sidecar 元数据中读取的（n-max 会被限制到该值）。推测性解码是精确的：目标会验证每个提议的令牌，因此贪婪输出仅等于目标；每次响应的时间报告 draft_n / draft_n_accepted。

DSpark 草稿模型检查点可在 Hugging Face 上以 Safetensors 和 GGUF 格式获取：

我们迫不及待想看看你们会构建什么。

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

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

How does DSpark work ：#how-does-dspark-work Training and Architecture ：#training-and-architecture Quality parity ：#quality-parity Inference Speed Up on CPU and GPU ：#inference-speed-up-on-cpu-and-gpu How to use LFM2.5-DSpark ：#how-to-use-lfm25-dspark Get Started ：#get-started Citation ：#citation Today, we release DSpark draft model checkpoints for three models from our LFM2.5 family: LFM2.5-1.2B-Instruct, LFM2.5-2.6B, and LFM2.5-8B-A1B. These add a speculative decoding path that trades a minimal memory increase for a large decoding speedup without changing output quality:

The decode phase in LLM inference is traditionally memory-bound. Most latency comes from streaming weights from DRAM into SRAM, not from intense computation. Speculative decoding addresses this by using a lightweight draft model to produce candidate tokens, then having the target model verify them all in a single forward pass, sharing the cost of loading the weights across all tokens we verify.

Over the years, multiple approaches of speculation have been proposed, with the most prominent being EAGLE-3：https://huggingface.co/papers/2503.01840, DFlash：https://huggingface.co/papers/2602.06036, and, most recently, DSpark：https://huggingface.co/papers/2607.05147, which combines three components:

：https://cdn-uploads.huggingface.co/production/uploads/644249b08443bce4c9890a0f/QSig7XupRwDH70cDopwv2.png

We follow the DSpark recipe with a larger and more diverse data mix covering SFT, chat, code, and function-calling data. Based on our ablations, the first versions of the draft models are simplified attention-only draft models, with 5 layers and a block of 9. For each draft model, we ran 15 epochs on the entire dataset and selected the epoch with the highest acceptance rate rather than the lowest loss.

The resulting draft models are relatively small, with each around ~300M parameters.

Under greedy decoding, a draft token is only accepted if it matches the target model’s distribution. On rejection, the target model's own token takes its place. The emitted sequence is therefore identical to baseline greedy by construction, so benchmark accuracy (pass@1 or exact match) is unchanged.

Our DSpark draft models for LFM2.5 ship with day-one support for llama.cpp (implementation builds on top of the official codebase：https://github.com/ggml-org/llama.cpp/pull/27383, which we run with experimental metal kernels：https://github.com/ggml-org/llama.cpp/pull/27441) and **SGLang (**implementation builds on the official SGLang implementation of DSpark：https://github.com/sgl-project/sglang/pull/31041).

We measure on-device throughput with llama.cpp and Metal on an M4 Max MacBook Pro using FP16 GGUF weights and up to 256 output tokens. We measure GPU throughput with SGLang on a single H100 80 GB in BF16. Both configurations use a DSpark block size of 9, a batch size of 1, and a temperature of 0. We evaluate them on five benchmark datasets.

All three drafter models deliver noticeable throughput improvements on both the large-scale accelerator (H100) and the edge deployment (M4 Max MacBook).

For LFM2.5-2.6B, speedup on the MacBook is especially noticeable, as it pushes the interactivity level a user can enjoy far beyond the throughput offered by most proprietary cloud models (around ~140 tok/s, depending on the dataset).

Across various multi-tool scenarios, DSpark reduces the latency by 57% on average for LFM2.5-2.6B.

：https://cdn-uploads.huggingface.co/production/uploads/644249b08443bce4c9890a0f/RTL-W6OBn97nMW7gkkT-e.png

For LFM2.5-1.2B-Instruct , we see much more variance in dataset acceptance rates, so speedup varies by as much as 52% depending on the underlying text distribution.

For LFM2.5-8B-A1B , the acceptance rate increases compared to two dense models, yet on-device we get only an 18% improvement on average. This gap is due to the current MoE implementation in llama.cpp's Metal backend, and to the fact that verifying k tokens activates more experts and thus more weight traffic than a single decode step.

Running the DSpark draft models with SGLang requires an SGLang build with DSpark support for LFM2 targets (PR #31041：https://github.com/sgl-project/sglang/pull/31041). Launch the target with the draft attached:

Then query the OpenAI-compatible endpoint at http://localhost:30000/v1 . The block size is read from the draft's config.json ; the baseline is the same command without the three --speculative-* flags.

Running them with llama.cpp requires the respective llama.cpp build (PR#27383：https://github.com/ggml-org/llama.cpp/pull/27383).

The block size is read from the sidecar metadata (n-max is clamped to it). Speculative decoding is exact : the target verifies every proposed token, so greedy output equals the target alone; per-response timings report draft_n / draft_n_accepted .

The DSpark draft model checkpoints are available on Hugging Face as Safetensors and in GGUF format:

We can’t wait to see what you build.

For citations, please use the following reference or BibTeX:

Liquid AI, "LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook", Liquid AI Blog, Aug 2026.