Liquid AI Releases LFM2.5-VL-DSpark: 3B Vision Model Plus Draft Model, Up to 3.13x Decode Speedup
According to a Liquid AI blog post published in September 2026, Liquid AI introduced an experimental DSpark draft model for its open-weight vision-language model LFM2.5-VL-3B, adding roughly 280 million parameters (an 8.9% increase over the 3B target model), claiming up to 3.13x device-side decoding speedup and up to 2.66x on H100, with day-one support for llama.cpp, MLX-VLM and SGLang.
What changed
Liquid AI released an experimental DSpark draft model in September 2026, paired with its vision-language model LFM2.5-VL-3B. According to the vendor blog, the draft model follows the architectural approach of the text version LFM2.5-DSpark: it captures hidden states from the target model at fixed access layers and drafts a batch of candidate tokens from them; image patches and text tokens are projected into a shared representation space before entering these layers, so the draft model operates on hidden states of consistent dimensionality, and the inference algorithm matches that of the text model. The draft model uses a 4-layer, attention-only structure with a block size of 9 and about 279.5 million parameters, decomposed into a 193 million decoder stack, 21 million hidden-state projection, 65.5 million Markov head, and norms and confidence head 6400. The vendor claims decoding speedups of 2.30x to 3.13x per task and end-to-end speedups of 1.56x to 2.62x on M5 Max with MLX; 1.57x to 2.14x decoding on M3 Ultra with llama.cpp; the H100 decoding and end-to-end speedup figures appear to have a typographical anomaly in the original. The vendor stresses that speculative decoding is exact, that the target model verifies every proposed token so greedy output matches using the target model alone, and that the draft model is offered on Hugging Face in both Safetensors and GGUF formats.
What it means for developers
For developers deploying multimodal models on local or edge devices, the significance of this release is not the absolute speed numbers but the ratio of draft model to target model parameters, about 8.9%, which means the increment in VRAM and memory footprint is manageable. However, most of the speedup ratios are decoding-phase metrics, and end-to-end gains depend on the share of visual encoding and prefill in the workload, a point the vendor itself cites Amdahl's law to explain. This creates a fork: scenarios dominated by long outputs, multi-turn dialogue or image captioning may approach the vendor's claimed end-to-end numbers; scenarios dominated by single-pass long-image question answering, which require processing many visual tokens up front and then finish quickly, will see noticeably smaller gains. In addition, running the draft model depends on llama.cpp, MLX-VLM and SGLang branches that are not yet merged into mainline or require specific builds, so integration cost cannot be ignored. Note that, as of this article's check, KimiSeek's current model catalog has no entry for LFM2.5-VL-3B or LFM2.5-VL-DSpark, and the API and weight availability described in the source reflect the vendor's statements.
Integration and evaluation
Recommendation one: first measure the share of decoding in your total latency before deciding whether to adopt the draft model. The source notes that speculative decoding only accelerates decoding, not visual encoding or prefill, and that prefill accounts for a higher share of end-to-end latency on edge devices. This presupposes you can already obtain breakdown data for time to first token and decoding time; it is advisable to run baseline and draft-model configurations on the same set of six visual task categories (general VQA, text VQA, image captioning, chart VQA, complex reasoning, multi-turn dialogue), with end-to-end latency percentiles rather than decoding throughput alone as the evaluation metric. If your workload consists mainly of short images with long text output, the draft model may pay off; if it consists mainly of single-turn long-image question answering, the upside is capped by prefill. Recommendation two: choose between llama.cpp and SGLang based on deployment form, not on claimed peak speedup. The source gives different specific startup methods for the two: SGLang mounts the draft model via parameters such as --speculative-dspark-block-size and explicitly requires disabling radix cache; on the llama.cpp side, --spec-type draft-dspark is needed together with --spec-draft-n-max 8. This presupposes that the build you use includes the corresponding PR, otherwise these parameters are unavailable. During evaluation, it is advisable to record draft_n and draft_n_accepted for each response, and use the acceptance rate to judge whether block size 8 or 9 is more suitable; when acceptance is low, check whether the task distribution deviates from the training data mixture. These are recommended practices, not vendor commitments.
Limits and open questions
First, as of this article's check, KimiSeek's current model catalog has no exact entry for LFM2.5-VL-3B or LFM2.5-VL-DSpark, so this version is not currently listed on KimiSeek; the weight downloads, formats and integration methods mentioned in the source reflect the vendor's statements and do not represent availability on this site. Second, in the vendor's original text the decoding speedup range for one H100 case is written as "20.4x to 2.66x," an obvious typographical or transcription anomaly that should not be cited as a reliable upper bound. Third, the vendor describes the draft model as experimental; its 4-layer structure and block size 9 come from 3-, 4- and 5-layer ablations, and the training data mixture is weighted by expected workload, so acceptance rates and speedup ratios will drift with the actual task distribution. Fourth, the speedup figures come from vendor self-testing on M5 Max, M3 Ultra and H100, evaluated on the six task categories of the MMSpec benchmark; performance on other hardware, quantization formats, context lengths and batching settings has not been independently verified. Fifth, the source describes the model as open-weight and freely downloadable, fine-tunable and deployable, but the blog does not give specific license terms; weight availability does not equal an open-source license, and commercial use and redistribution rights must be based on the actual license on the Hugging Face model page.
Illustrations from the original report
