LFM2.5-VL-DSpark: How to Treat Liquid AI’s Vision Drafter as a Verified Sidecar, Not a Second Model

What Liquid AI actually released: a vision drafter sidecar for LFM2.5-VL-3B

Liquid AI released its experimental LFM2.5-VL-DSpark vision drafter on September 24, 2026. It is easy to misread. The small DSpark artifact looks like something a team could deploy beside, or maybe instead of, a larger vision-language model. That is the wrong read. The useful question is not, how fast is the little model? The useful question is whether the target, sidecar, projector, runtime, tap point, verification logic, and rollback path are matched tightly enough that the target would have produced the same answer.

Liquid AI describes LFM2.5-VL-DSpark as an experimental drafter for LiquidAI/LFM2.5-VL-3B. The drafter is roughly 279.5M BF16 parameters, has four attention layers, and uses Markov and confidence heads. It reads target hidden states at fixed tap layers after image and text inputs enter the shared representation. In plain terms, it is not a standalone vision-language model. It is not a compressed replacement for LFM2.5-VL-3B. It is not a shortcut around the vision encoder. It is a speculative decoding sidecar, useful only when the unchanged target verifies the proposed tokens.

That distinction sounds fussy until it breaks a deployment. A team can pair the wrong sidecar, copy a text-model example, serve the drafter alone, or benchmark latency before checking whether greedy outputs still match the target path. None of those failures would be exotic. They are exactly the sort of mistakes that happen when a release is treated as a speed knob instead of a contract.

If you are still evaluating the base model, Optijara’s earlier LFM2.5-VL-3B local vision acceptance test is the parent context. This article is narrower. It is about DSpark as a verified sidecar. For teams already working with local quantized artifacts, Optijara’s Transformers GGUF llama.cpp packed path guide also explains why a plausible file name is not enough.

The DSpark execution contract: draft, verify, roll back, then accept tokens

In a correct vision DSpark setup, the image and prompt still enter the target vision-language path. The target remains responsible for the processor, tokenizer, prompt template, vision projector, language backbone, and final verification. DSpark reads hidden-state information at supported tap points and proposes candidate tokens. The target checks those proposals. Accepted tokens move forward. Rejected proposals need cache rollback so the system returns to a target-consistent state.

The tap point is the boundary that matters. A drafter trained to read one internal state cannot be dropped into an arbitrary model path and expected to preserve behavior. The target checkpoint, projector, tap layer, shared embedding or LM head assumptions, and runtime implementation all shape whether the draft tokens are meaningful.

Verification is the protection. For greedy decoding under matched conditions, speculative decoding is designed to preserve the target output while reducing expensive target steps. That algorithmic idea is useful. It is also not a warranty across every backend. Kernel differences, precision, image preprocessing, prompt templates, runtime revisions, and sampling implementations can still create divergences. The SGLang vision PR discussion reports output-token differences in a test context due to verification-shape numerical differences. Treat that as a prompt to test carefully, not as a reason to dismiss the release.

The gains also have a shape. DSpark does not remove image preprocessing or vision prefill. It can help when enough decode tokens are accepted to offset the cost of drafting, verification batching, rejected proposals, and cache traffic. That is related to stage timing, but it is not the same problem as mapping encode and decode timing with OpenVINO GenAI.

Original framework: the Draft-Target Compatibility Map

Optijara’s recommended framework for this release is the Draft-Target Compatibility Map. Fill it in before timing DSpark. If a row is unknown, the benchmark is not trustworthy yet.

For GGUF, prefer the current official VL pair: LiquidAI/LFM2.5-VL-3B-GGUF:F16 with LiquidAI/LFM2.5-VL-3B-DSpark-GGUF:F16, using the DSpark draft flags described on the model card. Avoid generic Hub commands that imply the drafter can be served alone. Also avoid copying a text-drafter example into a vision release. A text DSpark sidecar and a VL target are not interchangeable just because the names look close.

Runtime support deserves the same skepticism. The DSpark model card mentions SGLang version support and MLX-VLM support, but teams should verify that the installed build contains the relevant vision capability, not only the version string. The SGLang vision PR exposes nested language model LM head access and capture-layer support. The MLX-VLM PR connects DSpark-style hidden-state taps, speculative verification, and convolution-state cache rollback. The llama.cpp PR addresses target vocabulary architecture and double RoPE reordering in conversion. Those are capabilities to verify, not labels to quote in a slide.

What to test before you trust the speedup table

Optijara inspected the public model cards and integration code for this article. We have not run these models or reproduced the benchmarks; the test plan below is proposed work.

Start with parity. Then measure latency. A useful smoke test pins the model, tokenizer, processor, projector, chat template, runtime commit or package version, precision, image preprocessing, generation settings, and block setting. Run target-only greedy output first. Run DSpark greedy output second. Compare exact text. If it diverges, log the prompt, image hash, settings, runtime revision, and output diff before making any speed claim.

Liquid AI’s reported performance figures are useful, but they are condition-specific vendor results. The model card frames results around batch 1, temperature 0, 16-bit encoder and backbone settings, H100 BF16 with block 9, Apple FP16 with block 8; the Apple measurements use up to 2,048 output tokens. It reports examples such as H100 COCO decode and end-to-end ratios, plus Apple results including M5 Max and M3 Ultra rows. Treat those as directional evidence for the release, not as a promise for your workload. If benchmark evidence will be compared across systems, use protocol discipline like Optijara’s Evaluation Cards and benchmark protocols guide: score, prompt set, runtime, precision, and measurement rules need to travel together.

Mean accepted tokens per verification pass are not an acceptance percentage by themselves. Accepted length, rejected work, drafter cost, verification batch behavior, cache traffic, and output length all determine realized speed. A short answer can spend most of its time in vision preprocessing and prefill. A longer decode-heavy answer gives accepted draft tokens more room to matter.

Here is the practical rule: if your DSpark evaluation starts with the speedup table, it is pointed in the wrong direction. Start with output parity and artifact pairing. Speed comes later, and only if the compatibility checks pass.

Common mistakes when adopting LFM2.5-VL-DSpark

The first mistake is treating the sidecar as a second deployable vision model. It is a drafter for a matched target path. If your deployment plan says, serve the DSpark file as the model, the plan is wrong.

The second mistake is pairing a text DSpark sidecar with the VL target. Liquid AI’s launch material includes examples that can be easy to copy out of context. For the vision release, use the current vision target and current vision DSpark artifacts, then verify the projector and runtime path.

The third mistake is timing before proving parity. A fast path that changes greedy output is not a valid acceleration path for a target-preserving speculative decoder. It may still be interesting research, but it is not evidence that DSpark safely accelerates your target model.

The fourth mistake is reading a decode speed ratio as throughput, quality, memory savings, or product latency. Decode speed is not concurrency throughput. It is not a quality improvement. It does not automatically reduce peak memory. It does not remove prefill. Measure each separately.

The fifth mistake is ignoring license and artifact provenance. The LFM Open License v1.0 includes revenue-conditioned commercial terms and a threshold described in the license text. That is not unrestricted open source. Review the current license and get legal advice for commercial deployment boundaries.

Caveats and limits: where DSpark may not help

DSpark may help least on short outputs and vision-heavy prompts where preprocessing and prefill dominate. If a use case asks for a one-line caption, the sidecar may not have enough decode length to offset overhead. If a use case produces longer chart explanations, document reasoning, or multi-step image-grounded answers, the evaluation is more promising, but still workload-dependent.

Backend drift is another limit. H100, Apple MLX, SGLang, llama.cpp, BF16, FP16, FlashAttention, image templates, and tokenizer handling can all affect parity and performance. A runtime that works for one path does not prove every conversion or backend is safe.

Sampling needs extra caution. In principle, speculative decoding can preserve the target distribution when matched sampling is correctly implemented. That is different from producing identical text for every seed across every backend. For DSpark today, make greedy temperature 0 parity the first trust gate, then evaluate sampling only if your runtime documents and supports the matched algorithm.

Decision matrix: when a team should evaluate DSpark now

The decision is not, is DSpark good? It is, does this release’s sidecar contract fit your target, backend, workload, and operating discipline? That framing keeps a promising acceleration technique from becoming an unverified deployment shortcut.

Implementation checklist

Use this checklist for the first evaluation sprint. Choose representative image prompts. Pin the target, projector, DSpark sidecar, tokenizer, processor, template, runtime revision, precision, block setting, and image preprocessing. Run a target-only greedy baseline. Run DSpark greedy output and compare exact text. Measure TTFT, p50 and p95 end-to-end latency, peak memory, accepted token length, rejected proposals, warmup policy, cache settings, and fallback target-only behavior. Review the license. Decide rollout scope only after the parity and measurement evidence are in the same report.

{
  "target": "LiquidAI/LFM2.5-VL-3B",
  "sidecar": "LiquidAI/LFM2.5-VL-3B-DSpark",
  "runtime": "pinned revision with VL DSpark taps, verification, and rollback",
  "parity_status": "greedy target-only versus DSpark comparison required",
  "latency_status": "measure TTFT and p50/p95 end-to-end after parity",
  "memory_status": "measure peak runtime memory, not parameter count only",
  "license_review": "required before commercial rollout",
  "fallback_ready": "target-only path documented"
}

If your team needs help turning this into a reproducible inference evaluation rig, Optijara can help define the compatibility map, artifact pinning plan, and deployment decision record. The validation work still has to happen on your workload, with your images, prompts, runtime, and constraints.