8 月 20 日,Liquid AI 在 Hugging Face 上发布了 LFM2.5 家族的 DSpark 草稿模型 checkpoints,覆盖三款目标模型:LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B。这不是新基座,而是给现有模型外挂投机解码引擎——用一个约 300M 参数的 draft 模型先生成候选 token,再由目标模型一次前向批量验证,以极小内存代价换大幅提速。
官方数字:GPU 3.18 倍,端侧 2.87 倍
按 Liquid AI 的测试(SGLang,单张 H100 80GB,BF16),吞吐最高提升 3.18 倍;端侧用 llama.cpp + Metal 在 M4 Max MacBook Pro 上跑 FP16 GGUF,最高 2.87 倍。以 LFM2.5-2.6B 为例,MacBook 上 MATH500 从 61 提到 137 tok/s,MT-Bench 从 62 到 123 tok/s,官方称约 140 tok/s 已超过多数专有云模型的交互吞吐。更实际的是:多工具调用场景下,LFM2.5-2.6B 的函数调用延迟平均降 57%。
DSpark 的三件套
LLM 解码的瓶颈通常不是算力,而是权重从 DRAM 进 SRAM 的带宽。投机解码让轻量 draft 模型连续产候选、目标模型一次验证多个,把权重加载成本摊到多个 token 上。DSpark 把这件事拆成三个组件:DFlash 风格的并行 backbone,以目标模型的上下文特征为条件,一次前向产出所有 draft token 的隐状态;一个建模相邻 token 间马尔可夫链的轻量顺序头,补上 token 间依赖、提高后位接受率;以及一个置信度调度的验证器,预测每个 token 的存活概率,验证不划算时提前剪枝。工程细节有点反直觉:训练跑了 15 个 epoch,最终选的不是 loss 最低、而是接受率最高的点——draft 模型的 KPI 是"被接受",不是自己算得准。
输出零损耗是"构造性"的
很多人担心投机解码牺牲质量,这里不用猜:贪心解码下,draft token 只有与目标模型分布一致才会被接受,被拒位置由目标模型自己的 token 补位,输出序列按构造就与基线完全一致,benchmark 精度(pass@1、exact match)不变。这比"几乎不掉点"的量化路线承诺更硬。
MoE 在端侧撞了墙
有意思的是 8B-A1B(MoE 版):它的接受率反而是三款里最高的(MT-Bench 8.52/10,MATH500 8.27/10),H100 上也打出了 3.18 倍的最高加速,但 M4 Max 端侧平均只提升 18%。官方解释是 llama.cpp Metal 后端的 MoE 实现限制——一次验证 k 个 token 会激活更多专家、带来更多权重流量。换句话说,dense 模型在端侧吃满红利,MoE 还得等推理框架先补课。
llama.cpp(PR #27383)和 SGLang(PR #31041)的集成都已开源上游,checkpoints 提供 Safetensors 和 GGUF 两种格式。与其追下一个更大的基座,不如把"验证是免费的"吃透——对端侧 Agent 来说,延迟降一半比榜单涨一分值钱。详见Liquid AI 官方博客。