LFM2.5-VL-DSpark：解码快三倍，整体受图像编码拖累
Liquid AI 为视觉语言模型 LFM2.5-VL-3B 发布了一个实验性的推测解码草稿模型：多占 8.9% 的参数，解码在设备端最高快到 3.13 倍，输出与原模型完全一致。但端到端的提速只有 1.30 到 2.62 倍，原文自己解释了原因——推测解码只加速解码，图像编码和预填充不受影响，而这两段在端侧恰恰占了大头。
编辑标为信号级，适合持续跟踪。
本页目录12 节
记录
信号正文
#发布了什么
一个约 2.8 亿参数的草稿模型，挂在 3B 的视觉语言模型旁边做推测解码，让部署后的参数量增加 8.9%。首日支持 llama.cpp、MLX-VLM 和 SGLang，权重以 Safetensors 和 GGUF 两种格式提供。
做法
草稿模型读取目标模型在几个固定层上的隐藏状态，据此一次起草一块候选 token，再由目标模型验证。图像块和文字在这些层之前已经被投影到同一个表示空间，所以草稿模型看到的向量维度与输入是图是文无关，推理算法和纯文本版本完全相同。
结构是只含注意力的 4 层、块大小 9，由 3、4、5 层的消融实验选出。训练跑了 10 轮，接受率随训练量上升，之后趋于平缓。推理时建议块大小取 8 或 9，视硬件而定。
推测解码是精确的：目标模型验证每一个被提议的 token，贪心解码下的输出与单独运行目标模型完全相同。
数字
- M5 Max 上用 MLX：解码快 2.30 到 3.13 倍，端到端 1.56 到 2.62 倍
- M3 Ultra 上用 llama.cpp：解码 1.57 到 2.14 倍，端到端 1.30 到 1.77 倍
- H100 上：解码最高 2.66 倍，端到端 1.64 到 2.27 倍
评测覆盖六类视觉任务：通用问答、文字问答、图像描述、图表问答、复杂推理和多轮对话。
H100 那一行原文写作「20.4 倍到 2.66 倍」，与文首的「最高 2.66 倍」对不上，下限应是笔误，这里只引用上限。
为什么解码快三倍，整体只快一倍多
视觉语言模型要先让图像过一遍视觉编码器，再让语言主干处理几百个视觉 token 加上文字提示。端侧设备的算力远小于数据中心的显卡，预填充在总耗时里占得更多。
推测解码只加速解码这一段。当前面几段已经占了大部分时间，解码再快，整体的提升也有限。原文直接点了名：这是阿姆达尔定律，整体加速受限于没有被加速的那部分。
怎么读这条
这份公告值得留意的地方是它把不利的数字和原因一起写了出来。对做端侧视觉应用的人，含义很具体：如果你的请求是一张图配一句短回答，推测解码帮不上多少；如果是一张图配一段长输出，它才划算。
公告把它标为实验性。三个推理框架的支持都依赖尚在合并过程中的改动，需要对应的构建版本。
为什么是现在
为什么重要
#推测解码正在从文本模型扩展到视觉语言模型，而这份公告说清了它在哪里有用、在哪里没用。先量出时间花在哪一段，再决定优化哪一段——这个顺序比任何一个倍数都重要。
背景
技术背景
#推测解码让一个小模型先猜一串 token，再由大模型一次验证；猜对的直接采纳，猜错的从出错处重来，所以输出与大模型单独运行时一致。预填充是模型在生成第一个 token 之前处理整段输入的阶段，输入越长越慢，而视觉输入会变成几百个 token。
关注人群
谁该关注
#下一步
学习路径
#- 先读《推测解码与推理加速技术》：接受率怎样决定加速上限
- 读本站 LFM2.5-2.6B 那一条：同一家的端侧文本模型
- 在你的应用里分别量出图像编码、预填充和解码各占多少时间
- 只有解码占比高的请求，才值得为它多加载一个草稿模型
关系网络
在技术网络中的位置
#当前技术与相邻技术、技能和背景知识的连接，点击节点可继续探索。
延伸思考
后续问题
#- 你的请求里，解码占总耗时的多少？
- 多占 8.9% 的参数，在你的目标设备上放得下吗？
- 你的输出通常是一句话，还是一段长文？
发布记录
收录于
#收录这条信号的技术简报，新的在前；最后一行是它那一周的周回顾。标签是它在那一期所在的栏目。
来源参考