LFM2.5-VL-DSpark加速视觉语言模型

LiquidAI 发布了一款实验性的 DSpark 草稿模型，专门为其视觉语言模型 LFM2.5-VL-3B 加速推理。简单说，这是一个"小模型帮大模型跑得更快"的方案：草稿模型先用极小的算力成本预测出一批候选 token，再由主模型批量验证，从而在不改变输出质量的前提下大幅提升解码速度。实测数据显示，端侧设备解码速度最高提升 3.13 倍，H100 显卡上最高提升 2.66 倍，端到端延迟分别最多改善 2.62 倍和 2.27 倍。代价仅仅是增加 2.8 亿参数，相当于原模型 30 亿参数的 8.9%，内存开销几乎可以忽略。 这套方案的技术原理值得关注。视觉草稿模型沿用了文本版 DSpark 的架构：在目标模型的若干固定层上抓取隐藏状态，据此一次性草拟出 k 个候选 token。图像 patch 和文本 token 在进入这些层之前就被投影到共享表示空间，因此无论输入是图片还是文字，草稿模型处理的隐藏状态向量维度完全一致，推理算法也与纯文本模型无异。训练方面，团队混合了视觉语言 SFT 数据，并根据预期负载做了加权，最终选定了 4 层、块大小 9 的简化注意力草稿器，训练 10 个 epoch 后收敛收益递减。推理时推荐块大小设为 8 或 9，具体看硬件。配套工具方面，llama.cpp、MLX-VLM 和 SGLang 三大框架均实现首日支持，开发者可以直接上手。 不过，这项技术并非万能。草稿解码只加速解码阶段，对视觉编码和预填充（prefill）无能为力。视觉模型本身就比纯文本模型多了一道工序：图片先过视觉编码器，再和文本提示一起送入语言主干处理数百个视觉 token。在算力有限的边缘设备上，预填充占端到端延迟的比例更高，首 token 时间往往才是瓶颈。这就是阿姆达尔定律的体现——整体加速比受限于未被加速的那部分工作。因此，当视觉编码和预填充已经吃掉大部分时间时，即便解码速度提升再大，端到端收益也会被明显稀释。对于需要在端侧跑多模态推理的跨境电商卖家来说，这意味着该方案更适合解码密集型的场景，比如多轮图文对话和复杂推理，而非单次图片描述这类预填充占主导的任务。