视觉模型输出更快，首字未必更快：读懂 Liquid AI 的 DSpark 新进展

让视觉语言模型回答得更快，未必只靠换一张更强的显卡。9 月 24 日，Liquid AI 发布了面向 LFM2.5-VL-3B 的实验性 DSpark 草稿模型，希望通过推测解码缩短生成阶段的耗时。官方博客与其在 Hugging Face 的团队文章均已公开这项进展。 对使用图片问答、文档识别或多模态 API 的开发者来说，这条消息值得关注。不过，决定用户体验的不只是输出 token 的速度，还包括模型看到图片后多久开始回答，以及完整任务何时完成。 草稿模型负责提议，目标模型负责验证 按官方介绍，DSpark 读取目标模型若干层的隐藏状态，用较轻量的草稿模型提出一组候选 token，再交给目标模型验证。图像与文字进入这些层时已经被转换为张量表示，因此可以沿用文本模型中的推测解码思路。 这次草稿模型约有 2.8 亿参数。官方说明，在匹配采样设置时，推测解码与直接从目标模型采样在分布上等价；它的目标是加速生成过程。这里的等价不意味着两次随机采样一定逐字相同，也不代表目标模型原有的识别错误会因此消失。 发布范围与测试条件 Liquid AI 公布了 llama.cpp、MLX-VLM 和 SGLang 的支持路径，并提供 Safetensors 与 GGUF 格式。其团队教程同时列出对应实现的构建要求，接入时应核对所用版本是否已包含相关支持，不能仅凭框架名称判断可用性。 官方测试覆盖通用视觉问答、文字视觉问答、图片描述、图表问答、复杂推理与多轮对话。主文明确说明，所列性能数据使用 16 位处理；量化模型的加速不在此次发布的评测范围内。下载格式与实际精度是两件事，不能因为存在 GGUF 文件，就把这些结果理解成低比特量化模型的表现。 官方还在单张 H100 上考察了并发提高后的吞吐表现，并指出温度升高可能降低草稿接受率。这意味着硬件、任务、采样设置和并发都会影响收益，单个最佳倍率不足以成为生产环境的速度承诺。 为什么输出提速，首字等待未必同步缩短 视觉任务通常先经过图像编码，再处理视觉 token 与文字提示，最后才逐步生成回答。官方强调，推测解码主要加速最后的解码阶段，图像编码与提示预填充保持不变。 如果一项任务的大部分时间都花在读图和处理输入，即使后续输出明显加快，完整请求的收益仍受前面阶段限制。图片较复杂、输入较长或回答较短时，尤其应分别查看首字等待和整体耗时。 Easycha 观察：把评测拆成用户能感知的指标 接入前，可以挑选真实业务中的图片样本，固定图片尺寸、提示词、输出长度、温度与并发，在同一硬件上比较启用和关闭草稿模型的表现。记录首个 token 等待、完整响应耗时、输出速度和显存占用，并单独检查结构化结果是否满足业务要求。 图表分析、长篇图片描述与简短字段抽取，应分别测试。长回答更可能让解码加速发挥作用，但具体幅度仍要测量；不能把一类任务的结果直接用于另一类任务。 此次发布提供了一个值得试验的多模态推理优化选项，也给 API 选型提出了更具体的问题：加速发生在哪个阶段，是否恰好改善用户最在意的等待？以上接入建议为 Easycha 编辑分析，本文未进行新增性能实测，也未据此评价任何中转服务商。