LFM2.5-VL-DSpark：视觉 Agent 能否在本地更快完成推理？

先说结论

Hugging Face 上的 Liquid AI 官方博客在 2026 年 9 月 24 日发布了 LFM2.5-VL-DSpark：它不是重新训练一个更大的视觉语言模型，而是给 LFM2.5-VL-3B 增加一个轻量的草稿模型，让推理系统先提出一小段候选 token，再由目标模型验证。官方报告称，在不同设备和任务上，解码速度最高可提升 3.13 倍，端到端延迟最高可改善 2.62 倍；新增草稿模型约 280M 参数，只占目标模型参数量的 8.9%。

这件事对 Agent 的真正价值，不是一个漂亮的加速数字，而是视觉 Agent 开始有机会在本地设备上把“看图、读表、理解界面、调用工具”的等待时间压下来。我的判断是：推测解码很适合低风险、可回放的视觉任务，但不能把单项解码加速直接等同于完整工作流加速。输入图像处理、上下文准备、工具调用、验证和模型加载，仍然可能成为端到端瓶颈。

发生了什么

主来源是 Hugging Face 上 Liquid AI 的官方文章《Accelerating vision-language models with LFM2.5-VL-DSpark》，发布日期为 2026-09-24，原始 URL：https://huggingface.co/blog/LiquidAI/lfm2-5-vl-dspark。

官方事实是：Liquid AI 发布了面向 LFM2.5-VL-3B 的实验性 DSpark 草稿模型，并提供 Safetensors 与 GGUF 格式；官方给出的首日集成包括 llama.cpp、MLX-VLM 和 SGLang。该草稿模型采用与文本版 DSpark 类似的思路，利用目标模型若干层的隐藏状态，预测一组候选 token，再交给目标模型验证；视觉 patch 和文本 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 的 GPU 结果，解码提升最高为 2.66 倍，端到端提升最高为 2.27 倍。

这些数字是官方在特定硬件、软件栈、任务和测试设置下报告的结果，不是所有视觉 Agent 的上线保证。下文关于系统设计、路由和验收的内容，是我的工程判断。

技术细节

1. 推测解码为什么能加速

普通自回归生成通常由目标模型逐 token 产生结果。每一步都要运行完整模型，确认下一个 token 后才能继续。推测解码则增加一个更小的草稿模型：它先快速生成一段候选 token，目标模型再批量检查这一段。如果候选大部分被接受，就能减少目标模型逐步运行的次数。

这个方法的关键不是让草稿模型“比目标模型更聪明”，而是让它足够快，同时生成与目标模型分布接近的候选。接受率越高，一次草稿带来的收益越大；接受率太低，系统就会多付出草稿模型的计算成本，却没有减少足够多的目标模型计算。因此，推测解码的收益取决于目标模型、草稿模型、任务分布、硬件内核和块大小的组合。

LFM2.5-VL-DSpark 的草稿模型采用四层的简化注意力结构，并以 9 为候选块大小进行训练分析；官方在推理时建议根据硬件使用 8 或 9 的块大小。它约有 280M 参数，相比 3B 目标模型增加的参数量不大，这也是它适合边缘设备和本地推理的原因之一。

2. 视觉输入没有被“免费处理”

视觉语言模型的输入不只是文字。图片需要经过视觉编码、patch 切分和跨模态投影，然后才能与文本 token 一起进入生成链路。DSpark 主要优化的是生成阶段，不能自动消除图像加载、视觉编码、分辨率变化和多图拼接的成本。

这一区分对 Agent 很重要。一个读取截图并点击界面的 Agent，端到端耗时可能包括图片截取、压缩、上传或本地读取、视觉编码、目标模型生成、工具参数校验和动作回执。即使生成 token 阶段快了两倍，如果视觉编码占掉大部分时间，用户感知到的改善也会小很多。工程验收必须把每一段单独计时，而不是只报告 tokens per second。

3. 多轮对话和图表问答更接近真实 Agent

官方测试没有只选择单一的图像描述，还覆盖图表问答、复杂推理和多轮对话。这些任务更接近 Agent 的真实负载：模型不仅要识别内容，还要保留上下文、处理约束并持续输出结构化结果。

不过，视觉问答准确率与 Agent 成功率不是一回事。对工具型 Agent，还要检查输出是否遵守 JSON Schema、字段是否完整、数字是否与图表一致、引用的区域是否正确，以及模型是否在证据不足时标记未知。推测解码的目标是减少等待时间，不会替代这些确定性校验。模型负责提出结果，程序负责验证结果，界面负责区分规则结果、输入证据、AI 解释和未知项。

4. GGUF、MLX 与 SGLang 是不同的工程选择

LFM2.5-VL-DSpark 同时提供多种运行时集成，这对开发者很方便，但也意味着“同一模型”并不等于“同一性能”。llama.cpp 更适合成熟的本地 GGUF 工作流；MLX-VLM 面向 Apple Silicon 的本地运行；SGLang 更适合服务化和 GPU 场景。不同运行时的内存布局、批处理、并发、算子支持和图像预处理方式都可能影响最终结果。

因此，不能只下载模型后用默认参数跑一次，就宣布已经获得官方数字。至少要锁定模型文件、草稿块大小、运行时版本、硬件、图像分辨率、并发数和任务集。对于生产系统，还要记录草稿接受率、目标模型回退次数、首 token 延迟、完整响应延迟、峰值内存和最终任务成功率。

对 Agent / 工程的影响

第一，视觉 Agent 可以新增一个“本地低延迟”路由。截图摘要、票据字段提取、设备面板读取、图表初步解释和离线资料整理等任务，如果不涉及高风险自动动作，可以优先尝试本地 LFM2.5-VL-3B 与 DSpark。原始图像不必离开设备，延迟也更容易预测。

第二，路由条件不能只看模型大小。应同时考虑任务风险、图像分辨率、上下文长度、内存余量、工具权限和失败后的回退方案。低风险任务可以使用更激进的量化与较小草稿块；涉及医疗判断、付款凭证、权限变更、设备控制或对外发布时，应切换到更强的模型或人工复核，不应因为本地速度快就降低安全门槛。

第三，推测解码必须进入可观测性体系。建议每次运行记录模型标识、草稿模型标识、运行时、硬件、块大小、草稿接受率、实际回退次数、输入图像尺寸、首 token 延迟、完整延迟和结构化输出通过率。服务端只保留必要的脱敏元数据，不默认保存原始图片、私人文档或完整生成结果。

第四，评测集要覆盖视觉 Agent 的失败模式。准备不含私人信息的合成图片，包含正常截图、模糊图片、长文字、表格、图表、多图对比和证据缺失等情况。对每个任务比较普通推理与 DSpark 的准确率、结构化输出通过率、工具调用成功率、P50/P95 延迟、内存和失败降级。若速度提升伴随格式错误或工具误触发增加，就不能算有效优化。

第五，先优化工作流，再追求更大的倍数。减少重复图片编码、复用稳定视觉上下文、裁剪无关区域、限制工具返回长度，往往比单独追求生成阶段的峰值速度更能改善端到端体验。但这些优化必须由程序确定性执行，并对裁剪的数据标记未知项，不能让模型自行隐藏缺失证据。

第六，本地运行仍然需要供应链治理。开源权重、GGUF 文件、运行时依赖和转换脚本都应锁定来源与版本；部署前检查文件哈希、许可证和兼容性。模型能在本地运行，不代表它天然安全，也不代表所有输入都适合交给它处理。

我的判断

LFM2.5-VL-DSpark 值得关注，因为它把视觉模型的加速从“换更大硬件”扩展到“增加一个小而专门的草稿路径”。我会把它用于低风险、本地优先、可回放的视觉 Agent 任务，并以端到端延迟和任务成功率作为门槛；不会只用官方最高加速倍数做采购或上线依据。

短期内，最有价值的工作不是把所有视觉请求都切到 DSpark，而是建立一套运行时对照：同一任务、同一图片、同一输出 Schema，比较普通推理、DSpark、不同量化和远程模型的质量、延迟、成本与失败类型。只有当接受率、结构化输出和工具调用都稳定，速度收益才真正属于产品，而不只是 benchmark。

Q&A

Q1：来源和发布日期是什么？

A：主来源是 Hugging Face 上 Liquid AI 的官方文章《Accelerating vision-language models with LFM2.5-VL-DSpark》，发布日期为 2026-09-24，原始 URL：https://huggingface.co/blog/LiquidAI/lfm2-5-vl-dspark。文章介绍 LFM2.5-VL-3B 的实验性 DSpark 草稿模型、架构、测试结果和运行时集成。

Q2：它是不是一个全新的 3B 视觉语言模型？

A：不是。它主要是在 LFM2.5-VL-3B 旁边增加轻量草稿模型，服务于推测解码。目标模型仍负责验证候选 token，草稿模型不能单独代表完整的视觉理解能力。

Q3：官方最高 3.13 倍是否等于 Agent 端到端快 3.13 倍？

A：不等于。3.13 倍是特定设备和任务上的解码速度结果；端到端延迟还包括图像预处理、视觉编码、上下文准备、工具调用和校验。部署时必须测量完整链路。

Q4：什么任务适合先试？

A：适合从低风险、可回放、结果容易验证的任务开始，例如截图摘要、图表字段提取、票据初筛和离线资料整理。涉及医疗、付款、权限、设备控制或对外发布的任务，不应仅凭加速结果自动放行。

Q5：最小验证需要记录什么？

A：至少记录模型和运行时版本、硬件、图像尺寸、草稿块大小、接受率、回退次数、首 token 延迟、完整延迟、峰值内存、结构化输出通过率、工具调用成功率和失败降级结果，并与无 DSpark 基线比较。

来源

1. Liquid AI，Accelerating vision-language models with LFM2.5-VL-DSpark，发布日期：2026-09-24，发布平台：Hugging Face，原始 URL：https://huggingface.co/blog/LiquidAI/lfm2-5-vl-dspark

本文区分官方事实与作者判断；官方性能数字对应其公布的硬件、运行时和任务设置，不构成对其他部署环境的性能保证。
隐私自检：未写入姓名、账号、用户输入、内部网络细节、凭据或会话标识
封面 seed：2026-09-24-lfm25-vl-dspark-agent（唯一）
coverWidth/Height：1600 / 900
categories：ai_tech