LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: Du väljer inte en, du fäster en

Sökningen som för människor hit är en jämförelse, men det ärliga svaret är att LFM2.5-VL-3B-DSpark och LFM2.5-VL-3B inte är två saker man väljer mellan. Den andra är en 3,1B visions- och språkmodell som du kan ladda ner och servera. Den första är en utkastmodell med 279,5M parametrar som bara finns för att sitta framför den andra och få den att avkoda snabbare. Ta bort utkastaren ur stacken och den producerar ingenting; du kan inte prestandatesta den på egen hand, eftersom ”på egen hand” inte är en konfiguration som den stöder. Den verkliga jämförelsen är LFM2.5-VL-3B som körs ensam mot samma modell som körs med utkastaren ansluten.

Läs det så och det kokar ner till en enda fråga: ger den extra minnesanvändningen och den extra runtime-komplexiteten dig tillräckligt för att spela roll för din arbetsbelastning? Liquid AI:s egna siffror säger ja för avkodningstungt arbete och säger uttryckligen nej när prefill dominerar. Ingendera sidan av det har reproducerats utanför företaget.

De två kontrollpunkterna, sida vid sida

Det som skiljer dem åt är hela historien, så det är värt att ställa de två repositorierna bredvid varandra innan hastighetsargumentet börjar.

• Roll — LFM2.5-VL-3B genererar text och svarar på frågor om bilder; LFM2.5-VL-3B-DSpark föreslår tokens för den att verifiera och genererar ingenting användbart på egen hand

• Parametrar — 3,1B för målmodellen, 279,5M BF16 för utkastmodellen, vilket Liquid anger som en ökning med 8,9 % av antalet driftsatta parametrar

• Arkitektur — målet är en hybridmodell byggd på en LFM2.5-2.6B-backbone med en SigLIP2 NaFlex-vision-encoder; draftaren är 4 lager med full uppmärksamhet vid dold storlek 2 048 med grouped-query attention plus ett Markov-huvud och ett konfidenshuvud

• Kontextfönster — 32 768 tokens för målet; utkastaren har ingen egen kontext och ärver målets

• Visionskodare – SigLIP2 NaFlex 400M på målmodellen; utkastaren har ingen och ser aldrig bilden direkt

• Vokabulär — 128 000, och draftmodellens inbäddning och LM-huvud delas med målmodellen i stället för att dupliceras, vilket är varför minneskostnaden är mindre än vad 279,5M parametrar skulle antyda

• Licens — båda levereras under Liquids LFM1.0-licens, som är "other" på Hugging Face snarare än en OSI-licens, så läs villkoren före en kommersiell driftsättning

• Format – målmodellen levereras som kvantiseringar i safetensors, GGUF, ONNX och MLX; draftmodellen levereras som safetensors och en enda F16-GGUF på ungefär 567 MB

En rad i den listan förtjänar att betonas, eftersom den är det mekaniska skälet till att den här kombinationen fungerar överhuvudtaget: draftmodellen är inte en liten visionsmodell. Den har ingen visionskodare och rör aldrig bilden. När tokens har nått de dolda lager som den skapar utkast från, är en bildpatch och en texttoken båda bara tensorer, så modaliteten är osynlig för utkastberäkningen. Det var vad som gjorde att Lotus kunde portera en teknik som utvecklats för textmodeller till en VLM utan att designa om den.

Vad upprättaren gör, och vad den lämnar ifred

Målmodellen ändras inte. Det är inte marknadsföring — det är korrekthetsegenskapen hos spekulativ avkodning. Vid girig avkodning verifieras varje draft-token av målet, så utdata är exakt vad målet skulle ha producerat på egen hand. Under matchade samplingsinställningar vid temperatur som inte är noll matchar utdatadistributionen målets. Draftmodellen byter minne mot tid och rör inget annat.

Vilket innebär att varje kvalitetsvärde du kan hitta för LFM2.5-VL-3B gäller oförändrat för den parade konfigurationen. I Liquids egen utvärdering får målmodellen 80,7 på ScreenSpot-v2, 61,5 på BLINK, 58,3 på MuirBench, 73,1 på MME, 63,3 på MMStar, 81,3 på ChartQA och 88,7 på POPE – alla rapporterade av leverantören, inga oberoende reproducerade, och alla lika sanna oavsett om draftmodellen är ansluten eller inte. Det finns ingen avvägning mellan kvalitet och hastighet att fundera över här, och varje jämförelsesida som presenterar en sådan har missförstått modellen.

Det som förändras är kostnaden för en token i väggklockstid. Liquid mäter hastighetsökningar för avkodning från 2,04× till 2,66× på en enda H100 i BF16 via SGLang vid blockstorlek 9, 2,30× till 3,13× på en Apple M5 Max via MLX-VLM vid blockstorlek 8, och 1,57× till 2,14× på en M3 Ultra via llama.cpp. End-to-end hamnar samma körningar på 1,64×–2,27×, 1,56×–2,62× och 1,30×–1,77× respektive. De paren är hela argumentet: avkodningen förbättras ungefär dubbelt så mycket som end-to-end gör, och gapet är den del av arbetsbelastningen som draftaren inte kan påverka.

Prefill-problemet, såsom leverantören formulerar det

Den mest användbara meningen i Liquids eget tillkännagivande är den som argumenterar mot en obegränsad tolkning av dess rubrik. Vision-språk-inferens betalar en prefill-kostnad som textinferens inte gör: bilden går genom en visionskodare, och språkbackbonen bearbetar sedan de hundratals visuella tokens som kodaren skickar ut. På en edge-enhet utgör den prefillen en stor del av den totala latensen. Spekulativ avkodning accelererar endast avkodningen — visionskodning och prefill är oförändrade. Där prefill dominerar omvandlas en 3× snabbare avkodning till en mycket mindre total vinst.

Det är Amdahls lag tillämpad av leverantören på leverantörens egen produkt, och det bör styra vem som läser den här sidan. En lång transkription av en enda skannad sida, en bildtext, en fleromgångskonversation som för en bild vidare – avkodningstung, och draftaren förtjänar sina 279,5M parametrar. En kort fråga om en stor högupplöst bild – prefill-tung, och det gör den inte. Sätt samma mål på en server vid hög samtidighet och bilden ändras igen: Liquid mäter en front för genomströmning och interaktivitet snarare än ett enda tal, och rapporterar att DSpark behåller sin fördel på varje testad samtidighetsnivå medan gapet minskar när samtidigheten ökar.

Två mindre avgränsningsnoteringar från samma källa. Alla mätningar använder 16-bitars bearbetning för både visionskodaren och språkryggraden, och acceleration av kvantiserade modeller ligger utanför utgåvans omfattning. Om din plan var att para ihop en 4-bitars målexport med draftaren eftersom hela tjusningen med en 3B VLM är att den får plats i några gigabyte, är den kombinationen inte vad som mättes.

Vad det faktiskt kostar dig att bifoga det

Minnet är den synliga kostnaden och kortet kvantifierar den: 8,9 % fler parametrar i den driftsatta stacken. Körtidskomplexiteten är den osynliga. SGLang kräver v0.5.19 eller nyare och en startrad som innehåller --speculative-algorithm DSPARK, sökvägen till draft-modellen och en blockstorlek; kortets eget exempel inaktiverar också radix-cachen och låser en statisk minnesfraktion, vilket är serveringsbeslut du nu måste resonera kring. MLX-VLM kräver v0.7.2 eller nyare och tar draft-modellen via --draft-model, men DSpark-avkodning där använder för närvarande girig sampling, så temperaturen måste tvingas till 0 – en verklig begränsning om din applikation förlitar sig på samplingsmångfald. llama.cpp fungerar genom GGUF-draftmodellen i par med GGUF-målet, inte med den ursprungliga safetensors-checkpointen.

Det finns en kostnad till som visar sig i produktion snarare än i ett benchmark: draftaren och målmodellen måste färdas tillsammans. Versionsskevhet mellan dem är ett felmod som inte existerar i en distribution med en enda modell, och att rulla ut endera oberoende är nu ett problem med två artefakter.

Det här är en självhostad parning. OrcaRouter dirigerar inte LFM2.5-VL-3B eller dess drafter – du laddar ner båda och serverar dem själv – så dirigeringsfrågan handlar om allt som den lilla modellen lämnar över till. De flesta distributioner som parar en 3B-edge-VLM med draftern har fortfarande frågor som den lilla modellen inte bör svara på, och att skicka dem till en enda slutpunkt som täcker 200+ modeller till varje leverantörs listpris, med automatisk failover om en leverantör försämras, är en integration i stället för en per leverantör. Det innebär också att i samma stund som en leverantör sänker ett pris återspeglas det i din taxa samma dag i stället för vid nästa avtalsförnyelse.

Vilken ska man ladda ner

Om din arbetsbelastning är avkodningstung och din hårdvara är en av de tre som Liquid testade, anslut draftmodellen — nackdelen är begränsad, eftersom utdata bevisligen är målmodellens och minneskostnaden är under en tiondel av en modell. Om din latens domineras av prefill, eller om du kör en kvantiserad målmodell, eller om du är beroende av icke-girig sampling i en runtime som inte har hävt den begränsningen, kör LFM2.5-VL-3B ensam. Den är snabb i sin egen rätt: 228 tokens per sekund på en M5 Max, 116 på en AMD Ryzen AI Max+ 395 och 20 på en Galaxy S26 Ultra, alla siffror från tillverkaren, i ungefär 3 GB minne.

Vad ingen kan säga dig ännu är huruvida Liquids siffror håller på din hårdvara. Draftmodellen hade 37 nedladdningar på Hugging Face vid skrivandets stund och ingen oberoende reproduktion av någon siffra i dess tabeller. Konstruktionen är gedigen och korrekthetsargumentet är ett bevis snarare än ett påstående, men magnituden är en mätning – och mätningar från ett labb på en uppsättning maskiner är precis den typ av siffra som du själv bör verifiera innan du sätter dem i en kapacitetsplan.

OrcaRouter når 200+ modeller genom en enda nyckel, med varje leverantörs listpris som förs vidare direkt utan påslag (0 %) och automatisk failover mellan leverantörer. leverantörens listpris förs vidare med 0 % påslag Parkopplingen på den här sidan är självhostad hur som helst – routern är till för allt som den lilla modellen lämnar över till, och det innebär att en leverantörs prissänkning syns i din taxa samma dag.