Liquid AI 发布 LFM2.5-DSpark 草案模型，推理最高提速 3.18 倍

Liquid AI 近日在 Hugging Face Blog 发布 LFM2.5 系列的 DSpark 草案模型权重，覆盖 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B 三款模型。该草案模型配合推测解码路径，可在几乎不增加显存的前提下显著提升解码速度，且不改变输出质量。实测显示，在 H100 GPU 上推理吞吐最高可达 3.18 倍加速，在 M4 Max MacBook 上端侧推理最高可达 2.87 倍加速。

DSpark 的工作机制

LLM 推理的解码阶段通常受显存带宽制约：大部分延迟来自将权重从 DRAM 流式加载到 SRAM，而非计算本身。推测解码（speculative decoding）的思路是用一个轻量级草案模型先生成候选 token，再由目标模型在一次前向传播中统一验证，从而把加载权重的开销分摊到多个被验证的 token 上。

DSpark 是这一方向的最新方案，融合了三种思路：

• DFlash 风格的并行骨干网络：以目标模型的上下文特征为条件，在一次前向中为所有草案 token 生成隐藏状态。
• 轻量级序列头：建模相邻 token 之间的马尔可夫链依赖，提高后续位置的接受率。
• 置信度调度的验证器：预测每个 token 的存活概率，在验证收益小于成本时剪除低置信后缀。

训练与架构要点

Liquid AI 采用更大的数据混合，涵盖 SFT、对话、代码与函数调用数据，每款草案模型训练 15 个 epoch，并按验收率而非 loss 选取最佳 checkpoint。结构上，草案模型是简化的纯注意力模型，共 5 层，block size 为 9。

各组件参数规模如下：

• 解码层（5 layer）：约 241.2M
• 隐藏状态投影：约 21.0M
• 马尔可夫头：1.2B 版本约 33.6M，2.6B 与 8B-A1B 版本约 65.5M
• 归一化与置信度头：约 27.5K
• 总参数：1.2B 版本约 295.7M，2.6B 与 8B-A1B 版本约 327.7M

在 greedy 解码下，草案 token 只有在匹配目标模型分布时才会被接受，被拒绝的位置由目标模型自填，输出序列与基线 greedy 解码在构造上完全一致，因此 pass@1、exact match 等基准精度不发生变化。

推理速度实测

DSpark 草案模型在 llama.cpp 与 SGLang 上均获首日支持，其中 SGLang 实现基于官方 DSpark 实现，llama.cpp 实现运行在实验性 Metal kernel 上。GPU 端在单卡 H100 80GB（BF16）测试，端侧在 M4 Max MacBook Pro（FP16 GGUF）测试，DSpark block size 为 9、batch size 为 1、温度为 0，覆盖五个基准数据集。

LFM2.5-2.6B

• H100：平均 2.67 倍加速，吞吐从 323 tok/s 提升至 864 tok/s
• M4 Max：平均 2.27 倍加速，吞吐从 61 tok/s 提升至 139 tok/s
• 多工具场景下，函数调用延迟平均降低 57%

LFM2.5-1.2B-Instruct

• H100：平均 2.10 倍加速，吞吐从 656 tok/s 提升至 1384 tok/s
• M4 Max：平均 2.54 倍加速，吞吐从 138 tok/s 提升至 350 tok/s
• 不同数据集加速差异较大，最高可达 52%

LFM2.5-8B-A1B

• H100：平均 2.54 倍加速，吞吐从 418 tok/s 提升至 1074 tok/s
• M4 Max：平均仅 1.18 倍加速，提升有限
• 端侧加速受限，主要原因是 llama.cpp 的 Metal 后端当前 MoE 实现以及验证 k 个 token 会激活更多专家、增加权重搬运开销

上手与生态

LFM2.5-DSpark 在 SGLang 上需要支持 LFM 目标 DSpark 的构建（PR #31041），在 llama.cpp 上则通过实验性 Metal kernel 部署。由于草案模型仅约 300M 参数，显存与内存开销增量极小，但收益随目标模型规模、上下文与数据集分布而变化，对 MoE 模型的端侧收益仍需后续优化。