LFM2.5-DSpark 草稿模型发布:推测解码提速至多约 3.2 倍
Liquid AI 于 2026 年 8 月 20 日发布 LFM2.5 系列的 DSpark 草稿模型检查点,覆盖 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 与 LFM2.5-8B-A1B。官方称在基本不改变输出质量的前提下以少量额外内存换取解码加速,GPU 上吞吐提升最高约 3.18 倍,端侧最高约 2.87 倍,并称对 LFM2.5-2.6B 的函数调用延迟平均降低 57%。
发布内容
Liquid AI 于 2026 年 8 月 20 日发布 LFM2.5 系列的 DSpark 草稿模型检查点,覆盖 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 与 LFM2.5-8B-A1B 三个目标模型。草稿模型以 Safetensors 与 GGUF 两种格式提供,并同步开源 llama.cpp 与 SGLang 的 LFM 兼容 DSpark 集成。
原理
LLM 解码阶段通常受内存带宽限制,延迟主要来自把权重从 DRAM 搬到 SRAM,而非计算。推测解码用一个轻量草稿模型生成候选 token,再让目标模型在一次前向中统一验证,从而分摊权重读取开销。DSpark 在该思路上组合三部分:以目标模型上下文特征为条件的 DFlash 式并行主干、建模相邻 token 依赖的轻量马尔可夫头,以及预测 token 存活概率并在收益不足时裁剪低置信后缀的置信度调度验证器。
训练与规模
官方称使用覆盖 SFT、聊天、代码与函数调用数据的更大混合数据集,草稿模型为 5 层、块大小 9 的纯注意力结构,每个数据集训练 15 个 epoch,并按最高接受率而非最低损失选择 epoch。模型规模约 3 亿参数,各目标模型的草稿模型总量在 295.7M 至 327.7M 之间。
质量与速度
在贪心解码下,草稿 token 被接受当且仅当与目标分布一致,被拒时由目标模型自选 token 取代,因此输出序列按构造与基线相同,基准准确率不变。
测试条件为:端侧使用 M4 Max MacBook Pro 上 llama.cpp 与 Metal、FP16 GGUF 权重、最多 256 个输出 token;GPU 使用单张 H100 80 GB 上 SGLang、BF16;均为块大小 9、批大小 1、温度 0,评测 5 个数据集。
- LFM2.5-2.6B:H100 平均 2.67 倍(323 → 864 tok/s),M4 Max 平均 2.27 倍(61 → 139 tok/s)。
- LFM2.5-1.2B-Instruct:H100 平均 2.10 倍,M4 Max 平均 2.54 倍;官方称接受率随文本分布差异较大,加速幅度最多可相差 52%。
- LFM2.5-8B-A1B:H100 平均 2.54 倍,但 M4 Max 平均仅 1.18 倍;官方将端侧差距归因于 llama.cpp Metal 后端当前的 MoE 实现,以及验证 k 个 token 会激活更多专家、带来更多权重搬运。
此外,官方称在多工具场景下,LFM2.5-2.6B 的延迟平均降低 57%。
使用方式
SGLang 需使用支持 LFM2 目标 DSpark 的构建,以 --speculative-algorithm DSPARK 等参数挂载草稿模型;llama.cpp 需对应构建,通过 --spec-type draft-dspark 等参数加载 sidecar 草稿 GGUF。块大小从草稿配置或 sidecar 元数据读取,基线为去掉相应参数的同一条命令。推测解码是精确的,逐响应计时会报告 draft_n 与 draft_n_accepted。具体参数与版本要求以原文和对应 PR 为准。
来源与核对说明
- Hugging Face 官方博客 ↗https://huggingface.co/blog/LiquidAI/lfm25-dspark
本文经 AI 整理及独立自动校对,未做运行验证;自动校对仍可能遗漏问题,请以原始资料为准。
这篇内容对你有帮助吗?
点赞人数由服务器记录,收藏保存在当前浏览器。
继续阅读
Meta 发布 Muse Glimmer 30B:面向本地智能体场景的开源多模态模型 →
NVIDIA Magpie 多语言 TTS 扩展至 12 种语言 →