Today, we release DSpark draft models for LFM2.5-1.2B-Instruct, LFM2.5-2.6B, and LFM2.5-8B-A1B. These add a speculative decoding path that trades a minimal memory increase for a large decoding speedup without changing output quality. A lightweight draft model proposes a block of candidate tokens and the target model verifies them in a single forward pass. Across MATH500, GSM8K, HumanEval, MBPP, and MT-Bench at batch size 1: > Up to 3.18x throughput on an H100: LFM2.5-8B-A1B on MATH500, 428 → 1362 tok/s > Up to 2.87x on an M4 Max MacBook Pro: LFM2.5-1.2B-Instruct on HumanEval, 136 → 389 tok/s > LFM2.5-2.6B means: 2.67x on the H100 (323 → 864 tok/s), 2.27x on device (61 → 139 tok/s) > Under greedy decoding, the emitted sequence is identical to baseline by construction, so benchmark accuracy is unchanged. Each draft model is around 300M parameters, with embedding and LM head tied to its target model. The gain shows most in agentic workloads, where the model reasons before every tool call and the user waits through it all: on BFCL multi-tool scenarios, DSpark cuts LFM2.5-2.6B latency by nearly 50% on average. 🧵
Measured with llama.cpp and Metal on an M4 Max MacBook Pro, FP16 GGUF weights, batch size 1, temperature 0: > LFM2.5-1.2B-Instruct: 2.54x mean, 138 → 350 tok/s > LFM2.5-2.6B: 2.27x mean, 61 → 139 tok/s > Day-one GGUF checkpoints, with the LFM-compatible DSpark integration open-sourced upstream in llama.cpp In agentic workloads the model reasons before every tool call, and the user waits through it all. That is where speculation pays most: on BFCL multi-tool scenarios, DSpark cuts LFM2.5-2.6B latency by nearly 50% on average. 2/

A parallel draft backbone proposes a block of tokens in one forward pass, a Markov-chain head adds dependency between neighboring draft tokens, and the target model verifies the whole block at once. We follow the DSpark recipe with an extended data mixture of SFT, chat, code, and function-calling data. Every draft model and every ablation is trained on @AMD MI325x GPUs. Ablations set the architecture: > 5 layers, block of 9, attention-only for the first version > 15 epochs per draft model, tracking validation loss and acceptance rate at every epoch > Mean acceptance of 10 drafted tokens: 6.95 for LFM2.5-8B-A1B, 5.02 for LFM2.5-1.2B-Instruct, 4.81 for LFM2.5-2.6B 3/
The speedup varies by architecture. LFM2.5-8B-A1B is the strongest case on the H100 and the weakest on device, at 1.18x mean on the M4 Max (90 → 106 tok/s). That traces to how mixture-of-experts models currently run on Metal in llama.cpp, and to the memory the target model needs while verifying draft tokens. We publish the numbers as measured, and it is the subject of subsequent work. The DSpark draft model checkpoints are available now on Hugging Face. Read more: https://t.co/HHVuu0fSju > LiquidAI/LFM2.5-1.2B-Instruct-DSpark: https://t.co/2W7lAvffxu > LiquidAI/LFM2.5-2.6B-DSpark: https://t.co/z8BBGupluL > LiquidAI/LFM2.5-8B-A1B-DSpark: https://t.co/usgnONMXRa > SGLang: https://t.co/jpnDIBZVnw > llama.cpp: https://t.co/HxEiT6DK3S 4/4
loops that reason before every tool call pay latency users feel. These roughly 300M draft models cut it by nearly half on BFCL multi-tool scenarios, with output identical to baseline under greedy decoding and day-one GGUF plus llama.cpp support.
Checking sign-in…
Loading comments…