Liquid AI udgiver DSpark-drafters: op til 3.18× hurtigere dekodning (kun ved greedy decoding)
Liquid AI udgav 20. august 2026 DSpark-drafters til tre LFM2.5-modeller som rigtige vægte, ikke en hostingtjeneste (kilde 3029). De leveres i Safetensors og GGUF og kører i praksis via SGLang eller llama.cpp i builds med DSpark-understøttelse. Der er ingen hosted udbydere på Hugging Face i skrivende stund (kilde 3027). Valget er derfor mere teknisk, men også mere kontrollerbart for teams, der selv hoster.
Nyheden kort
Tre DSpark-draftere er frigivet til LFM2.5-1.2B-Instruct, LFM2.5-2.6B og LFM2.5-8B-A1B (kilde 3027, 3029). Liquid AI rapporterer op til 3,18× hurtigere dekodning på H100 og op til 2,87× på M4 Max, målt ved batch size 1 og temperatur 0 (kilde 3027, 3029). Under greedy decoding matcher output 1:1 med target-modellen, så benchmark-nøjagtighed ændres ikke; det er ikke dokumenteret for sampling-scenarier (kilde 3027, 3029). Licensen er LFM Open License v1.0 med gratis kommerciel brug under 10 mio. dollar i årlig omsætning; ellers kræves kommerciel aftale (kilde 3027).
Hvad er en drafter og hvorfor betyder det noget
DSpark bygger på speculative decoding: en lille drafter på cirka 300 millioner parametre foreslår en blok på ni kandidat-tokens, og den større target-model verificerer hele blokken i et enkelt forward pass (kilde 3027). Når mange tokens i blokken godkendes, falder antallet af dyre target-forward passes per output-token. Det giver fart. Når teksten er mindre forudsigelig, accepteres færre tokens, og gevinsten krymper.
Hvad blev frigivet — konkrete facts
Drafters dækker LFM2.5-1.2B-Instruct, LFM2.5-2.6B og MoE-modellen LFM2.5-8B-A1B (kilde 3027, 3029). Hver drafter er omtrent 300M parametre: 295,7M for 1,2B-drafteren og 327,7M for 2,6B og 8B-A1B (kilde 3027). Blokstørrelse 9. Backbone: 5 full-attention-lag, hidden_size 2048, intermediate_size 6144, GQA med 32 hoveder over 8 KV-hoveder. Embedding og LM-head deles med target ved load, så drafteren medbringer ikke eget vocab (kilde 3027).
Vægtene udgives som Safetensors og GGUF, og 2,6B-drafterens repository fylder cirka 655 MB i BF16. Det er den ekstra hukommelse oven på target (kilde 3027). Der er omtalt “day-one support” i både SGLang og llama.cpp, men i praksis kræves specifikke builds med DSpark-understøttelse for LFM2-targets. Det er ikke plug and play fra en hosted endpoint (kilde 3027).
De målte gevinster
Liquid AI publicerer throughput på 1×H100 i BF16 via SGLang og på en M4 Max MacBook Pro via llama.cpp med Metal og FP16 GGUF. Fælles setup: block size 9, batch size 1, temperatur 0. Benchmarks: MATH500, HumanEval, MBPP, GSM8K og MT-Bench (kilde 3027). Toppene er op til 3,18× på H100 og 2,87× på M4 Max, bekræftet af både MarkTechPost og Unite.ai (kilde 3027, 3029). 3,18× kommer fra 8B-A1B på MATH500; 2,87× på M4 Max ses på HumanEval for 1,2B-modellen (kilde 3027).
MoE på Mac er svagere: 8B-A1B giver i gennemsnit 1,18× på M4 Max. Liquid AI peger på Metal-backendens nuværende MoE-implementering og at verifikation af flere tokens aktiverer flere eksperter og mere vægttrafik end én decode-step (kilde 3027). Gevinsten afhænger altså af backend og modeltype.
Hvorfor hastigheden svinger
Acceptance driver speedup. LFM2.5-8B-A1B accepterer cirka 8,27 ud af 10 tokens på MATH500 og kun 4,02 på GSM8K på samme GPU. Det svarer til et sving fra cirka 3,18× til omkring 1,29× i målt gevinst (kilde 3027). LFM2.5-1.2B-Instruct rammer en lavere acceptance på MT-Bench og får tilsvarende lavere speedup i de målinger (kilde 3027). Tag udgangspunkt i jeres teksttyper, ikke en enkelt gennemsnitsfaktor.
Hvad det betyder for drift og implementering
Man bytter ekstra vægte og lidt mere hukommelse for færre target-forwards. Det er attraktivt ved batch size 1, hvor latency styrer oplevelsen. På Mac giver tallene for 1,2B og 2,6B en mere smidig lokal udvikling — hvis I kører SGLang eller llama.cpp i builds med DSpark-support, for der er ingen hosted endpoints endnu (kilde 3027). Og husk versionsstyring: embedding og LM-head bindes fra target, så inkompatible target-versioner kan give load-fejl (kilde 3027).
Driftsmæssigt er der tre nøgletal at logge: acceptance, faktisk tok/s og peak-mem. Falder acceptance i en bestemt feature, forsvinder gevinsten, og SLA kan glide. Hav et fallback til ren target-dekoding, hvis drafter ikke kan loades eller hvis acceptance dykker.
To korte app-cases
Kundesupport-chat med batch size 1: standardspørgsmål om leveringstider og returregler giver typisk forudsigelige svar. Her ligger acceptance højt, og svartiden falder mærkbart. De frie henvendelser, hvor sprog og intention zigzagger, trækker acceptance ned — og hastighedsgevinsten tørrer ind. Mål det i spidsbelastningstimerne, ikke kun i en POC midt formiddag.
Lokal kodeassistent på laptop: korte hjælpetekster, snippet-kommentarer og rename-forslag er ofte gentagelige og giver høj acceptance. Lange refaktoreringer med flere deltrin og nye symboler er mere uforudsigelige — her falder acceptance, og speedup’en bliver mindre synlig for brugeren.
Hvad med hukommelse og concurrency
Speedup ved batch size 1 kan reducere beregningstid pr. svar og give en mere stabil oplevelse. Tradeoff’et er mere kompleks orkestrering og et behov for en plan, hvis DSpark-builds ikke er tilgængelige overalt. Test også om peak-GPU-mem ændrer sig ved flere samtidige sessioner. Der mangler offentlige tal for production-grade concurrency, så her bør man logge selv (kilde 3027).
Licens og kommerciel brug
LFM Open License v1.0 tillader gratis kommerciel brug, så længe organisationens årlige omsætning ligger under 10 mio. dollar. Større virksomheder skal kontakte Liquid AI for kommerciel licens (kilde 3027). Grænsetilfælde som hurtig vækst eller M&A er ikke beskrevet i de offentlige materialer. Involver juridisk, før pilot bliver produktion, og få skriftlig afklaring, hvis koncern og datterselskaber er i spil (kilde 3027).
Risici og uklarheder
De publicerede benchmarks er målt i kontrollerede setups på H100 via SGLang og på M4 Max via llama.cpp/Metal med FP16 GGUF (kilde 3027, 3029). Det kalder på egne tests på A100, L40S, RTX 4090 og i ROCm-miljøer. Adfærd under sampling for temperaturer over 0, top-k/top-p og beam search er ikke dokumenteret i kilderne. Langkontekst, multi-turn og tool-calling er heller ikke gennemtestet offentligt (kilde 3027, 3029).
Mini-tjekliste til drift
- Log acceptance rate per feature og prompttype; sæt alarm ved fald.
- Mål fallback-tid fra drafter-fejl til ren target og effekten på SLA.
- Profilér peak-GPU-mem ved stigende samtidighed; se efter spikes.
- Versionssikring: test target+drafter-load i CI; typisk fejlsymptom er load-fail ved embedding/LM-head mismatch (kilde 3027).
Guide til en praktisk testplan
Vil I vurdere, om DSpark hjælper i produktion, så kør en kort, målrettet test tæt på den rigtige app. En mulig plan:
- Reproducer basis: LFM2.5-1.2B-Instruct og 2.6B på 1×H100 (BF16 via SGLang) og M4 Max (FP16 GGUF via llama.cpp/Metal), block size 9, batch 1, temperatur 0. Sammenlign tok/s med og uden drafter (kilde 3027).
- Datasæt til sanity-check: MATH500, HumanEval, MBPP, GSM8K, MT-Bench. Notér både throughput og acceptance rate (kilde 3027).
- Sampling-scenarier: temperatur 0,2–0,7, top-k/top-p. Mål nøjagtighed, stilistisk drift og safety-regressioner vs. ren target.
- Multi-turn og tool-calling: se om acceptance holder, når værktøjskald og systemprompter flytter konteksten.
- Memory og concurrency: mål peak-GPU-mem og latency ved stigende samtidighed. Log pruning i verifier-leddet.
- Fallback og failover: simuler at drafter er utilgængelig. Mål skiftet til ren target og effekten på SLA.
Hellere tre gode cases end ti løse benchmarks.
Tekniske detaljer, der er værd at holde øje med
DSpark kombinerer tre dele: en DFlash-lignende parallelt kørende backbone, en let sekventiel head modelleret som en Markov-kæde ved rank 256 og en confidence-scheduled verifier, der beskærer lavt-begrundede suffixer, når verifikation koster mere, end det sparer (kilde 3027). Hvis acceptance dør ud i de sene positionsrækker, kan den sekventielle head løfte kvitteringerne.
Et praktisk punkt: embedding og LM-head bindes fra target ved load. Det reducerer vægtdobbeltarbejde, men gør versionsstyring vigtig. Inkompatible target-versioner kan give fejl ved load, så hold styr på parringerne (kilde 3027).
Åbne spørgsmål til næste runde
Der er brug for uafhængige benchmarks på flere GPU’er og backends, især for MoE. Sampling-resultater for temperaturer over 0 mangler i de citerede materialer. Langkontekst og meget lange svar er ukendte i praksis. Der mangler også et klart billede af memory-spidser under høj samtidighed i produktion (kilde 3027, 3029).
Korte checks: 1) test MoE på Metal, CUDA og ROCm hver for sig, 2) profil verifierens pruning i workloads med varierende kontekst, 3) se om tool-calling-sekvenser udhuler acceptance.
Konklusion og anbefalinger
LFM2.5-DSpark-drafters ændrer regnestykket for dekodning ved batch size 1. Gevinster på op til 3,18× på H100 og 2,87× på M4 Max er dokumenteret i kilderne, men de er målt i kontrollerede opsætninger og uden sampling (kilde 3027, 3029). Næste skridt for danske drift- og produktteams: test på egen hardware, med egen promptform og faktisk samtidighed. Afklar licensgrænsen mod forretningstal, før der rulles bredt ud (kilde 3027).
Man opdager først forskellen, når latencynålen rykker nedad på skærmen.
