Liquid AI zrychlil lokální AI až 3,2×. LFM2.5-DSpark míří na počítače i servery

Na první pohled jde o další model s dlouhým názvem, který si člověk snadno splete s označením pračky. Ve skutečnosti ale LFM2.5-DSpark není samostatný chatbot. Je to pomocný model neboli drafter, který spolupracuje s hlavním modelem LFM2.5 a navrhuje mu několik tokenů dopředu. Cílem je zkrátit dobu generování a současně zachovat výstup, který by vytvořil samotný cílový model.

Liquid AI novinku oficiálně vydal 20. srpna 2026 prostřednictvím technického článku na Hugging Face. Dostupné jsou checkpointy pro tři modely: LFM2.5-1.2B-Instruct, LFM2.5-2.6B a LFM2.5-8B-A1B. Váhy jsou zveřejněné ve formátech Safetensors i GGUF, takže s nimi mohou pracovat například nástroje llama.cpp a SGLang.

Proč vůbec jazykové modely čekají na paměť

Generování odpovědi jazykovým modelem není jen otázkou výpočetního výkonu. Při každém dalším tokenu musí systém znovu pracovat s velkým množstvím parametrů modelu. V praxi proto často naráží spíše na rychlost přesunu dat z paměti než na samotný počet výpočetních operací.

Je to podobné jako práce ve skladu. Velký model má všechny potřebné součástky, ale při každém kroku musí skladník znovu dojít pro další krabici. Spekulativní dekódování vyšle dopředu menšího pomocníka, který připraví několik pravděpodobných krabic najednou. Velký model pak nemusí kontrolovat každou položku samostatně, ale ověří celý připravený blok v jediném průchodu.

Pokud drafter navrhne tokeny správně, cílový model je přijme. Pokud se některý návrh neshoduje s jeho distribucí, cílový model ho odmítne a použije vlastní token. Při takzvaném greedy dekódování je proto výsledná sekvence podle popisu Liquid AI shodná s běžným generováním cílového modelu. Zrychlení tedy nemá vznikat tím, že by systém používal méně přesný model, ale efektivnějším způsobem práce.

DSpark přidává jen malého pomocníka

Každý z pomocných modelů má přibližně 300 milionů parametrů. U varianty pro LFM2.5-2.6B jde přesně o 327,7 milionu parametrů, u LFM2.5-1.2B-Instruct má drafter 295,7 milionu parametrů. V porovnání s cílovým modelem je to relativně malá přirážka, která ale stále znamená vyšší nároky na paměť.

Architektura DSpark kombinuje tři části. První je paralelní základ inspirovaný přístupem DFlash, který připravuje skryté reprezentace pro několik tokenů v jediném průchodu. Druhou částí je lehká sekvenční hlava založená na vztazích mezi sousedními tokeny. Ta má zvýšit šanci, že budou přijaty i pozdější tokeny v připraveném bloku. Třetí částí je ověřovač řízený mírou důvěry, který zahodí málo slibné pokračování dříve, než by jeho kontrola stála více času, než kolik může ušetřit.

DSpark používá blok o velikosti devět tokenů. Neznamená to, že model vždy vygeneruje přesně devět tokenů najednou. Cílový model každý návrh ověřuje a podle výsledku přijme celý blok, jeho část, nebo žádný z navržených tokenů.

Nejlepší výsledek: 1 362 tokenů za sekundu

Liquid AI testoval modely na jednom akcelerátoru NVIDIA H100 80 GB prostřednictvím SGLang a také na MacBooku Pro s čipem M4 Max přes Metal a llama.cpp. Testy probíhaly při batch size 1, teplotě 0 a s maximálně 256 výstupními tokeny. Výsledky proto nelze automaticky přenést na každý počítač nebo každý typ úlohy.

U modelu LFM2.5-2.6B vzrostla průměrná rychlost na H100 z 323 na 864 tokenů za sekundu. To odpovídá zrychlení 2,67×. Na MacBooku Pro s M4 Max se průměr zvýšil z 61 na 139 tokenů za sekundu, tedy 2,27×.

Jednotlivé benchmarky se lišily. V testu MATH500 dosáhl model na H100 rychlosti 1 000 tokenů za sekundu oproti původním 326 tokenům za sekundu. V HumanEval šlo o nárůst z 326 na 835 tokenů za sekundu. Na MacBooku byl nejvyšší výsledek u HumanEval, kde rychlost vzrostla z 61 na 161 tokenů za sekundu.

Nejvyšší naměřené zrychlení nabídla varianta LFM2.5-8B-A1B. V testu MATH500 se rychlost na H100 zvýšila z 428 na 1 362 tokenů za sekundu, což představuje násobek 3,18×. Průměr této varianty činil 2,54× na H100. Na Apple Silicon byl ale efekt podstatně slabší: průměrné zrychlení dosáhlo jen 1,18×.

Důvodem je podle Liquid AI současná implementace Mixture of Experts v Metal backendu llama.cpp. Při ověřování více tokenů se aktivuje více expertů a tím roste objem přesouvaných vah. U MoE modelů tedy větší počet parametrů automaticky neznamená lepší výsledek spekulativního dekódování.

Agenti mohou reagovat rychleji

Zajímavý je dopad na funkční volání. Agentní systém při něm nevrací pouze text, ale například rozhodne, že má zavolat kalendář, databázi nebo jiný nástroj. Každý takový krok přidává latenci. U LFM2.5-2.6B Liquid AI uvádí průměrné snížení latence při function-callingu o 57 procent v různých scénářích s více nástroji.

Právě tady může být rychlejší lokální model praktičtější než prosté honění maximálního počtu tokenů za sekundu. U běžné odpovědi si člověk rozdílu mezi 100 a 140 tokeny za sekundu nemusí všimnout. U agenta, který musí několikrát za sebou vyhodnotit situaci, zavolat nástroj a pokračovat, se ale každé zkrácení čekání násobí.

Co to znamená pro české uživatele a firmy

Modely jsou k dispozici ke stažení z Hugging Face ve formátu Safetensors a také jako GGUF pro llama.cpp. To znamená, že je lze provozovat lokálně na podporovaném hardwaru bez povinného volání cloudového API. Pro české vývojáře je podstatná také podpora Windows, macOS a Linuxu v používaných nástrojích, nikoli speciální regionální dostupnost.

Česká lokalizace ani garantovaná kvalita češtiny nejsou v oznámení Liquid AI výslovně uvedeny. Model proto nelze bez vlastního testování označit za plnohodnotně optimalizovaný pro český jazyk. Pro vývojáře, kteří chtějí provozovat AI v domácí síti, na pracovních stanicích nebo v edge zařízeních, je ale důležitá možnost lokálního běhu a práce s otevřenými váhami.

Podle dostupných informací je použití modelů bezplatné pro společnosti s ročními příjmy do 10 milionů dolarů. Je však nutné řídit se konkrétními licenčními podmínkami daného modelu. Lokální provoz navíc není úplně zdarma: je třeba počítat s hardwarem, elektřinou, správou modelu a časem potřebným k integraci.

Pro domácího uživatele nebude DSpark fungovat jako samostatná aplikace typu ChatGPT. Je potřeba spárovat drafter s odpovídajícím cílovým modelem a použít podporovaný backend. Modelová karta například uvádí, že GGUF drafter je pouze pomocný soubor a při běhu sdílí tokenové embeddingy a výstupní hlavu s cílovým modelem.

Srovnání s GPT, Gemini a Claude má háček

Liquid AI zveřejnil hlavně měření rychlosti inference, nikoli přímé srovnání kvality nebo ceny s konkrétními cloudovými modely GPT, Gemini a Claude. Takové srovnání by navíc nebylo úplně férové: testy probíhaly na konkrétním H100 a M4 Max, při batch size 1 a greedy dekódování.

Čísla proto ukazují především to, co DSpark přidává k vlastnímu modelu LFM2.5. Neříkají, že LFM2.5 je kvalitnější než současné špičkové cloudové modely, ani že bude rychlejší v každé aplikaci. Říkají něco praktičtějšího: pokud už někdo chce provozovat LFM2.5 lokálně nebo na serveru, může díky pomocnému modelu výrazně snížit dobu generování bez změny cílového výstupu.

Verdikt: méně čekání, ale ne kouzelná nálepka

LFM2.5-DSpark je zajímavý hlavně jako optimalizace běhu, nikoli jako nový samostatný jazykový model. Největší smysl dává vývojářům, kteří řeší latenci, lokální provoz a agentní workflow. Na H100 jsou výsledky velmi výrazné, u modelu LFM2.5-2.6B je zrychlení dobře vidět i na Apple Silicon.

Současně je nutné vnímat limity. Výkon závisí na typu textu, akceptační míře návrhů, backendu, kvantizaci i konkrétním hardwaru. U LFM2.5-8B-A1B je rozdíl mezi H100 a MacBookem přímo učebnicový. Spekulativní dekódování tedy není univerzální turbo tlačítko. Je to spíše dobře navržená převodovka: na správném stroji a ve správné situaci dokáže stejný motor využít výrazně efektivněji.

Technické podrobnosti, checkpointy a postup instalace zveřejnila Liquid AI v původním oznámení. Princip DSpark popisuje také výzkumný článek na Hugging Face Papers a integrace jsou dostupné v projektech llama.cpp a SGLang.

FAQ