LFM2.5-VL-3B-DSpark: de 279,5M-Drafter van Liquid AI uitgebracht zes dagen voordat iemand het aankondigde

Er is een versie van dit verhaal waarin LFM2.5-VL-3B-DSpark een nieuw model is. Dat is het niet. Het is een draftmodel voor speculatieve decoding met 279,5 miljoen parameters dat precies voor één doel bestaat — het eigen visie-taalmodel van Liquid AI, LFM2.5-VL-3B, sneller laten decoderen — en het kan op zichzelf geen bruikbaar antwoord genereren. De reden dat het toch de moeite waard is om erover te lezen, is de tijdlijn: de weights verschenen op 18 september 2026 op Hugging Face, zonder enige aankondiging, bleven daar zes dagen staan en kregen pas op 24 september een blogbericht van de leverancier. Radar ving de repo op in die tussenliggende periode.

Die kloof is ook de grens van wat op dit moment kenbaar is. Alles in de repository — de uitsplitsing van de parameters, de blokgrootte, de frameworkintegraties, de licentie — is een bestand op schijf dat jij of ik kunnen openen. Elk versnellingscijfer is door de leverancier gemeten, met Liquid's eigen benchmarkharnas, en niemand buiten het bedrijf heeft een reproductie gepubliceerd. Dit stuk houdt die twee stapels bewust gescheiden.

Wat de repository daadwerkelijk bevat

Open de modelkaart en de vorm van het ding is ondubbelzinnig. LFM2.5-VL-3B-DSpark is een conceptmodel waarvan het doelmodel in zijn metadata vastligt: base_model: LiquidAI/LFM2.5-VL-3B. Je richt het niet op een ander model en je serveert het niet alleen.

• Totaal aantal draft-parameters — 279,5M, BF16, waarvan 193,0M de 4-laags decoderstack is, 65,5M een Markov-head, 21,0M een hidden-stateprojectie, en 6,4k normalisatielagen plus een confidence-head

• Backbone — 4 volledige attention-lagen, verborgen grootte 2.048, tussengrootte 6.144 met SiLU/SwiGLU, grouped-query attention met 32 attention-heads en 8 key-value-heads, head-dimensie 64

• Extra heads — een Markov-head met rang 256 en een confidence-head, wat DSpark-drafting onderscheidt van een gewone parallelle drafter

• Blokgrootte — 9 tijdens training; 8 of 9 bij inferentie, afhankelijk van de hardware, en specifiek 8 op Apple silicon

• Woordenschat — 128.000, gekoppeld aan de doeltaal in plaats van gedragen door het concept

• Gewicht in de gedeployeerde stack — Liquid stelt dat de drafter het aantal gedeployeerde parameters met 8,9% verhoogt

De 8,9% is het getal om aan vast te houden. Het verkoopargument voor deze klasse van modellen is nooit "snellere inferentie is gratis"; het is "snellere inferentie kost je ongeveer een tiende van een model aan geheugen." Bij 279,5 miljoen extra parameters bovenop een doelmodel van 3,1 miljard is dat een kleinere belasting dan de omvang van alleen de drafter zou doen vermoeden, omdat embedding en LM-head aan het doelmodel zijn gekoppeld en niet worden gedupliceerd.

DSpark is eerder een DeepSeek-techniek dan een Liquid-model.

De naamgeving leidt tot verwarring, dus het is de moeite waard precies te zijn. DSpark is geen uitvinding van Liquid AI en geen modelfamilie. Het is een framework voor speculatief decoderen uit een aparte onderzoekslijn, in een paper uit juli 2026 beschreven als confidence-scheduled speculative decoding met semi-autoregressieve generatie. De drie ideeën erachter: een parallelle backbone die in één forward pass een heel blok opstelt, een lichtgewicht sequentiële module die enige afhankelijkheid tussen naburige concepttokens herstelt, zodat de acceptatie niet instort aan het einde van het blok, en een verificateur die het verificatievenster per verzoek verkort wanneer het eigen vertrouwen van het concept erop wijst dat de staart wordt afgewezen.

Wat Liquid deed, is dat recept toepassen op visie-taalmodellen en een checkpoint uitbrengen. De modelkaart is openhartig dat deze overdracht minder dramatisch is dan het klinkt: vanuit het perspectief van de drafter is modaliteit irrelevant, want tegen de tijd dat tokens de verborgen lagen bereiken, zijn een afbeeldingspatch en een teksttoken allebei gewoon tensoren. Dat is waarom een techniek die op tekstmodellen is ontwikkeld, naar een VLM wordt overgezet zonder opnieuw te worden uitgevonden — en het is ook waarom de drafter niet als een nieuwe capaciteit kan worden verkocht.

Liquid had al tekstuele DSpark-drafters uitgebracht — de 2.6B-, 8B-A1B- en 1.2B-Instruct-metgezellen verschenen in augustus 2026, met GGUF-exports die op 19 augustus volgden. De vision-drafter is hetzelfde idee, doorgetrokken naar de multimodale tak, en de vierde of vijfde toevoeging in een reeks, geen debuut.

De speedupcijfers, en wie ze heeft gemeten

Elk cijfer hieronder is van Liquid zelf, verzameld op Liquids benchmarkinginfrastructuur, en geen ervan kent een onafhankelijke reproductie. Zie ze als een plafond van de leverancier, niet als een verwacht resultaat. De kaart scheidt decode-versnelling van end-to-endversnelling, wat belangrijker is dan de kop.

• Beste decodeversnelling — 3,13× op COCO, gemeten met MLX-VLM op een Apple M5 Max bij blokgrootte 8, FP16, batchgrootte 1, temperatuur 0

• Beste GPU-decodeversnelling — 2,66× op COCO, SGLang op één H100 80GB, BF16, blokgrootte 9

• Beste llama.cpp-decodeversnelling — 2,14× op COCO, Apple M3 Ultra, blokgrootte 8

• H100-decodeerbereik over zes visietaken — 2,04× tot 2,66×, met end-to-end van 1,64× tot 2,27×

• M5 Max decodeerbereik — 2,30× tot 3,13×, end-to-end 1,56× tot 2,62×

• M3 Ultra decodebereik — 1,57× tot 2,14×, end-to-end 1,30× tot 1,77×

• Conceptacceptatie — ongeveer 3,2 tot 4,5 tokens geaccepteerd per doelverificatieronde, op alle drie de stacks

Het patroon in die bereiken is het eerlijke deel. End-to-endwinsten zijn steevast de kleinere helft van elk paar, omdat de drafter het decoderen versnelt en verder niets. Merk ook op dat dezelfde drafter bij dezelfde blokgrootte op de ene stack op 3,13× uitkomt en op een andere op 1,57× — de acceptatiegraad is een eigenschap van de drafter en de werklast, maar de wall-clockwinst is een eigenschap van de hardware en de overhead van de runtime. Een claim van "2,66× sneller" zonder stack is geen claim waarop je kunt handelen.

Twee correctheidspunten uit de kaart zijn het waard om ronduit te stellen, want ze zijn wat een drafter überhaupt acceptabel maakt in productie. Bij greedy decoding is speculatief decoderen exact: het doelmodel verifieert elke voorgestelde token, dus de tekst is wat het doelmodel alleen zou hebben geproduceerd. Onder overeenkomstige samplinginstellingen bij een temperatuur die niet nul is, behoudt het de outputdistributie van het doelmodel. De formulering van Liquid — je krijgt de snelheidswinst, niet een ander model — is juist voor zover die strekt, en de kaart geeft eerlijk toe dat het verhogen van de temperatuur de acceptatie verlaagt en daardoor het doorvoervoordeel uitholt.

Wat Liquid in zijn eigen bericht toegeeft

Het blogbericht van 24 september is om één reden nuttiger dan de modelkaart: het benoemt de beperking. Vision-language-inferentie betaalt een prefill-kostenpost die tekstinferentie niet kent — de afbeelding moet door een vision-encoder heen, en de taal-backbone moet vervolgens de honderden visuele tokens verwerken die die encoder produceert. Op een apparaat domineert die prefill de end-to-end-latentie. Speculatief decoderen versnelt alleen het decoderen. Visuele encodering en prefill blijven onaangeroerd. Liquid roept de wet van Amdahl in tegen zijn eigen product en wijst erop dat waar prefill een groot deel van de wandkloktijd uitmaakt, een grote versnelling van het decoderen slechts een bescheiden end-to-end-verbetering oplevert.

Dat is een echte beperking voor de aankoopbeslissing, en het verklaart waarom time-to-first-token niet op de lijst staat van dingen die deze drafter verbetert. Het impliceert ook dat de workloads die het meest profiteren, degene zijn die lange outputs genereren vanuit een bescheiden afbeelding — een bijschrift, een lange OCR-transcriptie, een multi-turn gesprek met één afbeelding die wordt meegenomen — in plaats van degene die een korte vraag over een grote afbeelding beantwoorden.

De post voegt nog twee beperkingen aan de scope toe. Alle cijfers gaan uit van 16-bits verwerking voor zowel de visie-encoder als de taalbackbone, en acceleratie van gekwantiseerde modellen valt buiten de scope van deze release. Aangezien het hele verkoopargument van een 3B edge-VLM is dat hij binnen een paar gigabyte draait, is "de snelheidsverbeteringen worden bij FP16 gemeten" een belangrijke kanttekening voor iedereen die van plan was hem met een 4-bit-export te combineren. Liquid merkt ook op dat de drafter volledig op AMD-hardware is getraind.

Het uitvoeren

Ondersteuning vanaf dag één is er echt en dekt drie runtimes, wat meer is dan de meeste drafters krijgen. SGLang op NVIDIA vereist v0.5.19 of nieuwer en voert de drafter door --speculative-algorithm DSPARK met het draft-pad en een blokgrootte van 9. MLX-VLM op Apple silicon vereist v0.7.2 of nieuwer en detecteert de drafter wanneer deze wordt meegegeven met --draft-model; er is één valkuil — DSpark-decodering in MLX-VLM gebruikt momenteel greedy sampling, dus de temperatuur moet op 0 worden ingesteld. Voor llama.cpp is er een aparte GGUF-repository, met één enkele F16-export van ongeveer 567 MB, en de kaart vermeldt expliciet dat je de gekwantiseerde drafter koppelt aan het gekwantiseerde doelmodel in plaats van aan het originele safetensors-checkpoint.

Waar een routeringslaag hier zijn plek verdient, is niet bij dit model — OrcaRouter routeert LFM2.5-VL-3B-DSpark of LFM2.5-VL-3B niet, en dit is een zelfgehoste draftercombinatie die je zelf downloadt en serveert. Die plek is in de rest van de stack eromheen. Dezelfde applicatie die een klein open-weight visiemodel op het apparaat draait, heeft meestal een fallbackpad voor de query's die het kleine model niet aankan, en het richten van dat pad op één endpoint dat 200+ modellen dekt — gefactureerd tegen de lijstprijs van elke provider, zonder opslag, met automatische failover wanneer een provider degradeert — is een kleinere integratie dan het opzetten van een tweede leverancierscontract. De drafter verbetert één poot van die architectuur; de router zorgt ervoor dat de andere poot geen tweede project wordt.

Wat is nog niet bekend

De repository heeft op het moment van schrijven 37 downloads en 6 likes. Er is geen vermelding voor deze drafter op enige openbare benchmarkaggregator, geen reproductie door derden van een van de speedup-bereiken, en geen onafhankelijke meting van de acceptatiegraad op hardware die Liquid niet heeft getest. Er staan ook geen kwaliteitsbenchmarks op de kaart, om voor de hand liggende redenen — de drafter is door zijn constructie output-preserving, dus de kwaliteitscijfers horen bij LFM2.5-VL-3B, en de kaart verwijst naar de benchmarks van dat model in plaats van eigen benchmarks te verzinnen.

Eén detail in de metadata is een kleine aanwijzing voor hoe nieuw dit is: het model draagt een SGLang-bibliotheektag en een SGLang-algoritmevlag die specifiek bestaat om het aan te roepen. Frameworkondersteuning moest er zijn voordat de aankondiging werd gedaan, wat consistent is met de zesdaagse kloof tussen de repository en de blogpost.

Dus: een oprecht, nuttig, nauw afgebakend stukje engineering, een week na de release aangekondigd, waarvan de hele waardepropositie een door de leverancier gemeten getal is op hardware die je misschien niet bezit. Als je LFM2.5-VL-3B op een H100 of een Mac uit de M-serie draait en je workload decode-heavy is, bedragen de geheugenkosten 8,9% en is het nadeel vrijwel nihil, omdat de output aantoonbaar die van het doelmodel is. Als je latentie wordt gedomineerd door prefill, of als je op de 4-bit-export rekende, dan zegt Liquid's eigen bericht je dat het niet zal helpen. De reproductie, wanneer die komt, is het ding om op te wachten.

OrcaRouter zet 200+ modellen achter één sleutel tegen de lijstprijs van de provider met 0% opslag, en drukt het fallbackpad uit als een routeringslaag in plaats van applicatiecode. De drafter is hoe dan ook self-hosted - de router is wat voorkomt dat het stuk waar je kleine model naartoe overdraagt een tweede project wordt.