LFM2.5-2.6B-DSpark: 328M-draftern som får Liquid's on-device-agent att köra 2,3× snabbare

Ingen utanför Liquid AI har kört LFM2.5-2.6B-DSpark på egen hårdvara och publicerat en siffra än. Det är den ärliga utgångspunkten för den här modellen, eftersom alltihop är ett prestandapåstående: det är inte en bättre 2.6B, det är en 328M-parameters förslagsmodell som sitter framför den 2.6B agentiska modellen LFM2.5-2.6B och föreslår token som den ska verifiera, så att agenten kör ungefär dubbelt så snabbt utan att ändra sitt utdata.

LFM2.5-2.6B-DSpark, som släpptes den 20 augusti 2026 med en teknisk genomgång på Hugging Face och ett kompletterande inlägg på Liquids egen blogg, är flaggskeppet i en liten familj av drafter-checkpoints för spekulativ avkodning som Liquid publicerade den dagen. Allt nedan i hastighetskolumnen är uppmätt av leverantören och ännu inte oberoende bekräftat; allt i repot, formaten och ramverksstödet finns helt enkelt där för att kontrolleras.

Vad DSpark är, i ett nötskal

Spekulativ avkodning är tricket att köra en billig utkastmodell före den riktiga: utkastmodellen gissar de nästa få token, målmodellen kontrollerar hela batchen i ett enda framåtpass och behåller de token som den håller med om. När gissningarna är rätt får du flera token för priset av en, så genomströmningen ökar utan att röra målmodellens vikter. DSpark – tekniken, som ursprungligen föreslogs av forskare vid DeepSeek i juli 2026 och redan används i DeepSeek-V4 – är en version av det tricket anpassad för små modeller på enheten. Liquid kallar det konfidensschemalagd spekulativ avkodning, och det har tre rörliga delar: en parallell ryggrad som producerar dolda tillstånd för alla utkast-token i ett enda pass, en lätt sekventiell head som modellerar beroendet mellan närliggande token så att acceptansgraden inte kollapsar sent i blocket, och en verifierare som beskär lågkonfidenssuffix när det skulle kosta mer att kontrollera dem än det sparar.

Den sista detaljen är det som får DSpark att kännas annorlunda jämfört med en vanlig utkastsmodell: den skickar inte alltid ett helt block genom verifiering. När utkastets egen säkerhet säger att ett suffix sannolikt inte kommer att accepteras, kortar den av blocket och sparar det bortkastade beräkningsarbetet. Utkastsblocket består av nio tokens, så målmodellen verifierar upp till tio åt gången.

Ritaren, i siffror

LFM2.5-2.6B-DSpark-checkpunkten är en draftmodell med 0,3 miljarder parametrar som enbart använder attention: fem fullständiga attention-lager (dold storlek 2 048, grouped-query attention med 32 huvuden och 8 key-value-huvuden), ett ordförråd på 128K tokens, ett Markov-huvud med rang 256 och ett konfidenshuvud. Liquid tränade den i 15 epoker på en blandning av instruktions-, konversations-, kod- och funktionsanropsdata — på AMD-hårdvara — och valde epoken utifrån högsta acceptansgrad snarare än lägsta förlust.

Den acceptanstakten är siffran som avgör hur mycket utkastaren är värd. Över fem riktmärken med batchstorlek 1 och temperatur 0 uppnådde LFM2.5-2.6B-DSpark i genomsnitt 4,83 accepterade token per avkodningssteg på en H100 och 4,42 på en M4 Max — ungefär hälften av blocket accepterades, vilket är där de tvåfaldiga hastighetsökningarna kommer ifrån.

Snabbningarna, märkta

Alla följande siffror kommer från Liquid AIs egna mätningar — SGLang på en enda H100 80GB i BF16, och llama.cpp med Metal-backend på en M4 Max MacBook Pro i FP16 GGUF, batchstorlek 1, temperatur 0 — och ingen av dem har oberoende reproducerats i skrivande stund:

• H100 genomsnitt — 2,67×, från 323 till 864 tokens/s. Per benchmark: MATH500 3,06×, HumanEval 2,56×, MBPP 2,64×, GSM8K 2,22×, MT-Bench 2,87×.

• M4 Max-genomsnitt — 2,27×, från 61 till 139 tokens/s. Per benchmark: MATH500 2,25×, HumanEval 2,63×, MBPP 2,11×, GSM8K 2,36×, MT-Bench 1,99×.

• Verktygsanrop — i scenarier med funktionsanrop för flera verktyg sjönk den genomsnittliga latensen med 57%.

• Familjekontext — den största draftern i familjen, LFM2.5-8B-A1B-DSpark, nådde upp till 3,18× på H100 och 1,2B-draftern upp till 2,87× på M4 Max; 2,6B-siffrorna ovan är i mitten av fältet.

Två saker om dessa siffror är viktiga utöver genomsnitten. För det första mäts de vid temperatur 0 och batchstorlek 1 – den konfiguration som gynnar spekulation och den konfiguration som interaktivt agentarbete på enheten mestadels är. Identitetsgarantin gäller även där: spekulativ avkodning verifierar varje föreslagen token, så under girig avkodning är den producerade texten exakt vad målet skulle ha genererat på egen hand. För det andra minskar gapet när samtidigheten ökar: på en enda H100 rapporterar Liquid att DSpark:s fördel konvergerar runt batchstorlek 128, så utkastaren är en latensvinst för interaktiva och verktygstunga arbetsbelastningar, inte en silverkula för rå genomströmning på en maxad server.

Vad är bekräftat, och vad är inte

Bekräftat, i den meningen att repot är offentligt och kontrollerbart: utkastaren levereras som Safetensors (BF16) och GGUF; den paras ihop med den eftertränade LFM2.5-2.6B, inte med basmodellen; stöd från dag ett hamnade upstream i llama.cpp (med experimentella Metal-kärnor) och i SGLang; den är licensierad under Liquid's LFM Open License v1.0; och — viktigt för alla som planerar kring den — modellkortet anger att ingen inferensleverantör betjänar den, så detta är en kör-det-själv-komponent.

Ännu inte bekräftat: att snabbningarna reproduceras på annan hårdvara och andra konfigurationer (ingen utanför Liquid har publicerat en mätning), hur utkastaren beter sig vid sampling snarare än girig avkodning, och huruvida siffran på 57 % för verktygsanropslatens håller streck i riktiga agentramverk utöver det benchmarkramverk Liquid använde. Inget av detta är anklagelser — releasen är en dag gammal — men det är skillnaden mellan en lovande siffra och en verifierad sådan.

Kör det

I SGLang använder du en build med DSpark-stöd, startar servern mot målmodellen och anger draftmodellen: den spekulativa algoritmen är DSPARK, draftmodellens sökväg pekar på LiquidAI/LFM2.5-2.6B-DSpark, och blockstorleken läses från draftmodellens config.json. I llama.cpp laddar du mål-GGUF-filen med draft-GGUF-filen som draftmodell och ställer in spec-typen till draft-dspark, med blockstorleken läst från sidecar-metadatan. Båda integrationerna är uppströms, så inga forks behövs — bara en build som är tillräckligt ny för att innehålla dem.

När det är värt att lägga till

LFM2.5-2.6B-DSpark motiverar sina cirka 0,3 GB extra minne när du faktiskt distribuerar 2.6B-agenten där Liquid designade den att leva – på en telefon, en bärbar dator eller en edge-box – för interaktiva eller verktygsanropsbaserade arbetsbelastningar som är latensbundna och körs med greedy-avkodning. Det är just den profilen där den 2,27× snabbningsfaktorn på enheten och den 57-procentiga sänkningen av verktygsanropslatensen gör jobbet. Det är mindre intressant om du serverar med hög batchstorlek på en server (snabbningen konvergerar mot 1×), eller om din arbetsbelastning körs med temperatur över noll, där de rapporterade siffrorna inte längre gäller. Och om du använder 8B-A1B-varianten av familjen, notera specialfallet: dess snabbningsfaktor på enheten är bara cirka 1,18× i dag, eftersom verifiering av draft-tokens aktiverar fler experter i llama.cpp:s Metal-backend – Liquid flaggar detta som känt.

Ingenting med DSpark ändrar var 2.6B-agenten körs – det är designat för självhostning, och den kommer att ligga sida vid sida med de hostade modeller du redan anropar. Den blandningen av en lokal drafter och ett dussin API-slutpunkter är precis den typ av infrastruktur som ett routinglager är till för att hantera: en API-nyckel över 200+ modeller, automatisk failover när en leverantör försämras, och leverantörernas listpriser som förmedlas med 0% påslag, så att kostnadsjämförelsen mellan lokalt och hostat för en 2.6B-klassagent förblir tydlig istället för att leva i ett kalkylblad.

Det rätta sättet att läsa LFM2.5-2.6B-DSpark idag är som ett lovande, leverantörsuppmätt, ännu inte oberoende hastighetspåstående kopplat till en verklig, nedladdningsbar, körbar checkpoint. Om du distribuerar 2.6B-agenten på enheten är draftern billig att prova och lätt att ta bort — lägg till de två spekulativa flaggorna i SGLang-kommandot, behåll girig avkodning och mät mot din egen arbetsbelastning innan du litar på 2,3×. Repot finns där; den oberoende verifieringen är den öppna punkten.