Liquid AI发布DSpark:VLM推测解码提速3.13倍
Liquid AI Releases LFM2.5-VL-3B-DSpark: Speculative Decoding for Vision-Language Models With Up to 3.13x Faster Decoding
VLM推理优化干货,给出了具体的Draft架构参数与多硬件实测数据,做端侧或云端部署的同学可以直接参考配置。
Liquid AI has announced LFM2.5-VL-3B-DSpark, an experimental speculative-decoding draft model for its LFM2.5-VL-3B vision-language model. The drafter adds about 280M parameters and speeds up decoding without changing the model’s output. Liquid AI team reports up to 3.13x faster decoding on Apple silicon and up to 2.66x on an NVIDIA H100.
Liquid AI 宣布了 LFM2.5-VL-3B-DSpark,这是其 LFM2.5-VL-3B 视觉语言模型的一个实验性推测解码草稿模型。该草稿模型增加了约 2.8 亿个参数,并在不改变模型输出的情况下加速了解码过程。Liquid AI 团队报告称,在 Apple Silicon 上解码速度最高提升 3.13 倍,在 NVIDIA H100 上最高提升 2.66 倍。
Is it deployable? Yes, Weights are live on Hugging Face in Safetensors and GGUF, with day-one support in SGLang, MLX-VLM, and llama.cpp. Liquid AI team labels the release experimental, and it ships under the LFM Open License v1.0, which allows free commercial use only for companies under $10M in annual revenue.
可以部署吗?是的,权重已发布在 Hugging Face 上,格式为 Safetensors 和 GGUF,并获得了 SGLang、MLX-VLM 和 llama.cpp 的首日支持。Liquid AI 团队将该发布标记为实验性质,它根据 LFM Open License v1.0 许可分发,该许可仅允许年收入低于 1000 万美元的公司免费用于商业用途。
What Speculative Decoding Changes for a VLM
推测解码对 VLM 的影响
A standard model generates one token per forward pass. Speculative decoding adds a small drafter that proposes several tokens ahead. The large target model then checks the whole block in one pass and keeps the tokens it agrees with.
标准模型在每个前向传播中生成一个 token。推测解码增加了一个小型草稿模型,用于提前提议多个 token。然后大型目标模型在一次前向传播中检查整个块,并保留其同意的 token。
DSpark follows the recipe from Liquid AI’s text-model DSpark drafters, described in the DSpark paper. The drafter reads the target model’s hidden states from several layers and predicts the next k tokens.
DSpark 遵循 Liquid AI 文本模型 DSpark 草稿模型的配方,详见 DSpark 论文。草稿模型从多层读取目标模型的隐藏状态,并预测接下来的 k 个 token。
The key design point: modality does not matter to the drafter. By the time tokens reach the hidden layers, text and image patches are both just tensors. So Liquid AI team reuses the exact same inference algorithm for its vision-language model.
关键设计要点:模态对草稿模型并不重要。当 token 到达隐藏层时,文本和图像补丁都变成了张量。因此,Liquid AI 团队在其视觉语言模型中复用了完全相同的推理算法。
Drafter Architecture and Training
草稿模型架构与训练
The drafter is a simplified attention-only model. Ablations picked 4 layers and a block size of 9. Liquid AI recommends a block size of 8 or 9 at inference, depending on hardware. Apple silicon runs use 8.
草稿模型是一个简化的纯注意力模型。消融实验选择了 4 层和大小为 9 的块。Liquid AI 建议在推理时使用大小为 8 或 9 的块,具体取决于硬件。Apple Silicon 运行使用大小为 8。
| Component | Parameters |
|---|---|
| Decoder stack (4 layers) | 193.0M |
| Hidden-state projection | 21.0M |
| Markov head | 65.5M |
| Norms + confidence head | 6.4k |
| Total | 279.5M |
| 组件 | 参数 |
|---|---|
| 解码器堆栈(4 层) | 1.93 亿 |
| 隐藏状态投影 | 2100 万 |
| 马尔可夫头 | 6550 万 |
| 归一化 + 置信度头 | 6400 |
| 总计 | 2.795 亿 |
The embedding and LM head are tied to the target, so the drafter does not carry them. Liquid AI says this raises the deployed parameter count by 8.9%. Training used supervised fine-tuning data covering common vision-language tasks for 10 epochs. All ablations and training ran exclusively on AMD hardware.
嵌入和 LM 头与目标模型共享,因此草稿模型不包含它们。Liquid AI 表示这使部署的参数数量增加了 8.9%。训练使用了覆盖常见视觉语言任务的监督微调数据,共 10 个 epoch。所有消融实验和训练均在 AMD 硬件上独家进行。
Benchmark Results
基准测试结果
Evaluation follows the MMSpec benchmark across 6 task types: General VQA, Text VQA, Image Captioning, Chart VQA, Complex Reasoning, and Multi-turn Conversation. All runs used batch size 1, temperature 0, and 16-bit weights for the vision encoder and backbone. Data was collected on Pipette, Liquid AI’s public device-benchmarking infrastructure.
评估遵循 MMSpec 基准,涵盖 6 种任务类型:通用 VQA、文本 VQA、图像描述、图表 VQA、复杂推理和多轮对话。所有运行均使用批量大小 1、温度 0,以及视觉编码器和主干网络的 16 位权重。数据收集于 Pipette,即 Liquid AI 的公开设备基准测试基础设施。
| Stack | Decode speedup | End-to-end speedup | Accepted tokens per pass |
|---|---|---|---|
| MLX-VLM, M5 Max MacBook Pro (block 8) | 2.30x to 3.13x | 1.56x to 2.62x | 3.24 to 4.34 |
| llama.cpp, M3 Ultra (block 8) | 1.57x to 2.14x | 1.30x to 1.77x | 3.31 to 4.50 |
| SGLang, 1x H100 80GB (block 9) | 2.04x to 2.66x | 1.64x to 2.27x | 3.46 to 4.57 |
| 堆栈 | 解码加速比 | 端到端加速比 | 每轮接受的 token 数 |
|---|---|---|---|
| MLX-VLM,M5 Max MacBook Pro(块 8) | 2.30x 至 3.13x | 1.56x 至 2.62x | 3.24 至 4.34 |
| llama.cpp,M3 Ultra(块 8) | 1.57x 至 2.14x | 1.30x 至 1.77x | 3.31 至 4.50 |
| SGLang,1x H100 80GB(块 9) | 2.04x 至 2.66x | 1.64x 至 2.27x | 3.46 至 4.57 |
The ‘up to’ decode and end-to-end figures often come from different tasks. On the M5 Max, 3.13x decode is from COCO captioning, while 2.62x end-to-end is from MMMU-Pro.
“最高”解码和端到端数据通常来自不同的任务。在 M5 Max 上,3.13x 的解码加速来自 COCO 图像描述任务,而 2.62x 的端到端加速来自 MMMU-Pro。
Acceptance landed in a similar range on both Apple stacks. Liquid AI reads this as acceptance depending on the drafter and workload, not the runtime.
Apple 两个平台的接受率处于相似范围。Liquid AI 认为,接受率取决于草稿模型和工作负载,而非运行时框架。
At higher concurrency, DSpark kept a throughput advantage at every measured level on a single H100 in SGLang. The gap narrows as concurrency rises.
在高并发情况下,DSpark 在 SGLang 的单张 H100 上始终保持着吞吐量优势。随着并发量增加,差距逐渐缩小。
Output Quality and Temperature
输出质量与温度
Under greedy decoding, the target verifies every proposed token, so output is identical to the base model. At non-zero temperatures with matched sampling, speculative decoding preserves the target’s output distribution, as proven by Leviathan et al.
在贪婪解码下,目标模型会验证每个提议的 token,因此输出与基础模型完全一致。在匹配采样策略且温度非零的情况下,推测解码保留了目标模型的输出分布,这一点已由 Leviathan 等人证明。
Temperature does affect speed. Higher temperatures spread probability across more candidate tokens, so drafter and target disagree more often. In Liquid AI’s tests, this lowered acceptance and throughput.
温度确实会影响速度。较高的温度会使概率分布在更多的候选 token 上,导致草稿模型和目标模型更容易产生分歧。在 Liquid AI 的测试中,这降低了接受率和吞吐量。
Why End-to-End Gains Are Smaller on Edge
为何边缘设备的端到端收益较小
Speculative decoding only accelerates decoding. Image encoding and prefill run at the same speed. A VLM must encode the image, then process hundreds of visual tokens alongside the prompt.
推测解码仅加速了解码过程。图像编码和前缀填充(prefill)的运行速度保持不变。视觉语言模型(VLM)必须先编码图像,然后处理数百个视觉 token 以及提示词。
On edge devices with less compute than data center GPUs, prefill takes a larger share of latency. Liquid AI frames this as Amdahl’s law: total speedup is bounded by the part left unaccelerated. This explains cases like TextVQA on the M5 Max, where 2.69x faster decoding yields 1.56x end to end.
在计算能力低于数据中心 GPU 的边缘设备上,前缀填充占延迟的比例更大。Liquid AI 将其归结为阿姆达尔定律:总加速比受限于未加速部分。这解释了 M5 Max 上 TextVQA 案例的情况:解码速度快了 2.69 倍,但端到端仅快了 1.56 倍。
How to Run It
如何运行
SGLang requires v0.5.19 or newer. Launch LiquidAI/LFM2.5-VL-3B with --speculative-algorithm DSPARK and point --speculative-draft-model-path at the drafter. On Apple silicon, MLX-VLM v0.7.2 or newer accepts the drafter through --draft-model. DSpark in MLX-VLM currently supports greedy sampling only, so set temperature to 0. For llama.cpp, pair the GGUF drafter with the LFM2.5-VL-3B-GGUF target.
SGLang 需要 v0.5.19 或更高版本。使用 --speculative-algorithm DSPARK 启动 LiquidAI/LFM2.5-VL-3B,并将 --speculative-draft-model-path 指向草稿模型。在 Apple Silicon 上,MLX-VLM v0.7.2 或更高版本可通过 --draft-model 接受草稿模型。MLX-VLM 中的 DSpark 目前仅支持贪婪采样,因此请将温度设置为 0。对于 llama.cpp,将 GGUF 格式的草稿模型与 LFM2.5-VL-3B-GGUF 目标模型配对。
Integration work is public in the llama.cpp, SGLang, and MLX-VLM pull requests. Acceleration of quantized models is outside the scope of this release.
集成工作已在 llama.cpp、SGLang 和 MLX-VLM 的拉取请求中公开。量化模型的加速不在本次发布的范围内。
Key Takeaways
关键要点
- A 279.5M drafter adds 8.9% parameters to LFM2.5-VL-3B.
- Decoding runs up to 3.13x faster on M5 Max, 2.66x on H100.
- Output is identical under greedy decoding; distribution preserved when sampling.
- Prefill and vision encoding cap end-to-end gains, especially on edge.
- Tested at 16-bit only; quantized acceleration is not covered yet.
- 一个 2.795 亿参数的草稿模型使 LFM2.5-VL-3B 的参数增加了 8.9%。
- 在 M5 Max 上解码速度最高提升 3.13 倍,在 H100 上提升 2.66 倍。
- 在贪婪解码下输出完全一致;采样时分布得以保留。
- 预填充和视觉编码限制了端到端的收益,尤其在边缘设备上更为明显。
- 仅在 16 位精度下进行测试;量化加速尚未涵盖。
Check out the Technical Details. All credit goes to the researcher of this project. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
查看技术细节。所有功劳归于本项目的研究人员。此外,欢迎在 Twitter 上关注我们,别忘了加入我们有 15 万+成员的 ML SubReddit,并订阅我们的新闻通讯。等等!你在 Telegram 上吗?现在你也可以加入我们的 Telegram 群组。
更进一步:量化金融体系
看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力