Liquid AI 在8月20日给自家 LFM2.5 系列配了一套加速外挂:DSpark草稿模型检查点。官方数字很漂亮——GPU上最高3.18倍吞吐,端侧最高2.87倍,2.6B模型的函数调用延迟平均砍掉57%,还宣称llama.cpp和SGLang"day-one支持"。但把这份公告和当天能查到的生态现状对照一下,"day-one"这个词的成色,没有公告读起来那么足。
三个数字，一套三件套原理
投机解码的思路不新:decode阶段大部分时间耗在把权重从DRAM搬进SRAM,不是算力不够,是搬得慢。让一个轻量草稿模型先吐一串候选token,目标模型一次前向验证全部,权重加载的成本就摊到了多个token头上。
DSpark是这条路线上最新一版方案,拼了三块东西:DFlash式并行backbone一次性产出所有草稿token的隐藏态,Markov链式头给相邻token补上依赖关系防止后段接受率掉水,置信度调度器在验证不划算时直接剪掉低置信度的尾部。三块拼起来,草稿模型体量不大,约3亿参数,贪婪解码下输出理论上和baseline逐字一致。
加速比背后，得挤一挤水分
DSpark这个方法本身另有出处,原始论文对比的是行业里常见的MTP-1生产基线,给出的加速幅度是60%到85%。Liquid这次对比的baseline不一样,3.18倍换算成百分比接近218%,两组数字看着都在说"更快",但口径不同,不能直接摆在一起比大小。
"day-one支持llama.cpp"这句话也值得多看一眼。llama.cpp官方文档目前公开列出的DSpark支持,主干只有Qwen3,其余架构标注的是"计划中"。Liquid所说的LFM兼容实现如果确实存在,大概率还压在某个尚未合并的PR或实验分支上,离主线文档同步还有一步。Hugging Face上关联的草稿模型仓库,上传者正是本文的作者之一,更像是团队自己的工程产物,还够不上独立第三方的对齐验证。
快不快看芯片，信不信看第三方。
发布会讲的"day one",和代码仓库commit日历上的"day one",经常不是同一天。这不是说Liquid在撒谎,更可能是发布节奏跑在了生态同步前面——但这个时间差,读者自己要留意。
落地还有几道坎没过
速度提升最扎眼的地方,恰恰也暴露了瓶颈在哪。8B-A1B这款MoE模型,GPU上加速比不差,端侧却只提升了不到两成——因为验证多个token意味着激活更多专家,权重搬运量反而上去了,现有llama.cpp Metal后端还接不住这个账。
- 风险.vLLM社区已有公开issue,报告LFM2这种混合卷积-注意力架构在投机解码场景下,草稿模型的卷积层和注意力层需要不同的KV-cache分组方式,现有框架改动还不足以支撑,这个障碍原文完全没提。
Liquid自己另一篇博客里提到过,2.6B模型在M5 Max上能跑到约220 tok/s——不同芯片代际,不能和这次M4 Max的数据直接对着算,但至少说明端侧速度这件事,不同测试环境下的数字差异本来就大,一份公告里的benchmark只能当参考,不能当承诺。
速度之外，底座本身够不够硬
倍速再好看,最终体验还是取决于底座模型的质量。第三方对LFM2.5-1.2B的工具调用格式做过评测,评测者一开始按标准JSON格式测,分数不高,修正了它偏好的括号式语法之后,才和几款同量级小模型并列榜首——说明它的能力没问题,但对解析格式敏感,不是开箱即用那么简单。
语言可接受性测试里,LFM2.5-1.2B-Instruct的准确率和召回率都明显落后于Qwen3-4B。多模态场景下,它幻觉率低,但对矛盾证据的识别率也低,更像是倾向直接采信文本通道,而不是主动去核对信息是否冲突。
- 结论.DSpark这套加速方案,工程上站得住,贪婪解码下的输出严格等价这一点是可信的。但它加的是速度,不是能力,底座模型本身的短板不会因为跑得快而消失。
一份公告能验证到什么程度,取决于读者愿不愿意去查commit记录、去跑一遍复现。Liquid这次做的是一件工程上扎实的事,DFlash加Markov头加置信度调度,思路清楚,数字也有出处。但"day-one支持"四个字背后,主线文档还没跟上,MoE在端侧的瓶颈也没解决方案,vLLM那边的兼容性问题依然悬着。倍速是真的算出来的,但公告读完就信,和自己动手核对一遍,是两种完全不同的信任成本。