AI Model & Platform UpdatesInference Acceleration

Liquid AI’s DSpark Turbocharges LFM2.5 With Up to 3.2× Throughput—Without Changing Greedy Outputs

Liquid AI released DSpark draft checkpoints for LFM2.5-1.2B-Instruct, 2.6B, and 8B-A1B that add speculative decoding for big speedups: up to 3.18× on GPU and 2.87× on-device, with minimal memory overhead and greedy-output parity. Day-one support in llama.cpp and SGLang makes this a practical upgrade for edge and agentic workloads.

NexusAi Research TeamAug 25, 20262.1K views8 min read

Liquid AI’s DSpark Turbocharges LFM2.5 With Up to 3.2× Throughput—Without Changing Greedy Outputs

AI Brief

Liquid AI’s DSpark arrives as draft checkpoints for three LFM2.5 models, adding a speculative decoding path that preserves greedy output while boosting decode throughput—measured up to 3.18× on an H100 and up to 2.87× on a MacBook with minimal memory overhead. DSpark combines a parallel backbone, a lightweight sequential head, and a confidence-scheduled verifier to lift acceptance rates and amortize weight loads across multiple tokens. With day-one support in llama.cpp and SGLang, teams can evaluate DSpark quickly in both GPU and on-device contexts. The takeaway: smaller instruction-tuned models can now hit “interactive” speeds for chat, coding, and agentic loops—especially function-calling—without retraining or sacrificing output determinism under greedy settings.

Liquid AI is shipping DSpark draft checkpoints for LFM2.5-1.2B-Instruct, 2.6B, and 8B-A1B that add speculative decoding to the decode path. The claim is straightforward: up to 3.18× throughput on a single H100 and up to 2.87× on-device, while keeping greedy outputs identical to baseline. That parity matters—DSpark verifies every proposed token—so teams can adopt the speedup without compromising established evaluation baselines. With day-one support in SGLang and llama.cpp, the rollout isn’t just a lab demo; it’s immediately runnable in common inference stacks. The impact is most visible where small models must feel instant: local chat, coding assistants, and agentic function-calling, where DSpark also cuts latency materially.

Why does this work now? LLM decoding is often memory-bound: repeatedly pulling large weights from DRAM dominates latency. DSpark tackles this by using a compact drafter that proposes multiple tokens, then having the target model verify them in a single pass—amortizing the weight traffic. Its recipe pairs a DFlash-style parallel backbone with a lightweight Markov head to add inter-token dependency, and a confidence-scheduled verifier that prunes low-confidence suffixes. Liquid AI’s drafters are ~300M parameters and trained for acceptance rather than pure loss, pushing more verified tokens per pass. The result: fewer round trips through memory per emitted token, which translates into higher throughput without changing greedy outputs.

Performance isn’t flat across contexts. For small dense models (1.2B–2.6B), DSpark delivers consistent 2–3× gains on GPUs and strong on-device speedups that cross the “feels instant” threshold for interactive use. The 8B-A1B MoE model shows robust GPU gains but thinner on-device improvements due to current Metal MoE efficiency and the cost of verifying multiple tokens across more experts. Still, DSpark’s ability to raise tokens-per-second on laptops makes local assistants and agents meaningfully more useful, and in agentic flows Liquid AI reports average function-calling latency dropping by more than half—an outsized win for tools-heavy scenarios where turn-time is the bottleneck.

Operationally, DSpark is a low-friction upgrade: attach the draft to the target model in SGLang or use a DSpark-enabled llama.cpp build, then monitor acceptance rate and draft_n/draft_n_accepted to validate benefit. Start with the drafter that matches your LFM2.5 target and a moderate block size; tune for your domain text to stabilize acceptance. Because speculative decoding is exact under greedy, your evaluation harnesses and benchmarks remain apples-to-apples. For production, validate agentic performance end-to-end—especially tool latency and function-calling cadence—since DSpark’s practical ROI appears largest where multi-step tool calls dominate response time.

Key Takeaways

Greedy Parity With Real Speed

DSpark verifies every proposed token, so greedy decoding matches baseline outputs while delivering up to 3.2× throughput on GPUs and strong on-device gains—ideal where correctness and responsiveness both matter.

Edge and Agent Workloads Benefit First

Smaller dense LFM2.5 models hit interactive speeds locally, and multi-tool agent flows see notably lower turn-time as DSpark trims function-calling latency by more than half on average.

Adopt Fast, Measure Smart

Attach the DSpark draft, track acceptance rate and draft_n_accepted, and evaluate tokens-per-dollar and end-to-end latency. Expect thinner on-device gains for MoE until Metal kernels and scheduling mature.

What Liquid AI Just Shipped—and Why It Matters

DSpark draft checkpoints for three LFM2.5 models enable speculative decoding that increases throughput without changing greedy outputs. The gains are meaningful for both cloud and edge: measured up to 3.18× on an H100 and up to 2.87× on a MacBook-class device with minimal additional memory. With day-one support in SGLang and llama.cpp, DSpark is not another research-only branch; it’s production-adjacent. For founders and platform teams prioritizing responsiveness and cost, this allows smaller models to reach interactive speeds in coding, chat, and agent loops—reducing the pressure to scale to larger models purely for latency reasons.

How DSpark Lifts Throughput While Preserving Greedy Parity

Speculative decoding addresses the memory-bound decode bottleneck by proposing multiple tokens via a lightweight drafter and verifying them in one pass on the target model. DSpark’s blend—parallel backbone for all draft tokens, a sequential Markov head to raise later-position acceptance, and a confidence-scheduled verifier to prune low-confidence suffixes—pushes more accepted tokens per verification. Liquid AI trained ~300M-parameter drafters tuned for acceptance, not just loss. Under greedy decoding, rejected proposals are replaced by the target’s own choice, so emitted tokens are identical to baseline. The net: fewer roundtrips through memory per emitted token and higher tokens-per-second without changing outputs.

Where It Helps Most: GPU vs. On-Device and the MoE Caveat

For dense 1–3B models, DSpark routinely delivers 2–3× throughput on GPUs and 2×+ on modern laptops—enough to transform chat and code experiences and to accelerate agent loops. On-device speedups for the 8B-A1B MoE variant are slimmer due to current Metal backend efficiency and the cost of validating k tokens across more experts. If your workload is tools-heavy, the 57% average reduction in function-calling latency is particularly valuable. Bottom line: pick DSpark for small-to-mid models targeting interactive UX or cost-sensitive serving; for MoE on-device, expect benefits but budget conservatively until kernel and backend support matures.

Integration Playbook: From Lab to Production Confidence

Adopt DSpark by pairing the target LFM2.5 model with its matching draft in SGLang or a DSpark-enabled llama.cpp build. Start with the default draft block size and verify gains using acceptance-rate telemetry and per-response draft_n vs. draft_n_accepted. Evaluate on your real traffic mix—chat, code, math, and tool use—to avoid overfitting to a single corpus. For on-device deployments, profile memory headroom with your chosen quantization and context length. In production, track end-to-end agent latency and tokens-per-dollar, not just raw tok/s, to capture DSpark’s effect on function-calling turn-time and overall user-perceived responsiveness.

Limits, Risks, and What to Watch Next

DSpark’s greedy-output parity does not extend to non-greedy settings; sampling with temperature or nucleus changes acceptance dynamics and may re-introduce drift, so use deterministic decoding where parity matters. On MoE models, verifying multiple tokens can activate more experts and saturate memory bandwidth, dampening on-device speedups until kernels improve. There is a small memory overhead from the draft; budget for it alongside context length and KV cache. Finally, monitor upstream support in SGLang and llama.cpp; as kernels and scheduling improve—especially on Metal—you can expect the on-device gap for MoE to narrow.

Frequently Asked Questions

Will DSpark change my model’s answers?

Under greedy decoding, no—DSpark’s verifier ensures the emitted sequence matches the target model. If you enable sampling (temperature, nucleus), acceptance dynamics shift and outputs can diverge; keep deterministic settings when parity is required.

How much extra memory does the draft add, and does quantization help?

The drafter is about a few hundred million parameters, adding a modest overhead relative to the target model. Quantized GGUF builds reduce the footprint further, which is especially useful on laptops and edge devices with tighter memory budgets.

What should I measure to validate DSpark in production?

Track acceptance rate, tokens-per-second, and draft_n vs. draft_n_accepted. For real ROI, measure end-to-end latency (especially function-calling), tokens-per-dollar, and user-visible responsiveness on your actual workload mix.