# Liquid AI adds a 280M draft model to speed up its 3B vision model > Source: > Published: 2026-09-24 14:14:14+00:00 # Liquid AI adds a 280M draft model to speed up its 3B vision model **Ramin Hasani's team says the experimental add-on cuts decoding time by up to 3.13x on an M5 Max, while leaving image processing and prompt prefill unchanged.** By [RuntimeWire Staff](https://runtimewire.com/author/runtimewire-staff) ยท Published Primary source: [Hugging Face Newsroom](https://huggingface.co/blog/LiquidAI/lfm2-5-vl-dspark) ## Why it matters Liquid AI is extending its device-first model strategy from smaller footprints to faster multimodal inference. The caveat is built into the benchmarks: DSpark speeds token generation, while image encoding and prompt prefill remain untouched, and quantized deployments were not tested. [Liquid AI](https://www.liquid.ai/?ref=runtimewire) released an experimental draft model for its LFM2.5-VL-3B vision-language model on September 24th, adding a 279.5-million-parameter component that the company says speeds up token generation without changing the target model's output distribution. The release extends the on-device strategy of co-founder and CEO [Ramin Hasani (@ramin_m_h)](https://x.com/ramin_m_h?ref=runtimewire), whose team is trying to make multimodal models responsive on local hardware, where every extra pass through a large model costs time and memory. [Hugging Face Newsroom covered the release](https://huggingface.co/blog/LiquidAI/lfm2-5-vl-dspark?ref=runtimewire), and [Liquid AI published its technical details](https://www.liquid.ai/blog/lfm2-5-vl-dspark?ref=runtimewire). Hasani came to the company from MIT's Computer Science and Artificial Intelligence Laboratory, where he was a postdoctoral associate and research affiliate, and from Vanguard, where he served as a principal AI and machine-learning scientist. He earned a computer science Ph.D. with distinction from Vienna University of Technology in 2020. Liquid AI, spun out of MIT CSAIL in 2023, was founded by Hasani, CTO Mathias Lechner, chief science officer Alexander Amini and MIT professor Daniela Rus. Its bet has been that capable foundation models can run close to users and devices rather than defaulting to data-center infrastructure. DSpark applies that bet to a practical bottleneck: how long a vision model takes to produce its answer after it has already processed an image. ([Liquid AI's company page](https://www.liquid.ai/company?ref=runtimewire); [Hasani's biography](https://www.liquid.ai/team/ramin-hasani?ref=runtimewire).) ### A small helper for a recent model The base model arrived on August 12th. Liquid AI described [LFM2.5-VL-3B](https://www.liquid.ai/blog/lfm2-5-vl-3b?ref=runtimewire) as a vision-language model for tasks including screen understanding, document reading, object grounding and tool use. Six weeks later, the company has added a drafter designed to accelerate its decoding stage, rather than replacing the model or changing its vision encoder. The drafter reads hidden states from selected layers of the target model and proposes a block of candidate tokens. The larger target model checks those candidates together; tokens that pass can be emitted without making the target model generate each one serially. Liquid says the vision version can use the same process as its text-model drafters because image patches and text tokens have already been projected into a shared representation by the time they reach those layers. The addition has four attention-only layers, a block size of nine in training, and about 280 million parameters, or 8.9% of the target model's parameter count. Liquid recommends an inference block size of eight or nine, depending on hardware. The company says it trained the drafter for 10 epochs on a mix of vision-language supervised fine-tuning data weighted toward expected use cases, and ran the training and ablations on AMD hardware. This is a continuation of Hasani's device-first product work. RuntimeWire previously covered Liquid AI's [LFM2.5 checkpoints tuned for 4-bit deployment](https://runtimewire.com/article/liquid-ai-lfm2-5-qad-4-bit-checkpoints) and its [2.6B model for on-device agents](https://runtimewire.com/article/liquid-ai-lfm2-5-2-6b-on-device-agents). Those releases addressed the model's footprint and its ability to act; DSpark targets the time spent generating an answer. Together, the work shows Liquid AI treating deployment limits as a set of engineering problems that can be tackled at multiple layers of the stack. ### The speedup depends on the workload Liquid AI reports decoding speedups of 2.30x to 3.13x on an Apple M5 Max using MLX-VLM, with end-to-end latency gains of 1.56x to 2.62x. On an M3 Ultra using llama.cpp, the company reports 1.57x to 2.14x faster decoding and 1.30x to 1.77x end-to-end gains. On a single Nvidia H100 80GB using SGLang, it reports 2.04x to 2.66x faster decoding and 1.64x to 2.27x end-to-end improvements. Vision-language workloads still spend time encoding the image and processing the prompt before generation. DSpark accelerates token generation; it does not speed up those earlier steps. Liquid's own measurements show why the headline maximum is not the whole deployment story: the best decoding gain on the M5 Max was 3.13x, while the largest reported end-to-end improvement was 2.62x. The tests covered six categories, including visual question answering, text in images, chart questions, image captioning, complex reasoning and multi-turn conversation. Liquid reports using batch size one, 16-bit weights, and a median answer length of 90 tokens for its on-device testing. Quantized-model acceleration was outside the scope of the release. The benchmarks were run on Liquid's Pipette benchmarking infrastructure, so the reported figures are company measurements rather than an independent replication. Speculative decoding is designed to preserve the target model's output distribution when sampling settings are matched: the target model verifies draft tokens and corrects rejected ones. Liquid reports roughly 3.2 to 4.5 accepted tokens per verification pass on its tested on-device setups, with acceptance varying by task. ### More runtimes, same deployment question Liquid says the drafter is available in [Safetensors](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark?ref=runtimewire) and [GGUF](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark-GGUF?ref=runtimewire) formats, with integrations for [llama.cpp](https://github.com/ggml-org/llama.cpp?ref=runtimewire), [MLX-VLM](https://github.com/Blaizzy/mlx-vlm?ref=runtimewire) and [SGLang](https://github.com/sgl-project/sglang?ref=runtimewire). That support gives developers several paths to test the model on Apple hardware, local inference setups and GPU serving stacks. The release also builds on Liquid's August DSpark release for text models, which introduced the same general approach to three LFM2.5 text models. The commercial test remains whether a faster generation loop meaningfully improves products people use, especially when workloads include large images or long prompts that DSpark cannot accelerate. For Hasani, the point of the add-on is clear: keep the target model's behavior while making a local vision model more responsive. The measured gains are strongest in decoding; real applications will see smaller, workload-dependent improvements whenever image encoding and prompt processing dominate the wait.