推論系統
LFM2.5 Adds DSpark Draft Models, Boosting H100 Decoding Throughput by Up to 3.18×
Liquid AI has released DSpark draft checkpoints with about 300 million parameters for three LFM2.5 models and integrated them with llama.cpp and SGLang. Official tests show that acceleration varies significantly by model, data distribution, and hardware, so peak results should not be treated as representative of gains across all workloads.
Liquid AI has released DSpark draft models for LFM2.5-1.2B-Instruct, LFM2.5-2.6B, and LFM2.5-8B-A1B, providing both native and GGUF checkpoints. These roughly 300-million-parameter sidecars do not generate the final answer. Instead, they propose a sequence of candidate tokens that the original model verifies in a single pass. As long as sampling and verification are implemented correctly, the target model’s original output distribution is preserved.
Unlike conventional parallel drafters, DSpark adds a lightweight sequential module after the parallel backbone, allowing tokens within the same candidate block to depend on one another. This mitigates the decline in acceptance rates toward the end of a block. A confidence head then estimates the survival probability of candidate prefixes, allowing the scheduler to shorten the verification length based on the hardware throughput curve and system load. This prevents batch capacity from being wasted on low-confidence tails under high concurrency.
For LFM2.5-2.6B, Liquid AI tested five math, coding, and conversational workloads. On a single H100, average decoding speed rose from 323 to 864 tokens per second, a 2.67× increase. On an M4 Max, it increased from an average of 61 to 139 tokens per second, a 2.27× gain. Average function-calling latency in multi-tool scenarios fell by 57%. Across the series, peak gains in individual tests reached 3.18× on the H100 and 2.87× on-device.
Engineering teams should measure accepted sequence length, drafter memory usage, batch size, and tail latency together. Structured math and code are generally easier to predict than open-ended conversation, and the official tables show that gains can differ by more than twofold across datasets. The current results primarily come from vendor testing at batch size 1 on specific hardware configurations. The DSpark path in llama.cpp also remains concentrated in the shared server layer, so applications embedded directly through its core C API may not be able to enable it immediately.