LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: Je kiest er niet één, je bevestigt er één

De zoekopdracht die mensen hierheen brengt is een vergelijking, maar het eerlijke antwoord is dat LFM2.5-VL-3B-DSpark en LFM2.5-VL-3B niet twee dingen zijn waar je tussen kiest. De tweede is een vision-language-model van 3,1B dat je kunt downloaden en serveren. De eerste is een draftmodel met 279,5M parameters dat alleen bestaat om vóór het tweede te zitten en het sneller te laten decoderen. Haal de drafter uit de stack en het produceert niets; je kunt het niet op zichzelf draaien, omdat 'op zichzelf' geen configuratie is die het ondersteunt. De echte vergelijking is LFM2.5-VL-3B die alleen draait versus hetzelfde model dat draait met de drafter eraan gekoppeld.

Als je het zo leest, komt de beslissing neer op één vraag: leveren het extra geheugen en de extra runtimecomplexiteit je genoeg latentie op om voor jouw workload van belang te zijn? De eigen cijfers van Liquid AI zeggen ja voor decode-intensief werk en expliciet nee wanneer prefill domineert. Geen van beide kanten daarvan is buiten het bedrijf gereproduceerd.

De twee controlepunten, naast elkaar

Wat hen onderscheidt, is het hele verhaal, dus het is de moeite waard om de twee repositories naast elkaar te leggen voordat de discussie over snelheid begint.

• Rol — LFM2.5-VL-3B genereert tekst en beantwoordt vragen over afbeeldingen; LFM2.5-VL-3B-DSpark stelt tokens voor die het kan verifiëren en genereert zelf niets bruikbaars

• Parameters — 3,1 miljard voor het doelmodel, 279,5 miljoen BF16 voor het draftmodel, wat Liquid neerzet als een toename van 8,9% in het aantal parameters in productie

• Architectuur — het doelmodel is een hybride model dat is gebouwd op een LFM2.5-2.6B-backbone met een SigLIP2 NaFlex-visionencoder; de drafter bestaat uit 4 volledige attentionlagen met een hidden size van 2.048, met grouped-query attention plus een Markov-head en een confidence-head

• Contextvenster — 32.768 tokens voor het doel; de opsteller heeft geen eigen context en erft die van het doel

• Visie-encoder — SigLIP2 NaFlex 400M op het doelmodel; het conceptmodel heeft er geen en ziet de afbeelding nooit rechtstreeks

• Vocabulaire — 128.000, en de embedding en LM-head van de drafter zijn gekoppeld aan die van het target in plaats van gedupliceerd, waardoor de geheugenbelasting kleiner is dan 279,5M parameters zouden doen vermoeden

• Licentie — beide vallen onder Liquid's LFM1.0-licentie, die op Hugging Face als "other" staat in plaats van als een OSI-licentie, dus lees de voorwaarden voordat je commercieel implementeert

• Formaten — het doelmodel wordt geleverd als safetensors-, GGUF-, ONNX- en MLX-kwantisaties; het draftmodel wordt geleverd als safetensors en één enkele F16-GGUF van ongeveer 567 MB

Eén regel in die lijst verdient nadruk, want het is de mechanische reden waarom deze combinatie überhaupt werkt: het conceptmodel is geen klein visiemodel. Het heeft geen visie-encoder en komt nooit in aanraking met de afbeelding. Tegen de tijd dat tokens de verborgen lagen bereiken waaruit het conceptmodel put, zijn een beeldpatch en een teksttoken allebei gewoon tensors, dus is modaliteit onzichtbaar voor de berekening van het conceptmodel. Dat is wat Liquid in staat stelde een techniek die voor tekstmodellen was ontwikkeld naar een VLM over te zetten zonder die opnieuw te ontwerpen.

Wat de opsteller wijzigt en wat hij ongemoeid laat

Het doelmodel verandert niet. Dat is geen marketing — het is de correctheidseigenschap van speculatieve decoding. Bij greedy decoding wordt elk concepttoken door het doelmodel geverifieerd, dus de uitvoer is precies wat het doelmodel alleen zou hebben geproduceerd. Bij overeenkomstige samplinginstellingen bij een temperatuur die niet nul is, komt de uitvoerdistributie overeen met die van het doelmodel. De opsteller ruilt geheugen voor tijd en raakt verder niets aan.

Wat betekent dat elk kwaliteitscijfer dat je voor LFM2.5-VL-3B kunt vinden, ongewijzigd geldt voor de gepaarde configuratie. In de eigen evaluatie van Liquid scoort het doelmodel 80,7 op ScreenSpot-v2, 61,5 op BLINK, 58,3 op MuirBench, 73,1 op MME, 63,3 op MMStar, 81,3 op ChartQA en 88,7 op POPE — allemaal door de leverancier gerapporteerd, geen ervan onafhankelijk gereproduceerd, en allemaal evenzeer waar of het conceptmodel nu wel of niet is gekoppeld. Er valt hier geen afweging tussen kwaliteit en snelheid te maken, en elke vergelijkingspagina die er een presenteert, heeft het model verkeerd geïnterpreteerd.

Wat wél verandert, is wat een token aan kloktijd kost. Liquid meet decode-versnellingen van 2,04× tot 2,66× op een enkele H100 in BF16 via SGLang bij blokgrootte 9, van 2,30× tot 3,13× op een Apple M5 Max via MLX-VLM bij blokgrootte 8, en van 1,57× tot 2,14× op een M3 Ultra via llama.cpp. End-to-end komen dezelfde runs uit op respectievelijk 1,64×–2,27×, 1,56×–2,62× en 1,30×–1,77×. Die paren vormen het hele argument: decode verbetert ongeveer twee keer zoveel als end-to-end, en dat gat is het deel van de workload waar de drafter niet bij kan.

Het prefill-probleem, zoals gesteld door de leverancier

De nuttigste zin in de eigen aankondiging van Liquid is degene die pleit tegen een onbeperkte interpretatie van de kop. Visie-taal-inferentie betaalt een prefill-kostenpost die tekstinferentie niet kent: de afbeelding gaat door een visie-encoder, en de taalbackbone verwerkt vervolgens de honderden visuele tokens die de encoder produceert. Op een edge-apparaat vormt die prefill een groot deel van de end-to-end latentie. Speculatief decoderen versnelt alleen het decoderen — visie-encoding en prefill blijven ongewijzigd. Waar prefill domineert, vertaalt een 3× decodeversnelling zich in een veel kleinere end-to-end winst.

Dat is de wet van Amdahl, door de leverancier toegepast op het eigen product, en het zou moeten bepalen wie deze pagina leest. Een lange transcriptie van één gescande pagina, een bijschrift, een gesprek met meerdere beurten waarin één afbeelding wordt meegenomen — decode-intensief, en daar verdient de drafter zijn 279,5M parameters. Een korte vraag over een grote afbeelding met hoge resolutie — prefill-intensief, en dat is dan niet zo. Zet hetzelfde doel op een server bij hoge gelijktijdigheid en het beeld verschuift opnieuw: Liquid meet een grens tussen doorvoer en interactiviteit in plaats van één enkel getal, en rapporteert dat DSpark zijn voordeel behoudt op elk getest gelijktijdigheidsniveau, terwijl het verschil kleiner wordt naarmate de gelijktijdigheid toeneemt.

Twee kleinere afbakeningsnotities uit dezelfde bron. Alle metingen gebruiken 16-bits verwerking voor zowel de vision-encoder als de taalbackbone, en versnelling van gekwantiseerde modellen valt buiten de scope van de release. Als het je plan was om een 4-bits target-export te combineren met de drafter omdat het hele voordeel van een 3B VLM is dat hij in een paar gigabyte past, dan is die combinatie niet wat er is gemeten.

Wat het bevestigen ervan je werkelijk kost

Geheugen is de zichtbare kostenpost en de kaart kwantificeert die: 8,9% meer parameters in de gedeployde stack. Runtimecomplexiteit is de onzichtbare. SGLang vereist v0.5.19 of nieuwer en een opstartregel met --speculative-algorithm DSPARK, het pad naar het draftmodel en een blokgrootte; het voorbeeld op de kaart zelf schakelt ook de radixcache uit en zet een statische geheugenfractie vast, wat beslissingen voor de serving zijn waarover je nu moet nadenken. MLX-VLM vereist v0.7.2 of nieuwer en neemt de drafter mee via --draft-model, maar DSpark-decodering gebruikt daar momenteel greedy sampling, dus de temperatuur moet op 0 worden geforceerd — een echte beperking als je applicatie afhankelijk is van samplingdiversiteit. llama.cpp werkt via de GGUF-drafter in combinatie met het GGUF-target, niet met het originele safetensors-checkpoint.

Er is nog een kostenpost die zich in productie voordoet in plaats van in een benchmark: de drafter en het target moeten samen meereizen. Versieverschil tussen hen is een faalmodus die niet bestaat bij een implementatie met één model, en het onafhankelijk uitrollen van een van beide is nu een probleem met twee artefacten.

Dit is een self-hosted combinatie. OrcaRouter routeert LFM2.5-VL-3B of zijn drafter niet — je downloadt beide en serveert ze zelf — dus de routeringsvraag gaat over alles waaraan het kleine model overdraagt. De meeste deployments die een 3B edge-VLM met de drafter combineren, hebben nog steeds query's die het kleine model niet zou moeten beantwoorden, en het sturen daarvan naar een enkel endpoint dat 200+ modellen dekt tegen de listprijs van elke provider, met automatische failover als een provider verslechtert is één integratie in plaats van één per leverancier. Het betekent ook dat op het moment dat een provider een prijs verlaagt, je tarief dat dezelfde dag weerspiegelt in plaats van bij de volgende contractverlenging.

Welke moet ik downloaden?

Als je workload decode-intensief is en je hardware een van de drie is die Liquid heeft getest, koppel dan de drafter — het nadeel is beperkt, want de uitvoer is aantoonbaar die van het doelmodel en de geheugenkosten bedragen minder dan een tiende van een model. Als je latency wordt gedomineerd door prefill, of als je een gequantiseerd doelmodel draait, of als je afhankelijk bent van niet-greedy sampling in een runtime die die beperking niet heeft opgeheven, draai dan LFM2.5-VL-3B alleen. Het is snel op eigen kracht: 228 tokens per seconde op een M5 Max, 116 op een AMD Ryzen AI Max+ 395 en 20 op een Galaxy S26 Ultra, allemaal cijfers van de fabrikant, in ongeveer 3 GB geheugen.

Wat niemand je nog kan vertellen, is of de cijfers van Liquid standhouden op jouw hardware. De drafter had op het moment van schrijven 37 downloads op Hugging Face en er was geen enkele onafhankelijke reproductie van welk cijfer dan ook in de tabellen van de drafter. Het engineeringwerk is solide en het correctheidsargument is een bewijs in plaats van een bewering, maar de grootte is een meting — en metingen van één lab op één set machines zijn precies het soort getal dat je zelf moet verifiëren voordat je ze in een capaciteitsplan opneemt.

OrcaRouter bereikt 200+ modellen via één sleutel, waarbij de lijstprijs van elke provider rechtstreeks wordt doorgegeven tegen 0% opslag en met automatische failover tussen providers. lijstprijs van provider doorgegeven tegen 0% opslag De combinatie op deze pagina is hoe dan ook self-hosted - de router is er voor alles wat het kleine model overdraagt, en het betekent dat een prijsverlaging van een provider dezelfde dag in je tarief te zien is.