Liquid AI’s new LFM2.5-VL-DSpark can accelerate the text generated after a vision-language model reads an image. It does not accelerate the vision encoder or input prefill. For an enterprise evaluating local document extraction or visual assistance, the deployment decision is therefore not whether the advertised token rate is attractive. It is whether the complete image-to-answer path improves enough to justify an experimental drafter, a compatible runtime and additional memory.
On 24 September 2026, Liquid AI announced the experimental vision drafter for LFM2.5-VL-3B. The release is available as downloadable weights, not a new hosted-service tariff. The practical recommendation: benchmark the exact paired artifacts on your own image and answer-length distribution before changing a production endpoint. The measurements below are vendor results; I have not reproduced the hardware benchmarks.
What changed: a vision-specific drafting sidecar
The new component is not a replacement vision model. Its approximately 280 million parameters propose blocks of output tokens using hidden states from the target LFM2.5-VL-3B. The target verifies those proposals. Liquid AI reports an 8.9% increase in deployed parameter count; that is not a guarantee of an 8.9% increase in total process memory. Runtime buffers, cache capacity and temporary allocations still need measurement.
Image and text representations have already entered the target’s hidden layers when the drafter uses them. This lets the drafting algorithm operate after multimodal input processing, but it also explains its boundary: it cannot remove work that happened earlier in the request. The earlier text-only DSpark release is background, not today’s news. This release adds a matched drafter for the vision-language target.
The model card identifies the target/drafter pairing and runtime requirements. Use LFM2.5-VL-3B-DSpark with LFM2.5-VL-3B; the similarly named text drafter is not an interchangeable artifact. For GGUF, the dedicated sidecar card specifies the VL target and its vision projector. Preserve all their revisions in the deployment manifest.
Read the benchmark as two different claims
Liquid AI reports M5 Max results with MLX-VLM of 2.30–3.13× faster decode and 1.56–2.62× end-to-end improvement across six task categories. On an M3 Ultra with llama.cpp, the corresponding ranges are 1.57–2.14× and 1.30–1.77×. On a single H100, the original announcement reports 2.04–2.66× decode and 1.64–2.27× end-to-end improvement.
Those are different machines and software stacks, not a controlled hardware purchase comparison. The headline single-request measurements use batch size one, temperature zero and 16-bit processing. Apple runs use FP16 and draft block size eight; the H100 run uses BF16 and block size nine. Quantized-model acceleration is outside the reported release measurements. Do not apply these ratios to an existing four-bit deployment.
The gap is visible inside a single task. For TextVQA on the M5 Max, the card reports 2.69× decode acceleration but 1.56× end-to-end improvement. For COCO image captioning on the same stack, it reports 3.13× and 2.59×. These vendor observations support segmenting by task; they do not predict German invoices, low-contrast technical labels or your camera images.
For a short extraction response, vision encoding and prefill may dominate. A longer explanation gives faster decode more time to matter. Measure input image count, resolution and actual output length alongside latency. Do not lengthen answers to manufacture a more flattering speedup.
Availability, runtime support and commercial use
The Safetensors and GGUF repositories are publicly accessible. Deployment on customer-controlled hardware is possible in principle, but a download does not establish suitability for a particular device, processing region or regulated workflow. Local inference can reduce transmission to a hosted model; it does not automatically control application logs, telemetry, backups or artifact downloads.
The model card names SGLang v0.5.19 or newer and MLX-VLM v0.7.2 or newer. The MLX-VLM release notes include the LFM2-VL change enabling speculative decoding. Treat version strings as a starting point: verify that the installed build recognizes the target, drafter and intended sampling mode. The card currently limits MLX-VLM DSpark to greedy sampling, with temperature zero. A general claim about distribution-preserving speculative sampling does not override that runtime restriction.
For SGLang, the model-card example disables radix caching. Preserve that setting in the matched baseline when isolating the drafter’s contribution. Then compare against your actual production configuration separately. Otherwise a simultaneous cache-policy change can be misattributed to speculation. The general speculative-decoding break-even framework explains draft and verification overhead; this release adds the vision-input bottleneck and artifact-pairing checks.
Commercial licensing needs a separate procurement gate. Both the drafter license and the target license are LFM Open License v1.0. They include a commercial-use limitation tied to annual revenue and define a US$10 million threshold. Do not interpret promotional “open-weight” language as unrestricted enterprise commercial use. Ask counsel to review the legal-entity definition, threshold wording and intended use; obtain appropriate terms from Liquid AI where needed. This is a procurement warning, not legal advice. The checked sources do not provide a price for a separate enterprise agreement.
A release-specific acceptance decision
Use this compact decision table to choose the first test, not to approve deployment from documentation alone.
|
Observed condition |
Next decision |
|---|---|
|
Short answers; slow first token |
Profile vision and prefill first |
|
Long answers; decode dominates |
Test the matched VL drafter |
|
Four-bit production baseline |
Do not transfer 16-bit speedups |
|
MLX needs nonzero temperature |
Keep the supported baseline |
|
Commercial terms unresolved |
Hold the commercial rollout |
Freeze the target weights, image preprocessing, projector, tokenizer, prompt template, sampling settings and output cap. Compare the same runtime with speculation disabled and enabled. Keep a second comparison against the current production deployment, clearly labelled when precision or cache policy differs. This separates “does this drafter help?” from “is migrating our service worthwhile?”
Build a small governed test corpus from real workload classes: short field extraction, longer visual explanation and difficult image inputs. Include German terminology where the application requires it. Hold image preprocessing constant during the initial comparison. Reducing resolution may reduce latency while removing small text; that is a quality change, not a free inference optimization.
Capture time to first token, completion latency, generated token count, peak memory and accepted draft tokens where the runtime exposes them. Repeat at representative concurrency. Liquid AI reports a narrowing advantage as concurrency increases; a batch-one result is not evidence that a busy shared service gains the same ratio. Use the inference SLO framework to separate queue delay from model execution.
Output equivalence is not task correctness
The vendor describes exact greedy decoding and distribution preservation under matched sampling. Check the pinned implementation and numerical configuration rather than promising byte-identical output across every device or precision. Record malformed extraction fields, omitted units and incorrect visual claims alongside speed. An answer can match the baseline and still be wrong.
For industrial assistance, faster generation does not qualify the VLM to reject parts or control machinery. Keep any proposed visual explanation separate from a validated inspection policy. The visual-quality calibration guide addresses defect scores and disposition decisions; DSpark supplies no new evidence for those thresholds.
A bounded canary should preserve a no-drafter route, memory headroom and the previous artifact bundle. Stop promotion if task-quality checks fail, first-token latency breaches its budget, peak memory removes required capacity or completion gains disappear under realistic arrivals. No useful speedup is also a valid result: keep the simpler route rather than maintaining an extra experimental component without service-level benefit.
Make the next step a measured pilot
Bring the current model route, an approved image sample, the answer-length distribution and the latency budget to an AI implementation review. The useful deliverable is a paired-artifact manifest, a phase-level comparison and a reversible release decision—not another tokens-per-second headline. Resolve commercial terms before the production rollout, then promote only the workload classes for which the complete image-to-answer path has earned the added complexity.
