8 月 20 日，Liquid AI 在 Hugging Face 放出一组 LFM2.5-DSpark 草稿模型，给自家三个模型配上投机解码：LFM2.5-1.2B-Instruct、2.6B 和 8B-A1B。官方给出的加速幅度最高 3.18 倍，输出结果与原模型完全一致。
投机解码的思路不复杂：让一个小模型先把接下来几个词猜出来，大模型不再逐词计算，而把这一串候选放进一次前向传播里批量验证。猜中就直接用，猜错才回炉重算。省下来的全是权重反复搬进搬出的时间。
655MB 换来两三倍
Liquid AI 这次配的草稿模型都很小。1.2B 版本对应 2.957 亿参数，2.6B 和 8B-A1B 共用一个 3.277 亿参数的版本。结构是 5 层全注意力，隐藏维度 2048，中间层 6144，32 个查询头共享 8 组 KV，每次提议 9 个候选词。BF16 精度下，显存占用 655MB。
拿一台 16GB 内存的 Mac 粗算：655MB 大约占总内存的 4%，换来的是本地对话响应快一倍多。这个交换比在端侧场景里相当划算。端侧最缺的从来都不是算力峰值，是等待时那几秒空白。
数字得看跑在什么硬件上
官方基准分了两套环境，结果差得不小。
| 目标模型 | H100 均值 | H100 峰值 | M4 Max 均值 | M4 Max 峰值 |
|---|---|---|---|---|
| 1.2B-Instruct | 2.10x | 2.56x | 2.54x | 2.87x |
| 2.6B | 2.67x | 3.06x | 2.27x | 2.63x |
| 8B-A1B | 2.54x | 3.18x | 1.18x | 1.44x |
标题上那个 3.18 倍来自 8B-A1B 在 H100 上的最好成绩。同一个模型换到 M4 Max 笔记本上只剩 1.18 倍。Liquid AI 自己把原因写了出来：llama.cpp 的 Metal 后端目前对混合专家结构的实现不够好，端侧 MoE 是这套方案的弱项。
接受率数据也一并公开了。8B-A1B 在 MATH500 上平均每 10 个候选词能被接受 8.27 个，GSM8K 上只有 4.02 个。数学证明这类文本结构规整、可预测性强，草稿模型猜得准；换成小学应用题那种表述随意的题面，命中率立刻掉一半。
另一项数据更贴近实际用途：多工具函数调用场景下，2.6B 版本的延迟平均降了 57%。Agent 每一步都要等模型吐出结构化调用，这类往返最怕延迟叠加。
方法是从哪儿来的
DSpark 这个名字不是 Liquid AI 起的。它出自今年 6 月底 DeepSeek 与北京大学联合开源的一篇工作，用并行草稿骨干配上轻量马尔可夫头，再加一层按 GPU 实时负载调度验证长度的机制。当时给出的数据是单用户生成速度提升 60% 到 85%，严格延迟目标下单卡吞吐最高冲到 6.6 倍。
两个月后，这套方法出现在一家美国端侧模型公司的发布里。SGLang 的启用方式是加一个 --speculative-algorithm DSPARK 参数，llama.cpp 首日支持 Metal 后端的 FP16 GGUF。上游框架把算法名当成开关值写进命令行，这件事本身就说明方法已经被当作既成标准。
国内实验室这两年开源了不少推理侧的工程成果，讨论多半集中在能不能省卡。DSpark 这次外溢给出了另一种回报：方法进了别人的默认路径，后续基于该框架的部署都在跑你的思路。
许可证划了一条线
权重以 Safetensors 和 GGUF 两种格式发布，走 LFM 开放许可证 1.0：年营收低于 1000 万美元的主体可以免费商用，超过这条线得单独谈商业协议。部署方式只有自托管一种，Liquid AI 没有提供托管 API。
这条线卡在创业公司和中大型企业之间，意图相当明确——用免费额度换开发者的默认选择，把收入留给付得起的那一档。
参考来源：Hugging Face 官方博客、Liquid AI 模型卡、CocoLoop、MarkTechPost；加速倍数、参数量与接受率数据以官方基准表为准，许可证条款以模型页面为准。