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

DSpark草案模型：不改输出，只提速度

Liquid AI正式发布LFM2.5-DSpark系列草案模型（drafter），覆盖三款基础模型：LFM2.5-1.2B-Instruct、LFM2.5-2.6B和LFM2.5-8B-A1B。每个草案模型均作为轻量级‘推测器’，附加于对应的目标大模型之上，构成推测解码（speculative decoding）流水线。其核心机制是：约300M参数的草案模型一次性生成9个候选token，目标模型则在单次前向传播中完成整块验证。该设计在仅增加少量显存占用的前提下，显著提升解码吞吐量——在NVIDIA H100上最高提速3.18倍，在Apple M4 Max MacBook Pro上达2.87倍；关键的是，greedy解码下的输出序列与目标模型单独运行时完全一致，所有基准测试准确率保持不变。

开源即用，但需自托管

DSpark模型权重已开放下载，格式为Safetensors与GGUF，但目前未接入Hugging Face等托管推理服务。用户需自行部署：须使用支持DSpark的SGLang或llama.cpp定制构建版本，并加载LFM2.5目标模型及其配套草案模型。Liquid AI明确表示‘可部署’（deployable），前提是用户采用自托管方式。开源许可沿用LFM Open License v1.0：年营收低于1000万美元的企业（含独立开发者、初创公司及中小企）可免费商用；超限企业须另行联系获取商业授权。

技术架构：三模块协同优化

DSpark并非简单叠加小模型，而是融合三项创新设计：

• DFlash式并行主干网络：基于目标模型上下文特征进行条件化建模，一次性产出全部9个草案token的隐藏状态；
• 轻量级序列化头部：以秩256的马尔可夫链建模相邻token依赖关系，提升后置位置token的接受率；
• 置信度调度验证器：预测各token存活概率，主动剪枝低置信度后缀，避免验证开销超过收益。

草案模型本身不含词表嵌入与语言建模头权重，加载时直接复用目标模型对应参数。以LFM2.5-2.6B草案为例，BF16格式仅占655MB，即实际新增内存成本。

实测性能：加速比高度依赖任务可预测性

Liquid AI在H100（BF16+SGLang）与M4 Max（FP16+llama.cpp+Metal）平台测试了五大基准（MATH500、HumanEval、MBPP、GSM8K、MT-Bench），统一采用block size=9、batch size=1、temperature=0。结果显示：

• LFM2.5-1.2B-Instruct在H100上平均提速2.10倍（656→1384 tok/s），MATH500单项达2.56倍；
• LFM2.5-2.6B在H100上平均提速2.67倍（323→864 tok/s），MATH500达3.06倍；
• LFM2.5-8B-A1B在H100上平均提速2.54倍（418→1074 tok/s），MATH500峰值达3.18倍（428→1362 tok/s）；

但同一模型在不同任务上差异显著：8B-A1B在MATH500接受率8.27/10，提速3.18倍；在GSM8K接受率仅4.02/10，提速降至1.29倍。MT-Bench下1.2B模型接受率跌至3.90，H100增益亦回落至1.66倍。值得注意的是，8B-A1B在M4 Max上平均仅提速1.18倍（90→106 tok/s），Liquid AI归因于llama.cpp Metal后端对MoE架构支持尚不完善，且验证多token会激活更多专家，加剧权重传输压力。

面向智能体场景的低延迟优势

DSpark的价值在AI智能体（agentic）工作流中尤为突出。Liquid AI实测显示，在多工具调用（multi-tool function-calling）场景下，LFM2.5-2.6B+DSpark可将平均延迟降低57%。典型如‘规划→调用→再规划’的agent交互，每轮用户请求需多次触发解码，提速效果逐层累积。SGLang用户可通过命令行一键启用：指定`--speculative-algorithm DSPARK`及草案模型路径，其余配置与标准部署一致。