Liquid AI发布LFM2.5-VL-DSpark视觉语言模型草稿模型，解码最高提速 3.13 倍
该草稿模型为LFM2.5-VL-3B增加投机解码路径，额外参数约 2.8 亿（较 3B目标模型增加 8.9%），在M5 Max上按任务解码提速 2.30 至 3.13 倍，端到端延迟改善 1.56 至 2.62 倍，首日支持llama.cpp、MLX-VLM与SGLang。
AI解读：Liquid AI放出了一个给视觉语言模型加速的草稿模型LFM2.5-VL-DSpark，专配自家的LFM2.5-VL-3B。它不是换更小的模型，而是在推理时开一条投机解码通道：先由草稿模型猜一批token，再交给目标模型逐颗验证。因为验证是精确的，贪心解码的输出与原模型单独运行完全一致，等于白拿速度。
代价写在参数表里：草稿模型约 2.8 亿参数，相对 30 亿的目标模型只多 8.9% 的显存或内存占用。换来的解码提速在M5 Max上是 2.30 到 3.13 倍，端到端 1.56 到 2.62 倍；H100上按任务差异较大，解码 20.4 倍到 2.66 倍都有出现，端到端 1.64 到 2.27 倍。数字跨度大不是笔误，而是取决于任务里预填充占了多少时间。
真正需要留意限制的是做端侧部署的人。投机解码只加速解码阶段，图像编码和预填充一点没动，而端侧算力弱，预填充本来就在总时延里占大头，所以解码哪怕快 3 倍，端到端也可能只快 1.3 倍，这是典型的阿姆达尔定律。想在本地跑VLM的开发者可以先用llama.cpp、MLX-VLM或SGLang的对应构建试一下，block size建议 8 或 9；如果瓶颈卡在首token延迟上，这个方案帮不上忙。
Liquid AI在Hugging Face博客发布实验性草稿模型LFM2.5-VL-DSpark，为视觉语言模型LFM2.5-VL-3B增加投机解码路径。据该博客，它在不明显增加显存占用的前提下提升解码速度，且不改变输出质量。
该草稿模型增加约 2.8 亿参数，相当于在 3B目标模型之上增加 8.9%。官方给出的提速是：设备端解码最高 3.13 倍、H100上最高 2.66 倍；端到端延迟最高分别改善 2.62 倍和 2.27 倍。
草稿模型首日支持llama.cpp、MLX-VLM和SGLang的LFM兼容DSpark集成，并在Hugging Face以Safetensors和GGUF格式提供。
草稿模型如何对VLM做投机解码
视觉草稿模型沿用文本版LFM2.5-DSpark草稿模型的架构：在一组固定的被截取层上捕获目标模型的隐藏状态，并以这些状态为条件草拟出k个候选token组成的一个块。
图像patch与文本token在这些层之前就被投影到共享表示，因此无论输入是哪种模态，草稿模型处理的隐藏状态向量维度都一致。博客称，推理算法与文本模型完全相同。
训练配置：4 层、块大小 9、共 10 个epoch
训练沿用DSpark配方，使用视觉语言SFT数据混合，并按照预期服务的工作负载加权。
据博客，基于 3 层、4 层、5 层的消融实验，草稿模型最终采用简化的纯注意力结构，4 层、块大小 9；在最终数据混合上训练 10 个epoch，并在每个epoch后测量接受率，结果显示接受率随训练token增加而提升，直至进入收益递减。
推理时，博客建议根据硬件选择块大小 8 或 9。草稿模型总参数约 2.8 亿，其中解码器堆栈 4 层（193.0M）、隐藏状态投影（21.0M）、马尔可夫头（65.5M）、归一化与置信度头（6.4k），合计 279.5M。
实测速度：设备端与H100的具体数字
DSpark草稿模型随LFM2.5-VL-3B首日支持llama.cpp、MLX-VLM与SGLang，测量分设备端推理与GPU推理两组，均使用DSpark块大小 8，并在六个视觉任务上评测，包括通用VQA、文本VQA、图像描述、图表VQA、复杂推理和多轮对话，评测遵循MMSpec基准。
- 设备端（MLX，M5 Max）：按任务解码提速 2.30 倍至 3.13 倍，端到端延迟改善 1.56 倍至 2.62 倍。
- 设备端（llama.cpp，M3 Ultra）：解码提速 1.57 倍至 2.14 倍，端到端改善 1.30 倍至 1.77 倍。
- GPU（H100）：同一草稿模型带来约 20.4 倍至 2.66 倍的解码提速，端到端改善 1.64 倍至 2.27 倍。
投机解码对视觉负载的局限
博客指出，在LLM中预填充主要是计算受限的，其开销随提示长度呈（次）二次增长。VLM在此基础上又多了一层：图像先经过视觉编码器，再由图语言主干处理数百个视觉token以及文本提示。
边缘设备的算力远低于数据中心GPU，因此预填充在端到端延迟中占比更大，Apple芯片与H100上的首token时间及解码测量都体现了这一点；博客提到M5的每核GPU神经加速器缩小了这一差距。
投机解码只加速解码，不加速视觉编码或预填充。当这些阶段已经占据大部分墙钟时间时，即使解码提速很大，端到端收益也有限。博客引述阿姆达尔定律解释：整体加速比会被未被加速的那部分负载限制。
如何运行LFM2.5-VL-DSpark
博客给出三种运行方式的具体命令与前置条件。
- SGLang：需要支持LFM2目标DSpark的SGLang构建（PR #40651）。启动目标模型时附带草稿模型，关键参数包括 --speculative-algorithm DSPARK、--speculative-draft-model-path LiquidAI/LFM2.5-VL-3B-DSpark、--speculative-draft-attention-backend flashinfer、--speculative-dspark-block-size 9，并加 --disable-radix-cache；随后可查询http://localhost:30000/v1上的OpenAI兼容端点。块大小也从草稿模型config.json读取；基线就是去掉三个 --speculative-* 标志的同一条命令。
- llama.cpp：需要相应构建（PR #29339）。命令使用 -m models/LFM2.5-VL-3B-F16.gguf、--mmproj models/mmproj-LFM2.5-VL-3B-F16.gguf、-md LFM2.5-2.6B-DSpark-F16.gguf，参数为 --spec-type draft-dspark --spec-draft-n-max 8 --spec-draft-n-min 0，另加 -fa on -ngl 99 -c 8192。
- MLX-VLM：需要相应构建（PR #2280）。命令为mlx_vlm.server --model LiquidAI/LFM2.5-VL-3B --draft-model LiquidAI/LFM2.5-VL-3B-DSpark；块大小从sidecar元数据读取，n-max会被钳制到该值。
- 博客强调投机解码是精确的：目标模型验证每一个被提出的token，因此贪心输出与单独运行目标模型一致；每次响应的计时中会报告draft_n / draft_n_accepted。