Liquid AI lancerer LFM2.5-DSpark for op til 3,2 gange hurtigere inferens

Liquid AI udgav speculative-decoding draft checkpoints for tre modeller i sin LFM2.5-familie den 20. august 2026 og rapporterede gennemstrømningsgevinster på op til 3,18× på en enkelt H100 GPU og op til 2,87× på en Apple‑silicon MacBook, uden ændring af modellens output. LFM2.5-DSpark‑udgivelsen dækker draftere til LFM2.5-1.2B-Instruct, LFM2.5-2.6B og den mixture‑of‑experts LFM2.5-8B-A1B, som hver tilføjer cirka 300 millioner parametre af draft‑overhead oven på målmodellen.

Checkpointene leveres i Safetensors- og GGUF-formater med dag‑en support i llama.cpp og SGLang, hvor begge integrationer er bidraget opstrøms til de officielle kodebaser. Da speculative decoding kun udsender tokens, som målmodellen har bekræftet, hævder virksomheden, at den genererede tekst er identisk med hvad målmodellen alene ville producere under greedy decoding, så benchmark‑nøjagtigheden forbliver uændret.

Liquid AIs målinger, udført med batch‑størrelse 1 og temperatur 0 på tværs af fem datasæt, viser en gennemsnitlig hastighedsforøgelse for LFM2.5-2.6B på 2,67× på en H100 (323 til 864 tokens pr. sekund) og 2,27× på en M4 Max MacBook Pro (61 til 139 tokens pr. sekund). Det største enkeltresultat kom fra LFM2.5-8B-A1B på MATH500, hvor gennemstrømningen på H100 steg 3,18×, fra 428 til 1.362 tokens pr. sekund. Virksomheden rapporterer også, at DSpark reducerede funktion‑kalds‑latens med i gennemsnit 57 % for LFM2.5-2.6B på tværs af multi‑tool‑scenarier, hvilket er hovedresultatet for de on‑device agent‑arbejdsbelastninger, som LFM2.5‑serien er rettet mod.

Hvordan DSpark accelererer dekodning

Dekodningsfasen i LLM‑inferens er hukommelses‑begrænset: størstedelen af latensen skyldes streaming af vægte fra DRAM til on‑chip‑hukommelse snarere end selve beregningen, hvilket er grunden til, at inferensekonomi er blevet feltets centrale ingeniørproblem.

DSpark, introduceret i et juli‑2026‑papir af DeepSeek‑forskerne og implementeret i virksomhedens DeepSeek-V4‑servingsystem, kombinerer tre komponenter: en parallel rygsøjle, der producerer skjulte tilstande for alle draft‑tokens i ét enkelt pass, et letvægts sekventielt hoved, der modellerer afhængigheder mellem nabotokens for at forhindre, at accept‑raterne falder sent i blokken, samt en tillids‑styret verifikator, der beskærer lav‑tillids‑suffixer, når verifikation af dem ville koste mere end den sparer. I DeepSeeks produktions‑deployment rapporterer papiret per‑bruger generations‑hastighedsforøgelser på 60 til 85 % i forhold til den tidligere MTP‑1‑baseline ved tilsvarende gennemstrømning.

Liquid AIs draftere følger denne opskrift med et forenklet attention‑only design: fem lag, en blokstørrelse på ni draft‑tokens pr. trin og et Markov‑hoved over et ordforråd på 128.000 tokens, ifølge LFM2.5-2.6B‑modelkortet. Hver drafter blev trænet i 15 epoker på en blanding af superviseret finjustering, chat, kode og funktion‑kald‑data, hvor checkpointet blev udvalgt ud fra den højeste accept‑rate i stedet for den laveste tab. Nøjagtighedsgarantien leverer kvaliteten: “Speculative decoding er eksakt: målmodellen bekræfter hver foreslået token, så greedy‑output svarer til målmodellen alene,” står der på GGUF‑modelkortet, med per‑respons‑tidsmålinger, der viser, hvor mange draft‑tokens der blev foreslået og accepteret.

LFM2.5-DSpark i tal

• 3,18× — bedst rapporterede GPU‑hastighedsforøgelse (LFM2.5-8B-A1B, MATH500, H100: 428 → 1.362 tok/s)
• 2,87× — bedst rapporterede on‑device hastighedsforøgelse (LFM2.5-1.2B-Instruct, HumanEval, M4 Max: 136 → 389 tok/s)
• 2,67× / 2,27× — gennemsnitlige H100‑ / M4 Max‑hastighedsforøgelser for LFM2.5-2.6B på tværs af fem datasæt
• 57 %: gennemsnitlig reduktion af funktion‑kald‑latens for LFM2.5-2.6B i multi‑tool‑scenarier
• 295,7 M–327,7 M (draft‑modelparametre, i forhold til mål på 1,2 B til 8 B)
• 4,81 af 10, gennemsnitligt accepterede draft‑tokens pr. trin for LFM2.5-2.6B ved blokstørrelse 9

Hvor de rapporterede hastighedsforøgelser aftager

Liquid AIs egne tabeller viser, at gevinsterne er ujævne, og virksomheden redegør for årsagerne. For LFM2.5-8B-A1B er on‑device‑forbedringen i gennemsnit kun 1,18× på trods af de højeste accept‑rater blandt de tre modeller, et hul som virksomheden tilskriver den nuværende mixture‑of‑experts‑implementering i llama.cpp’s Metal‑backend og den ekstra vægt‑trafik, som verifikation af en token‑blok aktiverer på tværs af eksperter. For LFM2.5-1.2B-Instruct varierer accept‑raterne nok mellem datasæt til, at hastighedsforøgelsen kan svinge med op til 52 % afhængig af tekstfordelingen, fra 1,66× på MT‑Bench op til 2,56× på MATH500 på H100.

Alle tal er leverandør‑rapporterede fra Liquid AIs egen test‑opsætning: SGLang på én H100 80 GB i BF16 for GPU‑tal, llama.cpp med eksperimentelle Metal‑kerner på en M4 Max med FP16 GGUF‑vægte for on‑device‑tal, begrænset til 256 output‑tokens. SGLang‑stien kræver et build med DSpark‑support for LFM2‑mål, og llama.cpp‑stien kræver det tilsvarende build, så hastighedsforøgelserne afhænger af disse integrationer frem for at blive leveret i en stabil udgivelse af nogen af motorerne.

Liquid AIs on‑device‑indsats indtil nu

DSpark‑udgivelsen er den tredje opdatering af LFM2.5‑familien på lidt over en uge. Den 12. august 2026 lancerede LFM2.5-VL-3B, en vision‑language‑model til edge, og den 19. august 2026 offentliggjorde den kvantisering‑bevidste destillerede Q4_0‑checkpoints for familien. Den gennemgående pointe er den samme: virksomheden siger, at 2,6B‑modellens DSpark‑hastighedsforøgelse på en MacBook skubber interaktiviteten ud over den gennemstrømning, som de fleste proprietære cloud‑modeller tilbyder, som de anslår til cirka 140 tokens pr. sekund.

Alle tre draftere er nu tilgængelige på Hugging Face: LFM2.5-1.2B-Instruct-DSpark, LFM2.5-2.6B-DSpark, og LFM2.5-8B-A1B-DSpark, med GGUF‑builds ved siden af til llama.cpp‑deployment.