LFM2.5-2.6B-DSpark: De 328M-drafter die de on-device-agent van Liquid 2,3× sneller laat draaien

Niemand buiten Liquid AI heeft LFM2.5-2.6B-DSpark op eigen hardware gedraaid en al een resultaat gepubliceerd. Dat is het eerlijke vertrekpunt voor dit model, want het is in zijn geheel een prestatieclaim: het is geen betere 2.6B, het is een draftmodel met 328M parameters dat voor het 2.6B-agentische model LFM2.5-2.6B zit en tokens voorstelt die het moet verifiëren, waardoor de agent ongeveer twee keer zo snel draait zonder dat de output verandert.

Uitgebracht op 20 augustus 2026 met een technische beschrijving op Hugging Face en een begeleidend artikel op de eigen blog van Liquid, is LFM2.5-2.6B-DSpark het vlaggenschip van een kleine familie van speculatieve-decodering-draftcheckpoints die Liquid die dag publiceerde. Alles hieronder in de snelheidskolom is door de leverancier gemeten en nog niet onafhankelijk bevestigd; alles in de repository, de formaten en de frameworkondersteuning is simpelweg aanwezig om gecontroleerd te worden.

Wat DSpark is, in één adem

Speculatieve decodering is de truc om een goedkoop draftmodel vóór het echte model te laten draaien: het draftmodel raadt de volgende handvol tokens, het doelmodel controleert de hele batch in één enkele forward-pass, en het houdt de tokens waarmee het instemt. Wanneer de gissingen juist zijn, verplaats je meerdere tokens voor de prijs van één, dus stijgt de doorvoer zonder de gewichten van het doelmodel aan te raken. DSpark — de techniek, oorspronkelijk voorgesteld door DeepSeek-onderzoekers in juli 2026 en al ingezet in DeepSeek-V4 — is een versie van die truc die is afgestemd op kleine modellen op het apparaat. Liquid noemt het confidence-scheduled speculatieve decodering, en het heeft drie bewegende delen: een parallelle backbone die verborgen toestanden produceert voor alle draft-tokens in één doorgang, een lichtgewicht sequentiële kop die de afhankelijkheid tussen naburige tokens modelleert, zodat de acceptatiegraad niet instort aan het einde van het blok, en een verificateur die achtervoegsels met een laag vertrouwen wegsnoeit wanneer het controleren ervan meer zou kosten dan het zou besparen.

Dat laatste stuk maakt dat DSpark anders aanvoelt dan een gewoon draftmodel: het duwt niet altijd een volledig blok door de verificatie. Wanneer het eigen vertrouwen van het draftmodel zegt dat een suffix waarschijnlijk niet wordt geaccepteerd, kapt het het blok af en bespaart het de verspilde rekenkracht. Het draftblok bestaat uit negen tokens, dus het targetmodel verifieert er maximaal tien tegelijk.

De opsteller, in cijfers

Het LFM2.5-2.6B-DSpark-checkpoint is een draftmodel met 0,3 miljard parameters en uitsluitend aandacht: vijf volledige aandachtslagen (verborgen grootte 2.048, gegroepeerde-query-aandacht met 32 heads en 8 key-value-heads), een vocabulaire van 128K tokens, een Markov-head met rang 256 en een confidence-head. Liquid trainde het 15 epochs op een mix van instructie-, conversatie-, code- en functieaanroepgegevens — op AMD-hardware — en koos de epoch op basis van het hoogste acceptatiepercentage in plaats van het laagste verlies.

Dat acceptatiepercentage is het getal dat bepaalt hoeveel de drafter waard is. Over vijf benchmarks bij batchgrootte 1 en temperatuur 0 behaalde LFM2.5-2.6B-DSpark gemiddeld 4,83 geaccepteerde tokens per decoderingstap op een H100 en 4,42 op een M4 Max — ruwweg de helft van het blok werd geaccepteerd, en daar komen de verdubbelde versnellingen vandaan.

De versnellingen, gelabeld

Alle volgende cijfers komen uit Liquid AI's eigen meting — SGLang op een enkele H100 80GB in BF16, en llama.cpp met de Metal-backend op een M4 Max MacBook Pro in FP16 GGUF, batchgrootte 1, temperatuur 0 — en geen ervan zijn tot op heden door een onafhankelijke partij gereproduceerd:

• H100 gemiddeld — 2,67×, van 323 tot 864 tokens/s. Per benchmark: MATH500 3,06×, HumanEval 2,56×, MBPP 2,64×, GSM8K 2,22×, MT-Bench 2,87×.

• M4 Max gemiddeld — 2,27×, van 61 naar 139 tokens/s. Per benchmark: MATH500 2,25×, HumanEval 2,63×, MBPP 2,11×, GSM8K 2,36×, MT-Bench 1,99×.

• Tool calling — in multi-tool-functieaanroepscenario's daalde de gemiddelde latentie met 57%.

• Familiecontext — de grootste drafter uit de familie, LFM2.5-8B-A1B-DSpark, haalde tot 3,18× op H100 en de 1,2B-drafter tot 2,87× op M4 Max; de hierboven vermelde 2,6B-cijfers zitten in de middenmoot.

Twee dingen aan die getallen doen ertoe naast de gemiddelden. Ten eerste worden ze gemeten bij temperatuur 0 en batchgrootte 1 — de configuratie die speculatie bevordert en de configuratie waarin interactief on-device-agentwerk meestal plaatsvindt. De identiteitsgarantie geldt daar ook: speculatieve decoding verifieert elk voorgesteld token, dus onder greedy decoding is de gegenereerde tekst precies wat het doelmodel alleen zou hebben geproduceerd. Ten tweede wordt de kloof kleiner naarmate de gelijktijdigheid toeneemt: op een enkele H100 meldt Liquid dat het voordeel van DSpark convergeert rond batchgrootte 128, dus de drafter is een latencywinst voor interactieve en tool-intensieve workloads, geen zilveren kogel voor ruwe doorvoer op een maximaal belaste server.

Wat is bevestigd, en wat niet

Bevestigd, in de zin dat de repository openbaar en controleerbaar is: de drafter wordt geleverd als Safetensors (BF16) en GGUF; hij werkt samen met de post-getrainde LFM2.5-2.6B, niet met de basis; ondersteuning op dag één is upstream in llama.cpp (met experimentele Metal-kernels) en in SGLang terechtgekomen; het is gelicenseerd onder Liquid's LFM Open License v1.0; en — belangrijk voor iedereen die eromheen plant — de modelkaart vermeldt dat geen enkele inferentieprovider het aanbiedt, dus dit is een component die je zelf draait.

Nog niet bevestigd: dat de versnellingen reproduceerbaar zijn op andere hardware en configuraties (niemand buiten Liquid heeft een meting gepubliceerd), hoe de drafter zich gedraagt onder sampling in plaats van greedy decoding, en of de 57% tool-call-latentie standhoudt in echte agent-harnesses buiten de benchmark-harness die Liquid gebruikte. Geen van deze punten zijn beschuldigingen — de release is een dag oud — maar ze vormen het verschil tussen een veelbelovend getal en een geverifieerd getal.

Het uitvoeren

{{1}}In SGLang gebruik je een build met DSpark-ondersteuning, start je de server met het doelmodel en benoem je de drafter: het speculatieve algoritme is DSPARK, het pad van het draftmodel wijst naar LiquidAI/LFM2.5-2.6B-DSpark, en de blokgrootte wordt uitgelezen uit de config.json van de draft.{{/1}} {{2}}In llama.cpp laad je de doel-GGUF met de draft-GGUF als draftmodel en stel je het spec-type in op draft-dspark, waarbij de blokgrootte wordt gelezen uit de sidecar-metadata.{{/2}} {{3}}Beide integraties zijn upstream opgenomen, dus er zijn geen forks nodig — alleen een build die nieuw genoeg is om ze te bevatten.{{/3}}

Wanneer het de moeite waard is om toe te voegen

LFM2.5-2.6B-DSpark verdient zijn ruwweg 0,3 GB extra geheugen wanneer je de 2.6B-agent daadwerkelijk inzet waar Liquid hem heeft ontworpen om te draaien — op een telefoon, laptop of edge-box — voor interactieve of tool-aanroepende workloads die latentiegebonden zijn en greedy draaien. Dat is precies het profiel waarin het on-device-cijfer van 2,27× en de 57% lagere latentie bij toolaanroepen hun werk doen. Het is minder interessant als je met een hoge batch op een server serveert (de versnelling convergeert naar 1×), of als je workload draait met een temperatuur boven nul, waar de gerapporteerde cijfers niet meer van toepassing zijn. En als je de 8B-A1B-variant van de familie gebruikt, let dan op het randgeval: de on-device-versnelling is vandaag slechts ongeveer 1,18×, omdat het verifiëren van draft-tokens meer experts activeert in de Metal-backend van llama.cpp — Liquid markeert dit als bekend.

Niets aan DSpark verandert waar de 2.6B-agent draait — het is per ontwerp een self-hostverhaal, en het zal naast de gehoste modellen staan die je al aanroept. Die mix van een lokale drafter en een dozijn API-endpoints is precies het soort infrastructuur dat een routinglaag moet wegwerken: één API-sleutel voor 200+ modellen, automatische failover wanneer een provider degradeert, en provider-lijstprijzen die tegen 0% opslag worden doorgegeven, zodat de lokale-versus-gehoste kostenvergelijking voor een 2.6B-klasse agent inzichtelijk blijft in plaats van in een spreadsheet te leven.

De juiste manier om LFM2.5-2.6B-DSpark vandaag te lezen is als een veelbelovende, door de leverancier gemeten, nog niet onafhankelijk geverifieerde snelheidsclaim die verbonden is aan een echte, downloadbare, uitvoerbare checkpoint. Als je de 2.6B-agent on-device inzet, is de drafter goedkoop om uit te proberen en makkelijk te verwijderen — voeg de twee speculatieve vlaggen toe aan het SGLang-commando, behoud greedy decoding en meet tegen je eigen workload voordat je de 2,3× vertrouwt. De repo is er; de onafhankelijke verificatie is het openstaande punt.