LFM2.5-VL-3B-DSpark: Liquid AI:s 279,5M Drafter släpptes sex dagar innan någon tillkännagav det

Det finns en version av den här historien där LFM2.5-VL-3B-DSpark är en ny modell. Det är den inte. Det är en utkastmodell för spekulativ avkodning med 279,5 miljoner parametrar som finns för exakt ett syfte – att göra Liquid AIs egen bild-språkmodell LFM2.5-VL-3B snabbare på att avkoda – och den kan inte generera ett användbart svar på egen hand. Anledningen till att den ändå är värd att läsa om är tidslinjen: vikterna landade på Hugging Face den 18 september 2026, utan något tillkännagivande, låg där i sex dagar och fick ett blogginlägg från leverantören först den 24 september. Radar fångade repot i mellanrummet.

Den klyftan är också gränsen för vad som går att veta just nu. Allt i förvaret – parameteruppdelningen, blockstorleken, ramverksintegrationerna, licensen – är en fil på disken som du eller jag kan öppna. Varje siffra för hastighetsökning är uppmätt av leverantören, från Liquids eget benchmark-ramverk, och ingen utanför företaget har publicerat en reproduktion. Den här artikeln håller medvetet de två högarna åtskilda.

Vad repositoryt faktiskt innehåller

Öppna modellkortet och sakens form är entydig. LFM2.5-VL-3B-DSpark är en draftmodell vars mål är fastställt i dess metadata: base_model: LiquidAI/LFM2.5-VL-3B. Du riktar den inte mot en annan modell och du serverar den inte ensam.

• Totala draft-parametrar – 279,5M, BF16, varav 193,0M är den 4-lagriga dekoderstacken, 65,5M är ett Markov-huvud, 21,0M är en projektion av dolt tillstånd, och 6,4k är normaliseringar plus ett konfidenshuvud

• Backbone – 4 fullständiga attention-lager, dold storlek 2 048, mellanstorlek 6 144 med SiLU/SwiGLU, grouped-query-attention med 32 attention-huvuden och 8 nyckel-värde-huvuden, huvuddimension 64

• Extra huvuden — ett Markov-huvud på rang 256 och ett konfidenshuvud, vilket är det som skiljer DSpark-draftning från en vanlig parallell drafter

• Blockstorlek — 9 under träning; 8 eller 9 vid inferens beroende på hårdvara, och 8 specifikt på Apple silicon

• Ordförråd — 128 000, knutet till målet snarare än buret av utkastet

• Vikt i den driftsatta stacken — Liquid anger att draftaren ökar antalet driftsatta parametrar med 8,9%

8,9 % är siffran att hålla fast vid. Argumentet för den här klassen av modeller är aldrig ”snabbare inferens är gratis”; det är ”snabbare inferens kostar dig ungefär en tiondel av en modells minnesstorlek”. Med 279,5M extra parametrar ovanpå en målmodell på 3,1B är det en mindre skatt än vad enbart draftmodellens storlek skulle antyda, eftersom embedding och LM-head är bundna till målmodellen och inte dupliceras.

DSpark är en DeepSeek-teknik snarare än en Liquid-modell

Namngivningen inbjuder till förvirring, så det är värt att vara precis. DSpark är inte en uppfinning från Liquid AI och inte en modellfamilj. Det är ett ramverk för spekulativ avkodning från en separat forskningslinje, beskrivet i en artikel från juli 2026 som konfidensschemalagd spekulativ avkodning med semi-autoregressiv generering. Dess tre idéer: en parallell ryggrad som utkastar ett helt block i en enda framåtpassning, en lättviktsmodul för sekventiell bearbetning som återställer ett visst beroende mellan angränsande utkaststoken så att acceptansen inte kollapsar i slutet av blocket, och en verifierare som förkortar verifieringsfönstret per begäran när utkastets egen konfidens tyder på att svansen kommer att avvisas.

Det Liquid gjorde var att tillämpa det receptet på visionsspråkmodeller och släppa en checkpoint. Kortet är uppriktigt om att den här överföringen är mindre dramatisk än den låter: från draftarens synvinkel spelar modaliteten ingen roll, för när tokenen når de dolda lagren är en bildpatch och en texttoken bara tensorer. Det är därför en teknik som utvecklats på textmodeller kan porteras till en VLM utan att uppfinnas på nytt – och det är också därför draftaren inte kan säljas som en ny förmåga.

Liquid hade redan släppt DSpark-drafters för text – kompanjonerna 2.6B, 8B-A1B och 1.2B-Instruct släpptes i augusti 2026, med GGUF-exporter som följde den 19 augusti. Vision-draftern är samma idé utvidgad till den multimodala grenen, och den fjärde eller femte posten i en serie, inte en debut.

Uppsnabbningssiffrorna, och vem som mätte dem

Alla siffror nedan är Liquids egna, insamlade på Liquids benchmarkinginfrastruktur, och ingen av dem har en oberoende reproduktion. Se dem som ett tak från leverantören, inte som ett förväntat resultat. Kortet skiljer på decode-acceleration och end-to-end-acceleration, vilket är viktigare än rubriken.

• Bästa snabbhetsökning vid avkodning — 3,13× på COCO, uppmätt med MLX-VLM på en Apple M5 Max vid blockstorlek 8, FP16, batchstorlek 1, temperatur 0

• Bästa GPU-avkodningsuppsnabbning – 2,66× på COCO, SGLang på en enda H100 80GB, BF16, blockstorlek 9

• Bästa snabbhetsökning för llama.cpp-avkodning — 2,14× på COCO, Apple M3 Ultra, blockstorlek 8

• H100-avkodningsintervall över sex vision-uppgifter — 2,04× till 2,66×, med end-to-end på 1,64× till 2,27×

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

• M3 Ultra-avkodningsintervall – 1,57× till 2,14×, ändå-till-ända 1,30× till 1,77×

• Acceptans av utkast – ungefär 3,2 till 4,5 accepterade tokens per målverifieringspass, på alla tre stackar

Mönstret i de intervallen är den ärliga delen. End-to-end-vinster är konsekvent den mindre hälften av varje par, eftersom draftern accelererar avkodningen och inget annat. Notera också att samma drafter vid samma blockstorlek hamnar på 3,13× på en stack och 1,57× på en annan – acceptansgraden är en egenskap hos draftern och arbetsbelastningen, men vinsten i väggklockstid är en egenskap hos hårdvaran och körtidens overhead. Ett ”2,66× snabbare”-påstående utan angiven stack är inte ett påstående du kan agera på.

Två korrekthetspunkter från kortet bör sägas rakt ut, eftersom de är det som gör en draftmodell acceptabel i produktion över huvud taget. Vid greedy-avkodning är spekulativ avkodning exakt: målmodellen verifierar varje föreslagen token, så texten är vad målmodellen skulle ha producerat. Vid matchade samplingsinställningar vid temperatur skild från noll bevarar den målmodellens utdatafördelning. Liquids formulering – du får snabbhetsvinsten, inte en annan modell – är korrekt så långt den räcker, och kortet är ärligt om att höjd temperatur sänker acceptansen och därför urholkar genomströmningsvinsten.

Vad Liquid själva medger i sitt inlägg

Blogginlägget den 24 september är mer användbart än modellkortet av en anledning: det pekar ut begränsningen. Vision-språkinferens betalar en prefill-kostnad som textinferens inte gör — bilden måste passera genom en visionskodare, och den språkliga basen måste sedan bearbeta de hundratals visuella tokens som kodaren producerar. På en enhet dominerar denna prefill den totala latensen. Spekulativ avkodning accelererar endast avkodningen. Visionkodning och prefill påverkas inte. Liquid åberopar Amdahls lag mot sin egen produkt och påpekar att när prefill står för en stor del av väggklockstiden ger en stor snabbhetsökning vid avkodning bara en blygsam förbättring av den totala prestandan.

Det är en reell begränsning för köpbeslutet, och det förklarar varför tid till första token inte finns med på listan över saker som den här draftmodellen förbättrar. Det innebär också att de arbetsbelastningar som har störst nytta är sådana som genererar långa utdata från en måttlig bild — en bildtext, en lång OCR-transkribering, ett samtal i flera turer med en bild som följer med — snarare än sådana som besvarar en kort fråga om en stor bild.

Inlägget tillför två ytterligare avgränsningar. Alla siffror använder 16-bitars bearbetning för både visionskodaren och språkryggraden, och accelerering av kvantiserade modeller ligger utanför omfattningen för den här utgåvan. Med tanke på att hela säljargumentet för en 3B edge-VLM är att den körs i ett par gigabyte, är "hastighetsökningarna mäts vid FP16" ett betydelsefullt förbehåll för alla som planerade att para ihop den med en 4-bitsexport. Liquid noterar också att draftmodellen tränades helt och hållet på AMD-hårdvara.

Kör det

Stöd från dag ett är verkligt och täcker tre körmiljöer, vilket är mer än vad de flesta draftmodeller får. SGLang på NVIDIA kräver v0.5.19 eller nyare och tar draftmodellen genom --speculative-algorithm DSPARK med draft-sökvägen och en blockstorlek på 9. MLX-VLM på Apple silicon kräver v0.7.2 eller nyare och upptäcker draftmodellen när den skickas med --draft-model; det finns en vass kant — DSpark-avkodning i MLX-VLM använder för närvarande girig sampling, så temperaturen måste sättas till 0. För llama.cpp finns ett separat GGUF-repositorium, med en enda F16-export på ungefär 567 MB, och modellkortet säger uttryckligen att du ska para den kvantiserade draftmodellen med den kvantiserade målmodellen snarare än med den ursprungliga safetensors-checkpointen.

Det är inte på den här modellen som ett routinglager förtjänar sin plats här – OrcaRouter routar inte LFM2.5-VL-3B-DSpark eller LFM2.5-VL-3B, och det här är en självhostad drafter-parning som du själv laddar ner och servar. Det är på resten av stacken runt omkring den. Samma applikation som kör en liten öppen vikt-visionmodell på enheten har vanligtvis en reservväg för de frågor som den lilla modellen inte klarar, och att peka den vägen mot en enda slutpunkt som täcker 200+ modeller – fakturerad till varje leverantörs listpris utan påslag, med automatisk redundansväxling när en leverantör försämras – är en mindre integration än att sätta upp ett andra leverantörsavtal. Draftern förbättrar en del av den arkitekturen; routern är det som hindrar den andra delen från att bli ett andra projekt.

Vad som ännu inte är känt

Repositoriet har 37 nedladdningar och 6 gillningar när detta skrivs. Det finns ingen post för denna draftmodell hos någon offentlig benchmark-aggregator, ingen tredjepartsreproduktion av något av intervallen för snabbhetsökning och ingen oberoende mätning av acceptansgraden på hårdvara som Liquid inte har testat. Det finns heller inga kvalitetsbenchmarks på modellkortet av uppenbara skäl – draftmodellen är utdatabevarande genom sin konstruktion, så kvalitetssiffrorna tillhör LFM2.5-VL-3B, och modellkortet hänvisar till den modellens benchmarks i stället för att hitta på egna.

En detalj i metadata är ett litet tecken på hur ny den här är: modellen har en SGLang-bibliotekstagg och en SGLang-algoritmflagga som finns specifikt för att anropa den. Ramverksstöd måste ha kommit på plats innan tillkännagivandet gjorde det, vilket stämmer med sexdagarsgapet mellan repositoriet och blogginlägget.

Ett genuint, användbart och snävt avgränsat ingenjörsarbete, tillkännagivet en vecka efter att det släppts, vars hela värdeerbjudande är ett leverantörsmätt tal på hårdvara du kanske inte äger. Om du kör LFM2.5-VL-3B på en H100 eller en Mac i M-serien och din arbetsbelastning är decode-tung, är minneskostnaden 8,9 % och nackdelen nära noll eftersom utdatan bevisligen är målmodellens. Om din latens domineras av prefill, eller om du räknade med 4-bitsexporten, säger Liquids eget inlägg att det inte kommer att hjälpa. Reproduktionen, när den kommer, är det man bör vänta på.

OrcaRouter placerar 200+ modeller bakom en enda nyckel till leverantörens listpris med 0 % påslag, och uttrycker reservvägen som ett routinglager snarare än applikationskod. Draftaren är självhostad oavsett - routern är det som hindrar delen som din lilla modell lämnar över till från att bli ett andra projekt.