Liquid AI推视觉模型DSpark

Liquid AI把推测解码带进视觉语言模型

Liquid AI 近日发布 LFM2.5-VL-DSpark，这是其面向 LFM2.5-VL 视觉语言模型的推理加速方案。简单说，DSpark 不是重新训练一个更大的视觉模型，而是增加一个更轻量的草稿模型，让目标模型一次性验证多个候选 token，从而减少逐 token 生成所需的完整前向计算。

这件事的重点不在于又多了一个视觉语言模型 checkpoint，而在于 Liquid AI 开始把推测解码从纯文本模型扩展到视觉语言模型。对于端侧 VLM 来说，真正影响体验的往往不是模型能不能看懂图片，而是从输入图片到输出第一个完整结果需要等待多久：拍一张票据，多久能返回字段；截取一帧屏幕，多久能判断按钮状态；摄像头连续输入时，模型能不能跟上帧率。

截至 2026 年 9 月 24 日，Liquid AI 尚未给出一个适用于所有硬件、所有输入类型的统一加速倍数。官方材料更强调 DSpark 的工作机制、输出一致性，以及它与 LFM2.5-VL 边缘部署场景的结合。此前，Liquid AI 为 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B 发布 DSpark 草稿模型，在 GPU 上最高报告 3.18 倍吞吐提升，在设备端最高报告 2.87 倍提升；这组数字属于文本模型版本，不能直接当作 LFM2.5-VL-DSpark 的通用成绩。

DSpark到底加速了哪一段

**推测解码是一种用小模型提出候选 token、再由大模型批量验证的生成加速技术。**它的基本思路并不复杂：目标模型通常一次只生成一个 token，草稿模型则先快速预测一小段文本；目标模型随后检查这段预测，如果大部分 token 都符合自己的分布，就一次接受多个 token，否则在出现分歧的位置回退到目标模型自己的结果。

传统自回归生成像是在一条生产线上每次只加工一个零件，即使后面的四五个零件其实已经可以预测，也必须等前一个零件完成。推测解码相当于先由一个低成本工位预加工一串零件，再让主工位一次验收。只要草稿模型和目标模型在当前上下文中的判断足够接近，主模型的调用次数就会下降。

对于视觉语言模型，完整推理链路通常可以拆成几个阶段：

1. 图像预处理：缩放、裁剪、归一化，并把图片转换为视觉编码器可以处理的输入。
2. 视觉特征提取：视觉编码器把像素转换成视觉 token 或连续特征。
3. 多模态上下文融合：模型将图像特征与用户问题、系统提示词拼接或映射到同一上下文中。
4. 自回归文本生成：模型逐步输出文字、JSON 字段、坐标、类别或工具调用参数。

DSpark 主要作用在第四阶段，也就是输出 token 的解码阶段。它不会让图片加载更快，也不会直接降低视觉编码器的计算量。因此，如果任务的主要耗时在高分辨率图片编码，DSpark 的整体收益会小于纯文本长输出任务；如果任务是 OCR、表格抽取、屏幕理解或短答案分类，收益也会受到输出长度和草稿 token 接受率影响。

这也是理解 LFM2.5-VL-DSpark 的关键：它不是把每张图片“看得更快”，而是让模型在完成视觉理解之后，把答案“说出来更快”。

输出质量不变，是它最值得关注的卖点

**在贪心解码下，推测解码可以通过目标模型校验机制保证输出序列与基线模型一致。**Liquid AI 的公开说明是：只有当草稿 token 与目标模型的分布匹配时，目标模型才接受该 token；如果不匹配，就由目标模型自己的 token 替换草稿结果。

因此，在 greedy decoding，也就是每一步都选择概率最高 token 的设置下，DSpark 的目标不是用一个小模型近似大模型，而是让小模型承担“提前猜测”的工作，最终决定权仍然在目标模型手中。理论上，生成结果可以与不启用 DSpark 的基线模型保持一致，准确率、pass@1 和 exact match 不应因为加速而改变。

这点与量化、蒸馏和剪枝不同：

| 技术 | 主要手段 | 是否可能改变输出 | 主要收益 | 典型代价 | |---|---|---:|---|---| | 量化 | 降低权重或激活精度 | 可能 | 降低显存、提升带宽效率 | 精度损失风险、算子适配成本 | | 蒸馏 | 训练更小模型模仿大模型 | 可能 | 模型更小、部署更轻 | 需要重新训练，能力可能下降 | | 剪枝 | 删除部分参数或结构 | 可能 | 减少参数和计算量 | 结构改造与质量恢复复杂 | | 推测解码 | 草稿模型预测，目标模型验证 | 贪心解码下可保持一致 | 减少目标模型串行解码次数 | 增加草稿模型显存和调度开销 |

不过，“输出质量不变”并不等于所有生成配置下都完全没有差异。温度采样、top-p、随机种子以及不同推理框架的采样实现都会影响结果一致性。DSpark 的确定性优势最适合结构化输出和低温度推理，而不是把它简单理解成任何采样参数下都能逐字复现。

为什么视觉语言模型特别需要这类优化

**边缘视觉语言模型的瓶颈通常不是参数规模本身，而是内存带宽、串行解码和端侧功耗的叠加。**在数据中心里，服务可以通过批处理和高并发摊薄计算成本；但在手机、笔记本、车载芯片、工业相机或机器人上，模型经常面对单请求、低并发和严格的响应时间约束。

以一个典型的端侧视觉任务为例：用户上传一张收据，要求模型返回商户名、日期、总价和税额。图像编码可能只执行一次，但生成结构化 JSON 时，模型仍然要逐个输出键名、引号、数字和标点。如果草稿模型可以连续猜中这些高度规律化的 token，目标模型就能批量确认一段结果。

类似的收益还可能出现在以下场景：

• 实时屏幕理解：桌面助手识别按钮、菜单、错误提示并给出下一步操作。
• 摄像头问答：模型对连续视频帧输出短句描述或风险标签。
• 票据与表格抽取：视觉模型输出固定字段，token 分布相对稳定。
• 车载视觉交互：在不上传图像的情况下识别道路、仪表盘或车内物体。
• 机器人控制：把视觉观察转换为短指令，减少等待时间。
• 本地 OCR 后处理：先提取文字，再由模型归纳、分类或转换成 JSON。

Liquid AI 此前发布的 LFM2.5-VL-450M 主打边缘设备视觉理解，公开材料曾以 512×512 图像约 240 毫秒的处理速度作为卖点，并定位于 4 FPS 视频流等低延迟场景。LFM2.5-VL-DSpark 的价值，是在已有视觉模型能够完成一次理解之后，继续压缩文本生成阶段的等待时间。两者并非同一个指标：240 毫秒主要描述图像处理链路，而 DSpark 的加速重点是解码吞吐。

与此前文本版 DSpark的关系

**LFM2.5-VL-DSpark 是 Liquid AI DSpark 家族向多模态模型的延伸，而不是一套完全独立的推理范式。**Liquid AI 在 2026 年 8 月发布文本模型 DSpark 草稿 checkpoint 时，已经展示了从 H100 到 MacBook 等不同硬件上的加速潜力。

此前版本覆盖三个 LFM2.5 模型：

| 模型 | DSpark角色 | Liquid AI公开的相关信息 | |---|---|---| | LFM2.5-1.2B-Instruct | 目标模型配套草稿模型 | 属于首批 DSpark 支持模型 | | LFM2.5-2.6B | 目标模型配套草稿模型 | 面向更强的通用文本任务 | | LFM2.5-8B-A1B | 目标模型配套草稿模型 | 采用稀疏激活路线，属于更大容量配置 | | LFM2.5-VL 系列 | 视觉语言目标模型配套草稿模型 | 将推测解码扩展到视觉输入场景 |

根据 Liquid AI 的公开数据，文本版 DSpark 在 GPU 上最高达到 3.18 倍吞吐提升，在设备端最高达到 2.87 倍。加速效果并非固定常数，取决于草稿模型大小、目标模型规模、输出长度、接受率、并发量以及硬件内存带宽。

在低并发端侧推理中，减少串行解码步骤通常更加重要；在高并发服务器场景中，批量验证会提高算术强度，系统可能从内存受限逐步转向计算受限。也就是说，DSpark 并不是永远随着并发增加而线性加速，而是需要推理框架正确处理草稿 token、目标模型验证和 KV cache。

部署支持决定它是不是“可用的加速”

**推测解码的实际收益高度依赖推理框架，而不是只取决于 checkpoint 文件本身。**Liquid AI 在 DSpark 发布时提供了 llama.cpp 和 SGLang 方向的支持，其中 llama.cpp 侧的实现基于官方代码库，并使用实验性的 Metal kernel；SGLang 侧则基于其官方 DSpark 实现。

这对端侧开发者尤其重要。一个模型即使理论上能用推测解码，如果运行时没有支持草稿模型调度、批量验证和缓存复用，开发者仍然只能按普通自回归模型运行，最终看不到加速。

部署时至少需要关注以下问题：

• 目标模型与草稿模型是否严格匹配：草稿模型通常不是任意小模型都能替代，模型架构、词表和训练方式需要兼容。
• 框架是否支持多模态输入：文本 DSpark 能运行，不代表同一套配置已经覆盖图像 token、视觉编码器和多模态模板。
• Metal、CUDA 或 CPU kernel 是否成熟：端侧加速可能受算子实现影响，理论 token/s 不等于真实端到端延迟。
• KV cache 是否正确复用：缓存管理不当会抵消草稿模型节省下来的计算量。
• 输出格式是否稳定：固定 JSON、短文本和代码补全通常更容易获得较高接受率，开放式长文本则可能更不稳定。

对于开发者来说，不能只看模型卡上的“最高倍数”。更合理的评估方式是同时记录首 token 延迟、端到端响应时间、解码 token/s、峰值内存和每瓦性能，并用真实图片、真实提示词和真实输出长度进行测试。

这次发布的边界也很清楚

**LFM2.5-VL-DSpark 解决的是解码阶段效率问题，不是视觉语言模型的全部性能问题。**它无法自动提升模型的 OCR 准确率、空间定位能力、复杂图表推理能力或长上下文记忆能力。若目标模型本身看错了图，草稿模型不会把它变聪明；它只会更快地帮助目标模型生成答案。

同时，推测解码的收益取决于草稿模型与目标模型的相似程度。如果草稿模型频繁猜错，目标模型仍然需要逐 token 接管，额外的草稿推理和验证反而可能带来开销。对于极短输出，比如只返回一个类别标签，草稿模型初始化、调度和验证成本也可能超过节省的时间。

因此，LFM2.5-VL-DSpark 最适合三类任务：第一，目标模型输出较长；第二，输出结构规律、草稿 token 接受率较高；第三，设备端或低并发环境中的串行解码是主要瓶颈。对于一次性分类、极短回答或视觉编码占绝大多数耗时的任务，收益则需要实测。

OpenAI Hub判断：端侧VLM正在从“能跑”进入“要快”

Liquid AI 这次发布的意义，不是又一次单纯的模型尺寸竞赛，而是把视觉语言模型的竞争拉回到系统工程：模型结构、草稿模型、推理框架、硬件 kernel 和真实工作负载必须一起设计。

过去，端侧模型的常见路线是继续压缩参数、做量化、减少视觉输入分辨率。这些方法仍然重要，但它们更多解决“模型能不能塞进设备”和“单次计算有多重”的问题。DSpark 解决的是另一个问题：模型已经能运行之后，如何减少自回归生成的等待。

如果 Liquid AI 能够在 LFM2.5-VL-DSpark 上复现文本版 DSpark 的加速效果，同时维持视觉编码和结构化输出的稳定性，那么它对本地 AI 应用会有实际价值，尤其是屏幕助手、票据抽取、车载交互和机器人等场景。不过，在官方进一步公开不同设备、不同图像分辨率、不同输出长度下的完整基准之前，直接把“最高 3.2 倍”套用到视觉语言模型上并不严谨。

更准确的结论是：**LFM2.5-VL-DSpark 为边缘视觉语言模型提供了一条不依赖牺牲输出质量的解码加速路径，但它的最终价值取决于接受率、视觉编码占比和推理框架实现。**对于准备在本地部署 LFM2.5-VL 的开发者，现在值得关注的已经不只是模型大小和图像准确率，还包括 DSpark checkpoint 是否匹配、运行时是否支持，以及在自己的真实任务上能否把端到端延迟真正降下来。

参考来源

1. Hugging Face：Accelerating vision-language models with LFM2.5-VL-DSpark —— Liquid AI 发布 LFM2.5-VL-DSpark 的技术说明，介绍视觉语言模型中的推测解码方案。
2. Hugging Face：LFM2.5-DSpark：Up to 3.2x Faster Inference —— DSpark 文本模型版本的工作机制、输出一致性和性能数据。
3. Reddit：LFM2.5-VL-450M 讨论帖 —— 社区对 LFM2.5-VL-450M 端侧视觉理解能力和部署场景的讨论。