이미지: X — 모델·오픈소스 영상 갈무리
摘要
- Liquid AI发布了面向LFM2.5-1.2B-Instruct、2.6B、8B-A1B的DSpark草稿模型，各自参数量约为3亿。
- 在H100上最高提速3.18倍（428→1362 tok/s），在M4 Max MacBook Pro上最高提速2.87倍（136→389 tok/s），且在贪心解码下输出文本与原模型完全相同。
- 速度提升幅度随草稿接受率在1.04倍至3.18倍之间波动。在苹果芯片上，MoE模型8B-A1B平均仅提速1.18倍。
- 공개 대상
- LFM2.5-1.2B-Instruct · LFM2.5-2.6B · LFM2.5-8B-A1B용 DSpark 초안 모델 3종 (2026-08-20)
- 초안 모델 크기
- 1.2B용 295.7M, 2.6B·8B-A1B용 327.7M. 2.6B용 저장소는 BF16 기준 655MB
- 구조
- 풀어텐션 5개 층, hidden 2048, intermediate 6144, GQA 32헤드/8 KV헤드, 블록 크기 9. 임베딩·LM 헤드는 대상 모델에서 로드 시 공유
- H100 실측
- 8B-A1B MATH500 428→1362 tok/s(3.18배), 2.6B 평균 323→864 tok/s(2.67배), 1.2B 평균 656→1384 tok/s(2.10배)
- M4 Max 맥북프로 실측
- 1.2B HumanEval 136→389 tok/s(2.87배), 2.6B 평균 61→139 tok/s(2.27배), 8B-A1B 평균 90→106 tok/s(1.18배)
- 수락률
- 8B-A1B는 MATH500에서 10토큰 중 8.27개 수락(3.18배), GSM8K에서 4.02개(1.29배). 1.2B의 MT-Bench 수락 3.90 → 1.66배
- 에이전트 지연
- 다중 도구 함수 호출 시나리오에서 2.6B 지연 감소 — X 게시물은 '평균 약 50%', MarkTechPost는 '평균 57%'로 다르게 적었다
- 실행 환경·라이선스
- llama.cpp·SGLang 첫날 지원, Safetensors·GGUF 배포. LFM Open License v1.0은 연 매출 1000만 달러 미만 조직에 무료 상업 이용 허용
在MacBook Pro M4 Max上，LFM2.5-2.6B原本每秒吐出61个token，现在变成了139个。既没有重新训练模型，也没有进一步收紧量化，只是在旁边挂了一个655MB的辅助模型而已。
Liquid AI于8月20日通过一条公开的X（推特）帖子宣布，为自家LFM2.5系列三款模型——LFM2.5-1.2B-Instruct、LFM2.5-2.6B、LFM2.5-8B-A1B——配套推出了DSpark草稿模型检查点。该公司此前于8月12日在Hugging Face上传了能读取屏幕和文档的轻量级视觉语言模型LFM2.5-VL-3B，8月19日LFM2.5小型模型的4比特检查点更新也被我们的采集网络捕捉到。此次发布的重点在于，在保持该系列模型性能不变的前提下，专门提升速度。
草稿模型先写九个，本体模型一次性打分
这项技术名为推测解码（speculative decoding）。大模型不再逐个生成token，而是由一个小型草稿模型先写出接下来可能出现的多个token，大模型再用一次计算对这批候选一次性打分。命中的token直接放行，从出错的地方重新生成。由于大模型跑一轮就能确定多个token，实际感受到的速度会提升。
DSpark的草稿模型每次提出9个候选token。模型规模上，1.2B-Instruct配套版本为2.957亿参数，2.6B与8B-A1B配套版本为3.277亿参数。结构上采用5层全注意力，隐藏层大小2048，中间层大小6144，32个query头共享8个KV头的GQA结构。词表权重完全不携带，在加载时直接从目标模型借用嵌入层和LM头。实际增加的内存占用，以2.6B配套版本的存储为基准，BF16格式下为655MB。
据MarkTechPost的技术梳理，DSpark整合了三个部分：以目标模型的上下文特征为条件、一次性提取所有草稿token隐藏状态的DFlash系列并行骨干网络；用秩为256的马尔可夫链还原相邻token间依赖关系、从而提升区块后段接受率的轻量顺序头；以及预测每个token存活概率、在验证成本可能超过收益时提前截断后续部分的置信度验证器。
关键在于质量完全不变。在温度为0的贪心解码下，输出的句子与原模型单独运行时的结果逐字相同。由于这是结构层面就设计成如此，基准测试分数也不会发生变化。
实测：H100上3.18倍，MacBook上2.87倍
测试环境分别为单张H100搭配BF16·SGLang组合，以及M4 Max MacBook Pro搭配llama.cpp·Metal·FP16 GGUF组合。两者均设置区块大小为9，批大小为1，温度为0，并跑了MATH500、HumanEval、MBPP、GSM8K、MT-Bench五项基准测试。
| 目标模型 | H100平均 | H100最高 | M4 Max平均 | M4 Max最高 |
|---|---|---|---|---|
| LFM2.5-1.2B-Instruct | 2.10倍（656→1384 tok/s） | 2.56倍（MATH500） | 2.54倍（138→350 tok/s） | 2.87倍（HumanEval，136→389） |
| LFM2.5-2.6B | 2.67倍（323→864 tok/s） | 3.06倍（MATH500） | 2.27倍（61→139 tok/s） | 2.63倍（HumanEval） |
| LFM2.5-8B-A1B | 2.54倍（418→1074 tok/s） | 3.18倍（MATH500，428→1362） | 1.18倍（90→106 tok/s） | 1.44倍（GSM8K） |
批大小为1这一条件值得留意。这项技术的用武之地不是要同时处理多个用户请求的服务器，而是一个人在自己的笔记本电脑或自己的GPU上独自使用的场景。
速度取决于「命中率有多高」
提升幅度会随工作负载大幅波动，因为草稿模型提出的token实际被采纳的比例——也就是接受率——直接决定了速度。8B-A1B在MATH500上每步10个候选中命中8.27个，取得了3.18倍的提速，但在GSM8K上命中数降至4.02个，同一块GPU上的提速也随之降到1.29倍。1.2B模型在MT-Bench上接受率也降到3.90，H100上的提速仅为1.66倍。整体测量结果分散在1.04倍到3.18倍之间。
| 条件 | 每步接受token数 | 提速倍数 |
|---|---|---|
| 8B-A1B · MATH500 · H100 | 8.27 / 10 | 3.18倍 |
| 8B-A1B · GSM8K · H100 | 4.02 / 10 | 1.29倍 |
| 1.2B · MT-Bench · H100 | 3.90 / 10 | 1.66倍 |
这意味着越是套路化的输出速度越快。规整的公式推导或代码，小模型也能较好地预测下一个token，而自由的对话语体则难以预测。
最明显的短板出现在苹果芯片上运行的MoE模型。只激活部分专家的8B-A1B在M4 Max上平均仅获得1.18倍提速。Liquid AI将原因归结为llama.cpp的Metal后端当前处理MoE的方式，以及一次验证k个token时会比单步解码唤醒更多专家、从而增加权重传输量。
在调用工具的智能体场景中体感提升最明显
效果最集中的地方另有其处：在每次调用工具前模型都要长时间思考、期间用户盯着屏幕等待的智能体任务。在多工具函数调用场景中，LFM2.5-2.6B的延迟大幅下降，但两个信息来源给出的降幅数字不同——X帖子称BFCL多工具场景平均降幅接近50%，MarkTechPost则写的是平均57%。无论哪个数字，由于智能体在用户的一轮对话中要多次经历规划、调用、再规划的过程，需要多次承担解码成本，因此绝对时间上的节省会更大。
如何上手试用
从哪里开始。 目前无法通过托管API使用。由于目前没有推理服务商为Hugging Face上的草稿模型检查点提供托管服务，需要自行部署运行。权重以Safetensors和GGUF两种格式发布，需要支持LFM2系列目标模型搭配DSpark的SGLang或llama.cpp构建版本。两者从公开首日起均已支持。
分步说明。
- 同时下载目标模型（例如LiquidAI/LFM2.5-2.6B）及与之配对的草稿模型（LiquidAI/LFM2.5-2.6B-DSpark）检查点。如果只下载草稿模型，由于缺少词表权重，无法单独运行。
- 若使用SGLang，启动服务器时在加载目标模型的同时挂载草稿模型。
python -m sglang.launch_server
--model-path LiquidAI/LFM2.5-2.6B
--speculative-algorithm DSPARK
--speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark
--speculative-draft-attention-backend flashinfer
--disable-radix-cache --mem-fraction-static 0.75 --port 30000
- 区块大小无需单独指定，会自动从草稿模型的
config.json中读取。 - 如果想对比速度，只需在上述命令中去掉以
--speculative-开头的三行，再运行同样的命令，这就是基准线。 - 如果打算在笔记本电脑上使用，可将FP16 GGUF权重接入llama.cpp。在Mac上会通过Metal后端运行。
谁可以使用。 LFM Open License v1.0仅对年营收低于1000万美元的组织开放免费商用。个人开发者、初创企业和中小企业都在此范围内，规模更大的企业需要另行向Liquid AI咨询商业授权。
能做些什么。 如果是在笔记本电脑上运行的本地代码助手，自动补全的等待时间会降到一半以下。也适用于数据不能出内网的医疗、金融、国防业务中本地部署运行的聊天机器人。若搭载到需要多次调用工具的端侧智能体上，用户盯着屏幕等待的时间会得到最明显的缩短。
编辑视角
这次发布中真正值得关注的数字不是3.18倍，而是655MB。把端侧模型落地到实际业务中会发现，瓶颈总是卡在同一个地方——精度勉强够用，但响应太慢，用户直接关掉窗口。这个问题过去往往靠把模型做得更小、或把量化压得更紧来解决，但每次这么做质量都会打点折扣。DSpark走的是相反的路：多花一点内存，但一个字的质量都不动。对于在8GB内存上勉强运行的用户来说，655MB是不小的负担，但对16GB以上的设备而言，这个体积大多数情况下都能承受。
草稿模型本身不携带词表权重的设计，从实用角度看也很聪明。词表嵌入在小型模型中往往占据相当一部分参数量，而通过在加载时向目标模型借用，一个3亿参数级的模型实际上只需要做3亿参数量的计算。这种目标模型与草稿模型一一绑定的结构缺乏通用性，但对只使用自家同系列模型的公司来说并不算损失。
不过，引入这项功能时不该以基准测试的最高值为基础来做容量规划。同一个8B-A1B在MATH500上是3.18倍，在GSM8K上却只有1.29倍，差距超过两倍。这意味着结果会因自身服务的实际对话日志更接近公式推导还是更接近自由对话而完全不同。如果考虑引入，正确的顺序是先用自己的数百条真实流量样本原样重放，测出接受率，而不是照搬基准测试结果。如果接受率降到6以下，把预期定在1.5倍左右会比预期两倍更稳妥。
苹果芯片上MoE的结果与其说是缺陷，不如说反映了当前llama.cpp Metal后端的现状。这部分很有可能会在框架层面得到修复，在此之前如果要在Mac上本地运行，比起MoE架构的8B-A1B，稠密架构的2.6B更实惠。批大小为1这一条件也值得记住——在同时服务多个用户的服务器上，由于GPU本身已经很繁忙，很难获得这种程度的提升。
预计未来几周内，其他小型模型阵营也会跟进推出各自同系列专属的草稿模型。端侧竞争的重心已经从参数量转移到「同样的硬件上每秒能跑出多少token」，既然存在不动质量、只买速度的办法，没有理由不用。
评论