En ny väg för lokal bildanalys
Liquid AI publicerade den 24 september 2026 en experimentell DSpark-drafter för sin bild- och språkmodell LFM2.5-VL-3B. Målmodellen introducerades i augusti; det nya är en separat, mindre modell som föreslår flera kommande token i ett block. Målmodellen verifierar sedan förslagen. Det gör att samma bildfråga kan besvaras med färre dyra avkodningssteg när många förslag accepteras.
För en lokal installation är den avgörande detaljen att Liquid AI även tillhandahåller draftern i GGUF-format. Därmed finns en konkret väg för att prova den tillsammans med målmodellen i llama.cpp, vid sidan av integrationer för MLX-VLM och SGLang. Nyheten är mer avgränsad än ett generellt löfte om snabbare multimodal AI: den gäller en bestämd modellkombination, en bestämd spekulativ metod och implementationer som stöder den.
Vad DSpark faktiskt gör
Vid vanlig autoregressiv generering producerar målmodellen i princip en token i taget. DSpark-draftern tar fram ett block med möjliga token, varefter målmodellen kontrollerar vilka som kan användas. En accepterad följd sparar verifieringsarbete jämfört med att låta målmodellen skapa varje token var för sig. Om förslagen inte passar måste målmodellen räkna om, så acceptansgraden är en central del av den verkliga prestandan.
Liquid AI beskriver draftern som en liten sidomodell med ungefär 279,5 miljoner parametrar, motsvarande 8,9 procent extra parametrar jämfört med målmodellen. Den använder fyra uppmärksamhetslager och ett block om nio kandidatpositioner. För de publicerade körkommandona rekommenderas vanligen högst åtta förslag i taget. Konstruktionen delar vissa delar med målmodellen vid inläsning, vilket är skälet till att drafterfilen inte fungerar som en fristående bildassistent.
Vid greedy-avkodning uppger Liquid AI att svaret förblir exakt detsamma som från målmodellen ensam: varje föreslagen token verifieras innan den släpps igenom. Det är ett påstående om utdata för den angivna avkodningen, inte ett bevis för identiskt beteende i alla samplinglägen eller för alla framtida implementationer.
Färdig GGUF-fil, men flera delar krävs
Den publicerade F16-filen för draftern är 567 MB. En fungerande lokal körning kräver också LFM2.5-VL-3B som målmodell och dess vision-projektor. Den extra filen lägger alltså minne ovanpå den befintliga bildmodellen, cache och kontext. Modellkortet anger dessutom licensen LFM 1.0. Öppna modellvikter innebär inte automatiskt obegränsad vidareanvändning; granska licensvillkoren innan modellen byggs in i en distribuerad eller kommersiell tjänst.
Liquid AI visar ett llama.cpp-kommando där målmodellen laddas med -hf, draftern med -hfd och spekulation aktiveras med --spec-type draft-dspark. Parametrarna --spec-draft-n-max 8 och --spec-draft-n-min 0 styr förslagsblocket. Integrationen kräver en llama.cpp-version som innehåller stödet för just denna modell och metod. Motsvarande gäller MLX-VLM och SGLang; ett generellt DSpark-stöd i ett program garanterar inte att varje VLM-kombination fungerar.
För den som driver lokala tjänster är detta ett användbart experiment snarare än en omedelbar standardinställning. Börja med modellkortets körväg, lås modell- och motorversioner, och kontrollera loggarnas mått för föreslagna respektive accepterade token. Om få förslag accepteras kan extraminnet och drafterberäkningen äta upp hastighetsvinsten.
Så ska prestandasiffrorna läsas
Liquid AI redovisar sex visuella uppgiftstyper med 16-bitars körning och DSpark-blockstorlek åtta. Med MLX på M5 Max uppges avkodningen bli 2,30 till 3,13 gånger snabbare, medan total svarstid förbättras 1,56 till 2,62 gånger. Med llama.cpp på M3 Ultra anges 1,57 till 2,14 gånger snabbare avkodning och 1,30 till 1,77 gånger bättre tid från start till färdigt svar. På H100 uppges upp till 2,66 gånger snabbare avkodning och upp till 2,27 gånger bättre total tid.
Detta är leverantörens egna mätningar. De beskriver hastighet för samma målmodell med och utan drafter under dokumenterade testvillkor; de visar inte att LFM2.5-VL-3B är bättre än andra bildmodeller. De är heller inte ett tillförlitligt löfte för en kvantiserad modell på en bärbar dator med annan GPU, CPU eller minnesbandbredd. Den praktiska slutsatsen måste bygga på mätning i den egna miljön.
Skillnaden mellan avkodningshastighet och total svarstid är särskilt viktig för bildmodeller. Bilden passerar först en vision-encoder och prompten måste bearbetas innan svarstoken börjar genereras. DSpark accelererar inte dessa steg. Stora bilder, långa promptar eller korta svar kan därför ge en betydligt mindre total vinst än en siffra för enbart tokenavkodning antyder.
Praktisk testplan för homelab och drift
Bygg ett litet men representativt testpaket med samma bilder och frågor som den planerade applikationen använder. Kör först målmodellen utan drafter och sedan med exakt samma modell, precision, kontextstorlek och hårdvaruinställningar. Mät tid till första token, efterföljande token per sekund, total svarstid, RAM- och VRAM-topp samt acceptansgrad. Dokumentera motorversion, drivrutin och eventuell kvantisering så att jämförelsen går att upprepa.
Testa också flera samtidiga förfrågningar. En sidomodell som är liten i parameterantal kan påverka minnesplacering, GPU-offload och den kapacitet som finns kvar för KV-cache. För en interaktiv skärm- eller dokumentassistent kan kortare väntetid vara mycket värdefull. För batchjobb som främst spenderar tid på bildkodning kan samma drafter göra mindre skillnad.
Om verksamheten kräver att bilder stannar lokalt ska även hela serverkedjan kontrolleras: uppladdning, loggar, API-gateway och lagring. GGUF-filen gör lokal inferens möjlig men garanterar inte i sig att resten av applikationen håller data innanför den egna miljön. Det är en driftfråga, inte en egenskap hos spekulativ avkodning.
LabOps IT:s bedömning
Det här släppet är värt att prova eftersom en etablerad lokal bildmodell nu har en färdig spekulativ sidomodell och ett publicerat GGUF-spår. Det flyttar en optimering från enbart metodstöd till en konkret modellkombination som kan mätas i ett homelab eller på en arbetsstation. Särskilt intressant är den för uppgifter som ger längre textsvar efter bildanalysen.
Vinsten bör bedömas på total svarstid och resursförbrukning, inte på högsta avkodningssiffra i leverantörens tabell. När bildkodning eller prefill dominerar får användaren mindre effekt. Vår rekommendation är därför en avgränsad pilot med realistiska bilder, tydligt versionslås och en baseline utan drafter innan tekniken tas i drift.