Liquid AI’s DSpark targets the wait for a vision model’s answer

A small model proposes; the target checks

Liquid AI announced LFM2.5-VL-DSpark on September 24 as an experimental companion to LFM2.5-VL-3B, its model for working with images and text. The add-on contains approximately 280 million parameters and is intended to accelerate the existing model rather than replace it. [1]

The technique, called speculative decoding, lets a smaller model propose a batch of tokens—the pieces of text that form a response. The target model checks those proposals before accepting them. This can produce several accepted tokens in one verification pass, reducing the need to generate each through a separate target-model step. The original DSpark paper explains that draft-and-check mechanism; its results on other models are not evidence for Liquid’s vision model. [3]

Liquid’s model card says that under greedy decoding, which chooses the highest-probability next token, the result matches what the target would have written alone. That is a claim about preserving output, not making the answer more accurate. An incorrect reading of an image would not become correct simply because the text appeared faster. [2]

Two clocks, two different gains

In Liquid’s reported COCO image-captioning test, MLX-VLM on an Apple M5 Max delivered a 3.13× decoding speedup, while the end-to-end speedup was 2.59×. The model card specifies 16-bit weights, one request per batch, temperature zero and a draft block size of eight for its Apple tests. These are the company’s measurements against the target without DSpark, not results from The Illustral. [2]

The gap between those two numbers is central to the announcement. Liquid explains that speculation accelerates decoding, but not the initial image encoding or processing of the prompt. When those earlier stages account for much of the wait, faster text generation has less effect on the overall response. [1]

What is available, and what remains to test

Liquid publishes a model repository and describes integrations for MLX-VLM, SGLang and llama.cpp, with compatible builds and the matching target model required. The drafter is an additional component to load, not a standalone image assistant. [1][2]

For developers, this could make an existing image-description or visual-question-answering workflow more responsive. The useful test would be the complete wait on their own hardware and images, alongside memory use and answer quality. We have not installed or benchmarked this release, and the reported speedup should not be assumed for another device or workload.