Liquid AI 发布 LFM2.5-DSpark 草稿模型：推理速度提升最高 3.18 倍

Liquid AI 发布 LFM2.5-DSpark 草稿模型：推理速度提升最高 3.18 倍 | 前端进阶之旅

Full translation

完整中文译文

Liquid AI 发布了 LFM2.5 家族三个模型的 DSpark draft model 检查点：LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B。每个 drafter 为现有的目标模型增加一条投机解码路径。一个约 300M 参数的 draft 模型提出 9 个候选 token 区块，目标模型在单次前向传播中验证整个区块。代价是少量内存增加，换来大比例的解码加速：在 H100 上最高 3.18x，在 M4 Max MacBook Pro 上最高 2.87x。输出不会改变。在贪心解码下，输出的序列与目标模型单独运行时完全相同，因此基准测试精度不变。llama.cpp 和 SGLang 在发布当天即支持。

自托管

是的，可以自托管。权重以 Safetensors 和 GGUF 格式发布，目前 Hugging Face 上没有任何托管推理提供商提供 drafter 检查点。运行它们需要 SGLang 或 llama.cpp 构建版本，且支持 LFM2 目标的 DSpark。

许可

公司层面：LFM Open License v1.0 允许你的实体在年收入低于 1000 万美元期间免费商业使用。独立开发者、初创公司和中小企业均在覆盖范围内；大型企业需先联系 Liquid AI 获取商业许可。

适用行业

开发者工具、在本地运行的消费级应用、机器人技术和嵌入式系统，以及医疗、金融和国防领域需要在本地或设备上保留数据的 workloads。

适用场景

本地 coding assistants、在每次 tool call 前进行推理的端侧 agents、单用户 chat（batch size 为 1）、以及笔记本级硬件上的离线 copilots。

投机解码技术详解

投机解码使用一个小模型来提出 token，再由大模型验证。每个 LFM2.5 drafter 约 300M 参数：1.2B-Instruct 目标对应的 drafter 为 295.7M，2.6B 和 8B-A1B 目标对应的 drafter 为 327.7M。backbone 是 5 层全注意力层，hidden_size=2048，intermediate_size=6144，GQA 配置为 32 个 head 对 8 个 KV head，block size 为 9。drafter 不携带词汇权重；embedding 和 LM head 在加载时从目标模型共享。2.6B drafter 仓库在 BF16 格式下为 655 MB，这是你实际增加的内存开销。

DSpark 由三部分组成。一个类似 DFlash 风格的并行 backbone，以目标模型的上下文特征为条件，在单次前向传播中为所有 draft token 生成 hidden states。一个轻量级的顺序 head，在 rank 256 处建模为相邻 token 之间的马尔可夫链，恢复 token 间的依赖性，并提升区块靠后位置的接受率。一个置信度调度的验证器，预测每个 token 的存活概率，在验证成本超过收益时剪除低置信度后缀。

性能数据

Liquid AI 通过 SGLang 报告了 1xH100 BF16 模式下的吞吐量，通过 llama.cpp（Metal + FP16 GGUF 权重）在 M4 Max MacBook Pro 上报告了性能。两者均使用 block size 9、batch size 1 和 temperature 0，测试集包括 MATH500、HumanEval、MBPP、GSM8K 和 MT-Bench。

目标模型	H100 平均	H100 最佳	M4 Max 平均	M4 Max 最佳
LFM2.5-1.2B-Instruct	2.10x (656 → 1384 tok/s)	2.56x on MATH500	2.54x (138 → 350 tok/s)	2.87x on HumanEval (136 → 389)
LFM2.5-2.6B	2.67x (323 → 864 tok/s)	3.06x on MATH500	2.27x (61 → 139 tok/s)	2.63x on HumanEval
LFM2.5-8B-A1B	2.54x (418 → 1074 tok/s)	3.18x on MATH500 (428 → 1362)	1.18x (90 → 106 tok/s)	1.44x on GSM8K

加速比与接受率正相关，而接受率与输出的可预测性正相关。LFM2.5-8B-A1B 在 MATH500 上每个 step 接受 8.27/10 个 token，而在 GSM8K 上只有 4.02，因此同一模型在同一 GPU 上从 3.18x 降到 1.29x。在 1.2B 模型上，MT-Bench 接受率降至 3.90，H100 收益降至 1.66x。

Apple 硅上的 MoE 结果是最明显的警示：LFM2.5-8B-A1B 在 M4 Max 上平均仅获得 1.18x 提升。Liquid AI 将此归因于 llama.cpp Metal backend 中当前 MoE 的实现方式，以及验证 k 个 token 会激活更多 experts，因此带来更多权重流量，而非单次 decode step。

收益集中在用户等待推理完成后才执行每次 tool call 的场景。在多工具 function-calling 场景中，Liquid AI 报告 DSpark 使 LFM2.5-2.6B 的延迟平均降低 57%。用你自己的 traces 测试：一个先规划、再调用、再规划的 agent，每个用户 turn 要支付好几次 decode 成本。

使用方法

在 SGLang 上，启动时附加 drafter：

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

block size 从 drafter 的 config.json 读取，baseline 是同一命令但不带那三个 --speculative-* 标志。

总结

DSpark drafters 增加约 300M 参数，在 H100 上实现最高 3.18x 的解码加速。

贪心输出与 baseline 完全相同，因此基准测试精度不变。

加速比随接受率变化，因工作负载不同从 1.04x 到 3.18x 不等。

端侧 MoE 是短板：LFM2.5-8B-A1B 在 M4 Max 上仅获得 1.18x。

多工具 function calling 获得最大的实际收益：LFM2.5-2.6B 延迟降低 57%。